Whale Fall 鲸落

https://nesbitt.io/2026/02/21/whale-fall.html whale-fall

When a whale dies in the open ocean, its carcass sinks to the abyssal floor and becomes an ecosystem. Marine biologists call this a whale fall, and the body sustains life in three overlapping stages: mobile scavengers strip the soft tissue over months, enrichment opportunists colonise the bones and surrounding sediment for years, and chemosynthetic bacteria feed on the skeleton itself for decades, converting the lipids stored in bone into energy that supports entire communities of specialised organisms. A single whale fall can sustain life on an otherwise barren ocean floor for fifty years.
当鲸鱼在公海中死亡时，它的尸体沉入深渊底部，形成生态系统。海洋生物学家称之为鲸落 ，身体在三个重叠阶段维持生命：活动的食腐动物在数月内剥离软组织，富集机会主义者在骨骼及周围沉积物中定殖多年，化学合成细菌则以骨骼为食数十年，将骨骼中的脂质转化为支持整个专门生物群落的能量。一次鲸落就能维持在一片贫瘠海底上五十年的生命。

Michael Winser mentioned whale fall offhand while we were talking about what happens to the dependency graphs of abandoned projects, and it won’t leave my head.
Michael Winser 在我们讨论废弃项目依赖图的处理时，随口提到了“鲸落”，这让我一直耿耿于怀。

A large open source project goes unmaintained. Maybe the maintainer burns out, maybe the company behind it pivots. The project stops getting updates but doesn’t disappear. It sits on GitHub accumulating issues, its last commit receding further into the past, and somebody forks it to start merging the most urgent patches. If the project was popular enough, multiple forks appear, competing for users the way hagfish compete for blubber, though most die quickly and one or two survive on the strength of someone with enough time or institutional support to keep going. OpenOffice became LibreOffice this way, MySQL became MariaDB, Hudson became Jenkins, each a scavenger fork that grew into the canonical replacement through a familiar sequence of fork announcement, migration guide, and “why you should switch” blog posts.
一个大型开源项目却未被维护。也许维护者会精疲力竭，也许背后的公司会转向。项目停止更新，但不会消失。它在 GitHub 上堆积问题，最后一次提交被推迟到过去，有人分支它开始合并最紧急的补丁。如果项目足够受欢迎，会出现多个分支，像黑鲀争夺脂肪一样争夺用户，尽管大多数很快死亡，只有一两个靠着足够时间或机构支持的人存活下来。OpenOffice 就是这样变成了 LibreOffice，MySQL 变成了 MariaDB，Hudson 变成了 Jenkins，每一个都是拾荒分支，通过熟悉的分支公告、迁移指南和“为什么你应该切换”的博客文章，逐渐成长为经典替代品。

Smaller projects then start extracting specific modules or building tools that target the dead project’s data formats. Google Reader wasn’t open source, but the same thing happened when it shut down: Feedly, Miniflux, FreshRSS, Tiny Tiny RSS, and a dozen others rushed to fill the vacuum, several of them implementing the Google Reader API or the Fever API not because those were good APIs but because years of RSS clients had been built to speak them. The licence didn’t matter. The interfaces were public, other software depended on them, and that was enough.
较小的项目则开始提取针对已死项目数据格式的特定模块或工具。Google Reader 并不是开源的，但它关闭时也发生了同样的事情：Feedly、Miniflux、FreshRSS、Tiny Tiny RSS 以及其他十几个公司争相填补空白，其中几个实现了 Google Reader API 或 Fever API，不是因为它们本身很好，而是因为多年来的 RSS 客户端已经被开发出来支持它们。许可并不重要。接口是公开的，其他软件依赖它们，这就足够了。

And then the structural skeleton, the protocols and file formats and API contracts, goes on supporting specialised communities that may not even know where the bones came from. OpenDocument Format has outlasted the OpenOffice community that created it, sustained by document format libraries across dozens of language ecosystems. Docker donated its container runtime and image format to the Open Container Initiative in 2015. The OCI spec now defines how containers work regardless of runtime. Docker’s own dominance faded; the spec didn’t. Tree-sitter was built for Atom, and after GitHub archived Atom it became the syntax engine inside Zed, Neovim, Helix, and most editors shipped in the last few years.
然后结构骨架、协议、文件格式和 API 合同，继续支持那些甚至不知道Base来源的专业社区。OpenDocument Format 的寿命超过了创建它的 OpenOffice 社区，依靠遍布数十个语言生态系统的文档格式库。Docker 于 2015 年将其容器运行时和映像格式捐赠给了开放容器倡议。OCI 规范现在定义了容器的工作方式，无论运行时间如何。多克自身的统治力逐渐消退;但规格没有。Tree-sitter 是为 Atom 开发的，GitHub 归档 Atom 后，它成为了 Zed、Neovim、Helix 以及大多数近几年发布编辑器中的语法引擎。

Succession 继承

