It happens without ceremony. One day the issue tracker is quiet, the pull requests pile up unanswered, and the last commit is months old. The project isn't dead in any official sense, but it might as well be. The bus factor, the number of people who can be hit by a bus before the project stalls, has reached zero. No one inherits the keys, no one knows the deployment process, and users are left with code that works today but will rot tomorrow. This is the quiet death of open source, and it is far more common than anyone likes to admit.

When the Last Maintainer Logs Off

Consider the case of left-pad. In March 2016, a developer removed his packages from npm, including a tiny utility that padded strings. Thousands of projects broke because they depended on it, including some major ones. The incident was a wake-up call about the fragility of the open source ecosystem. But the more common scenario is less dramatic: a maintainer simply loses interest or gets too busy, and the project fades away. For instance, the popular JavaScript library event-stream was maintained by a single person for years. When he stepped back, the project was taken over by a new maintainer, but that person had malicious intent, leading to a security breach that affected many users. These examples show that the bus factor is not just a theoretical concern; it has real consequences.

The problem is not that the founder leaves. People leave projects all the time. The problem is that no one was prepared to take over. The knowledge of how the build system worked, why certain design decisions were made, and which contributors could be trusted lived entirely in one person's head. When that person logged off, the project didn't just slow down. It stopped.

Users feel the effects immediately. They file bugs that go unanswered. They submit patches that sit in limbo. They fork the project, but forks rarely gain the same momentum. The original project becomes a zombie, still downloadable, still referenced in tutorials, but no longer maintained. Security vulnerabilities pile up, and eventually someone writes a blog post about how a critical dependency is unmaintained, and the cycle of panic begins.

The bus factor is not just a theoretical concept. It is a real, measurable risk that every project faces. Yet most projects never discuss it. The topic is uncomfortable, because it forces maintainers to confront their own mortality and the possibility that their work will outlive their interest. But ignoring it does not make the risk go away. It just makes the eventual failure more abrupt.

The Onboarding Funnel Is Broken

For projects that do survive a founder's departure, the next challenge is bringing in new maintainers. The onboarding funnel is broken at almost every stage. Documentation assumes tribal knowledge. A new contributor reads the README, which says "see CONTRIBUTING.md," which points to a wiki that was last updated three years ago. The codebase has no comments, the issue tracker is a wall of unlabeled bugs, and the first commit takes months, not days.

Issue triage is a particular bottleneck. Maintainers spend hours each week sorting through reports, reproducing bugs, and asking for more information. New contributors see this chaos and decide it is not worth their time. They move on to projects with clearer processes. The result is a vicious cycle: the fewer maintainers there are, the less time they have to onboard newcomers, so the fewer newcomers become maintainers.

Mentorship is unpaid labor. The few experienced maintainers who do try to guide newcomers find themselves spending more time answering questions than writing code. They are not compensated for this work, and they often burn out faster than they would have if they had just done everything themselves. Some projects have tried to formalize mentorship, but the results are mixed. A structured program requires time and funding, both of which are scarce in most open source projects. This unpaid labor is a key reason why onboarding fails: the people who are best positioned to help newcomers are the same people who are already overworked.

There is a counterargument that the barrier to entry is a feature, not a bug. Some maintainers argue that a high bar keeps out low-quality contributions and ensures that only serious contributors get commit access. But this reasoning conflates rigor with exclusivity. A high bar can be maintained without making the process opaque. The best projects have clear contribution guides, labeled issues for newcomers, and a culture of constructive feedback. Those projects do not struggle to find maintainers.

Funding Follows Features, Not Maintenance

Money is a sensitive topic in open source. Many maintainers do the work for free, and some are proud of that fact. But the reality is that funding shapes what gets done. Grants and corporate sponsorships tend to favor shiny new features over boring maintenance work. A proposal to add a new API endpoint or a performance optimization is more likely to get funded than a proposal to fix flaky tests or update dependencies.

Sustainability grants are rare. Organizations like the Linux Foundation and various open source charities do offer grants for maintenance work, but they are competitive and often tied to specific projects. Corporate sponsors, on the other hand, want roadmaps. They want to know what new features will be added in the next quarter, not that the maintainers will spend that time refactoring the build system. The result is a misalignment between what projects need and what funders are willing to pay for.

Maintenance is invisible work. No one writes a blog post about updating a dependency or fixing a memory leak. These tasks do not show up in release notes as headline features. They are the plumbing that keeps the project running, and they are exactly the kind of work that gets postponed when funding is tight. When a project is struggling to pay its bills, maintenance is the first thing to be cut.

The firmware licensing fees that outlast every board revision are a reminder that maintenance costs are ongoing. Yet open source funding models often treat maintenance as a one-time expense. A grant might cover a year of work, but what happens after that? The maintainer is back to square one, looking for the next grant, while the project's technical debt continues to accumulate.

Consider the example of the curl project. Daniel Stenberg, its lead developer, has been maintaining it for decades. He has spoken publicly about the challenges of funding, noting that while companies use curl extensively, they rarely contribute financially. In 2019, he received a grant from the EU's Next Generation Internet program, but such support is the exception, not the rule. Similarly, the OpenSSL project, which powers much of the internet's encryption, had a single lead developer for years. After the Heartbleed vulnerability in 2014, it became clear that the project was underfunded and understaffed. The Linux Foundation stepped in to provide support, but the initial neglect had already caused a major security crisis.

