In 2024, 60% of surveyed open-source maintainers said they had quit or thought about quitting the volunteer work that keeps their software running1. Nearly all of them, 60%, were doing it for free1. Burnout was the reason 44% gave2.
That software is not some niche hobby project. It is the free, publicly shared code sitting underneath banking apps, hospital systems, and the checkout page you used last week. Often, one unpaid person maintains it in their spare time, answering bug reports at odd hours because nobody else will.
A Maintainer Burns Out
The pattern is familiar to anyone who has run a popular project.
Photo by A library gets millions of downloads a week and has exactly one active contributor. Requests arrive faster than one person can read them. Security patches, feature demands, and questions from strangers who assume there is a support team behind the name all land in the same inbox.
Eventually the maintainer stops answering. The code keeps running, because code doesn’t care whether anyone is watching it. The unpatched security holes stay open, though, and that’s the real risk.
In 2024, 60% of surveyed maintainers had quit or considered quitting, and 60% were paid nothing for the work. For anyone using a banking app or online store, this means the free software holding it together may have no one checking its messages tonight.
Why Code Alone Breaks Down
Good code doesn’t review itself.
Photo by Somebody has to decide which contributions get merged, which direction the project takes, and what happens when two contributors disagree about both. Those are human calls, and you can’t solve them by writing more functions.
The harder gap shows up at the exit. When a sole maintainer steps away, moves countries, changes jobs, or just stops caring, there’s often no written answer to a basic question: who has the keys now? Repository access, package publishing rights, and the domain name can all sit in one personal account.
Governance, the set of agreed-upon rules for who decides what, is the boring answer to that question. In plain terms, it covers how newcomers earn trust and what happens when someone leaves.
What Governance Looks Like in Practice
Mature projects have already worked this out, and their setups are worth studying before building your own from scratch.
Photo by The Linux kernel, the core software that runs most servers and Android phones, uses a layered structure. Subsystem maintainers review and route changes upward before anything reaches the main codebase3. No single inbox absorbs everything. The project also documents a continuity procedure for its top-level repository in case normal leadership becomes unavailable, essentially a plan for the day the person at the top goes silent.
Ubuntu, a popular Linux-based operating system, splits the job in two: a Technical Board for direction and a Community Council for oversight, with stated commitments to participation, accountability, transparency, and appeal4.
“There is a defined process that helps people participate in decisions,” and “there is a single path for the appeal or escalation of a decision when needed.”
That second clause matters more than it sounds. Most project blowups aren’t technical disputes. They’re disputes about who got to decide, with no agreed way to escalate.
Healthy projects tend to publish their decision-making the same way they publish their code, out in the open, for anyone to check.
Where This Is Heading
Two signals suggest governance is moving from optional to expected in 2026.
The first is institutional. Governments and public agencies have started treating open-source components as dependencies that need active stewardship, not just free downloads. Once an agency lists a library in its supply chain, someone eventually asks who maintains it and what happens if they stop.
The second is money. Foundations, sponsorship pools, and maintainer stipends are slowly attaching funding to projects that can show a governance structure. Funders want proof the work outlives one person’s enthusiasm.
Before building on a library, it’s worth checking three things:
- Bus factor, a rough measure of how many people could disappear before a project stalls. How many people have merge rights? If the answer is one, you’re the backup plan.
- Written process. Is there a GOVERNANCE or MAINTAINERS file, or only a README?
- Succession. Does anything describe what happens if the lead disappears?
None of that takes more than five minutes, and it predicts a project’s next three years better than its star count ever could.
Back to the Nightstand
A phone lights up on a nightstand at 1 a.m.
Photo by with another bug report. The person reaching for it isn’t on call, and nobody is paying them. They wrote a small piece of free software years ago to solve their own problem, published it, and moved on with their life.
With a co-maintainer, half those reports go to someone else’s morning. With a documented handover, the day the maintainer stops caring becomes a scheduled transition instead of a silent gap.
The code in both versions is identical. The difference is entirely organizational, which is exactly why it gets skipped: nobody gets thanked for writing a succession plan. The reliability of the software you depend on is partly a question of paperwork.
Next time you pull a package into a project, or read about a widely used component with a vulnerability that sat open too long, look past the code quality. Open the repository and count the people who can merge a change. Look for a file that says what happens when they leave. That short check tells you something download numbers never will: whether you’re building on a maintained project, or one person’s unfinished favor to the internet.
Sources
- Tidelift 2024 State of the Open Source Maintainer Report
- SonarSource, Maintainer Burnout Is Real
- Linux Kernel Documentation, A Guide to the Kernel Development Process
- Ubuntu Community Documentation, Governance
- Tidelift maintainer survey one-pager 2024
- Linux Kernel Documentation, Kernel Project Continuity