The pattern I keep noticing with unmaintained libraries is successive recolonisation. A project goes quiet, someone forks it, other projects start depending on the fork, and then that fork maintainer burns out too and the whole cycle repeats at a smaller scale. Each generation of fork is typically smaller than the last, with fewer contributors and a narrower user base, until eventually the idea itself migrates rather than the code. Someone in another language ecosystem looks at the accumulated wreckage and decides to rewrite the concept from scratch, carrying the design forward but leaving the implementation behind.
我一直注意到未维护的库有连续的重新殖民模式。一个项目沉寂，有人分支它，其他项目又开始，取决于分支，然后那个分支维护者也耗尽，整个循环在更小规模上重复。每一代分支通常规模都比上一代小，贡献者更少，用户基数更窄，最终是理念本身迁移，而非代码。另一个语言生态系统中的某人看到积累的残骸，决定从零重写概念，承载设计但放弃实现。

Sass went through this. The original reference implementation was a Ruby gem. When Ruby’s performance became a bottleneck, LibSass rewrote it in C++, and the sassc gem wrapped that for Ruby users. Then LibSass itself was deprecated in favour of Dart Sass, which is now the canonical implementation. The concept migrated from Ruby to C++ to Dart across a decade, each rewrite benefiting from the accumulated bug reports and design arguments of its predecessors, and at each stage there were wrapper libraries in other ecosystems feeding on the structural skeleton of the Sass language spec. Most people writing Sass today have no idea it started as a Ruby gem.
Sass 经历过类似的事。最初的参考实现是 Ruby gem。当 Ruby 的性能成为瓶颈时，LibSass 用 C++重写了它，sassc gem 为 Ruby 用户包装了它。随后 LibSass 本身被弃用，取而代之的是 Dart Sass，这成为了现在的规范实现。该概念在十年间从 Ruby 迁移到 C++再到 Dart，每次重写都受益于前辈积累的错误报告和设计论据，且在每个阶段，其他生态系统中都有封装库在 Sass 语言规范的结构骨架上汲取能量。如今大多数写 Sass 的人根本不知道它最初是一颗红宝石。

Successive recolonisation has a nasty failure mode. Edera discovered a differential parsing bug in Rust’s tar-rs library that affected every fork downstream: tar-rs itself, async-tar, tokio-tar, and multiple internal forks maintained by companies like Astral (whose fork ships inside the uv package manager). Coordinated disclosure meant contacting around twenty entities across a fragmented fork graph where three of the four library versions were unmaintained and several maintainers were unreachable. The vulnerability existed because the code had been copied forward through successive forks without anyone re-auditing the PAX header parsing that all of them inherited from the original. The bug had been sitting in the bones the whole time, inherited by every fork. Discovering which forks of a package are affected by an advisory is a problem I’m working on separately, because right now nobody has good tooling for it.
连续的移植一种糟糕的失败模式。Edera 发现了 Rust tar-rs 库中的差分解析漏洞 ，影响了所有下游分支：tar-rs 本身、async-tar、tokio-tar，以及由像 Astral 这样的公司维护的多个内部分支（其分支发包在 UV 包管理器中）。协调披露意味着通过一个支离破碎的分支图联系约二十个实体，其中四个库版本中有三个未被维护，且多个维护者无法联系。漏洞存在是因为代码被连续的分支复制，且没有人重新审计所有 PAX 头部解析，而这些 PAX 首部解析都是从原始中继承来的。这根虫子一直藏在骨头里，每一把叉子都遗传了下来。发现哪些分支会受到建议影响，是我另外在做的一个问题，因为目前没有人有好的相关工具。

CentOS after the Stream pivot is the same pattern at operating system scale: Rocky Linux and AlmaLinux forked, smaller RHEL-compatible rebuilds appeared in the enrichment layer around them, and the structural skeleton underneath, RPM packaging, systemd conventions, filesystem hierarchy, persisted unchanged regardless of which particular distribution is alive or dead at any given moment.
Stream 枢轴之后的 CentOS 在作系统规模上也呈现相同模式：Rocky Linux 和 AlmaLinux 分支后，围绕它们的丰富层中出现了较小的兼容 RHEL 重建，而其底下的结构骨架、RPM 打包、Systemd 约定、文件系统层级，无论哪个特定发行版活跃或死亡，都保持不变。

Licence changes 许可证变更

When a project switches from an open source licence to a source-available one, the scavenger stage triggers almost immediately, often before the change even takes effect. Redis to Valkey, Elasticsearch to OpenSearch, Terraform to OpenTofu, the pattern by now is familiar enough that the community has it down to a routine: rush to fork the last open commit, compete briefly, and consolidate around one or two survivors. The organism isn’t exactly dead in these cases. Redis the product still has revenue and a roadmap. But from the perspective of the open source ecosystem the body of code has stopped accepting outside contributions, and the forks start drifting from the original the way MariaDB drifted from MySQL.
当项目从开源许可证切换到可用源代码许可时，拾荒阶段几乎立即触发，往往在变更生效之前。从 Redis 到 Valkey，从 Elasticsearch 到 OpenSearch，从 Terraform 到 OpenTofu，这种模式已经足够熟悉，社区已经形成了一套惯例：匆忙分叉最后一个开放提交，短暂竞争，然后围绕一两个幸存者整合。在这些情况下，生物体并不完全死亡。Redis 这个产品依然有收入和路线图。但从开源生态系统的角度来看，代码体系已经不再接受外部贡献，分支也开始像 MariaDB 从 MySQL 那样逐渐偏离原来的。

