開源軟件支撐著現代互聯網的運轉，但這些項目并非總能健康存活。研究者 Andrew Nesbitt 日前發表文章，指出大量被高度依賴的開源軟件包，其實已經“死了”，而項目走向死亡的方式有很多種。

維護者離開了 幽靈維護者（Ghost maintainer）

最簡單、也最常見的一種情況：最后一次人工提交停留在幾年前，issue 不斷堆積卻無人回應，倉庫也沒被歸檔，所以各種健康度篩選工具根本不會標記它。

通常只是維護者去忙別的事了，項目對他來說沒重要到值得正式移交或關閉。但同樣的沉默，也可能意味著更極端的情況——包括維護者已經去世，而無論 registry 還是 repo 都沒有機制表達這一點。

從外部看，它和“人在休長假”毫無區別，直到未處理 issue 多到無法再自欺欺人。npm 上那批位列 Bernie’s dead list 頂部的工具，大多屬于這種。

企業棄兒（Corporate orphan）

一個公司開發并開源了項目，也曾有團隊維護它。但后來公司轉型、裁員，團隊沒了，而 README 卻沒人更新。

GitHub 組織還掛著公司 logo，但當年有 admin 權限的人已經離職，于是公司內部甚至沒人知道這個項目還是自己的。

Google 的各種“墓地”最出名，但任何稍微大點的公司都有類似遺跡。尤其是那些基礎設施類項目，很多甚至連 deprecated 公告都沒有。

論文遺孤（Thesis orphan）

項目是研究生或博士生為了論文做的，畢業后人走了。

實驗室名義上擁有 repo，但沒人理解上下文，也沒人有動力繼續維護——學術體系不會因為“維護別人軟件”給你表彰，更不會在評審里加分。相比之下，發一篇新 paper 顯然更重要。

科研軟件里這種情況極其普遍：論文還在被引用，代碼卻早就無法編譯。

資金斷裂（Funding cliff）

項目依靠贈款或固定期限贊助運行，通常來自基金會或公共軟件基金之一，一旦資金按計劃耗盡，維護者就回到維持生計的其他工作上，而一個原本按全職規模成長起來的項目，如今只能靠“晚上和周末”維護。對于這種規模來說，約等于沒人維護。

最迷惑的一點在于：贊助方 logo 在資金停止很久后往往還掛在 README 上，所以它看起來仍像一個“健康、有資助”的項目。

被大廠招安（Hired away）

維護者被一家公司聘用，而無論是勞動合同還是新的工作量，都會導致項目停止。有時是競爭對手故意“消滅項目”，但更常見的情況是完全沒有惡意：蘋果公司就是一個典型的例子，他們不允許大多數員工參與外部開源項目，因此維護者加入蘋果意味著他們的項目自然而然地就停止了。理論上，在入職前完成項目交接是最合理的做法。但現實里，幾乎沒人來得及做。

繼承僵局（Succession deadlock）

原維護者失聯了，也有人愿意接手，但：

• registry 的發布權限綁定在一個沒人能登錄的賬號上；

• GitHub repo 沒有其他管理員；

• registry 的 abandoned-package 流程，要么需要原作者同意，要么需要持續數月的爭議流程，而沒人有明確資格發起。

PEP 541 流程和 npm 的爭議處理政策正是為了解決這種情況而設立的，但兩者通常都比 fork 和重命名耗時更長。

維護者還在 倦怠平臺期（Burnout plateau）

從各種指標看，項目仍然“活著”。

拼寫修復、依賴升級還能 merge，issue 偶爾也會回復一句“謝謝，我會看看”。但真正需要設計決策或深度 debug 的問題，會無限期懸而未決——因為維護者早已沒有精力。

項目會維持一種詭異狀態：

• 活躍度足夠讓 fork 提議被反駁；

• 但又不足以真正發布新東西。

這種狀態能持續很多年。

善意“僵尸”（Benevolent zombie）

貢獻圖一片綠色，但 commit 全是 bot。

Dependabot 自動升級依賴、auto-merge 自動合并、自動 release，再加上如今的 coding agent，項目甚至可以長期“無人值守運行”。

所有基于“最近活躍度”的健康評分都會認為它很健康。

而這恰恰是 recency-based 指標最大的問題。

所有權大戰（Custody battle）

