Only because it has Bio in the name, I wonder if it would make sense to join up with BioJulia. It doesn’t look like there be much overlap in code or users, so it might not make any sense, but I thought I’d mention it. The package is modular enough that there’s no need to install anything you don’t need to get what you do need, and it might be nice to have everything from ecosystems to atoms pointed at from the same place.
I took a look through theBioJulia page, and I am not sure if there is much overlap as you said.This page seems to be closer although I don’t think that is the same as an organization?
No, that’s not the same as an organisation, but you may want to ask (via a PR) to have your package listed there. Note that I have an open PR to move the remaining ecology packages to biology (just to keep ecology consolidated - it’s tricky because the conventional split between Earth and Life sciences is meaningless).
It seems to me that the BioJulia organisation focuses almost exclusively on molecular biology. We have a more recent org for whole-organism ecology (https://github.com/EcoJulia/) where this might fit better (but still not perfectly).
The focus of biojulia is currently molecular biology, though I think that’s only because those involved are predominantly molecular biologists. No reason it has to stay that way IMO. there’s already a ton of stuff in there I’ll never use, but the new modularization push makes it much more lightweight, so I can just install the things I need.
I for one would love to include ecology stuff in the same place, since a number of methods overlap with my work (on microbial communities).
One thing to keep in mind with organizations is searchability. @Datseris mentioned the other day that the reason he likes orgs is because it helps you find and trust packages. I agree with that to a large extent: for statistics packages I know JuliaStats does well so I go straight there and generally (sometimes implicitly, sometimes explicitly) packages which are just some random dude’s repo to be “less trustworthy”, or at least less maintained and tested. Whether that’s the case or not, I think he made a good point that it makes sense to consolidate to organizations for more than just for permissions access and helping code-reuse, but also to grow a community.
Note that other relevant repos which should enter the conversion can be found here: https://github.com/PoisotLab
Yeah, @tpoisot is an owner of EcoJulia too, and the EcoJulia package ecosystem will interface with those - PoisotLab is a pretty strong brand in Ecology.
I also agree that the organizations are a key to the positive way Julia is developing - as also discussed here: Why I contribute more to Julia
And agreed @kevbonham , the more we can integrate the interfaces of our packages to generate a coherent ecosystem, the stronger julia will become as a platform for our science, and we should definitely communicate to ensure interoperability. I don’t see necessarily that everything related to living organisms should be confined to a single organisation, in fact I don’t think that would be the best for development. I know BioJulia quite well and there’s almost nothing in there that would be used directly in what we’re developing at EcoJulia (with the exception of phylogenetics). On the other hand, a lot of ecology is spatial, and so a lot will be explicitly based on the packages developed over at JuliaGeo.
But organisations that work together to create a coherent system of connected packages and to safeguard a high consistent level of quality - and that communicate with other organisations to facilitate things like your cross-disciplinary work on micro-organisms - that’s the best model for Julia’s development IMHO.
But organisations that work together to create a coherent system of connected packages and to safeguard a high consistent level of quality - and that communicate with other organisations to facilitate things like your cross-disciplinary work on micro-organisms - that’s the best model for Julia’s development IMHO.
This makes sense too. I suppose I’ll just need to keep abreast of changes in EcoJulia too. Perhaps to address @ChrisRackauckas’s point about findability - it might be worth linking from each org somewhere. If someone stumbles on Biojulia’s phylogenies package while doing ecology, it might be worth having a line in the docs saying “you might also find EcoJulia useful.”
I also think that BioJulia focuses on the molecular work – which is fine. Including more organismal/ecological packages would maybe make the organisation too heterogeneous. And there will be interactions between EcoJulia and BioJulia (mostly for phylogenetics) in any case.