開源專案積壓背後的指數曲線

背景

本文探討開源專案中拉取請求（PR）長期積壓的現象，作者以 Jellyfin 專案為例，指出即便貢獻者積極配合修改，小規模的功能更新仍可能耗時一年以上。文章引用排隊理論說明，當維護者的利用率接近飽和時，等待時間會呈指數級增長，形成難以跨越的開發瓶頸。

社群觀點

針對開源專案的積壓困境，社群討論呈現出幾種截然不同的應對思維。部分開發者抱持現實主義，認為與其在官僚體系中空等，不如直接進行「友善分叉」。這種觀點主張分叉不一定是敵對的，貢獻者可以先在自己的分支中整合被擱置的 PR 並持續維護，若後續證明判斷正確且具備管理能力，原維護者反而可能將其收編為核心成員。這種去中心化的開發模式被視為緩解單一維護者壓力的有效手段，但也引發了關於專案治理結構的深層辯論。

有評論者尖銳地指出，開源專案長期陷入「獨裁統治」的陷阱，將所有決策權集中在極少數未支薪的維護者身上，這本質上是一種意識形態的失敗。當專案規模擴大到足以支撐數十億美元價值的生態系時，仍依賴原始的個人管理模式顯然不切實際。社群中有人提議應引入更具民主色彩的治理工具，或是建立類似 Linux 核心的層級審核制度，透過多層級的「副官」來分擔審核工作，而非讓所有貢獻都擠在同一個瓶頸口。

關於技術輔助手段，人工智慧（AI）的介入引發了正反兩面的激烈爭執。支持者認為 AI 可以處理重複性的基礎錯誤檢查，為維護者節省寶貴時間；反對者則擔心 AI 生成的評論往往充滿瑣碎的噪音，反而增加維護者同時審核程式碼與 AI 評論的負擔。此外，也有人從工程實踐角度出發，建議專案應高度模組化或建立插件系統，讓新功能可以先以「實驗性」標籤存在，降低合併風險。

最後，討論也觸及了開源世界的現實殘酷面：維護者的時間並非無窮無盡，且往往缺乏經濟激勵。有意見認為，如果貢獻者真的重視某項功能，或許應該考慮付費請維護者優先處理，或是透過類似群眾募資的模式來資助特定功能的開發。這種將商業邏輯引入開源的作法雖然具爭議性，卻也反映出社群在面對指數級增長的積壓曲線時，對於現有模式能否持續運作的集體焦慮。

延伸閱讀

• 關於排隊理論在產品開發中的應用，可參考 Donald Reinertsen 的著作《The Principles of Product Development Flow》。
• 討論中提到的 OpenWrt 郵件列表，記錄了關於引入 AI 輔助程式碼審核的政策辯論。
• 關於開源維護者現狀的數據，可查閱 Tidelift 2024 年的維護者調查報告。