- Open source projects die in at least ten distinct ways, most of which are invisible to the developers depending on them.
- Many critical open source projects show every sign of health — green commit graphs, recent releases — while being effectively unmaintained.
- Corporate orphans and thesis orphans account for a huge share of abandoned packages that never get a formal deprecation notice.
- Fixing how open source projects die starts with registries and platforms acknowledging that silence and bot activity look identical to health.
- Open source projects die in at least ten distinct ways, most of which are invisible to the developers depending on them.
- Many critical open source projects show every sign of health — green commit graphs, recent releases — while being effectively unmaintained.
- Corporate orphans and thesis orphans account for a huge share of abandoned packages that never get a formal deprecation notice.
- Fixing how open source projects die starts with registries and platforms acknowledging that silence and bot activity look identical to health.
The Open Source Graveyard Nobody Wants to Map
Open source projects don’t just die — they haunt us. A project called Weekend at Bernie’s made waves recently by revealing just how many of the most-depended-on packages in the npm ecosystem are, functionally, corpses. Not archived. Not deprecated. Just… quiet. Still being pulled into production builds by millions of developers who have no particular reason to look twice. The dependency graph that underpins the modern web is, in places, a graveyard where the headstones haven’t been put up yet.
What’s striking isn’t that open source projects die — that’s always been true, and anyone who’s spent time in the ecosystem knows it. What’s striking is how many different ways they can die, and how few of those ways look like death from the outside. The signals we use to assess project health — recent commits, closed issues, a green contribution graph — are failing us badly, and the consequences are real. Dead or zombie packages sitting in your dependency tree aren’t just a philosophical problem; they’re a security risk, a maintenance liability, and a quiet tax on every team that inherits them.
Ghost Maintainers and Corporate Orphans: The Most Common Killers
The simplest case is what you might call the ghost maintainer. A developer builds something useful, shares it, and then quietly moves on. No announcement, no archive flag, no handover. Issues accumulate. PRs go unreviewed. The repo just sits there, technically public and technically alive, while being completely inert. This covers everything from burnout and career changes to, in some cases, the maintainer having died — a reality that neither npm, PyPI, nor GitHub has any formal mechanism to represent or surface.
Corporate orphans are arguably even more insidious. A company builds and open-sources a tool, staffs a team around it, and then a pivot or a round of layoffs dissolves that team overnight. The GitHub org persists, the company logo stays in the README, but the people who had admin access are gone. Often nobody still at the company even knows the project exists. Google is the most famous repeat offender here — its history of abandoned open source initiatives is long enough to have generated genuine cultural memes — but every large company past a certain scale has a few of these in the attic. Infrastructure tools are the worst victims. They rarely get a deprecation notice because they were never really treated as products.
Then there’s a category that doesn’t get enough attention: the thesis orphan. A grad student builds something genuinely useful for their PhD or master’s project, puts it on GitHub, and then graduates. The university lab nominally owns the repo, but nobody there has the context to continue it, and academia’s incentive structure actively punishes anyone who tries. Maintaining someone else’s software earns no citations. It counts for nothing at grant review or tenure consideration. The result is that research software is littered with tools that are still being cited in papers years after the code stopped building. The paper lives on; the software is a fossil.
Open Source Projects and the Funding Cliff
One of the more quietly devastating failure modes is what happens when grant funding ends. A lot of open source projects — particularly in scientific computing, security, and infrastructure — run on fixed-term grants from foundations or public software funds. The money arrives, a maintainer or small team works full-time, the project grows to match that capacity, and then the grant ends on schedule. The maintainers go back to whatever actually pays the rent. A project that needed 40 hours a week now gets evenings and weekends, which for that scope rounds to nothing.
The cruel irony is that the funder’s logo usually stays in the README long after the money stopped, which makes these projects actively misleading. To any outside observer, it looks like a sponsored, actively supported project. It’s not. The funding cliff is also a structural critique of how the industry approaches open source sustainability — throwing money at a problem for two years and then walking away doesn’t build lasting infrastructure, it builds a dependency on a ticking clock.
The “hired away” pattern is related but distinct. A maintainer gets picked up by a company — sometimes deliberately, sometimes not — and the new job either contractually prohibits outside open source work or simply consumes all available energy. Apple is the canonical example cited in this context: the company is well-known for employment terms that effectively end a developer’s open source contributions by default. The fix — handing the project over before you accept the offer — is obvious, and almost nobody does it in time.
The Zombie Problem: When Open Source Projects Look Alive but Aren’t
Here’s where it gets genuinely weird. Some open source projects score perfectly on every standard health metric while being completely hollow. No human has reviewed anything in months. What you’re seeing is Dependabot bumping versions, an auto-merge rule accepting the bumps, and possibly an automated release pipeline cutting new versions off the back of those bumps. The contribution graph is solid green. The latest release was last week. The project is, in any meaningful sense, unmaintained.
This is what you might call the benevolent zombie — and it exposes a real flaw in how platforms and tools assess project health. Recency-based signals made sense when recency implied human attention. They don’t anymore. A project that hasn’t had a meaningful human commit in 18 months can look healthier, by these metrics, than one where a single exhausted maintainer is triaging issues every weekend.
There’s also the burnout plateau, which is subtler and in some ways sadder. The maintainer is still technically there. Typo fixes get merged. Dependency bumps land. The occasional “thanks, I’ll look at this” appears on an issue thread. But anything that requires real design thinking — a hard bug, a new feature, an architectural decision — just sits open indefinitely. There’s just enough activity that anyone who suggests forking gets pointed at recent commits, but never enough to actually ship. Open source projects can hold this shape for years.
Succession Deadlock and the Access Problem
One of the most frustrating ways for a project to die is when it doesn’t have to. The original maintainer is unreachable, but there are developers ready and willing to take over. The problem is access. Publish rights on npm or PyPI are tied to an account nobody else can log into. The GitHub repo has no other admins. The registry’s abandoned-package process — both PEP 541 for Python and npm’s own dispute policy address exactly this — requires either the original maintainer’s consent or a months-long formal dispute that nobody has clear standing to initiate.
The result is succession deadlock, and it’s maddeningly common. The process that exists to resolve it routinely takes longer than just forking the project and renaming it. Which is what most people eventually do. That’s not a solution — it’s fragmentation, and it’s part of why the open source ecosystem ends up with a long tail of near-identical forks of the same abandoned project, none of which has the install base of the original.
Toxic Gatekeeping and the Bus Factor That Never Improves
Not every dying project looks like abandonment from the outside. Some of the most dangerous failure modes are the ones that look perfectly healthy until the moment they collapse. Toxic gatekeeping is one of them. A maintainer who’s actively hostile to contributors — bruising code reviews, dismissive responses, an atmosphere that makes PRs feel like a trial — will systematically drive away everyone who might eventually take over. The bus factor stays at one not because nobody else is capable, but because nobody else can stand to work there.
These projects score well on every metric that counts commits and closed issues. When the maintainer eventually burns out or disappears, there’s no successor pool, because everyone who might have taken over was driven off years ago. It’s a slow-motion failure that looks like success until suddenly it doesn’t.
The common thread across nearly all of these failure modes is that our infrastructure for understanding the health of open source projects is broken. The signals platforms expose — commit frequency, issue closure rates, contributor counts — were designed for a world where human activity and project vitality were the same thing. They’re not anymore. Until registries and platforms build better ways to distinguish genuine maintainership from automation, inherited history, and performative activity, the software we all depend on will keep dying in ways that nobody notices until something breaks in production.
Source: https://nesbitt.io/2026/05/19/dumb-ways-for-an-open-source-project-to-die.html
