鲸落——开源项目的生态循环

原文：Whale Fall
作者：Mike Nesbitt
翻译：汪汪

---

当一头鲸在公海死去，它的尸体会沉入海底，成为一个整的生态系统。海洋生物学家称之为"鲸落"，这个身体会经历三个重叠的阶段 来维持生命：

1. 移动食腐阶段：数月内，软组织被剥离
2. 富集机会主义阶段：数年骨骼和周围沉积物被寄居
3. 化学合成阶段：数十年，骨骼中的脂类被转化为能量

一个鲸落可以在原本贫瘠的海底维持生命长达五十年。

---

开源项目的"鲸落"

Michael Winser 在讨论废弃项目的依赖图时轻描淡写地提到了鲸落，从此这个概念就萦绕 在我心头。

一个大型开源项目停止维护了。也许是维护者精疲力竭，也许是背后的公司转型了。项目不再更新，但并没有消失。它静静地躺在 GitHub 上，问题越积越多，最后一次提交越来越久远，有人会 fork 它来合并最紧急的补丁。

如果项目足够热门，会出现多个分支，像盲鳗争抢鲸脂一样争夺用户。OpenOffice
变成了 LibreOffice，MySQL 变成了 MariaDB，Hudson 变成了
Jenkins——每一个都是从食腐分支成长为权威替代品的过程。

然后，小型项目开始提取特定模块，或针对已死项目的数据格式构建工具 。Google Reader 倒闭时，Feedly、Miniflux、FreshRSS 等十几个应用争相填补空白。

接着，骨架结构——协议、文件格式、API 契约——继续支撑着专业化社区。OpenDocument 格式比创建它的 OpenOffice 社区活得更久。Tree-sitter 是为 Atom 构建的，在 GitHub 将 Atom 归档后，它成了 Zed、Neovim、Helix 的语法引擎。

---

持续再殖民化

未维护库的模式，是持续的再殖民化。每一代 fork 通常比上一代更小，贡献者更少，用户基础更窄，直到最终想法本身发生 了迁移。

Sass 经历了这个过程：Ruby gem → LibSass (C++) → Dart Sass。概念在十年间迁移了三次，每次重写都受益于前人积累的 bug 报告和设计争论。

持续再殖民化有一个糟糕的失败模式：代码通过连续的 fork 被复制前进，却没有人重新审计继承的漏洞。Edera 发现的 Rust tar-rs 库的差分解析 bug 就是这样影响了所有下游 fork。

---

许可证变更

当一个项目从开源许可证切换到源码可用许可证时，食腐阶段几乎立即触 发。Redis 变成 Valkey，Elasticsearch 变成 OpenSearch，Terraform 变成 OpenTofu——这个模式现在已经非常熟悉。

抽象层是最持久的部分。兼容性垫片往往比创造它们的争议活得更久。

---

Sun Microsystems

2010 年 Oracle 收购 Sun，与其说是单次鲸落，不如说是整群鲸同时死在海里。Java、 Solaris、ZFS、MySQL 等每一个都沉入不同的海底，孕育自己的后续演变。 所有这些下面的骨架结构——JVM 字节码格式、ZFS 磁盘格式、MySQL
网络协议——在那些从未听说过 Sun 的开发者的项目中仍然是承重的。

---

浅水区

有些项目死在浅水区，尸体会很快被回收。收购工作就是这样：公司被吸
收，代码变成专有或被归档，知识随人而不是累积在公共尸骸上让人取食 。

目前云计算提供商主导的整合趋势正在降低开源的鲸落 rate，而这对生态系统多样性有二级效应。

---

结论

一个开源生态系统，如果每个大型项目都由平台公司拥有，在那里富集和化学合成阶段很少有机会发展，而依赖鲸落为食的小型专业化生物从未有 机会进化。

最健康的生态系统有稳定的鲸落供应。
这是个奇怪的期待，因为这就意味着希望大型项目死去——除了深海底没 有其他食物来源。

---

（完）