Dumb Ways for an Open‑Source Project to Die

Andrew Nesbitt – May 2026

The recent Weekend at Bernie’s analysis showed that a surprising share of the most‑depended‑on npm and Packagist packages are effectively dead. The problem isn’t a single cause; it’s a collection of recurring patterns that leave downstream projects stranded, lockfiles bloated, and security scanners confused. Below is a practical catalogue of those patterns, why they happen, and what the fallout looks like for anyone who still pulls the package.

---

1. Ghost maintainer

What it looks like – The last human commit dates back years, issues pile up unanswered, and the repository is never archived, so automated health checks still see it as “alive.” Why it happens – The original author moved on, didn’t hand over ownership, and may even be deceased. Registries have no field for “maintainer deceased.” Impact – Downstream users can’t rely on timely bug fixes or security patches; the package becomes a hidden technical debt.

---

2. Corporate orphan

What it looks like – A company open‑sourced a library, then a pivot or layoff removed the dedicated team. The GitHub organization remains, but the admins have left. Why it happens – Large firms often forget to deprecate internal tooling that never shipped as a product. The README stays untouched, giving a false sense of support. Impact – Enterprises that adopted the library may find themselves without a point of contact when a critical vulnerability surfaces.

---

3. Thesis orphan

What it looks like – A graduate‑student project that never graduated to a maintained codebase. The lab owns the repo but has no incentive to keep it alive. Why it happens – Academic credit is tied to publications, not to long‑term software stewardship. Impact – Papers continue to be cited while the underlying code no longer builds, breaking reproducibility.

---

4. Funding cliff

What it looks like – A library built on a grant or foundation sponsorship stops receiving money; maintainers revert to part‑time, weekend work. Why it happens – The funding period ends on schedule, and there is no hand‑off plan. Impact – Critical bugs linger, and the package’s health score stays artificially high because the repo still receives occasional commits.

---

5. Hired away

What it looks like – A maintainer joins a new employer that restricts open‑source contributions (e.g., Apple’s policy). Why it happens – Employment contracts or workload changes cut off the maintainer’s ability to continue the project. Impact – The project stalls without a successor, and downstream users receive no notice.

---

6. Succession deadlock

What it looks like – Interested volunteers can’t take over because the npm (or PyPI) publishing rights are tied to an inaccessible account, and the GitHub repo has no other admins. Why it happens – Registry dispute processes (PEP 541, npm’s policy) require the original maintainer’s consent, leading to months‑long stalemates. Impact – Fork‑and‑rename becomes the only practical rescue, but the community often lacks the coordination to do it cleanly.

---

7. Burnout plateau (maintainer still there)

What it looks like – Small typo fixes and dependency bumps land, but any substantive design work stalls. Why it happens – The maintainer lacks the energy for deep work, yet still wants to appear responsive. Impact – The project hovers in a gray area—alive enough to deter forks, dead enough to frustrate users.

---

8. Benevolent zombie

What it looks like – All commits are generated by bots (Dependabot, auto‑merge, scheduled releases). Why it happens – Automation keeps the version number moving, but no human reads the code. Impact – Recency‑based health metrics flag the project as healthy, masking the lack of real maintenance.

---

9. Custody battle

What it looks like – Two co‑maintainers block each other’s changes, leaving the repo frozen. Why it happens – Personal disagreements create a stalemate where neither party has full control. Impact – Users receive contradictory answers in issue threads; the project rarely sees a new release.

---

10. Tribal knowledge gone

What it looks like – Tests pass, but the original author understood a critical algorithm that no one else can modify safely. Why it happens – The code implements a complex paper‑derived solution without documentation. Impact – Any attempt to evolve the library is deemed too risky, effectively making it read‑only.

---

11. Toxic gatekeeping

What it looks like – The maintainer is present but hostile; new contributors are rebuffed, keeping the bus factor at one. Why it happens – Personality clashes or a desire for control create an unwelcoming environment. Impact – When the maintainer finally steps away, there is no community ready to take over.

---

12. Captured maintainer (sabotage)

What it looks like – A malicious actor gains co‑maintainer rights and publishes a backdoored release (e.g., the 2018 event‑stream incident). Why it happens – Social‑engineering or goodwill exploitation. Impact – Downstream supply chains are compromised until the package is removed or a fork is created.

---

13. Protestware

What it looks like – The legitimate maintainer deliberately publishes a breaking or malicious version as a political statement (e.g., colors and faker in 2022). Why it happens – Authors use their packages as a platform for protest. Impact – Consumers are forced to choose between the package’s functionality and the author’s message.

---

14. Maintained‑but‑not‑shipping

What it looks like – Commits land in Git, but the package cannot be published because the publishing account is lost or 2FA is broken. Why it happens – Account loss, company dissolution, or missing credentials. Impact – Downstream projects are stuck on the last published version, even though fixes exist in the repo.

---

15. Unreleasable main

What it looks like – The default branch has diverged so far from the last tag that a new release would be a breaking change. Why it happens – No one wants to own the risky migration. Impact – Users continue to depend on an ancient tag while development proceeds in isolation.

