一篇在Hacker News上获得166个points的文章《Dumb Ways for an Open Source Project to Die》详细梳理了开源项目死亡的各种方式。这篇文章来自对npm生态系统的观察，但其中的教训适用于所有开源项目。
作为站长，你每天都在依赖各种开源项目。了解这些项目可能”死亡”的方式，有助于你做出更明智的选择，避免在关键时刻遭遇”孤儿”依赖。
16种开源项目的死法
1. 维护者离开（Ghost Maintainer）
最常见的情况：维护者几年前就停止了提交，Issue不断积累但无人回复，仓库没有被归档所以不会出现在任何”已弃用”的筛选中。
通常维护者只是转向了其他事情，项目对他们来说不够重要到正式交接或关闭。但同样的沉默也覆盖了维护者已经去世的情况，而注册表和仓库都无法表示这一点。
2. 企业孤儿（Corporate Orphan）
一个公司开发并开源了这个项目，然后因为业务调整或裁员，整个团队被解散了。GitHub组织带着公司的logo继续存在，但最后拥有管理员权限的人已经离开，所以通常留在公司的人甚至不知道这个项目是他们的。
Google的各种”墓地”是著名的例子，但每个达到一定规模的公司都有几个这样的项目。那些作为基础设施而非产品的项目，往往连弃用通知都不会收到。
3. 论文孤儿（Thesis Orphan）
由研究生为硕士项目或博士论文章节而建，毕业后就离开了。托管它的实验室名义上拥有仓库，但没有人有上下文继续维护，而学术界也不鼓励这样做：维护别人的软件不会获得引用，在评审中不如发表新东西有价值。
研究软件中充满了这类项目，往往论文还在被引用多年后，代码已经无法编译。
4. 资金断崖（Funding Cliff）
项目依赖于一笔拨款或固定期限的赞助，通常来自基金会或公共软件基金，资金按计划结束了。维护者回到了能付房租的工作上，一个曾经适应全职容量的项目现在只能获得晚上和周末的时间，对于那个规模来说约等于零。
资助者的logo通常在资金停止后长期留在README中，这使得这种情况很容易被误认为是健康的赞助项目。
5. 被挖走（Hired Away）
维护者被公司雇佣，要么是雇佣合同，要么只是新的工作量导致项目停止。偶尔是竞争对手在消除一个问题，但更常见的情况完全不是恶意的：Apple是典型的雇主例子，它根本不允许大多数员工做外部开源，所以维护者加入意味着他们的项目默认安静下来。
入职前交接是显而易见的解决方案，但几乎没有人这样做。
6. 单人巴士因子（Bus Factor of One）
项目只有一个人理解核心架构、发布流程或关键的内部设计决策。当那个人离开时，没有人能真正维护项目，尽管表面上看起来还在被”维护”。
7. 依赖地狱（Dependency Rot）
项目的依赖逐渐过时，最终与现代环境不兼容。没有人更新依赖，因为那需要理解代码库和测试所有变更。项目继续”工作”但只能在特定环境中。
8. 社区分裂（Community Fork）
社区对项目方向产生分歧，分叉出一个新项目。原项目可能继续存在但失去活力，或者两个分叉都因为力量分散而衰退。
9. 需求变化（Shifting Needs）
项目解决的问题不再重要，或者有了更好的替代方案。用户逐渐流失，维护者失去了继续开发的动力。
10. 法律问题（Legal Issues）
版权、专利或许可证问题迫使项目关闭或改变。这在涉及商业代码或争议性功能的项目中尤其常见。
11. 安全事件（Security Incident）
一个严重的安全漏洞被发现，但没有人有能力或意愿修复它。项目被标记为不安全，用户被迫迁移。
12. 平台变化（Platform Shift）
项目依赖的平台发生了不兼容的变化。比如Python 2到Python 3的迁移”杀死”了很多没有更新的项目。
13. 维护者倦怠（Maintainer Burnout）
维护者因为无偿工作、无理要求或社区毒性而感到疲惫，最终放弃。这是最可预防但最常见的死法之一。
14. 质量下降（Quality Erosion）
项目逐渐变得不稳定或难以使用，但没有人负责质量。用户慢慢流失，最终项目变成了”僵尸”。
15. 没有继任计划（No Succession Plan）
维护者没有培养新的贡献者，也没有文档化关键知识。当他们离开时，项目失去了所有隐性知识。
16. 静默弃用（Silent Deprecation）
项目没有明确宣布弃用，只是慢慢停止了更新。用户在遇到问题时才发现项目已经”死了”。
站长如何选择靠谱的开源项目
检查项目健康度
在选择依赖一个开源项目之前，检查以下指标：
- 最近提交时间：最后的代码提交是什么时候？超过6个月没有更新要警惕
- Issue响应速度：维护者多久回复一次Issue？是否有大量未回复的Issue？
- 发布频率：最近的版本发布是什么时候？
- 贡献者数量：是否只有一个人在贡献？Bus Factor是多少？
- 依赖健康度：项目的依赖是否都是活跃维护的？
评估风险
根据项目在你系统中的重要性来评估风险：
- 核心依赖（没有它系统无法运行）：需要最严格的选择标准
- 重要依赖（影响功能但有替代方案）：需要中等标准
- 可选依赖（锦上添花）：可以接受更高风险
建立备选方案
对于核心依赖，始终有备选方案：
- 了解有哪些替代项目
- 评估迁移的难度和成本
- 定期检查替代项目的状态
如何避免你的项目”死亡”
如果你自己也在维护开源项目，以下建议可以帮助避免上述死法：
- 培养贡献者：不要做唯一的维护者
- 文档化一切：包括架构决策、发布流程、关键配置
- 明确交接计划：如果你要离开，提前安排
- 定期更新依赖：不要让项目积累技术债
- 设置继任者：在GitHub上设置多个管理员
- 透明沟通：如果无法继续维护，明确告知社区
- 考虑归档：如果项目不再维护，归档比沉默更好
总结
开源项目的”死亡”方式多种多样，但大多数都可以预防或至少可以被及早发现。作为站长，了解这些模式有助于你做出更明智的依赖选择。作为维护者，了解这些陷阱有助于你为项目的长期健康做出更好的规划。
开源软件是现代互联网的基石，但它的可持续性仍然是一个未解决的问题。我们每个人都可以通过更负责任地选择依赖、更积极地参与社区、更透明地沟通来改善这个状况。
本文参考来源：Dumb Ways for an Open Source Project to Die | Hacker News讨论
暂无评论内容