I was musing today about how to solve the problem of projects going stale on
github. It really is an annoying problem if you depend on a project where the main maintainers go absent without passing the project on to someone else. The project becomes trapped and dead. Usually (and rightfully), only the maintainers can push releases that can be used by a wider community. But that means if you’re depending on a ruby gem or an npm package or a java jar or any other build artifact on an official channel, you’re out luck because the release artifacts are no longer updated once the maintainers go absent. People can submit pull requests, but with no maintainers to accept them, the source code goes stale too. Though you can grab the pull release(s), the merge process often requires project-specific knowledge that has gone absent with the maintainers.
One approach to this problem that does work is to have a large stable of maintainers, which reduces the probability that all maintainers go absent simultaneously. Most projects don’t have that, though.
So it would seem that having a way of transferring control of a project from absent maintainers to aspiring active maintainers would be very nice to have. You don’t want that control to pass into the hands of some arbitrary person. But, let’s say there are people who are not currently maintainers issuing pull requests; and there are users submitting issues. You could imagine a mechanism whereby the pull request issuers can be “promoted” by community consent, where the community is the people submitting issues and other pull requests, plus anyone else who wants to be involved perhaps.
There are obviously dangers, but I don’t think they are meaningfully different from the dangers that already exist in the
github model of software development. Maybe I’ve overlooked something important though.
@firstname.lastname@example.org Not really an answer to your question, but I usually try to reduce the number of dependencies to a bare minimum in the first place. Of course this doesn’t always work out perfectly. If something becomes unmaintained there’s always the possibility to fork myself to either keep it at this version or maintain it a bit. Eventually, I probably move on to something else, though.
@email@example.com so, you don’t depend on libc, and you write device drivers from scratch for every project?
@firstname.lastname@example.org Exactly! What’s wrong with that? :-D