開源專案衰退的解剖學：為什麼專案會走向死亡

現代軟體供應鏈建立在不穩定的開源套件基礎之上。我們 lockfiles 中許多最關鍵的依賴項，實際上已經「死亡」了——它們不再受到維護，卻每天仍被安裝數百萬次。這種現象通常被比作「Weekend at Bernie's」的情境，即一個專案在背後的開發者消失後，僅憑藉著自身成功的慣性而繼續運作。

理解開源專案如何死亡不僅僅是一項分類學的學術練習；對於任何管理技術風險的人來說，這都是一種必要。當一個專案死亡時，它並不總是會立即消失。通常，它會以一種衰退的狀態持續存在，進而可能引入安全性漏洞、相容性中斷或完全的流水線故障。

當維護者消失時

專案走向死亡最直接的路徑是人類因素的消失。這可以透過幾種不同的模式發生：

• 幽靈維護者 (The Ghost Maintainer)： 最常見的情況，維護者單純地轉向其他領域。在沒有正式交接或將 repository 封存的情況下，專案仍處於一種模糊狀態——看起來就像是一場漫長的假期，直到堆積如山的未回應 issue 成為了無法忽視的棄置信號。
• 企業孤兒 (Corporate Orphans)： 在公司內部誕生並因策略原因開源的專案。當公司轉型或進行裁員時，團隊被解散，但 GitHub organization 仍然存在。通常，專案會變成一個「殭屍」，目前在公司任職的人甚至不知道該專案屬於他們。
• 論文孤兒 (Thesis Orphans)： 在研究軟體中很常見，這些是為了碩士或博士論文而建立的專案。一旦學生畢業，維護程式碼的動力就會消失，因為學術界獎勵的是新的發表，而非現有軟體的體的維護。
• 資金斷層 (Funding Cliffs)： 由補助金或固定期限贊助支持的專案。當資金用完時，全職開發能力會降至「晚上和週末」，對於大型專案而言，這實際上等同於零。
• 被挖角的效應 (The Hired-Away Effect)： 維護者加入了一家（如 Apple）對外部開源貢獻有嚴格政策的公司。在沒有及時交接的情況下，專案預設會陷入沉默。

「活著的死者」：留下來的維護者

更具隱蔽性的是那些看起來很活躍，但功能上已經死亡的專案。這些專案通常能規避自動化健康檢查，因為它們仍顯示「綠色」的活躍度。

倦怠高原期 (The Burnout Plateau)

在此狀態下，維護者仍會合併 (merge) 拼寫錯誤修正和依賴項更新 (dependency bumps)，但會避開任何需要設計決策或深度除錯 (debugging) 的任務。專案保持著恰好足以阻止他人 fork 的活躍度，但從不交付任何有意義的更新。

仁慈的殭屍 (The Benevolent Zombie)

這是自動化對人類主導權的勝利。Dependabot bumps、自動合併規則和 AI coding agents 讓 commit graph 保持綠色，且發佈 (releases) 持續進行。對於基於近期活躍度的健康評分而言，專案看起來很健康；但實際上，沒有人在閱讀程式碼。

有毒的把關與知識流失 (Toxic Gatekeeping and Knowledge Loss)

有些專案在維護者仍在場的情況下，因為社交失敗而走向死亡。有毒的把關 (Toxic gatekeeping) 發生在敵對的維護者驅逐了所有潛在的繼任者，確保「巴士因素 (bus factor)」維持在 1。或者，部落知識流失 (tribal knowledge loss) 發生在原始架構師離開時，留下了一段雖然能運作但讓其他人感到恐懼而不敢觸碰的程式碼，有效地將專案轉變為唯讀狀態。

破壞、接管與流水線故障

並非所有的死亡都是被動的。有些是主動干預或系統性故障的結果。

• 接管與抗議軟體 (Capture and Protestware)： 專案可能被敵對行為者「接管」（如 xz 後門），或被其創作者以「抗議軟體 (protestware)」的形式進行破壞（例如 2022 年的 colors 或 faker），即 registry 中的程式碼被刻意地破壞或植入惡意程式碼。

• 發佈流水線中斷 (The Release Pipeline Break)： 專案可能在 Git 中積極開發，但如果發佈權限與遺失的 2FA device 綁定，或與已失效的企業帳號，修正程式程序將永遠無法傳達給使用者。這造成了一種差距：原始碼是健康的，但分發的 artifact 仍然是死的。

• 影子維護 (Shadow Maintenance)： 當開發工作移至私有的企業 monorepo，而公開的 repo 僅僅是一個「同步」頻道。公開社群對於實際的開發工作一概不無視，因為實際的工作是在防火牆後方進行的。

環境與生態系統死亡

有時專案本身沒問題，但世界已經向前邁進了。

• 平台孤立 (Platform Stranding)： 專案與已停止支援的 runtime (例如 Python 2) 綁定，而將其移植到新平台的努力超出了社群的剩餘意志力。

• 轉移性死亡 (Transitive Death)： 專案從其依賴項中繼承了死亡。如果鏈條下游三層的某個關鍵 library 死亡了，頂層專案可能在沒有經過全面重寫的情況下變得無法維護。

• API 拔插效應 (API Rug-Pulls)： 專案是外部服務的包裝器 (wrapper) 。當該服務關閉或價格變得高不可攀（例如 2023 年的 Twitter/Reddit API 變更），該 library 隨即變得毫無用處。

社群觀點：死亡是「愚蠢」的嗎？

雖然分類學提供了失敗的模式圖，但社群辯論突顯了出了關於開源專案本質的更深層次緊張關係。有些人認為「愚蠢的死亡方式」這個詞是誤稱，認為這僅僅是自然的生命週期。

「因為你有自己的事情要忙而讓 repo unattended 狀態下留置，這並不是專案的開發者如何『愚蠢地』死亡。這就是生活。我並沒有因為只是把東西丟到 git 上就簽約成為終身維護者。

「

有些人則指出「維護者稅 (maintainer tax)」——處理處理器 (bots)、增長黑客 (growth-hackers) 和安全性掃描器 (security scanners) 的負擔——將 READMEs 作為 SEO 漏斗，將其視為倦怠的驅動因素。此外還有「範圍擴張 (scope creep)」的風險，即口若無言的使用者推動一個專注的工具轉變為「瑞士軍刀」，使其變得太過複雜，讓單一維護者難以持續維護。

最終，一個 package 在 lockfile 中的持續存在並不代表其健康度。無論是透過「仁慈的殭屍」還是「企業孤兒」，產業鏈繼續依賴著實際上已經是幽靈專案的專案，等待著某個時刻，墨鏡摘下後的真實情況顯露現形，衰退的真相顯露現形。