在開源世界里，“項目死亡”往往并不意味著倉庫被刪除或代碼徹底消失，更多時候，它只是以各種更隱蔽的方式繼續存在：沒人維護、無法發布、依賴鏈仍在運行，或者只是看起來還活著。

這正是 Andrew Nesbitt 長期關注的問題。這位曾任職于 GitHub 和 Tidelift 的軟件工程師指出，所謂“項目死亡”，從來不是單點事件，而是一連串結構性失效的結果。

來源：https://nesbitt.io/2026/05/19/dumb-ways-for-an-open-source-project-to-die.html

作者 | Andrew Nesbitt 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

如今大量被廣泛依賴的軟件包，其實早已在某種意義上停擺，只是依然通過依賴鏈持續運轉。它們沒有統一的死亡時刻，也沒有明確的終點，而是在不同條件下逐漸滑向失效狀態。

而一個項目之所以會走到這種“仍然存在但已經失去生命力”的狀態，原因往往五花八門。下面這些情況，基本覆蓋了開源項目如何一步步“消失”的路徑。

維護者離開了

“幽靈維護者”

這是最簡單、也最常見的一種情況：很多開源項目的最后一次人工提交記錄停留在幾年前，后來 Issue 不斷堆積卻無人回應，但倉庫又沒有被歸檔，因此不會出現在那些專門篩查“廢棄項目”的過濾列表中。

通常情況下，這些項目的維護者們只是轉去做別的事情了，而這個項目對他們來說，又沒重要到需要正式移交或關閉的程度。當然，同樣的“沉默”背后，也可能意味著更極端的情況——甚至包括維護者已經去世，而無論是軟件倉庫還是包管理平臺注冊表，都沒有辦法表達這種狀態。

從外部來看，這種項目很難和“維護者只是休了個長假”區分開來。直到無人回復的問題越來越多，沉默才逐漸變得無法忽視。如今 npm 生態中很多高依賴量、卻已經“名存實亡”的工具，大多屬于這一類。

“企業棄兒項目”

有些項目最初由公司創建并開源，也曾擁有專門團隊負責維護。但后來公司戰略轉向、組織調整，或者經歷裁員之后，原團隊消失了，而 README 卻沒人更新。

GitHub 組織頁面還掛著公司 Logo，但最后擁有管理員權限的人可能早就離職了，于是公司內部甚至沒人知道這個項目依然“屬于自己”。

Google 各種著名“墓地項目”算是最典型的例子，但實際上，幾乎每一家發展到一定規模的公司，都會留下幾個類似的遺棄項目。尤其是那些偏基礎設施性質、而不是直接面向用戶的項目，往往連正式的棄用公告都沒有。

“論文孤兒”

還有一類項目，是研究生為了碩士課題或博士論文而開發的。等學生畢業離開后，項目也隨之失去維護。雖然實驗室名義上仍擁有倉庫，但里面已經沒人具備繼續維護它所需的上下文知識。

更現實的問題在于：學術體系并不會激勵人去維護別人留下的軟件。維護舊代碼拿不到引用，對評審和晉升也幾乎沒有幫助，相比之下，發表新的論文顯然更重要。因此，科研軟件生態里充滿了這種“論文還在被引用，但代碼早已無法編譯”的項目。

“資金斷崖”

有些項目依靠資助、基金會撥款，或者限期贊助維持運轉。

問題是，這類資金往往本來就有明確結束時間。一旦資金到期，維護者就得回去做真正能養活自己的工作。

于是，一個原本依靠全職投入發展起來的項目，突然只能靠業余時間維護。而對于已經擴張到一定規模的項目來說，“晚上和周末維護”基本等于無人維護。

很多時候，資助方的 Logo 依然會長期留在 README 里，因此外界很容易誤以為它依舊是一個健康、持續被贊助的項目。

“被公司挖走”

還有些項目，是因為維護者被公司招募后逐漸停擺。

有時候是勞動合同限制，有時候只是新工作太忙，導致項目自然失去維護。

偶爾也會出現“競爭對手故意挖人”的情況，但更常見的其實并非惡意。例如 Apple 就是一個經典案例：它通常不允許大部分員工繼續參與外部開源項目。

因此，一個維護者加入 Apple，往往就意味著他原本的項目默認進入“靜默狀態”。

理論上，最合理的做法是在入職前完成項目交接，但現實里，幾乎沒人能及時做到這一點。

