Andrew Nesbitt’s May 19 post catalogs the ways open-source projects die, and the striking part is not the variety but how many of those deaths are invisible to the health-score dashboards most teams rely on. OpenSSF Scorecard and similar tools measure security-oriented signals like branch protection, CI configuration, and recent activity. The failure modes Nesbitt describes show those metrics systematically miss the slower, more common killers.
What Nesbitt Actually Wrote
The post, titled “Dumb Ways for an Open Source Project to Die,” sorts project deaths into categories. The first and most detailed covers maintainer departure: ghost maintainers who simply stopped responding, corporate orphans abandoned after a pivot or layoff, thesis orphans left behind by graduated researchers, projects that fell off a funding cliff, maintainers hired away by companies that don’t permit outside open-source work, and succession deadlocks where the original maintainer is unreachable and no one else has write access. Each sub-pattern is illustrated with real examples pulled from the npm and Packagist ecosystems.
The taxonomy is notable because it refuses the easy narrative. The most discussed failure mode in open-source sustainability writing is the bus factor, the risk that a key maintainer gets hit by a bus. Nesbitt’s framework argues that bus-factor deaths are the simple cases. The harder ones are projects that look alive but aren’t, or projects killed by forces entirely outside their own repo.
Bot Activity and the Recency Illusion
Consider a project whose contribution graph is solid green, but where every commit is a bot. Dependabot bumps, auto-merged dependency updates, and similar automated activity keep the repo looking maintained. Every recency-based health score rates this project as fine.
The core problem is that recency-based health scores were never designed to distinguish between human maintenance and automated churn. A project that hasn’t had a human review a pull request in two years can still post green squares every week. If your dependency selection criteria include “last commit within 90 days,” you are selecting for bot activity, not maintainer engagement.
Dependency-Graph Propagation: The Recursive Killer
The pattern most likely to affect teams that think they’re safe is recursive dependency death. A healthy, actively maintained project dies because something two or three levels down its dependency tree has died, and that lower dependency cannot be swapped without a rewrite of the layers above it.
This is a structural problem that no single-repo health metric can capture. Scorecard evaluates repositories individually. It has no mechanism to flag that your direct dependency is healthy but depends on a package whose maintainer last responded to an issue in 2022. The death propagates upward through the dependency graph, and by the time it reaches your package.json, the fix is no longer a version bump but an architectural decision.
Supply-Chain Incidents: The Cases That Shaped the Conversation
The supply-chain incidents that shaped how the industry thinks about open-source risk are well documented. The xz backdoor, discovered in March 2024, involved a two-year social-engineering campaign to gain maintainer access before inserting a backdoor into a compression library used by nearly every Linux distribution. The event-stream incident in 2018 saw a volunteer contributor add cryptocurrency-wallet-stealing code to a widely used npm package. The colors and faker sabotage in 2022 saw a maintainer intentionally corrupt their own packages to protest the ecosystem. And left-pad in 2016 demonstrated what happens when a single 11-line package is unpublished and thousands of builds break.
Each of these fits a different sub-pattern. Xz was patient, targeted social engineering. Event-stream was opportunistic malicious contribution. Colors/faker was maintainer self-sabotage. Left-pad was unilateral unpublishing. The diversity matters: there is no single defense that addresses all four.
The Metrics Blind Spot
Nesbitt’s argument, read against what OpenSSF Scorecard is designed to do, exposes a real gap. Scorecard evaluates security-oriented signals: branch protection, CI configuration, and similar repository hygiene indicators. These are useful signals for some risks. They are the wrong signals for the death modes Nesbitt catalogs.
Burnout plateaus, where a maintainer is still technically present but has stopped responding to issues or reviewing PRs, score as healthy under recency metrics. Repositories kept alive only by bot activity score as healthy. Shadow-maintained projects, where the listed maintainer has handed off to someone not reflected in the repository metadata, may score as unhealthy despite being well cared for.
The gap is not a flaw in Scorecard’s design. The tool was built to measure security practices, not maintainer sustainability. But in practice, Scorecard scores are used as proxies for overall project health, including sustainability. When a procurement team or a compliance checklist asks “is this dependency healthy?” and the answer comes from Scorecard, the question being answered is not the one being asked.
What OpenSSF Is Doing About It
Two days after Nesbitt’s post, OpenSSF announced its Q2 2026 growth at Community Day North America on May 21. The foundation added five new members: ActiveState, Aikido, Minimus, TuxCare, and the FreeBSD Foundation. It also accepted OSS-CRS as a sandbox project, described as an AI-driven system for automated vulnerability finding and patching.
The timing is coincidental but the juxtaposition is useful. OpenSSF is expanding its membership and its tooling portfolio. The question Nesbitt’s taxonomy raises is whether that tooling is measuring the right things. OSS-CRS, focused on automated vulnerability discovery, addresses a different category of risk than the one Nesbitt is describing. No OpenSSF tool currently tracks maintainer burnout trajectories, distinguishes human commits from bot activity, or evaluates transitive dependency health across multiple hops.
Practical Signals for Dependency Consumers
For engineering teams making dependency decisions today, the actionable takeaway from Nesbitt’s taxonomy is that the signals that actually predict abandonment are not the ones in standard dashboards. Based on the patterns in the post, the indicators worth checking are:
Oldest unanswered issue. A project with open issues older than six months that have no maintainer response, not even a triage label, is in a burnout plateau regardless of what the commit graph shows.
Last human commit date. Exclude Dependabot, Renovate, and other automated commits. If the last human-authored commit was more than a year ago, the project’s maintenance is automated, not intentional.
Registry-to-source integrity. Verify the package registry entry points to a reachable, current source repository. A non-trivial fraction of packages in any large registry may have no recoverable source.
Publish account accessibility. Whether the npm or PyPI account that owns the package is still accessible to a living maintainer. This is the left-pad vector: the account exists, the package exists, but the human behind it has moved on.
None of these signals appear in OpenSSF Scorecard today. Building them into a dependency review workflow requires custom tooling or manual audit. The alternative is accepting that your health scores are measuring maintenance theater, not maintenance.
Frequently Asked Questions
How many failure categories does Nesbitt’s taxonomy actually define?
The post organizes project deaths into seven major categories (maintainer left, maintainer still there, sabotage/capture, release pipeline broke, force majeure, world moved on, project split) with 25+ named sub-patterns. Most coverage of the post focuses on maintainer departure and dependency death, but categories like release-pipeline failure and project split describe structural risks that have nothing to do with maintainer motivation or availability.
How many registry packages are orphaned with no recoverable source?
Prior analysis cited in the post puts the figure at roughly 1.7% of npm packages and 4% of Packagist packages whose source repo URLs return 404. These percentages translate to tens of thousands of packages across the two registries: still installable, but with no upstream to file issues against, submit patches to, or fork.
What else did OpenSSF announce alongside the new members?
The same Community Day North America announcement included CRA (Cyber Resilience Act) compliance guides for open-source projects, positioning the foundation’s Q2 2026 work toward regulatory alignment with the EU’s forthcoming software-security requirements. That regulatory focus is orthogonal to the maintainer-sustainability measurement gap Nesbitt identifies.
What is the ‘project split’ death mode and why does it break health scores?
Project split occurs when a community forks a package and the successor thrives under a new name while the original repository goes dormant. Health scores attached to the original package name will report decline or abandonment, even though the codebase is actively maintained elsewhere. The inverse of the benevolent-zombie problem: the score is directionally wrong in the opposite direction.