How to find new maintainers for your open source project
Tags: webdev, programming, tutorial, opensource
Published: 2022-02-09 19:21:45

**This open source software helps you build a healthy team of co-maintainers so that no project gets left behind.**

- before we starting, support me by adding a star to the [volder repository](https://github.com/devSupporters/volder)

### Table of Content
- [The problem of unmaintained open source projects](#the-problem-of-unmaintained-open-source-projects)
- [The load of seemingly unmaintained projects](#the-load-of-seemingly-unmaintained-projects)
- [Building Adoptoposs](#building-adoptoposs)
- [How you can help](#how-you-can-help)
- [Looking for maintainers? Give Adoptoposs a try!](#looking-for-maintainers-give-adoptoposs-a-try)

If there's one thing you can say about open source software (OSS), it's that it quietly yet inarguably runs our world. Most of the internet is built on open source software, and, these days, millions of developers build and maintain hundreds of thousands of open source packages in more than 250 programming languages. If that's not enough, enterprise companies continue to grow their investments in open source in 2020.

The more open source software permeates our everyday life, the more important it becomes to keep all these projects secure, compatible, and well-maintained.

As we will see, this is not as easy as it sounds, especially if a great amount of open source is built by volunteers. To address the problem of open source maintenance, I built [Adoptoposs.org](https://adoptoposs.org), an app (open source of course!) that helps you find co-maintainers and keep open source projects and their maintainers healthy.

## The problem of unmaintained open source projects

Many developers contribute to open source at work, whether it's a massive project like Kubernetes or an open source product like Ansible.

However, 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 talk about 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 sometimes feel overwhelmed by the amount of work and walk away from their projects.

The reasons for dedicating less time to or even leaving an open source project are many and varied. 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.

In all these cases, projects are left behind, often with no one but the original author having administration rights or access to the publishing accounts. Of course, you can fork and publish a project under a new name. But ultimately, that leads to confusion about the state of the project and whether it can and should still be considered a stable piece of software.

## The load of seemingly unmaintained projects

Over the last couple of years doing web development, I often found myself in situations where long-used libraries were no longer compatible with the latest version of a framework or programming language. It turned out that the original maintainers had lost access to the project after leaving their company or just could not dedicate enough time. It was always hard to contact anyone who could help with merging bug fixes and releasing a new version.

## Building Adoptoposs

After I found that, on GitHub alone, there were more than 36,000 issues asking "Is this project abandoned?", I thought about how to tackle this problem. More than 15,000 of these were open issues. So, lots of projects need help with their maintenance.

I was lucky that I was between jobs at the beginning of this year and had a lot of time to think about the problem and how I could help contribute to the health of open source projects and their maintainers. So I just started working on something.

First, I thought it might be nice to have a dashboard that rates OSS projects by whether they needed help with their maintenance. When I had a prototype running after a couple of days' work, I found that it kind of worked but did not really overcome the problem of getting into contact with the maintainer. And when a maintainer was hard to reach when I needed support, it would already be too late.

So, I reconsidered the actual goal. Because maintainers know first when they need help, they should be able to make their project visible to potential co-maintainers and ask for it. Likewise, people who considered becoming a co-maintainer should be able to find interesting projects and contact the maintainer.

With these goals written down, I started building Adoptoposs in February 2020. I must say it went faster than I expected. As a tech stack, I chose Elixir and gave Phoenix LiveView a try, primarily because I wanted to learn more about it but also because I planned to publish Adoptoposs as open source from the beginning. This stack seemed perfect in terms of productivity and the resources I would have to spend on maintaining and hosting the app.

Two months later, after I had learned a lot about Elixir, HTML, CSS, and user experience design, Adoptoposs went live on March 30. Since then, it has already found itself its first co-maintainer—by using Adoptoposs, of course!

## How you can help

The philosophy of Adoptoposs is that each and every open source project of considerable popularity should have a team of co-maintainers to avoid sliding into neglect. Multiple people should have full access to the project and all related services—like package registries, hosting accounts, and third-party services—to ensure ongoing maintenance even as maintainers come and go.

For your popular open source projects, I encourage you to build a team of co-maintainers to remove the single point of failure. There are great ways to do this while building trust.

Your co-maintainers do not necessarily need to work on the project every day. They might only be an in-case-of-emergency contact, but at least they will be able to be there. This process often means giving new maintainers access when former maintainers want to step down. You can follow examples like the core-dev program for Python or look at project guides like the one at Homebrew for ideas and direction.

## Looking for maintainers? Give Adoptoposs a try!

If you don't have co-maintainers for your open source project in mind yet, consider submitting your project to [Adoptoposs.org](https://adoptoposs.org/). Adoptoposs will list your project and also notify developers interested in the programming languages you use.

Keep in mind to document important details about your project to make it easier for people to help you. Start seeking out help early on and build a team of co-maintainers to keep your open source projects and yourself healthy.

If you are considering becoming a co-maintainer, you can explore projects that need help and contact the maintainers. You can be pretty certain that your help is needed, and it is a great way to level up your expertise or simply have some fun with code.

And of course, if you find any issues with Adoptoposs or have suggestions on how to improve it, please let us know in our [GitHub repository](https://github.com/adoptoposs/adoptoposs/issues).

support me by adding a star to [volder repository](https://github.com/devSupporters/volder)