兩位或多位共同維護者意見不合，各自擁有足夠的權限來阻止對方，但又不足以獨立推進項目，導致項目陷入僵局。

有些最后會 fork，有些會有人退出，但更多情況是：

issue 區越來越滿，用戶不斷問“到底發生了什么”，而雙方給出兩套互相矛盾的答案。

經驗知識消失（Tribal knowledge gone）

代碼能跑，測試也通過。

但真正理解“為什么這樣設計”的那個人已經離開了。剩下的人沒有任何人敢動核心部分。

于是項目實際上進入“只讀模式”：

• 邊緣小 patch 可以接受；

• 結構性修改風險太大沒人敢碰。

這種情況在數值計算和解析代碼中尤為常見，因為其中最難的部分往往是某個人十年前根據一篇論文實現的算法，而他本人卻從未寫過相關文檔。

有毒守門人（Toxic gatekeeping）

維護者人還在，但抱著極大的敵意。

新人第一次 PR 就會遭遇毀滅性 code review，然后就再也不來了，而 “巴士系數” 一直保持在 1，因為其他人都無法忍受和他共用 repo。

從所有統計 commit 次數和已關閉 issue 的指標來看，代碼庫看起來都很健康，但當維護者最終停止維護時，就會出現 “幽靈維護者” 的情況，而且沒有接班人，因為所有可能接手的人幾年前就被趕走了。

破壞與劫持 被劫持的維護者（Captured maintainer）

有人惡意獲得 commit 或發布權限。

xz 就是一個精心策劃的例子：針對一位疲憊的獨立維護者發起了一場長達兩年的社會工程攻擊，最終讓攻擊者成為 co-maintainer，并植入后門。

2018 年的 event-stream 更簡單：原作者把軟件包交給一個“熱心志愿者”，這位志愿者禮貌地請求后，在下游依賴項中添加了一個竊取錢包的程序。

有趣的是：項目在被“劫持”期間，往往比以前“更活躍、更健康”。

因為真正干活的人，正是攻擊者。

利用軟件進行抗議（Protestware）

合法維護者故意破壞自己的包。

• colors 和 faker 在 2022 年因作者抗議而被自己破壞；

• node-ipc 同年對俄羅斯和白俄羅斯 IP 發布惡意載荷；

• left-pad 則在 2016 年 npm 爭議中被直接下架。

動機各不相同，但結果一致：

registry 里的代碼已經不再是用戶以為自己在運行的東西，而且通常毫無預警。

發布流水線壞了 有維護，但發不了版（Maintained-not-shipping）

開發仍在繼續，git 里也有修復。

但沒人能發布新版本：

• 唯一擁有發布權限的賬號丟了；

• 雙因素認證設備丟失；

• 賬號所屬公司已經倒閉。

下游只能繼續使用舊版本，而真正修復 bug 的 commit 明明就在 repo 里，卻無法從 registry 安裝。

無法發布的 main 分支（Unreleasable main）

默認分支與上一個 release 已經偏離太遠。

現在發版會導致增加大量破壞性變更，而沒人愿意背鍋，于是永遠沒人打 tag。

新貢獻者繼續往 main 提 patch，而用戶仍跑著幾年前的版本。差距不斷擴大，直到“發一個新版”本身變成了一個永遠沒人啟動的大項目。

構建考古學（Build archaeology）

已發布的制品庫（artifact）還能用，但沒人能重新構建。

因為進行構建需要的依賴如下：

• 一個已經關閉的 CI 服務；

• 一個被刪除的基礎鏡像；

• 某個維護者電腦上的特殊工具版本。

現在想發新版本，第一步是“重建古代構建環境”。而其中的所有內容都已遺失，只剩下搭建環境的人。

影子維護（Shadow-maintained）

真正的開發工作在公司內部的私有單體倉庫中進行，公開倉庫只是定期收到一次壓縮后的代碼 dump，提交信息類似于 “sync”。

提交到公開倉庫的 issue 和 PR 都石沉大海，因為那里根本沒人工作，開源項目已經淪為閉源項目的發布渠道。從外部來看，除了偶爾 sync 一次，它和幽靈維護者沒什么區別。

停滯不前的大版本（Stranded major）

項目已經發展到 v4，而且維護活躍。

但整個生態還停留在 v1，因為 v2 曾是一次大重寫，大家根本沒遷移過去。