The abstraction layers are the part that lasts. Every project that integrated with the open version faces a choice between following the proprietary version or switching to the fork, and plenty of them just build a compatibility shim instead. Those shims tend to outlast the controversy that created them, feeding quietly on the skeleton of the original API years after the licence debate has cooled off.
抽象层是持久的部分。每个与开放版本集成的项目都面临选择：要么遵循专有版本，要么切换到分支，很多项目干脆直接构建兼容垫片。这些“假”往往比引发它们的争议更持久，在许可争议冷却多年后，悄然依赖原始 API 的骨架。

Sun Microsystems Sun系项目的微生态

Oracle’s acquisition of Sun in 2010 was less a single whale fall than an entire pod dying at sea simultaneously. Java, Solaris, ZFS, DTrace, VirtualBox, NetBeans, GlassFish, Hudson, MySQL, each sank to a separate ocean floor and spawned its own succession. Some produced single dominant forks (Hudson to Jenkins, ZFS to OpenZFS), others scattered into competing lineages (MySQL alone fed MariaDB, Percona, and briefly Drizzle, which itself became a smaller whale fall when it was abandoned), and some bounced between foundations before settling (NetBeans to Apache, GlassFish to Payara and the broader Jakarta EE ecosystem). The structural skeletons underneath all of it, the JVM bytecode format, the ZFS on-disk format, the MySQL wire protocol, are still load-bearing in projects whose developers have never heard of Sun.
甲骨文在 2010 年收购 Sun，与其说是鲸落，不如说是一整群鲸鱼同时在海上死亡。Java、Solaris、ZFS、DTrace、VirtualBox、NetBeans、GlassFish、Hudson、MySQL，各自沉没到不同的海底，并催生了自己的后代。有些分支产生了单一主导分支（Hudson 到 Jenkins，ZFS 到 OpenZFS），有些则分散成竞争的分支（MySQL 单独支持了 MariaDB、Percona 和短暂的 Drizzle，后者被放弃后变成了更小的“大块鲸鱼”），还有些在多个基础间辗转后最终定居（从 NetBeans 到 Apache，从 GlassFish 到 Payara 以及更广泛的雅加达电气生态系统）。所有这些结构骨架、JVM 字节码格式、ZFS 磁盘格式、MySQL 线协议，仍然承载着开发者从未听说过 Sun 的项目。

Shallow water 浅水区

Some projects die in shallow water where the carcass gets recycled quickly. Acqui-hires work this way: the company gets absorbed, the code goes proprietary or gets archived, and the knowledge disperses with the people rather than accumulating in a public carcass that others can feed on. Corporate consolidation has a similar effect, because when a large independent project gets folded into a platform company’s proprietary service, the nutrients get recycled in the water column rather than sinking deep enough for succession to happen.
有些项目在浅水区会死去，因为尸体会被快速回收。收购雇佣的运作方式是这样的：公司被吸收，代码变成专有或归档，知识随着人们一起传播，而不是积累成公共资源供他人食用。企业整合也有类似效果，因为当大型独立项目被纳入平台公司的专有服务时，养分会在水柱中循环，而不是沉得足够深以实现继承。

I think the current trend of consolidation under cloud providers is reducing the whale fall rate in open source, and that this has second-order effects on ecosystem diversity that nobody is tracking. You could measure it: look at the fork and dependency graphs of dead projects over time, count how many new projects cite a dead dependency, compare the half-life of a whale fall in npm versus crates versus rubygems. Do some ecosystems have deeper ocean floors, slower decomposition, longer-lasting structural influence? The data exists in package registries and forge APIs, but I haven’t seen anyone ask the question.
我认为当前云服务提供商整合的趋势正在降低开源中的鲸鱼下降率，而这对生态系统多样性产生了二级影响，而没人真正追踪这些影响。你可以测量：看看死项目的分支和依赖图随时间变化，数数有多少新项目引用了死依赖，比较鲸鱼坠落的半衰期（NPM）、箱子和红宝石。有些生态系统是否拥有更深的海底、分解较慢、结构影响更持久？数据存在包注册表和 Forge API 中，但我没见过有人问这个问题。

An open source ecosystem where every large project is owned by a platform company, maintained indefinitely or quietly absorbed on death, is one where those enrichment and chemosynthetic stages rarely get a chance to develop, and the small specialised organisms that depend on whale falls for food never get a chance to evolve. The healthiest ecosystems have a steady supply of whale falls, which is an odd thing to root for since it means wishing for the death of large projects, except that the deep ocean floor has no other food source.
一个开源生态系统中，每个大型项目都由平台公司拥有，无限期维护或在死亡后悄然吸收，这种生态系统中那些富集和化能合成阶段很少有机会发展，依赖鲸落食物的小型专门生物也永远没有机会进化。最健康的生态系统中，鲸落源源不断，这让人感到奇怪，因为这意味着希望大型项目的消亡，只不过深海底部没有其他食物来源。