軟體軟體永續：為什麼開源治理
問題在於，使用者的採用速度永遠快於專案的治理成熟速度。一個專案可能在成熟期前就被大量企業導入，此時它還沒有能力承受這種規模的期待。OpenSSL 在 Heartbleed 之前就是如此：全球都在用，但專案的組織能力遠遠跟不上它的實際重要性。這也是為什麼「軟體永續」不能只看技術指標，必須把治理能力一併納入評估。
二、開源治理到底在治理什麼？
很多人聽到「治理」兩個字，會聯想到企業管理、KPI、績效考核。但開源治理談的不是這些，而是決策的正當性與可預測性。一個專案由誰決定要不要接受某個功能？由誰決定何時發版？由誰決定授權條款？由誰保管捐款？當兩個人意見不合時，用什麼機制解決？這些問題如果沒有事先講清楚，就會在壓力來臨時引爆衝突。
治理不等於管理。管理是「把事做完」，治理是「把做事的規則講清楚」。前者追求效率，後者追求正當性。一個沒有治理的專案，短期內可能跑得很快，因為決策不需要開會、不需要公告、不需要說服任何人；但長期而言，它無法擴張，因為沒有人知道決策是怎麼來的，也沒有人敢把重要系統託付給一個「看維護者心情」的專案。
治理不是管理：決策權、責任與透明度的分配
具體來說，一份完整的開源治理文件通常會處理以下幾件事：
MAINTAINERS 或 OWNERS 檔案明列各模組負責人。資產與財務：捐款由誰管理？商標與網域歸誰？資金用途是否公開？
行為準則：如何處理騷擾、歧視與毒性行為，避免社群因人事問題而崩解。
這些文件的存在本身就是一種訊號：它代表專案領導層意識到「自己總有一天會離開」，並且願意把權力交接的規則寫下來。反過來說，一個連 CONTRIBUTING.md 都沒有的專案，通常也還沒有思考過永續問題。
四種常見治理模型：BDFL、基金會、商業贊助、共治
實務上，開源專案的治理模型大致可以分成四類。它們沒有絕對優劣，重點是「是否與專案的風險等級相匹配」。
治理模型
決策核心
優點
風險
典型案例
BDFL（仁慈獨裁者）
單一創始人或核心維護者
決策快、路線一致、避免無謂爭論
巴士因子低、接班困難、易生個人崇拜
早期 Linux、Python、Vue
基金會託管
理事會或技術指導委員會
中立、法律與財務有實體、較易取得企業信任
決策較慢、行政成本高、可能與商業需求脫節
Apache 軟體基金會、Linux 基金會、CNCF
商業贊助／單一廠商主導
贊助企業的產品團隊
資源充足、開發節奏穩定、有專職人力
路線圖服務商業利益、授權變更風險、社群話語權低
React、Angular、部分資料庫專案
社群共治
維護者委員會、SIG 分組
可擴展、參與者多元、決策透明
容易陷入討論癱瘓、責任分散、需要成熟文化
Kubernetes、Debian、Rust
值得注意的是，治理模型會隨時間演化。Linux 從 BDFL 走向基金會與大量子系統維護者；Python 從 Guido van Rossum 的 BDFL 走向指導委員會；許多原本由單一公司主導的專案，在授權爭議後也開始思考中立化。這種演化本身就是永續性的體現：能夠調整治理結構的專案，才有機會活過下一個十年。
三、為什麼沒有治理的開源專案會「爛掉」
沒有治理的專案不是「比較不正式」而已，而是會在特定壓力下出現結構性失效。以下幾種失效模式，幾乎可以在每一次重大開源安全事件中找到影子。
巴士因子與單點依賴：一個人離線，半個網路停擺
巴士因子（bus factor）指的是「要讓一個專案停擺，需要幾個人同時被公車撞到」。當這個數字是一，代表專案的存活完全依賴單一維護者。這種情況在開源世界極為普遍，因為許多專案原本只是某個工程師的副業，後來意外被大量採用，卻沒有相應地長出團隊。
單點依賴的危險不只在於「維護者離開」，也在於「維護者被攻擊」。2024 年的 xz-utils 事件就是一個典型：攻擊者不是破解密碼，而是花時間成為社群的一份子，取得信任後逐步接管發佈流程。這類社會工程攻擊之所以可行，正是因為專案缺乏多人審查、缺乏雙人覆核、缺乏對新維護者的背景檢驗。治理結構在這裡不只是行政流程，而是最實際的安全控制。
此外，維護者 burnout 也是真實風險。當一個人在業餘時間回應大量 issue、審查 PR、處理安全通報，卻沒有相應的報酬與支持，退出只是時間問題。colors.js 的作者在 2022 年刻意推送惡意版本，背後就有對大型企業「免費使用卻不付費」的不滿情緒。這類事件提醒我們：社群的勞動條件，是軟體永續的一部分。
授權變更與供應鏈風險：從 log4j 到 xz 事件的教訓
另一種常見的失效，是授權條款的變更。當一個專案原本採用寬鬆授權（如 Apache 2.0、MIT），後來因為商業策略調整而改為限制性授權（如 SSPL、BSL），使用者的法律風險就會瞬間升高。HashiCorp 將 Terraform 改為 BSL、Elastic 將 Elasticsearch 改為 SSPL、Redis 調整授權，都曾引發社群分裂與 fork。對企業而言，這不是單純的「換個版本」問題，而是可能導致產品無法再散布的法律風險。
供應鏈風險則更為隱蔽。現代應用動輒引入數百個間接依賴，其中任何一個出了問題，都可能沿著依賴樹向上影響。log4j 的案例最具代表性：一個廣泛被 Java 生態使用的日誌函式庫出現嚴重漏洞，影響範圍擴及全球數百萬個系統，而專案本身的維護人力長期不足。事件之後，產業開始重視 SBOM（軟體物料清單）、SLSA 供應鏈等級、Sigstore 簽章等機制，這些機制的本質，都是試圖用制度補足治理的缺口。
換句話說，沒有治理的專案不是「不會出事」，而是「出事時沒有人負責、沒有流程可循、沒有備援方案」。這正是為什麼軟體評測不能只看功能與效能，必須把治理能力納入評分。
四、軟體評測視角：如何評估一個開源專案的「永續分數」
如果你是一位技術主管、架構師或採購決策者，下一個問題自然是：有沒有辦法量化？答案是「可以接近，但不能完全」。永續性本質上是組織能力與社會關係的總和，很難用單一數字表示；不過，我們可以透過一組可觀測指標，建立一個實用的評估框架。
近年最具參考價值的公開工具是 OpenSSF 的 Scorecard，它針對開源專案檢查多項供應鏈安全實踐，例如是否啟用分支保護、是否有安全政策、是否簽署發佈產物、是否使用固定版本的依賴、是否有 CI 測試等。Scorecard 的價值在於把「看不見的治理」轉換成「可比較的分數」，讓企業在選型時有一個客觀起點。
可觀測的永續指標清單
以下是一份筆者實務上常用的檢查清單，分成「治理透明度」、「維護活躍度」、「安全與供應鏈」、「財務與組織」四類。每一項不需要完美，但如果有三項以上亮紅燈，就應該提高警覺。
類別
觀察指標
紅旗訊號
治理透明度
是否有 GOVERNANCE.md、MAINTAINERS、行為準則、決策流程說明
完全沒有治理文件，所有決策只在聊天室進行
維護活躍度
近六個月的提交頻率、issue 回應時間、PR 合併率、發版節奏
超過一年沒有正式發版，issue 長期無人回應
貢獻者分布
前三位貢獻者占比、是否有新血加入、維護者人數
單一貢獻者占比超過八成，且無接班規劃
安全與供應鏈
SECURITY.md、漏洞通報管道、依賴更新頻率、是否簽章發佈
無安全政策，依賴版本老舊且未見更新
財務與組織
是否有基金會或法人、捐款透明度、商業贊助關係
資金來源完全不公開，或完全依賴單一廠商
授權穩定
授權條款是否曾變更、是否有貢獻者授權協議（CLA/DCO）
授權曾突然改為限制性條款，且無中立治理機制
文件與測試
架構文件、遷移指南、測試覆蓋率、CI 狀態
無測試、無文件，只有原始碼與口耳相傳
把這些指標做成內部評分表，會比憑感覺選型可靠得多。例如可以給每個類別 1 到 5 分，總分低於某個門檻就必須啟動「替代方案評估」或「內部 fork 能力建置」。這樣的做法不是要否定小專案，而是要求團隊知道自己承擔了什麼風險。
企業選型實務：把治理條款寫進採購流程
評估之外，更重要的是把永續要求制度化。實務上可以從三個動作開始：
第一，把 SBOM 與 Scorecard 納入採購與上線流程。要求每個引入的開源元件都附上物料清單與基本治理檢查結果，讓風險可追蹤。這不是形式主義，而是當漏洞發生時，你能在幾小時內回答「我們哪裡用了它」。
第二，要求「退場計畫」。對於核心依賴，應該預先思考：如果專案停止維護，我們能否自行修補？能否轉移到 fork？轉移成本有多高？這個問題會逼團隊正視授權與架構耦合度。
第三，區分「消費」與「投資」。不是每個依賴都需要你投入資源，但對於被認定為關鍵基礎的專案，企業應該有預算與人力回饋 upstream，無論是修 bug、補測試、寫文件或直接贊助。這不只是道德問題，而是降低自身風險最便宜的方式。
五、從使用者到貢獻者：社群可以怎麼參與治理
談到這裡，很多小團隊會覺得「治理是大型基金會的事，與我無關」。其實不然。治理可以從非常輕量的形式開始，重點不是文件多厚，而是讓外部的人知道規則、讓內部的人能夠交接。
小團隊的輕量治理起步法
如果你的團隊維護著一個內部或半公開的開源專案，可以從以下四件事開始，成本極低但效果顯著：
這些動作的共通點是：把隱性知識顯性化。治理的本質不是增加官僚，而是降低「只有某個人知道」的風險。
文件、測試與資金：三種最實際的永續投資
如果你問「我能為開源永續做什麼」，答案通常不是「去當維護者」，而是以下三種投資，按影響力排序：
一、文件。文件是最被低估的貢獻。一篇好的入門指南、一份架構說明、一個可重現的範例，能讓新人更快上手，直接擴大潛在貢獻者基數。很多專案缺的不是程式碼，而是「讓人願意留下來」的體驗。
二、測試。測試是維護者的安全網。當一個專案有足夠的自動化測試，維護者才敢合併陌生人的 PR，也才敢進行重構。補測試看起來不酷，但它直接提升了專案承受變化的能力。
三、資金。資金不是萬靈丹，但它能讓維護者從「業餘燃燒」轉為「有時間投入」。Open Collective、GitHub Sponsors、Tidelift 等平台降低了贊助門檻；企業也可以透過基金會會員、專案贊助或直接聘用維護者的方式回饋。關鍵是長期且可預測，一次性的小額捐款對永續幫助有限，穩定的支持才能讓維護者做出承諾。
對企業而言，還有一個常被忽略的原則：上游優先（upstream first）。內部修補若不上游，就會形成永久性的 fork 維護負擔；把修正送回上游，讓所有人一起受益，才是真正降低長期成本的做法。
六、結語：永續不是情懷，是風險管理
回到最初的問題：為什麼開源治理值得我們認真對待？因為現代軟體的地基，是由無數個大小不一的開源專案堆疊而成的，而這些專案的穩定程度，取決於它們是否有能力承受成長、交接與攻擊。治理不是為了讓專案「看起來專業」，而是為了在維護者離開、漏洞爆發、商業策略轉彎時，系統仍然能夠被理解與修補。
對使用者來說，這意味著選型時要多問幾個問題：這個專案有治理文件嗎？貢獻者集中度如何？資金與決策是否透明？對企業來說，這意味著把永續指標納入採購與上線流程，並且對關鍵依賴做出實質回饋。對維護者來說，這意味著及早把規則寫下來，讓專案不再是「一個人的事業」。
軟體永續不是一種情懷，而是一種風險管理。當我們願意用評估效能與安全性的同等嚴謹，去評估一個專案的治理能力時，整個生態系才會往更健康的方向移動。下一次你按下 npm install 或 pip install 之前，不妨多看一眼那個專案的 GOVERNANCE.md：那短短幾行字，可能比任何效能 benchmark 都更能決定你的系統能不能活過下一個十年。