于是：

• v4 在維護；

• 安裝量最大的 v1 卻多年沒人管。

“這個項目死了嗎”完全取決于你問的是哪個大版本，而安裝量最高的版本通常并非最受關注的版本。

Registry 孤兒（Registry orphan）

包還能從 registry 下載，但 metadata 里的源碼地址已經 404：

• repo 被刪了；

• 改私有了；

• 搬遷后沒更新；

• 托管平臺倒閉了。

你無法提 issue，也無法 fork，甚至無法驗證 tarball 是否與任何曾經在源代碼控制中存在的內容匹配。

約 1.7% 的 npm 包、4% 的 Packagist 包都指向不存在的 repo，而其中很多仍在被安裝。

不可抗力 制裁困境（Sanctions-stranded）

維護者有能力、也愿意更新，但推不上去。

因為：

• registry 封鎖了其所在地區；

• 賬號因出口管制被凍結。

過去幾年，npm 和 GitHub 都出現過這種案例。對下游來說，它和幽靈維護者完全一樣，只是維護者會在別的平臺拼命解釋發生了什么。

下架受害者（Takedown casualty）

項目因收到 DMCA 版權投訴或商標糾紛而被從 registry 或托管平臺移除。

youtube-dl 在 2020 年下架后又恢復了，但大量小項目再也沒回來。

而“指控是否合理”，與“包還能不能下載”沒有任何關系。

世界已經變了 平臺遺棄（Platform-stranded）

項目綁定在一個已經停止維護的運行時上：

• 只支持 Python 2；

• 依賴的 Node 版本已從 CI 鏡像中移除

• 使用被移除的編譯器擴展。

向前移植的工作量太大，而剩下的人沒人愿意做。

于是它和它依賴的平臺一起慢慢消失。

傳遞性死亡（Transitive death）

項目本身沒問題，維護者也還在。

但它依賴樹下游兩三層的某個依賴死了，而且無法替換。

于是項目“繼承了死亡”。

這是遞歸問題：

你死亡的每一種方式，也都會成為殺死依賴你的項目的方式。

API 突然終止（API rug-pull）

項目封裝的外部服務被擁有者撤掉了。

比如：

• API 被關閉；

• API 定價高到無法承受。

Twitter 2023 年的 API 改動，以及 Reddit 后續動作，一次性殺死了一整代客戶端庫。

平臺層面也類似：

• 瀏覽器移除接口；

• 操作系統鎖定某個功能；

Flash、NPAPI、Chrome Apps 全部屬于這一類。

無論哪種情況，維護者對此毫無辦法。

被時代替代（Superseded）

項目的功能已經不再需要：

• 規范被淘汰；

• 語言原生支持了。

例如：

• Object.assign 出現后的 object-assign；

• ES2015 后的 lodash 單函數包；

• 各種 Promise/fetch polyfill；

• 以及協議層面上大量用于處理不再有人使用的格式的庫。

維護者理所當然地停止了維護，但數十萬個 lockfile 文件仍然在安裝它，因為“既然還能運行，就沒人有動力刪依賴”。

項目分裂 Fork 地獄（Fork limbo）

因為分歧或維護者離開，項目分裂成多個 fork。

沒有哪個 fork 明顯勝出，于是下游停留在“分裂前最后一個版本”，不愿押注未來可能失敗的 fork。

原項目繼續擁有最高安裝量，而真正開發工作已經發生在別的名字下。

io.js 與 Node 最終重新合并，libav 最后回歸 FFmpeg，但更多小型 fork 永遠不會解決。

許可證變更的后續影響（Licence rug-pull aftermath）

項目改成非開源許可證。

社區基于舊許可證 fork 出新項目，但生態尚未統一。

Terraform/OpenTofu、Redis/Valkey 都處于這個階段，而 Elasticsearch 已經更往前走了一段。

多數 lockfile 仍指向原項目最后一個開源版本——一個再也沒人維護的固定版本。

開源核心被掏空了（Open-core hollowing）

真正有價值的開發已經轉向商業版。

開源 repo 仍存在，也會繼續發版，但主要只是：

• 刷版本號

• 更新不影響付費版差異化的功能。

用戶最初采用的那個項目，實際上已經變成了一個更小、更弱的東西，只是從未改名。