“繼承僵局”

還有一種情況更加棘手：

原維護者已經失聯，但社區里其實有人愿意接手項目。

問題在于，軟件包發布權限綁定在一個無人能訪問的賬號上，而 GitHub 倉庫也沒有其他管理員。與此同時，包管理平臺針對“廢棄項目”的處理流程，又通常要求原維護者同意，或者經歷漫長的爭議處理過程，而沒人明確知道該由誰來發起。

Python 的 PEP 541 流程、npm 的爭議處理政策，都是專門為這種情況設計的。

但現實是，它們往往耗時長到一個程度：開發者重新 Fork 一個新項目并改名，反而更快。

「CSDN讀者專屬福利」，免費領 100 小時云算力

進群月月抽顯卡、AIPC，好運不停！

咖啡領取地址：https://s.csdn.cn/4nPsOp

維護者其實還在

“項目陷入了停滯期”

從各種指標上看，項目似乎依然活躍。

一些拼寫錯誤修復、依賴升級還會被合并，Issue 下面偶爾也能看到一句“謝謝，我會看看”。但凡是真正需要做設計決策、深入調試的問題，卻會無限期掛在那里，因為維護者早已沒有精力再認真投入這個項目。

這種狀態通常最微妙：項目“看起來”還活著，因此任何提出 Fork 的人，都會被拿近期活動記錄反駁；但與此同時，它又始終無法真正推進。

而這種“不死不活”的狀態，完全可能持續好幾年。

“善意僵尸”

貢獻圖一片翠綠，但所有提交都是機器人完成的。

Dependabot 自動升級依賴、自動合并規則自動通過 PR、自動化發布流程自動生成版本，如今甚至還有定時運行的 AI Coding Agent，可以在沒有任何人類閱讀代碼的情況下，讓項目長期“保持運轉”。

于是，所有基于“最近是否有提交”的健康評分系統，都會認為這個項目狀態良好。

而這恰恰暴露了“基于活躍度評分”的最大問題：它根本無法判斷，背后到底還有沒有真正的人類維護者。

“項目管理權之爭”

有時，開源軟件項目的多個共同維護者之間會徹底鬧翻。雙方都擁有足夠權限阻止對方，但又沒有能力單獨推進項目，于是整個項目被凍結在中間。

有些項目最終會演變成 Fork，有些則會以其中一方退出收場。但也有很多項目，就這樣長期僵在那里。

Issue 區不斷涌入用戶詢問“到底發生了什么”，而他們得到的，往往是兩套互相矛盾的說法。

“經驗知識流失了”

這種情況下，代碼還能運行，測試也全部通過。但真正理解“為什么這樣設計”的那個人已經離開了。

剩下的人雖然還能修一些邊邊角角的小問題，卻沒人敢碰核心結構，因為沒人有信心改動那些真正承重的部分。

于是項目實際上進入了一種“只讀模式”：外圍補丁還能接受，任何結構性修改都被視為風險過高。

這種情況在數值計算、解析器等領域尤其常見。因為最難的部分，往往是某個人十年前根據一篇論文實現的算法，而他從未真正寫過完整文檔。

“有毒守門人”

還有一種情況更糟：維護者不僅還在，而且態度極其敵對。

新貢獻者第一次提交 PR，往往就會遭遇一次“毀滅性 Code Review”，之后再也不回來。于是項目的“巴士因子（Bus Factor）”始終停留在 1 —— 因為沒人愿意和這個人一起維護倉庫。

從提交量、關閉 Issue 數等指標來看，項目甚至可能非常“健康”。但等到這個唯一維護者最終停下來的時候，項目就會瞬間變成“幽靈維護者”狀態，而且沒有任何接班人，因為那些原本可能接手的人，早在很多年前就被趕跑了。

被破壞與被劫持

“維護者被劫持”

有時，代碼提交權限或發布權限會落到心懷惡意的人手里。

xz 事件是最復雜、最經典的案例：攻擊者花了兩年時間，對一個過勞的單人維護者進行社會工程攻擊，最終成功成為共同維護者，并在之后發布了帶后門的版本。

2018 年的 event-stream 事件則簡單得多：原作者把包交給了一個“主動幫忙”的志愿者，而對方隨后就在下游依賴里植入了盜取加密錢包的惡意代碼。

兩起事件有一個共同點：在“被劫持”期間，項目甚至比以前看起來更健康。因為真正積極干活的人，正是那個新的惡意維護者。

