文章指出开源项目常见的消亡方式：维护者离开（如长期不更新、公司团队解散却未移交）导致项目无人管理，问题堆积却仍被使用，最终成为"僵尸项目"。这种情况在外界看来与暂时停更难以区分，直到问题积累到无法忽视。

开源项目的愚蠢消亡方式

根据《伯尼的周末》一文揭示，许多被广泛依赖的开源项目实际上已经"死亡"，而其消亡方式多种多样。

一、维护者离开的情况 1. 幽灵维护者：最常见的情况是维护者多年前就已停止更新，问题堆积无人回应，但项目仓库未被归档。 2. 企业弃儿：公司开源项目后因团队变动无人维护，甚至无人知晓该项目归属。 3. 学术弃婴：研究生毕业后无人接手的学术项目。 4. 资金断供：项目因资助到期而失去全职维护能力。 5. 被企业收编：维护者加入限制外部开源贡献的企业（如苹果）。 6. 继承僵局：原维护者失联，但项目权限无法转移。

二、维护者在位但项目停滞 1. 倦怠期：维护者仅处理简单问题，重大决策无限期搁置。 2. 僵尸项目：完全由自动化机器人维护的"活跃"假象。 3. 维护权之争：共同维护者内斗导致项目冻结。 4. 知识断层：关键算法仅原开发者理解，无人敢修改核心代码。 5. 毒性把关：维护者态度恶劣吓退贡献者。

三、蓄意破坏与劫持 1. 维护者劫持：恶意贡献者通过社会工程学手段获取权限后植入后门。 2. 抗议软件：维护者故意破坏自己的项目。

四、发布渠道故障 1. 无法发布：失去发布权限或2FA设备导致修复无法推送。 2. 主分支偏离：默认分支与发布版本差异过大。 3. 构建考古：无法复现原有构建环境。 4. 影子维护：实际开发在私有仓库进行，公开仓库仅定期同步。

五、不可抗力因素 1. 制裁影响：维护者因地域制裁无法操作。 2. 下架处理：因版权或商标纠纷被平台移除。

六、技术淘汰 1. 平台淘汰：依赖已终止支持的技术栈。 2. 依赖链死亡：关键依赖项目死亡导致连锁反应。 3. API废止：依赖的外部服务关闭或变更。 4. 功能过时：语言原生实现或新标准取代项目价值。

七、项目分裂 1. 分叉困境：项目分裂后下游用户不敢迁移。 2. 许可证变更：项目改用非开源许可后的社区分叉。 3. 开源核心空心化：主要开发转向商业版本。

正如墨尔本地铁安全宣传所说"注意火车安全"，对于开源项目而言，最重要的是保持警惕。无论项目以何种方式"死亡"，在依赖锁定文件中它们看起来都依然"活着"，直到有人仔细检查。

以下是评论内容的总结，按主要观点分类呈现：

1. 项目分叉问题

• 观点：过度自信的分叉往往失败，而成功的分叉（如OpenSSH）会取代原项目
• 引用："overconfident fork...never gains critical mass" (tomwheeler)
• 引用："OpenSSH...community moved on" (tomwheeler)

2. 维护困境

• 观点：用户只索取不贡献导致维护者放弃
• 引用："users only take...never contribute back" (ndepoel)
• 观点：维护者将项目视为个人帝国，抵制分叉
• 引用："treat forks as hostile...fork deadlock" (Aurornis)

3. 外部干扰

• 观点：第三方牟利导致维护者放弃
• 引用："tried to profit off...pissed the maintainer" (sva_)
• 观点：大公司窃取项目并打压原作者
• 引用："claimed they wrote all the code...gang stalking" (kittikitti)

4. 开发模式争议

• 观点：现代开源动机不纯（个人品牌/竞争）
• 引用："building personal brand...outsmart somebody" (prymitive)
• 观点：私有代码库+公开转储模式仍然有效
• 引用："Real development happens...private monorepo" (charcircuit)

5. 维护压力

• 观点：功能蔓延导致项目复杂化
• 引用："scope creep...Swiss army knife" (apollyx_jojo)
• 观点：过度维护要求不合理
• 引用："ridiculous...expected to be maintained weekly" (killerstorm)

6. 项目生命周期

• 观点：项目"死亡"是正常生态现象
• 引用："parts of the software ecosystem's lifecycles" (zem)
• 观点：无维护≠死亡，软件存在即有价值
• 引用："not a single other person uses it...not 'dead'" (BrianKWhite)

7. 替代方案建议

• 观点：应建立函数/类型中心而非大型库
• 引用："build a function hub...mix and match" (usernametaken29)

注：所有评论均无评分数据。总结保留了不同观点的平衡性，每个观点选取2-3条最具代表性的原始评论引用。