Software is the infrastructure that powers our digital society. And most of this software is either Open Source Software (OSS) or heavily relies on it. And while this is great news in many ways, it’s also a huge problem, given that most open source projects face serious sustainability issues that riks them being abandoned. Like many other “public domain goods”, open source suffers from what it is known as the “tragedy of the commons”: everybody wants to benefit from the software but they all hope others will chip in. That is, there is a grossly disproportionate imbalance between those consuming the software and those participating in building the software.
There are several ways to mitigate the risk of abandonment of open source projects:
- Follow strategies to get the community at large (i.e. not only the maintainers but also the users) more involved in the project.
- Employ a swarm of software bots to assist in the project monitoring and maintenance. Simple bots will take care of janitorial tasks (e.g. assigning labels to new issues). Smart bots will learn from the project data to become highly qualified assistants (e.g. able to chat with users to make sure bug reports are detailed enough and automatically triage them).
- Get more funding to be able to pay the maintainers (see, for instance, the $1m to pay open source maintainers announcement by Tidelift).
but there is just so much bots are able to do today (see our updated list of the best bots to improve your software development process), money is not always the reason why people stay/leave in open source and even those projects that follow a governance model somehow democratic (not many by the way) still require a group of leaders or “champions” bringing a lot of the intangible value that really keeps the project moving. For some projects, these above strategies are just very partial solutions and they may still be inclined to give up.
So what to do when nothing else works? The best option is to put the open source project up for adoption. Making this explicit has two major benefits:
- It clarifies the owners of the project are looking for somebody to take over and will be happy to help in the transition (in contrast with a hard fork of the project, that technically-speaking may have the same result but that will confuse and break community around the project). Owners could use a special tag, a keyword in the name or project description of some kind of badge.
- It helps to search for orphan projects so potential “foster maintainers” can easily find potential projects to adopt.
This is not a new idea. In WordPress, the tag adopt-me is used to signal plugins looking for a new owner. Similarly, Jenkins employs the adopt-this-plugin label. The npm graveyard is a resting place for unmaintained npm packages, up for adoption.
Unfortunately, this is more the exception than the rule. We need this initiative to be followed by other communities. And it would be even more important to understand whether this actually works well for both sides. I mean, I believe in this idea but research needs to be done to draw some scientific conclusions on the percentage of projects that are actually successfully transferred and manage to survive with their new “parents”.
We would probably need also a more proactive way to detect projects at risk and, for those, have in place a procedure to start a conversation with the owners to convince them to put them up for adoption, instead of just relying on project owners to come up to this conclusion by themselves. This process should also include some guidelines on how to perform the transfer of ownership (including any copyright, IP or other legal issues if necessary), these 10 rules for handing over a project would be a good start.
What are your thoughts on this? Would you consider adopting a project?