“抗議軟件”

有時，破壞項目的人甚至就是合法維護者本人。

2022 年，colors 和 faker 的作者故意破壞了自己的包；更早之前，2016 年的 left-pad 則在與 npm 的爭議中被作者直接下架。

背后的動機各不相同，但對下游生態造成的影響卻是一樣的：倉庫里的代碼，不再是用戶以為自己正在運行的那份代碼，而且這一切通常毫無預警。

發布流程出“問題”了

“有人維護，但發不了版”

開發仍在繼續，修復也已經提交進 Git 倉庫，但就是沒人能真正發布新版本。

唯一擁有發布權限的賬號已經失聯、丟失了 2FA 設備，或者屬于一家早已不存在的公司。

結果就是，下游用戶只能繼續使用最后一個已發布版本，而他們真正需要的修復，其實已經靜靜躺在倉庫提交記錄里，只是永遠無法從軟件源安裝到。

“無法發布的主分支”

默認分支已經與上一次正式發布版本偏離太遠。如果現在直接發布，會對整個生態造成破壞性變更。而沒人愿意承擔這個責任，于是干脆沒人發布。

新貢獻者依然不斷往 main 分支提交補丁，但用戶實際運行的，還是幾年前的舊版本。

隨著時間推移，兩者差距越來越大，最終，“發布一個新版本”本身就變成了一個需要專門立項的大工程，而這個工程永遠排不上優先級。

“構建考古學”

已經發布的產物還能運行，但沒人知道該怎么重新構建它們。

可能是當年的 CI 服務已經關閉，也可能是依賴的基礎鏡像被刪除，或者某個關鍵工具版本，只存在于一位維護者已經報廢的舊電腦里。

于是，每次想發布新版本之前，都得先“考古”出當年的構建環境。而真正知道環境細節的人，早已經離開項目。

“影子維護”

真正的開發工作，其實發生在公司內部的私有單體倉庫里。公開倉庫只是偶爾同步一次代碼，提交信息通常只有一句簡單的 “sync”。

用戶在公開倉庫提交的 Issue 和 PR 基本不會得到回應，因為那根本不是開發者真正工作的地方。

于是，這個所謂的“開源項目”，實際上已經退化成了閉源項目的一個發布渠道。從外部來看，它和“幽靈維護者”項目幾乎沒區別，除了偶爾同步代碼的那幾天。

“被困住的大版本”

項目已經更新到 v4，而且維護得很好。但整個生態還停留在 v1。

因為 v2 曾經是一次徹底重寫，大多數用戶從那之后就再也沒遷移成功。而 v1 又已經很多年沒人真正維護。

于是，“這個項目到底死沒死”，完全取決于你問的是哪個大版本。

而最諷刺的是，安裝量最高的版本，往往恰恰不是維護者真正關注的那個版本。

“注冊表孤兒”

軟件包還能從注冊表正常下載，但它元數據里的源碼倉庫鏈接已經 404 了。

倉庫可能被刪除了、改成私有了、遷移后沒更新地址，或者托管平臺本身已經關閉。

這就導致沒人知道該去哪里提 Issue，也沒地方 Fork，更無法驗證注冊表里的 tarball 是否真的對應某次源碼提交。

統計數據顯示，大約 1.7% 的 npm 包，以及約 4% 的 Packagist 包，都指向了一個已經不存在的倉庫。而其中相當一部分，至今仍在被持續安裝。

不可抗力

“被制裁困住”

維護者既有能力，也愿意繼續維護項目，但就是無法發布更新。

原因可能是：軟件注冊表屏蔽了他們所在的司法轄區，或者他們的賬號因出口管制被凍結。

過去幾年里，npm 和 GitHub 上已經出現過多起類似案例：一些開發者賬號被直接暫停。而對于下游用戶來說，這種情況和“幽靈維護者”幾乎沒有區別——項目突然不再更新、沒人響應、版本停滯。

唯一的不同是：維護者本人通常還在其他平臺上大聲解釋到底發生了什么。

“下架受害者”

項目因為 DMCA 投訴或商標糾紛，被托管平臺或軟件注冊表移除。youtube-dl 在 2020 年被下架后最終恢復了，但大量更小的項目并沒有這么幸運。而且，一個項目最終是否還能繼續被安裝，和投訴本身是否合理，并沒有必然關系。

