Some Emacs maintainers started emacsorphanage, a git org for managing Emacs packages that are not maintained. The idea is that instead of archiving your source repo, you can transfer it to them, and they will do very basic upkeep, and also transfer it to a new maintainer if one shows up.
I am wondering a similar idea would make sense for Julia. A lot of packages in our ecosystem are “community maintained” after the original maintainer stepped down, and I have commit rights for a some of them. However, I feel uncomfortable signing off on major (breaking) changes, even if a package would clearly benefit from them.
A more formalized process might make this smoother. It would me it clear what someone who no longer wants to maintaine a widely used package should do. Also, if all orphaned Julia packages were in the same organization, anyone with commit rights would be able to dust off Github actions scripts or make similar trivial but sweeping changes with a script. We could have a policy about which Julia versions remain supported, coding standards, and most importantly, a path for new maintainers to step up and eventually get control of a package.
I don’t have very clear idea about the details, I am hoping that the discussion would clarify them.
I’ve had the same thought, and the result of that (and chatting with a few other people) is Julia Orphanage · GitHub. I’m pretty confident guessing most people (including those who would have use for it) aren’t aware of it at the moment though.
One of the things that makes the Julia community amazing is that most of the time I find a problem, it already has a solution.
If you are OK with it, the next step would be advertising this option mode widely. I am not marking your answer as a solution yet to encourage more discussion about this.
The current form of the Julia Orphanage org is just based on my ideas and the initial chat I had with Stefan and a few others about it. I think it would be great to discuss the approach taken with a wider audience, and promote it more widely!
I think it would be great to clarify what happens to packages in the orphanage. Only bug fixes? Or are minor feature additions OK?
Also, some guidelines about taking over a package and a few words about the process. Ideally, anyone who is willing to to the work should be able to chip in, but at the same time allowing total newcomers to take over an established package may be a security risk.
I think, there could be two ways to transfer a package to the orphanage. One - on the authors wish, that’s easy. Another one - the package just abandoned, author not responding at all, for whatever the reason, maybe dead (to the actuaries among us - what could the percentage of the authors of the 12000+ packages, which are dead by now?).
I’d suggest to ask at package registration for some statement concerning transferring the package into orphanage. E.g. author agrees in case they do not respond for like 1/2 - 1 - 2 years, the package can be transferred to the orphanage. The author could also provide some private ways to be contacted. In the case of no such agreement, a package could still be taken over, providing the license allows, if there is sufficient general interest.
Could it be different support levels for different packages depending on availability of maintainers and package importance?
I am wondering if we could just make it easier to fork packages. Someone who wants to step up to maintain an abandonned package could just announce that Y is now the continuation of X. That’s what it would really take, users should then opt in. It feels icky to take away package names forcefully from people, and we don’t really need it.
By a similar argument, I would prefer all transfers to the orphanage to be entirely voluntary. That’s how the Emacs orphanage works BTW. It should be primarily a service that well-meaning people could use, instead of some kind of package police.
I realize that I was initially overthinking formalizing this. I think that maintenance should be whatever the curators of the orphanage want to do, or have resources/time for.
I also think that once something ends up in the package orphanage, it should stay there, at least 90% of the time, as that is the cleanest solution. People can always fork and change the name.
In any case, I think that we can get the package orphanage rolling with the tooling we have at the moment. People should be able to volunteer to contribute as maintainers, and also open issues at various packages encouraging a transfer.
The problem is who declares a package is abandoned? If anyone could declare a package is abandoned and immediately take it over, that’d be an utter disaster.
Sorry if what I was proposing wasn’t clear. No, the idea is not to reallocate existing package names to other people, just to make it easier to fork under a new name.
Note that it is already easy to fork under a new name when permitted by the license. It just isn’t done, perhaps because of social norms; people are reluctant to do it.
But that’s orthogonal to the idea of a package orphanage, which be able to receive voluntary transfers of packages. That would be the cleanest way.
