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:
adoptoposs
/
adoptoposs
Finding co-maintainers for your open source software project.
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.
nayafia
/
awesome-maintainers
Talks, blog posts, and interviews about the experience of being an open source maintainer
- 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:
Fix for Python 3.7
#243
Fixes #233
According to PEP 479, if raise StopIteration occurs directly in a generator, simply replace it with return.
This is both backwards and forwards compatible code.
Another Python package, flask-security, that was forked multiple times and is now maintained by Chris Wagner and lives on as Flask-Security-Too:
Flask-Middleware
/
flask-security
Quick and simple security for Flask applications
Flask-Security
Quickly add security features to your Flask application.
Notes on this repo
This is a independently maintained version of Flask-Security based on the 3.0.0 version of the Original
Goals
- Regain momentum for this critical piece of the Flask eco-system. To that end the the plan is to put out small, frequent releases starting with pulling the simplest and most obvious changes that have already been vetted in the upstream version, as well as other pull requests. This was completed with the June 29 2019 3.2.0 release.
- Continue work to get Flask-Security to be usable from Single Page Applications such as those built with Vue and Angular, that have no html forms. This is true as of the 3.3.0 release.
- Use OWASP to guide best practice and default configurations.
- Be more opinionated and 'batteries' included by reducing reliance on abandoned projects and bundling in support for common use cases.
- Follow…
- 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:
NOTICE: cancan is moving!
#994
"parting is such sweet sorrow"
As discussed for the last month in the comment thread of pull https://github.com/ryanb/cancan/pull/989 it is time to move cancan forward before it fizzles. While the community support behind this gem is high, and pull requests have been added daily, the last merge into the official gem was in September of 2013. We both love and support the work that @ryanb has given to this gem, and in hopes to keep his legacy alive we have the following solution:
Enter cancancan
This will be the new gem repository going forward. Please put issues and pull requests in the new repo, as we will now be able to merge fixes into the main gem. Thanks to @bryanrite, as he has spearheaded the effort for the new repo.
For more details on the transition, please look at the readme on the new repo and the comment thread.
Michael Kessler (netzpirat), the maintainer of the haml-coffee Ruby gem, passed away:
Attention: @netzpirat passed away in April '14
#97
I, together with @sebastiandeutsch were the first committers on the project, before handing it over to Michael (@netzpirat).
I have just learned that Michael has passed away in the beginning of April. I'm putting up this issue to bring this to the attention of HAML-Coffee users.
This also means that haml-coffee needs a new maintainer. Unfortunately my free time doesn't allow for maintenance of this project in the extent Michael worked on HAML-Coffee.
:(
</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/netzpirat/haml-coffee/issues/97">View on GitHub</a></div>
Top comments (0)