很多時候，只要包已經被移除，生態就已經斷裂了。

世界已經變了

“平臺遺棄”

項目被困在一個已經壽終正寢的平臺上。例如只能運行在 Python 2 上、依賴一個已經從 CI 鏡像中移除的 Node 版本、依賴某個已經被刪除的編譯器擴展。

理論上這個開源項目可以遷移，但問題在于，把它移植到現代環境里，需要投入大量的工作量，而這些工作量已經超過現存維護者愿意承擔的范圍。

于是項目就這樣停留在過去，而它所依賴的平臺，也逐漸從所有現代運行環境中消失。

“傳遞性死亡”

有時，一個項目本身其實沒問題。維護者還在，也愿意繼續維護。

但它依賴樹中更深層的某個組件——可能是兩層、三層以下的依賴——已經通過前面提到的某種方式“死掉”了，而且除非徹底重寫，否則根本無法替換。

于是，這個項目也會被連帶“拖死”。

最關鍵的是它自己的倉庫里甚至什么都沒變。這是整個開源生態最遞歸、也最可怕的一點：前面列出的每一種“死亡方式”，其實也都是殺死所有下游依賴項目的方法。

“API 突然終止”

項目封裝的外部服務，被所有者撤掉了。在服務層面，最常見的是：某個 API 被關閉，或者價格漲到無法承受。

例如，Twitter 在 2023 年的 API 政策變化，以及 Reddit 后續的收費調整，就一次性“殺死”了整整一代依賴這些平臺的客戶端庫。

而在平臺層面，則是瀏覽器廢棄了某個接口，或者操作系統封鎖了某項能力。所有基于 NPAPI、Flash 或 Chrome Apps 構建的生態，都屬于這種情況。

無論是哪一種，維護者其實都無能為力。因為問題根本不在他們這一側。

“被時代取代”

開源項目的功能已經不再被需要。原因可能是：它實現的規范已經被替換，或者編程語言本身已經原生支持了同樣的能力。

例如：

• Object.assign 出現后，object-assign 失去意義

• ES2015 普及后，大量 lodash 單函數包逐漸被淘汰

• 各種 Promise 和 fetch Polyfill

• 以及那些用于處理早已沒人再生成的數據格式的協議庫

于是維護者很自然地停止維護。但與此同時，幾十萬份鎖定文件依然在持續安裝這些包。

因為對于大多數人來說：“一個還能正常解析的依賴”，永遠不會是優先清理事項。

項目分裂了

“項目 Fork 陷入僵局”

當社區里面存在理念分歧、或者維護者離開時，往往會讓項目分裂成多個 Fork，但問題在于：沒有任何一個分支可以最終勝出。

于是，下游生態寧愿停留在“原項目分裂前的最后一個版本”，也不愿賭哪個 Fork 能活下來。

結果就是——原項目依然保有巨大的安裝量，而真正的開發工作，卻已經在其他名字下悄悄進行。最典型的案例就是 io.js 與 Node 最終重新合并了；libav 也最終回歸 FFmpeg。但更多的小型分支項目，則永遠沒有迎來結局。

“許可證變更的后續影響”

有些開源項目修改了許可證，變成非開源軟件。隨后，社區仍然基于舊許可證 Fork 出一個新項目，但生態并沒有真正完成遷移，使用量一直上不來。Terraform / OpenTofu、Redis / Valkey 都面臨著類似的困境，而 Elasticsearch 已經比它們更早走上這條路幾年。

如今，大量鎖定文件依然指向原項目最后一個“真正開源”的版本。可那個已經變成了一個沒人維護、卻永遠停留在那里的固定版本。

“開源核心被掏空”

真正有價值的開發工作，已經轉移到商業版本里。開源倉庫仍然存在，但更多只是作為“免費版本”保留下來。它依舊會發布新版本，但大多數只是版本號的更新，以及進行一些與付費產品無關的改動。

于是，人們當初采用的那個“開源項目”，實際上已經慢慢變成了另一個規模更小、能力更弱的東西。只是它從來沒有改過名字。

免費領取 100 小時 AI 算力｜CSDN 讀者福利

加入 AI 開發者計劃獲取：

? AI 算力資源

? 官方技術社群

? Workshop 與 AI Academy

? 開發者專屬福利

立即掃碼，前 50 名額外領取「瑞幸咖啡」

咖啡領取地址：https://s.csdn.cn/4nPsOp