Open-source licenses have always been dry documents, the legal equivalent of a handshake. They tell you what you can do with the code, but they never say who will keep the lights on. That is changing. A small but growing number of maintainers are rewriting their LICENSE files to name a successor, turning a boilerplate legal text into a governance document that answers the question every user secretly asks: what happens to this project if you disappear?

The License File Is Becoming a Succession Document

The shift is subtle. Most people never read a LICENSE file past the first line. They see MIT, Apache 2.0, or GPL and move on. But tucked into some of these files now are sentences like "In the event of the maintainer's death or incapacitation, project control transfers to [name]." It reads like a will, because it functions like one.

This is not a formal standard. There is no RFC for succession clauses, no template approved by the Open Source Initiative. It is a grassroots practice, spreading through GitHub issues and maintainer mailing lists. Early adopters are mostly solo maintainers of popular libraries, people who have watched too many projects die quietly when their owner lost interest or worse.

The unspoken driver is the bus factor, the number of people who need to be hit by a bus before a project becomes unmaintainable. For a single-maintainer project, that number is one. Naming a successor does not raise the bus factor, but it does ensure that when the bus arrives, someone is already standing there to catch the wheel.

To be clear, this is still a minority practice. A survey of public repositories would find succession clauses in a fraction of a percent of LICENSE files. But the trend is visible in the projects that matter, the ones with thousands of dependents and no corporate backer. When those projects start writing succession plans, the rest of the ecosystem pays attention.

Bus Factor Meets Legal Formality

The bus factor is a morbid joke that became a risk metric. It measures how many key people a project can lose before it grinds to a halt. For a one-person library with millions of downloads, the bus factor is one, and that is not a comfortable number to sit with.

Unmaintained projects are not just sad; they are dangerous. They accumulate unpatched vulnerabilities, and attackers know it. The security community has documented dozens of cases where abandoned npm packages were hijacked to distribute malware. A successor clause does not fix that entirely, but it shortens the window between a maintainer stepping away and someone else taking responsibility.

Successor clauses are a cheap insurance policy. They cost nothing to write, require no legal fees if you use a simple template, and they save a future contributor from the agonizing question of whether they have the right to push a fix. Without a named successor, that contributor faces a fork, a hostile takeover, or a long and uncertain process of contacting the maintainer's estate.

Research on open-source sustainability, including work out of Georgia Tech, has long pointed to the bus factor as a primary risk. The Georgia Tech researchers studied thousands of projects and found that a significant portion rely on a single contributor for the majority of commits. Their work has been cited in countless maintainer guides, but the advice has always been vague: "recruit more maintainers." A successor clause is a concrete, actionable step that follows the same logic.

The Wear of Maintenance Is Real

Burnout is the quiet killer of open-source projects. It does not announce itself with a resignation letter. It shows up as unanswered issues, stale pull requests, and a maintainer who stops responding to email. The wear is cumulative, and it is not just about time. It is about the emotional load of being the last line of defense for thousands of strangers.

Maintainers juggle bug reports, feature requests, code reviews, and release management, often in their spare hours. The work is unpaid, unrecognized, and never done. A 2021 survey by the Tidelift company found that a majority of maintainers felt they were not adequately compensated, and a significant share said they had considered stepping away.

Succession planning reduces long-term wear because it gives maintainers permission to leave. Knowing that a successor is waiting means you can take a break without guilt, or exit entirely without leaving your users in the lurch. It converts an all-or-nothing commitment into a manageable one.

Deep tech startups face the same talent drain, but they have funding to hire replacements. Open-source projects usually do not. A successor clause is a way to institutionalize continuity without a budget. It is a governance hack, a way to make the project more resilient than the person running it.

How to Write a Successor Clause That Works

Writing a successor clause is not hard, but doing it well requires more than a sentence. The first step is to name a specific person, not just a team or an organization. A team can dissolve; an organization can change priorities. A person, ideally one who has contributed to the project and understands its quirks, is a more reliable target.

The second step is to define the trigger. Death is the obvious one, but disability and resignation are more common. The clause should specify what counts as incapacitation, and who gets to make that call. Some maintainers name a trusted friend or co-maintainer as the decider, to avoid a situation where the successor has to prove the maintainer is gone.

The third step is to describe the transfer-of-control process. This means specifying how the successor gains access to the repository, the npm or PyPI account, the domain name, and any other infrastructure. It is not enough to say "they take over." You need to document where the passwords are stored, or better yet, use a password manager with a dead-man's switch.

Finally, the clause should address what happens to the project's direction. Does the successor have full discretion, or are they expected to maintain the original vision? This is a matter of trust, but writing it down reduces the chance of a fork or a dispute later. And yes, a lawyer should review the clause if the project has any legal complexity, but for most MIT-licensed libraries, a plain-English paragraph is enough.

Forking Is the Fallback, Not the First Choice

When a maintainer disappears without a successor, the community's only option is to fork the project. Forks are a sign of failure, not success. They split the user base, duplicate effort, and create confusion about which version is canonical. A named successor avoids that mess entirely.

Hostile forks are worse. They happen when a group of users disagrees with the maintainer's direction and decides to take the code in their own direction. Sometimes that is healthy, but often it is a sign that governance failed. A successor clause does not prevent all forks, but it gives the community a legitimate path to continuity, which reduces the incentive to fork.

The Linux kernel offers a different model: many maintainers, each responsible for a subsystem, with a clear hierarchy and a benevolent dictator at the top. That works because the project is huge and has corporate backing. Small projects do not have that luxury. They have one person and a pile of goodwill. A successor clause is a way to give that goodwill a structure.

In practice, the fallback for most abandoned projects is a fork that slowly dies because no one has the authority or the energy to maintain it. The few that survive do so because a new maintainer emerges and is willing to take on the role. A successor clause simply makes that emergence intentional, rather than accidental.

The Funding Question Remains Unresolved

Succession is free, but maintenance costs money. A successor clause does not pay for server bills, code review time, or the hours spent answering questions. It is a governance fix, not a financial one, and the open-source community is still arguing about how to fund the work.

The Open Source Initiative has hosted debates about funding models for years, from corporate sponsorship to crowdfunding to government grants. None of these have solved the core problem: most maintainers are volunteers, and volunteer labor is not sustainable at scale. A successor clause can make a project survive a transition, but it cannot make that transition attractive to the successor.

Corporate sponsors rarely fund succession. They fund features and security fixes, not handover plans. Some foundations, like the Software Freedom Conservancy, offer transition support for projects they host, but that is a small fraction of the ecosystem. For the rest, the successor inherits a project with all its obligations and none of its funding.

The Verge's recent coverage of AI-era distrust in online content mirrors a similar trust problem in open source. Users cannot tell if a project is healthy or abandoned, and the absence of a successor clause is a signal. It says the maintainer has not thought about the future, which is not a good sign for the project's longevity.

Real-World Examples and Their Lessons

A few high-profile cases illustrate both the need for and the limits of succession planning. Consider the situation with the popular JavaScript library left-pad. In 2016, its maintainer unpublished the package from the npm registry, breaking thousands of projects that depended on it. The incident triggered a cascade of failures across the ecosystem, forcing npm to step in and restore the package. There was no successor clause, and the maintainer's abrupt action left users scrambling. A simple clause naming a co-maintainer might have prevented the chaos, or at least provided a smoother path to recovery.

Another example is the Ruby on Rails framework. While not a single-maintainer project, it has a clear leadership structure with a core team. When its original creator, David Heinemeier Hansson, stepped back from daily maintenance, the core team was able to continue development without a crisis. That transition was not formalized in a LICENSE file, but it worked because there was a defined team and a governance model. For smaller projects, a clause can formalize an informal arrangement.

On the other side, there are cautionary tales of projects that stalled despite having a named successor. The successor may lack the time, interest, or skills to take over effectively. A clause is only as good as the person named. That is why some maintainers choose to name a small group or a foundation as the successor, though that introduces its own complexities. A foundation can provide stability, but it also brings bureaucracy and may not move quickly.

These examples suggest that a successor clause is not a silver bullet. It is a piece of a larger governance puzzle. The clause can ensure a handover, but it cannot guarantee the successor's success. That requires ongoing mentorship, documentation, and community support. In that sense, the clause is a starting point, not an end point.

Counterarguments and Limitations

Not everyone is convinced that successor clauses are a good idea. Some argue that naming a successor in a LICENSE file creates a false sense of security. The clause has no legal force in most jurisdictions; it is a statement of intent, not a binding contract. If the successor is not willing or able to take over, the clause is meaningless. A user who sees a successor named might assume the project is safe, but that assumption could be wrong.

Others worry that a successor clause could discourage new contributors. If a project already has a named successor, potential contributors might think their help is not needed, or that they will never have a chance to lead. This could stifle the organic growth of a community. However, this concern is speculative. Most contributors do not join a project with the expectation of becoming the lead maintainer; they join to fix bugs and add features.

There is also the question of accountability. A successor clause names a person, but what if that person changes their mind? The clause can be updated, but it requires the maintainer to keep it current. If a maintainer names a successor and then stops updating the file, the clause becomes stale. This is a practical limitation, but it is not insurmountable. A clause can include a review date, prompting the maintainer to revisit it periodically.

Finally, some legal scholars question whether a LICENSE file is the right place for succession language. Licenses are about granting permissions to use the code, not about governance. Placing succession clauses there conflates two different legal functions. A better approach might be a separate GOVERNANCE.md file or a formal stewardship agreement. However, the LICENSE file has the advantage of being widely read and easily found. It is a pragmatic choice, even if it is not perfect.

A Practical Checklist for Current Maintainers

If you maintain a project, the first step is to review your LICENSE file this quarter. It is probably a generic template, and that is fine. But add a short paragraph at the end that names your successor and describes the transfer process. It does not need to be long.

Second, identify your successor and ask them first. Do not assume someone will want the job. A surprising number of maintainers have been approached by strangers offering to take over, and many have declined. The right successor is someone who already contributes, who understands the codebase, and who has the time to take on more.

Third, document your release process and passwords. Write down the steps to publish a new version, the location of the signing keys, and the credentials for the package registry. Store this in a secure place and share it with your successor, or use a service like a password manager with emergency access.

Fourth, test the transfer with a dry run. Give your successor temporary access to a staging repository and have them make a release. This will surface problems before they become emergencies. It is like a fire drill for your project's continuity.

Finally, consult a lawyer if your project is part of a larger organization or has complex licensing. A simple clause is fine for most cases, but if you are dealing with trademarks or patents, you want professional advice. And remember, the clause is not a legal requirement. It is a gift to your future self and your users.

The practice of naming successors in LICENSE files is still young, and it is not a cure-all. It does not solve funding, burnout, or the endless stream of issues. But it is a small, concrete step that any maintainer can take today. It is a way to say, without drama, that the project matters more than any single person, and that the work will continue.