In-reply-to » 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.

⤋ Read More