Distribute authority for your package. Build package teams.

Rust people had a similar discussion a few years back when crates.io was starting to get a lot of derelict packages. Keeping individual authority over a hosted repo is generally bad for its health and the ecosystem health. ### Add someone to your Github repo Settings → Collaborators & Teams → Add people / teams If you don't have someone in mind, look for someone or some team who maintains other packages that you use and ask them if they are too busy. If you trust them in your software delivery pipeline already because you're using their packages, you might as well trust them to not accept junk into your package. I'm adopting software lately under the Positron org, so even get a hold of me and we can make an Emacs-specific team exactly this kind of redundancy. There's two big reason to do this. First, more often than not, a repo with an individual authority will become an unintentional name-squatter soaking up Google traffic, filling up with forks in its network but nothing going into the original repo. It is a local black hole for ecosystem momentum. Second, you will inadvertently build teams. Instead of the unwanted pressure of being a solo maintainer, you will have the mutual encouragement from the assurance that the project is going to live, not just sit there, even if you want to take a break. When you neglect a package, the contributions still arrive, but they show up in forks in your Github network graph. **People are making changes, but they aren't bothering to PR because they don't think anyone is listening**, so they're all just pushing changes _just in case._ Go check your network for commits in other forks. See if your package is still the branch leader. Dust off the PR's and make sure not to look abandoned. Comment on fork commits. If you want to abandon a project, add it to an organization or add some people to the admin roles. Let people know to go elsewhere for PR's and questions. Tell someone else how your package works.

No thanks. People are free to fork things as they wish.

There's literally no point in doing it when someone can just fork the repository and take over the maintenance. This recently happened with pdf-tools: Vedang did a fantastic job at taking over the maintenance. Same happened with EXWM too if I'm not mistaken. Besides, who cares about the state of maintenance as long as it still works?

My recommendation would be to put your packages into GNU ELPA, and then other Emacs/ELPA developers still have the ability to implement fixes if the original maintainers are unable to do so any longer.

People are still free to fork as they wish, even with shared maintaince. One does not exclude the other. On contrary, it wasn't about making people not forking, but about giving PRs and contributing back fixes and improvements.

I don't agree with the premise of their argument. The onus isn't on the package author to ensure that something they wrote "lives on" beyond them. That's on the people interested in the software. In fact, I'd say a good number of programs should die and others should learn from their mistakes when writing new programs to replace them. Forks are a nice middle ground between the two that do not require or assume cooperation between authors.

I would only recommend this in cases where the authors vision of the package aligns with the goals of the GNU project and the author is willing to pay the overhead of communicating changes through that project (endless email bike-shedding being one cost).

Sure, I understand and agree with your opinion, to a degree. Some programs do not deserve to live further. ut not all programs should die when their authors leave the scene, for whatever reason it might be. It is also not always clear if and when the author has left. Might take a while efore people realize it. Take EXWM as an example. The situation can also result in several different forks leading to independent pockets of development and possible rewrites that unnecessary duplicate work already done by someone else, which is a waste of human resource for no good reason.

> where the authors vision of the package aligns with the goals of the GNU project For sure. > endless email bike-shedding I think that's pretty unfair. I've seen plenty of bike-shedding over the years of course, but mostly regarding Emacs features. I don't think that too many GNU ELPA packages incur much discussion at all. YMMV though, and I'm not discounting experiences you might have had, but I certainly haven't observed any pattern of such behaviour regarding ELPA contributions.

https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00471.html

True. I still don't believe it's a general pattern, but that's definitely a fair example.