请不要问一个开源项目是不是死了
当人们询问某个项目是否“已死”时，开源维护者与用户之间的紧张关系就会显现出来，尤其是在那些看起来很安静或存在未解决问题的仓库中。评论者认为，用户在依赖软件之前，合理地需要知道它是否仍在维护；而维护者则强调他们并不欠持续支持，这类问题可能让人感到被施压或士气低落。许多人建议在 README 中更清楚地展示状态、改进 GitHub 工具（归档、徽章、继任路径），并使用更体贴的措辞，以便让双方的预期更好地对齐。
问“这个项目死了吗”是否失礼
- 很多人认为这完全是个合理、甚至必要的问题：用户必须知道依赖某个库是否安全，尤其是涉及安全修复和上游破坏性变更时。
- 也有人说像“dead/abandoned”这样的措辞带有情绪色彩，感觉像在指责；他们建议使用更中性的说法，比如“当前维护状态”或“是否在积极维护？”。
- 几位评论者认为文章中的具体示例提问很礼貌，而把它称作“施压”或“失礼”是基于压力和倦怠的过度反应。
维护、生态系统与“完成了”的软件
- 有人说软件可以是“完成了”的，不需要频繁提交；缺少活动本身并不一定是问题。
- 也有人反驳说，在 Node/npm 这类生态或快速变化的 API 环境中，代码老化和依赖安全问题使持续维护变得必要。
- 关于“代码腐烂”的争论：有些人把问题归咎于不断变化的平台和糟糕的向后兼容，而不是原始代码本身。
Fork 与项目继任
- 许多人认为，当维护者不回应或对 PR 没兴趣时，fork 是标准解决方案。
- 也有人指出其弊端：会出现多个半维护的 fork、“继任者”不明确、社群分裂，以及如果原项目之后复活，重新 rebase 会很痛苦。
- 另一些人指出，Linux、BSD、办公套件、浏览器引擎等重要项目都源自 fork；大多数 fork 失败被视为正常现象。
预期、沟通与 GitHub 功能
- 反复出现的建议是：在 README/CONTRIBUTING 中清楚说明状态和预期（例如“已完成”“仅安全修复”、PR 策略、对 fork 的态度）。
- GitHub 的 archive 标记被视为一种有用但未被充分使用的方式，用于表明不活跃；有些人希望有更丰富的状态/徽章机制，以及用于突出活跃 fork 的界面。
- 还有几位说，如果你不想互动，关闭 issues/PRs 是合适的。
责任与心理健康
- 大致共识是：维护者在合同上并不欠用户什么；用户和贡献者同样也不欠维护者什么。
- 尽管如此，很多人强调基本礼貌、感谢，以及提供帮助或赞助的意愿。
- 有些人把这篇文章看作倦怠的信号，并建议退一步，而不是发布带有规定性、情绪化的“不要问”规则。