---

16. Build archaeology

What it looks like – The published tarball works, but reproducing the build requires a CI service, Docker image, or toolchain that no longer exists. Why it happens – Build environments are often undocumented and tied to a single maintainer’s workstation. Impact – New releases become a reverse‑engineering project, delaying critical patches.

---

17. Shadow‑maintained

What it looks like – The public repo receives periodic “sync” commits from a private monorepo; all real work happens behind closed doors. Why it happens – Companies use the open repo as a publishing façade. Impact – Issues filed on the public repo go unanswered, and users can’t see the true development cadence.

---

18. Stranded major version

What it looks like – Version 4 is actively maintained, but the ecosystem still runs on version 1 because version 2 was a dead‑end rewrite. Why it happens – Migration costs are high; many downstream projects never upgrade. Impact – Security fixes in the newer major may never reach the majority of users.

---

19. Registry orphan

What it looks like – The package’s source URL 404s; the repo was deleted, made private, or moved without updating the registry metadata. Why it happens – Owners forget to update the package manifest after a migration. Impact – About 1.7 % of npm and 4 % of Packagist packages resolve to nowhere, yet they still appear in lockfiles and get installed.

---

20. Sanctions‑stranded

What it looks like – The maintainer’s account is frozen due to export controls or sanctions, even though they are willing to publish. Why it happens – Geopolitical restrictions block access to npm or GitHub. Impact – Downstream users see the same symptoms as a ghost maintainer, but the maintainer may be publicly explaining the situation elsewhere.

---

21. Takedown casualty

What it looks like – A DMCA or trademark claim removes the package from the registry (e.g., youtube‑dl in 2020). Why it happens – Legal disputes can silence a package regardless of its technical merit. Impact – Forks may appear, but many downstream projects stay on the last reachable version.

---

22. Platform‑stranded

What it looks like – The library only runs on a deprecated runtime (Python 2, old Node versions, a removed compiler extension). Why it happens – No one is willing to invest the effort to port it forward. Impact – The package becomes unusable for new projects, yet old lockfiles still reference it.

---

23. Transitive death

What it looks like – The library itself is fine, but a deep dependency has vanished, making the whole chain unbuildable. Why it happens – Dependency trees are recursive; a single dead leaf can poison the entire branch. Impact – Projects that depend on the healthy library inherit the failure without any visible change in their own repo.

---

24. API rug‑pull

What it looks like – The library wraps an external service that shuts down or becomes paid (e.g., Twitter API changes in 2023). Why it happens – Service owners can change terms at will. Impact – The client library becomes obsolete overnight, and downstream code must be rewritten.

---

25. Superseded

What it looks like – The functionality is now native to the language or runtime (e.g., object-assign after Object.assign). Why it happens – Language evolution makes the library redundant. Impact – The package lingers in lockfiles for years; removal is low priority, but the code is no longer maintained.

---

26. Fork limbo

What it looks like – A disagreement splits the community across multiple forks, none of which gains clear dominance. Why it happens – Governance disputes or maintainer exits. Impact – Downstream users freeze on the pre‑split version, while active development lives elsewhere under a new name.

---

27. Licence rug‑pull aftermath

What it looks like – The original project relicenses to a non‑OSS licence; a community fork continues under the old licence but never consolidates. Why it happens – Commercial interests re‑license code. Impact – Most lockfiles still point to the last open‑source release, creating a fixed point that no one maintains.

---

28. Open‑core hollowing

What it looks like – The core open‑source repo stays alive, but the most valuable features live only in a paid edition. Why it happens – Companies adopt an open‑core model to monetize. Impact – Users of the free tier see only incremental updates, while the real innovation moves behind a paywall.

---

Why the taxonomy matters

Each of these failure modes leaves a similar symptom: a package that still resolves in a lockfile but no longer receives meaningful upkeep. The downstream consequences are cumulative—security patches go unfixed, build pipelines break, and teams waste time chasing ghosts.

What can the ecosystem do?

1. Better hand‑off tooling – npm’s npm owner add and PyPI’s collaborator commands should support multi‑factor recovery without the original maintainer.
2. Public deprecation metadata – A field in package.json or pyproject.toml that explicitly marks a project as “archived” would let registries surface dead packages in search results.
3. Automated fork‑and‑maintain bots – Projects like renovate already generate PRs; a similar bot could detect a ghost maintainer pattern and open a well‑documented fork.
4. Community escrow funds – Small grants that activate when a maintainer signals an upcoming exit could pay for a successor’s onboarding.
5. Legal‑friendly licensing – Dual‑licensing or permissive licences make it easier for the community to fork when a corporate owner disappears.

The list above is not exhaustive, but it captures the most common ways a beloved library can slip into oblivion. Recognizing the pattern is the first step toward building safeguards that keep the open‑source supply chain healthy, even when the people behind the code move on.

---

The Melbourne Metro safety campaign this post is named after closes with “be safe around trains,” which is more actionable than anything I’ve got.