Dumb Ways for an Open Source Project to Die
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A comprehensive taxonomy of the ways open source projects effectively die, even when they still appear alive in package registries. Covers 25+ failure modes organized into categories: maintainer departure (ghost maintainers, corporate orphans, funding cliffs), maintainer still present but ineffective (burnout, benevolent zombies run by bots, tribal knowledge loss), sabotage and capture (xz-style social engineering, protestware), broken release pipelines (publish rights lost, unreleasable main branches, shadow-maintained repos), force majeure (sanctions, DMCA takedowns), the world moving on (platform-stranded, superseded by native language features), and project splits (fork limbo, licence rug-pulls, open-core hollowing). The key insight is that a package resolving from a registry is no guarantee it's actually maintained, and lockfiles keep installing dead packages indefinitely because nobody checks.
Table of contents
The maintainer left #The maintainer is still there #Sabotage and capture #The release pipeline broke #Force majeure #The world moved on #The project split #Sort: