Dumb Ways for an Open Source Project to Die

This article, titled "Dumb Ways for an Open Source Project to Die," draws inspiration from the "Weekend at Bernie's" premise to identify a vast array of reasons why open-source packages, even widely depended-on ones, can become defunct or effectively unmaintained. Author Andrew Nesbitt meticulously categorizes these scenarios, highlighting that project death isn't always a clear-cut event but can manifest in many subtle and surprising forms.

The article outlines several major categories of project demise:

• The Maintainer Left: This includes cases like a 'ghost maintainer' who simply vanished, a 'corporate orphan' project whose team moved on, a 'thesis orphan' by a graduated student, a project hitting a 'funding cliff,' or a maintainer being 'hired away' and unable to continue their OSS work. It also covers 'succession deadlock' where potential successors can't gain access.
• The Maintainer Is Still There: This category covers scenarios where the maintainer is technically present but ineffective, such as 'burnout plateau' (minimal activity), a 'benevolent zombie' (only bots making commits), 'custody battle' between co-maintainers, 'tribal knowledge gone' (no one understands the core code), or 'toxic gatekeeping' driving away contributors.
• Sabotage and Capture: This dark side includes a 'captured maintainer' (like xz or event-stream) where a malicious actor gains control, or 'protestware' where a legitimate maintainer intentionally breaks their own package (e.g., colors, faker, node-ipc).
• The Release Pipeline Broke: Projects can die if 'maintained-not-shipping' (development happens but releases don't), 'unreleasable main' (the main branch is too far ahead of the last tag), 'build archaeology' (the build environment is lost), or 'shadow-maintained' (public repo is just a dump from a private monorepo).
• Force Majeure: External factors like 'sanctions-stranded' maintainers or a project being a 'takedown casualty' due to legal disputes.
• The World Moved On: Projects can become irrelevant due to 'platform-stranded' dependencies, 'transitive death' from a dead dependency, an 'API rug-pull' from an external service, or being 'superseded' by new language features or better alternatives.
• The Project Split: This covers 'fork limbo' where no single fork wins, 'licence rug-pull aftermath' leading to community forks, and 'open-core hollowing' where interesting development moves to the paid version.

Ultimately, the article serves as a comprehensive warning about the myriad vulnerabilities of open-source projects, often leaving downstream users reliant on code that is, for all intents and purposes, dead, even if it's still being 'wheeled around the party with sunglasses on.'