Please Don't Ask If an Open Source Project Is Dead
Tension between open-source maintainers and users surfaces when people ask if a project is “dead,” especially on repos that appear quiet or have unresolved issues. Commenters argue that users reasonably need to know whether software is maintained before depending on it, while maintainers stress they owe no ongoing support and can feel pressured or demoralized by such questions. Many propose clearer status signals in READMEs, better GitHub tooling (archiving, badges, succession paths), and more considerate phrasing so expectations on both sides are better aligned.
Whether Asking “Is This Project Dead?” Is Rude
- Many argue it’s a perfectly reasonable, even necessary question: users must know if depending on a library is safe, especially for security fixes and breaking upstream changes.
- Others say phrasing like “dead/abandoned” is emotionally loaded and feels accusatory; they suggest neutral wording such as “current maintenance status” or “actively maintained?”
- Several commenters think the specific example issue in the article was polite, and that labeling it “pressure” or “rude” was an overreaction rooted in stress and burnout.
Maintenance, Ecosystems, and “Done” Software
- Some say software can be “done” and not need frequent commits; lack of activity isn’t inherently a problem.
- Others counter that in ecosystems like Node/npm or fast‑moving APIs, bit‑rot and dependency security issues make ongoing maintenance essential.
- Debate over “code rot”: some blame changing platforms and poor backwards compatibility rather than the original code.
Forking and Project Succession
- Many consider forking the standard remedy when a maintainer is unresponsive or uninterested in PRs.
- Downsides noted: multiple half‑maintained forks, unclear “successor,” social fragmentation, and painful rebases if the original project later revives.
- Others point out that important projects (Linux, BSDs, office suites, browser engines) emerged from forks; most forks failing is seen as normal.
Expectations, Communication, and GitHub Features
- Repeated suggestion: clearly state status and expectations in README/CONTRIBUTING (e.g., “finished,” “security‑fixes only,” PR policy, attitude toward forks).
- GitHub archive flag is seen as a useful, but underused, way to indicate inactivity; some want richer status/badge mechanisms and UI for highlighting active forks.
- Several say turning off issues/PRs is appropriate if you don’t want interaction.
Responsibilities and Mental Health
- Broad agreement: maintainers owe users nothing contractually; users and contributors also owe maintainers nothing.
- Nonetheless, many stress basic politeness, gratitude, and offers of help or sponsorship.
- Some see the article as a sign of burnout and advise stepping back rather than publishing prescriptive, emotionally charged “don’t ask” rules.