When Ryan Dahl stepped back from Node.js, the project survived — but it took years of governance restructuring, a fork (io.js), and a reconciliation before it stabilized. When Guido van Rossum resigned as Python's BDFL ('Benevolent Dictator For Life'), the community spent months debating governance models before settling on a steering council. When the Deno project faced its own leadership questions, the ripple effects reached every developer who'd bet on the runtime.
These aren't isolated incidents. They're a structural feature of open source development. Most significant open source projects depend on a tiny number of people — often one person — far more than their users realize. When that person leaves, burns out, changes priorities, or makes a controversial decision, the project faces an existential crisis that no amount of GitHub stars can prevent.
The Bus Factor Problem
The 'bus factor' — how many people would need to be hit by a bus before a project collapses — is grimly low for most open source projects. A 2015 study found that over 60% of npm packages had a single maintainer. A more recent analysis of critical open source infrastructure found that many projects with millions of downstream dependents are maintained by one or two people, often as unpaid hobby work.
This isn't a hypothetical problem. OpenSSL, the library that secured most of the internet's encrypted traffic, was maintained primarily by two people working on it in their spare time when Heartbleed was discovered. Left-pad, a trivial 11-line npm package, broke thousands of builds when its author removed it. Core-js, downloaded over 25 million times per week, is maintained by a single developer who has publicly described himself as barely able to afford food.
The pattern is consistent: a critical project is started by a passionate individual, gains adoption, becomes infrastructure that millions depend on, and yet the maintenance burden remains on the same one or two people. The project's importance scales exponentially. Its support doesn't.
Governance Models and Their Trade-offs
Open source projects handle governance in a few distinct ways, each with predictable strengths and failure modes.
The BDFL Model
A single person makes final decisions. Python (Guido van Rossum), Linux (Linus Torvalds), Ruby (Matz) — the most successful projects often have a strong technical leader whose taste and judgment shape the project. The advantage is clear direction, consistent vision, and fast decision-making. The BDFL can say 'no' to features that don't fit, and the project stays focused.
The failure mode is equally clear: the BDFL leaves, and there's no succession plan. Python's transition after Guido's resignation was bumpy despite his decades of community building. Projects with less engaged communities often simply die when their BDFL moves on.
The Foundation Model
Projects like Apache, Eclipse, and the Linux Foundation sit under nonprofit foundations with formal governance structures: technical steering committees, committer elections, decision-making processes. This provides institutional continuity — the project survives individual departures because the structure persists.
The trade-off is bureaucracy and political dynamics. Foundation governance can be slow, contentious, and captured by corporate interests. Some developers find the committee process stifling compared to the agility of a BDFL-led project. The worst case: a foundation where governance becomes more about organizational politics than technical merit.
The Corporate Sponsor Model
React (Meta), Go (Google), Rust (originally Mozilla, now its own foundation), TypeScript (Microsoft) — many major projects are sponsored by companies that employ the core maintainers. This solves the funding problem: maintainers get paid, can work full-time, and the project benefits from corporate engineering resources.
The risk is alignment. Corporate priorities change. Mozilla laid off the Rust team. Google has deprioritized and underfunded open source projects when business focus shifted. When a company's strategic interests diverge from the project's community interests, friction is inevitable. The recent trend of open source projects having their licenses changed by corporate sponsors (Redis, Terraform, Elastic) shows how precarious this model can be.
When Forks Are Healthy
Forking — creating a competing copy of a project — is often treated as a sign of failure. But in open source, it's actually the ultimate safety valve. When leadership fails, forks allow the community to continue without depending on the original maintainers.
The io.js fork of Node.js pushed Node toward a more open governance model and faster release cycles. When the projects merged back, Node was better for it. LibreOffice forking from OpenOffice.org rescued the project from Sun/Oracle's declining interest. MariaDB, forked from MySQL after Oracle's acquisition, continues as the community-driven alternative.
More recently, license changes have triggered productive forks. When Elastic changed Elasticsearch's license, Amazon forked it as OpenSearch. When HashiCorp changed Terraform's license, the community forked it as OpenTofu under the Linux Foundation. These forks exist because the right to fork is the community's ultimate check on project leadership.
The key is that forking works best when the community — not just the code — splits cleanly. A fork with active maintainers and community buy-in thrives. A fork by a single frustrated developer that nobody follows just creates confusion.
The Burnout Spiral
Most open source leadership crises don't start with a dramatic exit. They start with burnout — the slow erosion of a maintainer's capacity and enthusiasm under the weight of issues, pull requests, feature requests, and entitled users.
The dynamics are predictable. A maintainer creates something useful. Users arrive. With users come bug reports, feature requests, support questions, and demands. The maintainer, feeling responsible, tries to respond to everything. The volume exceeds their capacity. They start dreading their notifications. They respond more slowly, then more tersely, then not at all. Eventually they disappear, and the project enters a period of zombie maintenance — technically alive, practically abandoned.
Open source maintainer burnout isn't a personal failing. It's a structural problem: projects generate unlimited demand for the time and attention of a finite number of people, with no built-in mechanism for managing that demand.
Some maintainers have found ways to cope: strict boundaries on response times, delegating triage to community members, paid maintenance through GitHub Sponsors or Open Collective, or simply being comfortable with slower response times. But these require consciously resisting the pressure to be endlessly available, which goes against the culture of many open source communities.
What Healthy Succession Looks Like
A few projects have handled leadership transitions well, and they share common patterns.
- Distributed knowledge, not just distributed code. The project's 'tribal knowledge' — why certain decisions were made, what alternatives were considered, what the design principles are — is documented, not just in one person's head. Architecture Decision Records (ADRs) and detailed RFCs serve this purpose.
- Multiple people with commit access and release authority. If only one person can cut a release, that person is a single point of failure. Healthy projects have at least 3-5 people who can independently release new versions.
- Explicit governance documents. How are decisions made? Who has authority over what? How are new maintainers added? Projects that answer these questions before a crisis handles succession better than those that improvise.
- Gradual transitions, not sudden departures. The best leadership transitions happen when the outgoing leader deliberately reduces their involvement over months, mentoring successors and explicitly transferring authority. Abrupt departures — even well-intentioned ones — create vacuums.
- Financial sustainability. Projects with reliable funding (through foundations, corporate sponsors, or community funding) survive transitions better because incoming maintainers can be compensated for their time. Asking someone to inherit an unpaid full-time job is a hard sell.
What Users and Companies Should Do
If your business depends on open source software — and it does — you have a stake in the health of the projects you depend on. A few practical steps:
- Audit your dependency bus factor. Look at the critical open source projects in your stack. How many active maintainers do they have? When was the last release? How quickly are security issues addressed? A project with one maintainer and a six-month-old security vulnerability is a risk you should know about.
- Fund what you use. If a project is critical to your business, contribute to its funding. GitHub Sponsors, Open Collective, and Tidelift provide mechanisms for this. The cost of funding a maintainer is trivial compared to the cost of a critical dependency becoming unmaintained.
- Contribute upstream. Bug fixes, documentation improvements, issue triage — these reduce the maintainer's burden and give your team familiarity with the codebase. If the project ever needs new maintainers, you'll be positioned to step in.
- Have a contingency plan. For critical dependencies, know what you'd do if the project was abandoned. Can you fork and maintain it? Is there an alternative you could migrate to? The time to answer these questions is before you need to.
Open source governance isn't glamorous work. It doesn't generate headlines or GitHub stars. But the difference between a project that survives its founder's departure and one that doesn't is almost always governance — the boring, structural work of documenting decisions, distributing authority, and planning for succession. The projects that last are the ones that build institutions, not just software.
