Dumb ways for an open source project to die
Open source projects often fade not through dramatic failure but via maintainer burnout, loss of interest, hostile or overambitious forks, and rising maintenance burdens driven by dependencies, security churn, and user support expectations. Commenters argue that it’s unreasonable to expect hobby maintainers to provide enterprise-grade support, and highlight “responsible sunsetting” (archiving, documenting status, or handing over stewardship) as a healthier alternative to quiet abandonment. Several note that today’s ecosystem and corporate pressures—GitHub workflows, license flips, contract clauses restricting OSS work, and spammy bots—have made sustaining volunteer projects substantially harder than simply “sharing a solution.”
Forks: Failure, Success, and Politics
- “Overconfident” or rage-forks often die without traction, but some succeed or re-merge (e.g., io.js/Node, EGCS/GCC, Compiz/Beryl).
- Forks are sometimes hostile and sometimes amicable; they can reflect either personal conflict or simply divergent needs.
- Some maintainers resent forks despite using open licenses; others accept forks as a healthy way to explore different directions.
Sunsetting, Burnout, and Scope Creep
- Common death modes: maintainer vanishes, loses interest, or finds maintenance cost disproportionate to user interest.
- “Responsible sunsetting” is praised: archive the repo, document its status, optionally provide handover guidance.
- Scope creep driven by vocal users or merged one-off features can bloat a focused tool into an unmaintainable mess.
- Bots, security-scanner PRs, and dependency updaters add noise and maintenance overhead.
Users, Expectations, and Money
- Tension between “open source is altruistic, no obligations” vs. maintainers drowning in unpaid support for organizations that refuse contracts.
- Some projects flip licenses or go commercial when free support for complex use cases becomes untenable.
- Open core and “almost-useful” free editions are criticized as traps.
Stability, Dependencies, and “Dead” Projects
- Disagreement on what “dead” means: no commits vs. “mature and done.”
- Some value decades-stable stacks with minimal deps; others emphasize rising security CVEs and ecosystem churn.
- Dependency rot, transitive breaks, and fragile registries (e.g., npm) are recurring complaints.
- Some argue you can just pin old versions; others note security, hiring, and tooling pressures to upgrade.
Culture, Platforms, and Governance
- Perceived shift from “here’s my solution, use it if helpful” to brand-building, resume content, and evangelism.
- GitHub is seen as both enabler and trap: issues/PRs create social obligations; stars and badges distort incentives.
- Licensing debates: permissive vs. copyleft, user rights vs. corporate adoption, and fear of successors abusing trust.
- Employment contracts restricting OSS work are reported; in some jurisdictions, commenters claim such clauses are partly unenforceable.
- Some mention political takeovers via governance/Codes of Conduct as another (contested) failure mode.