I am happy to announce Adoptoposs.org, an open source app that connects open source software maintainers with people who want to help keep projects and maintainers healthy in the long term.

Adoptoposs offers a platform to put your open source projects up for adoption and make initial contact with potential co-maintainers.

The source code is available on GitHub:

If you’d like to learn more about the reasons why I built Adoptoposs, the problem of unmaintained open source software, and what might be part of the solution, then read on.

---

Open source software (OSS) incontrovertibly runs our world. Enterprise open source is considered to continue to grow in 2020. Most of the internet is running on open source software and millions of developers build and maintain hundreds of thousands of open source software packages in more than 250 programming languages these days.

---

The Problem of Unmaintained OSS Projects

Whereas most developers use and contribute to open source software at work, the maintenance of a great amount of OSS projects is done by volunteers in their spare time.

Many projects grow out of a personal side-project into popular and widely used libraries. With a lot of attraction, more issues and pull requests are opened by the community. A maintainer’s growing responsibility is now to orchestrate incoming requests and changes, and steer the whole project.

There are loads of stories about the challenges and struggles of OSS maintainers. They include emotionally exhausting community management and the great effort that has to be put into triaging of issues and pull requests.

When hearing these stories of mostly voluntary efforts, it’s no surprise that maintainers feel overwhelmed by the amount of work and turn their back on their projects.

Reasons for dedicating less time to or even leaving an open source project are many. Maintainers leave their company or lose interest. Changes in their personal lives give them less time to take care of the project or they stop their activities in the open source scene entirely because of burnout or illness. In the worst case, they have passed away.

All these cases are leaving behind projects that often have no one but the original author with administration rights or access to the publishing accounts.

Bug reports stack up, pull requests don’t get merged, compatibility issues with the surrounding ecosystem emerge. Then, at some point, someone in the community steps up and opens the infamous “Is this project abandoned?” Issue.

Eventually, the project might be forked and fixes are being made by new volunteers from the community. New versions of the project are published under a new name because of lacking publishing access.

All this leads to confusion about the state of the project and whether it can and should still be used and considered as a stable piece of software.

---

So, What’s the Solution?

Simply put, each and every open source project of considerable popularity should have a team of maintainers.

What does “considerable popularity” mean? When do you know your project is an important dependency for others? You will probably know really soon by its download rates and the popularity of its direct dependents.

However, if it already gained popularity and you are still operating the project on a single-maintainer policy then maintenance issues are likely to loom on the horizon sooner rather than later.

Having a team of multiple maintainers, however, is likely to result in a better-maintained project for several good reasons.

1. The workload can be split up between all maintainers

Every one of us has different preferences on what to work on, different interests, and skills. And probably none of us is highly skilled and interested in working on all the tasks that open source maintenance demands.

Thus, it makes sense to build a team and split up the entire workload to let every maintainer work on the part they like and can do best.

Less workload will also mean less risk to burn out and will allow maintainers to better look after themselves. Just like what teams in a company are built for.

2. It’s easier to make decisions as a team

Not only does it take the pressure off every maintainer when decisions have to be made. It also potentially leads to more stability and more informed decisions.

Different points of view are taken into account by default. As the old saying goes: “A fresh pair of eyes prevents many bugs’ rise.”

3. There will be no single point of failure

In our daily lives of software development, we aim at reaching availability and fault tolerance by introducing redundancy. Our clusters consist of redundant servers, we use Git to decentralize repositories, and we (hopefully) create backups of our personal documents.

All of these measures try to prevent a single point of failure. By working in a team of co-maintainers, where multiple people have full access to the project, this single point of failure can be extinguished.

Communication with the community can happen, pull requests can be merged, releases can be published, and access can be granted even if one or more co-maintainers are not available at times.

4. It is possible to step down as a maintainer

It’s important to allow maintainers to leave the project when they decide to do so. If you leave your projects as a solo maintainer then it is abandoned. Unmaintained at a moment’s notice.

The community has to put extra effort into keeping it alive or bringing it to life again. If nobody has administration and publishing rights, this process will even get harder.

Having a team of co-maintainers allows you to think about how to deal with someone leaving the project and how to onboard new co-maintainers.

When having multiple maintainers in place, if someone wants to leave the project, they can just do that — without inevitably putting the project into an unmaintained state.

---

What Can I Do?

As a maintainer of open source software, you should remove the single point of failure of your project by building a team of co-maintainers. Granting multiple people full access to the project will ensure that there is always more than a single person who can administrate the project.

It doesn’t stop at giving access to the repository or GitHub organization, though. You should also give your co-maintainers push access to package registries and all other related accounts in the publishing process of your project.

Co-maintainers do not necessarily need to be people who are working a lot on the project. They might just be the one in charge in case of an emergency. This can also involve giving new maintainers access when former maintainers want to step down. Similar to a custodian.

If you want to leave a project, you should communicate that clearly and inform the involved people and the community. Try to educate people about your reasons and how they can help with maintaining the project.

Don’t forget to share and document knowledge while working on the project, so that if someone leaves, there is little to no unknowns for the rest of the team.

You can use community-driven projects that help with maintaining open source software, such as the wonderful CodeTriage project, collaborative communities like Jazzband (read an interview on opensource.com), and programs like Adopted Ember Addons.

And now there’s Adoptoposs, too, hopefully helping with keeping your projects and yourself healthy while maintaining open source software.
Check it out, and happy maintaining.

By the way — Adoptoposs is always happy to hear about your feedback. It’s built with Elixir, Phoenix LiveView, and Tailwind CSS, and is currently hosted on Heroku. If you want to help, don’t hesitate to check our open issues and discuss new features with us. Issues can be reported in the GitHub repository.

---

References

Here are some insightful links and references that I came across when doing research for building Adoptoposs and writing this post.

• Giving Open-Source Projects Life After a Developer's Death
• How to deal with leaving an open source project
• Request For Commits Podcast with Nadia Eghbal and Mikeal Rogers
• The State of Enterprise Open Source: A Red Hat Report
• https://opensourcesurvey.org/2017/
• https://opensource.guide/best-practices/

---

Situations where projects could not be maintained anymore

A widely used Python package, where a former maintainer left the company and was off-boarded from the team, had no access anymore, and could not merge existing PRs with bugfixes:

---

Another Python package, flask-security, that was forked multiple times and is now maintained by Chris Wagner and lives on as Flask-Security-Too:

• https://github.com/mattupstate/flask-security/issues/854
• https://github.com/italomaia/flask-empty/issues/35

---

Ryan Bates, the creator of railscasts.com, paused software development because of burnout. His CanCan Ruby gem lives on as CanCanCan:

---

Michael Kessler (netzpirat), the maintainer of the haml-coffee Ruby gem, passed away: