When the maintainer of a widely-used JavaScript utility library disappears for eighteen months with no commits, no responses to security issues, and no designated successor, thousands of downstream projects keep depending on code that nobody is actively defending. This is not a hypothetical. It happened with event-stream in 2018, when a burned-out maintainer handed control to a stranger who added a cryptocurrency-stealing payload three commits later. It happened again with ua-parser-js in 2021, and with coa and rc in 2021, all hijacked through the same pattern: an exhausted volunteer, no succession plan, and an attacker who simply asked nicely for commit access.
Succession planning sounds like an obvious fix. Yet across the open source ecosystem, it almost never happens in a deliberate, documented way. Understanding why requires looking at the economics, incentives, and social dynamics of maintaining software that millions of companies depend on but almost none of them fund or govern.
What does "succession planning" actually mean for an open source project?
It means a documented, pre-agreed process for transferring commit access, package registry ownership, and decision-making authority before a maintainer needs to step away, not after. For a company, succession planning is a slide deck and an org chart. For an open source project, it typically involves at minimum: a second and third person with equal publish rights on npm, PyPI, or crates.io; a written policy (often a GOVERNANCE.md file) describing how a new maintainer is nominated and approved; and a way for the community to reach the project if the primary maintainer goes silent for a defined period, say 90 days.
Very few projects have all three. The Linux Foundation's 2024 Census III report, produced with Harvard's Laboratory for Innovation Science, found that the median open source project has close to zero bus factor protection: a huge share of critical packages have only one or two people who can push a release. The report examined over 12,000 unique packages across the npm and other ecosystems and found this concentration is not shrinking over time, despite years of public warning after incidents like Heartbleed and left-pad.
Why don't maintainers plan for their own departure?
Because burnout arrives faster than the will to hand off, and handing off feels like admitting failure. Nadia Eghbal's 2020 book "Working in Public" documented dozens of interviews with maintainers who described maintenance as an obligation that crept up on them after a project became popular, not a role they signed up for. Planning a succession requires a maintainer to actively recruit, vet, and trust a stranger with the keys to code that may run inside banks, hospitals, and government systems, often for zero pay and while still doing a full-time job elsewhere.
The event-stream case is instructive here. Dominic Tarr, the original maintainer, had moved on to other priorities and received an email from a user named "right9ctrl" offering to help maintain the package. Tarr granted publish access with essentially no vetting, because that is how open source has worked for two decades: goodwill and reputation stand in for background checks. Two months later, that account pushed a version containing obfuscated code designed to steal cryptocurrency wallet credentials from a downstream dependency, copay, that had roughly 5 million weekly downloads at the time.
Have any high-profile incidents actually been caused by poor succession planning?
Yes, and they span more than a decade. Beyond event-stream, ua-parser-js was compromised in October 2021 after its maintainer's npm account credentials were reportedly stolen, allowing attackers to publish versions containing a password stealer and cryptominer to a package with over 7 million weekly downloads. In November 2018, the maintainer of the npm package flatmap-stream (bundled inside event-stream) illustrated how quickly a single unvetted handoff propagates: within days, security scanners flagged dozens of downstream projects pulling the malicious code transitively without any direct awareness they depended on it.
XZ Utils in March 2024 offers the most sophisticated version of this pattern. A contributor using the handle "Jia Tan" spent roughly two years building trust and commit history before being granted co-maintainer status on a compression library embedded in most Linux distributions. That access was ultimately used to insert a backdoor into the build process targeting OpenSSH, discovered only by chance when a Microsoft engineer, Andres Freund, noticed a 500-millisecond latency anomaly during routine performance testing. The original maintainer, Lasse Collin, had publicly described feeling overwhelmed and welcomed help years earlier, exactly the vulnerable moment succession planning is supposed to protect against.
Why don't foundations or companies just step in and formalize this?
They do, but only for a small fraction of projects that are already famous enough to attract attention. The OpenSSF's Alpha-Omega project, backed by Google, Microsoft, and Amazon, funds security work on roughly 100 to 130 critical open source projects a year, and Tidelift, GitHub Sponsors, and similar programs pay a subset of maintainers directly. But the Census III data referenced above covers tens of thousands of packages that sit deep in dependency trees, invisible to funders because no single company's leadership ever hears their name. A package with 2 million downloads a month that nobody has heard of gets no foundation attention until it fails.
Corporate consumers of open source also have a structural disincentive: paying for succession planning on a dependency is an ongoing cost with no product to show for it, while the risk of a maintainer disappearing feels abstract until the day it isn't. Legal and procurement teams rarely have a line item for "pay a stranger's open source project to have a backup maintainer."
Can package registries force better succession practices?
Partially, and npm, PyPI, and crates.io have all moved in this direction since 2022. npm began requiring two-factor authentication for maintainers of the top 100 most-downloaded packages starting in 2022, expanding the mandate through 2023 after the ua-parser-js and related incidents made credential theft an obvious attack vector. PyPI followed with mandatory 2FA for all users publishing new projects by the end of 2023. These are meaningful, but they address account takeover, not the deeper succession gap: a registry can require a second factor on a login, but it cannot require that a lonely maintainer recruit and trust a co-maintainer before burning out.
Some ecosystems have experimented with "maintainer of last resort" arrangements, where a neutral third party can be granted emergency access if a project goes dormant with open critical vulnerabilities. These remain rare and largely informal, negotiated project by project rather than built into registry policy.
How Safeguard Helps
Safeguard treats the maintainer and governance structure behind a dependency as a first-class security signal, not an afterthought. Rather than waiting for a CVE or a malicious release to appear, Safeguard's software supply chain monitoring surfaces bus-factor risk before it becomes an incident: how many active maintainers a package has, how recently commit and publish access changed hands, whether 2FA and provenance attestations are actually enforced, and whether a project shows the warning signs, long silence followed by a sudden new co-maintainer, that preceded event-stream, ua-parser-js, and XZ Utils.
For engineering and security teams, that means dependency risk scoring that accounts for succession and governance health alongside known vulnerabilities, alerts when a critical package's maintainer roster changes unexpectedly, and visibility into which parts of your software bill of materials rely on projects with a single point of human failure. Instead of discovering a succession failure the way Andres Freund did, by chance, Safeguard is built to help your organization see it coming.