開源專案死亡的那些蠢方式：七類失敗模式全解析
nesbitt.io · 2026-05-19
Andrew Nesbitt（libraries.io 共同創辦人）整理了一份開源軟體生態系的田野調查報告，將開源專案死亡的方式分為七大類，每類下有具體的子模式。這不是預言，而是已反覆發生的現象紀錄。
七類失敗模式
1. 維護者離開：最常見的類型。包含「幽靈維護者」（帳號存在但年餘未回應 issue）、被企業收購後拋棄的孤兒專案、論文畢業後停更的研究型工具，以及由於繼承人訪問不到套件倉庫的「發布鎖死」（registry 帳戶無法轉讓）。
2. 有人在但專案停滯：維護者存在卻無力推進。典型原因：長期燃盡（burnout）、只剩機器人自動更新依賴但無人審查、共同維護者之間的理念衝突造成 deadlock、核心知識無文件化導致「只有創辦人懂」的部落知識壁壘。
3. 蓄意破壞與供應鏈攻擊：涵蓋社會工程攻擊取得維護者帳號（xz/liblzma 模式）與原維護者主動注入惡意程式碼。
4. 發布管線失效：程式碼在 main 持續演進，但版本永遠發不出去。例如：建置知識失傳、private monorepo sync 中斷、套件倉庫失聯等。
5. 外部壓力：制裁法規導致維護者無法存取套件倉庫、DMCA 下架、第三方 API 服務關閉讓依賴者無法運作。
6. 被取代而成廢棄：語言或平台演進使套件失去必要性——如各種 polyfill「再也沒人需要」。這不是失敗，而是自然退役，但常被忽視的問題是文件從未更新，後進者繼續安裝已無意義的依賴。
7. 分裂：未解決的 fork、授權變更（如 BSL 或 SSPL 的非 OSI 認可版本）造成社群分裂，商業版本抽空社群版功能，最終兩者都萎縮。
貫穿全文的結構問題
Nesbitt 指出，大多數失敗模式的根源不是技術問題，而是治理與基礎設施問題——套件發布權、帳戶轉讓機制、維護者繼承流程。npm、PyPI、RubyGems 等生態系在這些面向的制度設計至今仍不完整。
原始來源：nesbitt.io
虛擬作業系統博物館：互動式探索電腦史上幾乎所有 OS
virtualosmuseum.org · 2026-05-20
一個名為 Virtual OS Museum 的網站在 Hacker News 首頁以 505 點登上前三，收錄了電腦史上幾乎所有主要與非主流作業系統，並以互動式展覽的形式讓訪客實際體驗這些系統的介面與操作。HN 討論串成為了一場作業系統懷舊馬拉松。
館藏範疇
博物館的收錄範圍跨越半個多世紀的 OS 歷史，從 1970 年代的大型主機系統到近年的奇特實驗性專案：商業 GUI 系統（早期 Macintosh System、OS/2 Warp、BeOS、NEXTSTEP）、消費端作業系統的各個演進版本、伺服器 UNIX 家族，以及 Amiga、Acorn 等平台特定系統。部分系統直接在瀏覽器中以模擬器運行，讓使用者可以輸入指令或操作 GUI。
HN 討論中的工程趣聞
HN 討論串中最高票的幾個回應聚焦於技術細節：Plan 9 的 9P 協定設計為何在概念上遠超時代、BeOS 的真實時間多媒體排程器為何在 1995 年就能流暢播放多路影片而當時的 Windows 95 做不到、以及 Haiku OS（BeOS 的開源繼任者）在近期成功啟動於 Apple Silicon M1 的近況。
Hacker News 的 討論串顯示，「真正的」多工 OS 的定義在不同世代工程師之間仍存在分歧，而這個博物館無意間成為了這場爭論的共同參考點。
原始來源：Virtual OS Museum