The Burnout Spiral

Burnout is the silent killer of open source projects. Maintainers are often on call 24/7, responding to security issues, answering user questions, and triaging bugs. They do this without pay, without vacation, and without backup. The pressure is relentless, and the rewards are often intangible. A thank-you note from a user is nice, but it does not pay the rent.

Entitled users make it worse. Every maintainer has a story about a user who demanded a fix within hours, threatened to switch to a competitor, or insulted the maintainer's intelligence. These interactions wear on the psyche. A single harsh comment can undo weeks of positive feedback. Over time, the maintainer begins to dread opening the issue tracker.

There is no vacation. Even when a maintainer takes a break, the project does not. Issues pile up, pull requests go stale, and the maintainer returns to a mountain of work. The guilt of leaving the project in a lurch is enough to keep some maintainers from ever taking time off. They work through holidays, sick days, and family events, and they resent it.

Quitting feels like relief. When a maintainer finally steps down, the immediate feeling is often liberation, not sadness. They have been carrying a weight for years, and they are finally free. The project may survive, but it will likely struggle. The GPU depreciation schedules that decide which models get trained are a different kind of resource constraint, but the principle is the same: when the person who knows how to operate the machinery leaves, the machinery stops.

Succession Planning Is a Taboo

Succession planning is rarely discussed in open source. The founder's identity is often tied to the project. The project is their baby, their legacy. Admitting that they might leave, or that they might be hit by a bus, feels like admitting failure. So they do not talk about it, and they do not prepare for it.

Handover documents are almost nonexistent. There is no standard format for documenting the unwritten rules of a project. The founder knows why they chose a particular coding style, why they rejected a certain architecture, and which contributors are reliable. None of this is written down. When the founder leaves, all of that knowledge leaves with them.

The bus factor is never discussed. It is a morbid topic, and it is easy to put off. "I will document things next month," the founder thinks. But next month never comes. The project grows, the founder gets busier, and the documentation remains unwritten. The bus factor stays at one, and everyone knows it, but no one says anything.

There are exceptions. Some projects have formal governance models, with elected maintainers and term limits. These projects are better equipped to handle turnover, because the process is institutionalized. But most projects are not like that. They are the product of one or two people's vision, and they are fragile.

Small Bets That Keep the Lights On

There is no silver bullet for the bus factor problem, but there are small bets that can make a difference. The first is to pair new maintainers with veterans. This is not a formal mentorship program, just a simple practice of having a new contributor shadow a seasoned maintainer for a few months. The new person learns the ropes, and the veteran gets a second pair of eyes on their work. This is distinct from the unpaid labor of informal mentorship; it is a structured, time-boxed arrangement that benefits both parties.

Writing down the unwritten rules is another small bet. It takes time, but it is not hard. A simple document that explains why the project uses tabs instead of spaces, how to run the test suite, and who to ask for help can save hours of confusion. It does not need to be comprehensive; it just needs to exist.

Rotating on-call duties is a third small bet. Instead of having one person responsible for security issues, spread the load across a team. This reduces burnout and ensures that more than one person knows how to handle a crisis. It also makes the project more resilient, because no single person is a bottleneck.

Funding maintenance as a line item is the most important small bet. This requires a shift in mindset, both for funders and for maintainers. Funders need to recognize that maintenance is not a luxury; it is a necessity. Maintainers need to ask for money for maintenance, even when it is not glamorous. The signed OAuth flows that leak less than federated logins are a good example of a boring but critical improvement that deserves funding.

The Bus Factor as a Metric

The bus factor should be a metric that every project tracks. It is not a vanity metric; it is a health metric. A project with a bus factor of one is a single point of failure. A project with a bus factor of three is still fragile. A project with a bus factor of ten is probably healthy.

Measuring the bus factor is not easy. It requires an honest assessment of who knows what. A simple way to start is to ask each maintainer to list the areas of the codebase they feel confident modifying. If there is an area that only one person can touch, that is a risk. The goal is to reduce the number of such areas over time.

Tracking onboarding time is another useful metric. How long does it take a new contributor to make their first commit? If it takes months, the onboarding process is broken. The goal should be to get that number down to days. This is not just about efficiency; it is about reducing the barrier to entry and making the project more welcoming.

Auditing critical knowledge is a third metric. What happens if the person who knows how to deploy the project is unavailable? Is there a runbook? Is there a backup? These are questions that every project should ask, and the answers should be documented. Making succession a KPI is a way to formalize this. It is not a punishment; it is a recognition that projects outlive their founders.

One project that handled succession well is Bootstrap, the popular CSS framework. It was created by two developers at Twitter, but over time, it grew into a large community with multiple maintainers and a formal governance structure. When the original creators moved on, the project continued to thrive because there was a clear process for onboarding new maintainers and a culture of shared ownership. Similarly, Kubernetes has a well-defined governance model with multiple steering committee members and working groups, ensuring that no single person is indispensable.

For maintainers, the call to action is clear: start today. Write down one thing about your project that only you know. Pair with a newcomer on your next issue. Ask your funders to support maintenance work. These small steps will not make the bus factor problem disappear, but they will make your project more resilient. The alternative is to pretend that the project will live forever, and that is a fantasy. Every project will eventually change hands, whether through a planned transition or a sudden departure. The projects that survive are the ones that prepare for that moment. The ones that do not are the ones that die quietly, leaving users to wonder what happened.