Thanks a lot for pointing this out @heliosdrm . I’ll try to add my side, although there isn’t much more to add other than what you said. I’ll try to outline how the JuliaDynamics story became a successful story. In principle I think I can summarize my though process in trying to make JuliaDynamics a “successful” org (even though this is totally subjective), in the following points:
- As you pointed out, someone (or a group of people) should have a drive (and willfulness to spend some extra time) to bring a high-quality organization for a specific “genre” into Julia. This group will help the org by coordinating things. My “genre” was dynamical systems and nonlinear dynamics and for JuliaDynamics I do most of the coordination.
- Documentations are extremely important and they attract users as well as developers to join the org. Everyone involved, should be spending time building quality documentation: for the community, a high-quality documented functionality is better than just having one more function implemented.
- Avoid redundancy and duplication: as pointed out in the very first post of this thread, there are dozens of packages that do similar things. To this, a community should collectively say “NO”. There should as little as possible packages, the best, that do all (or most) things the best way and just work flawlessly with each other (this is exactly what happens in JuliaDynamics e.g.). As @heliosdrm pointed out, this was yet one more benefit of joining the org: we compared the same features we had in two different packages, and kept the best implementations. I am very aware of how “wrong” this statement sounds to many here as the claim is that “this is not how open source works, everyone makes what they want”, etc. Well, in my eyes the best thing for a language is to have the MINIMUM AMOUNT of packages that are the BEST in what they do, while REUSING as much code as possible. Its up the community of the genre under discussion to think about what they want…
- The members of this org should actively “scout” relevant packages, and invite people to join. Having things together in an org is better for the community. And when you do find and invite some package, be good about it: help them join, help them get better documentation, help them get better code, help them get hooked up into the ecosystem. I think this was a really successful thing with RecurrenceAnalysis.jl and Agents.jl where I believe both packages saw both real code improvements, but also increase in popularity, after they joined. But @heliosdrm and @Ali_Vahdati should say for themselves, they were the original owners.
- An important thing that only recently I’ve come to realize, that is necessary for packages to join an organization and improve themselves and the organization is the following: developers should care more about getting a better ecosystem for Julia, than having their “name as the name of the owner of a package”. (You might think that this point is “ridiculous”, yet I claim that it is one of the driving reasons that there are 2 dozen packages that do the same thing)
Ultimately, and this has been discussed in this post many times, this takes not only time, but also willingness to collaborate and also drop parts of your “status” regarding a repo. It is up to the community at hand whether there is someone that is willing to spend some extra time or not.
As far as my life goes, I can say it is totally worth it to spend extra time trying to coordinate JuliaDynamics: everyone involved, including myself, just becomes happier because things improve collectively and collaboratively, and that is just cool!