軟體開源信任：為什麼永續維護
永續維護為什麼是開源信任的核心？
我們可以這樣理解：信任不是一次性的事件，而是一連串「兌現承諾」的累積。開源專案對使用者的承諾是什麼？是「當你發現問題，會有人處理」、「當新型態攻擊出現，會有人修補」、「當環境改變，會有人跟上」。這些承諾要能兌現，靠的不是熱情，而是制度化的維護能力。當維護中斷，承諾就跳票，信任也隨之崩解。
維護中斷的真實代價：從 Log4j 到 XZ 後門事件
談到開源維護風險，多數人第一個想到的是 2021 年底的 Log4j 漏洞。這個被大量 Java 應用程式使用的日誌函式庫，因為一個遞迴查詢功能引發遠端程式碼執行風險，短時間內震動全球資安圈。事件本身是技術缺陷，但真正讓傷害擴大的，是整個生態系對這個元件的依賴程度遠超過它所能承受的維護能量。許多企業直到漏洞爆發，才第一次認真去看「我們到底用了誰的程式碼、誰在維護它」。
另一個更令人警醒的案例，是 2024 年被揭露的 XZ Utils 後門事件。攻擊者以長期潛伏的方式，花費數年時間取得一個壓縮工具專案的維護權，再逐步植入惡意程式碼。這起事件之所以能發生，很大一部分原因在於：原本的維護者長期獨力支撐、身心俱疲，當有人願意「接手幫忙」時，很難拒絕。這正說明了一件事——維護者的過勞與孤立，本身就是一種可被利用的安全弱點。永續維護不只是「有沒有空修 bug」，而是「有沒有一個健康、多元、不容易被單點突破的維護結構」。
維護者的 burnout（過勞）與「巴士係數」風險
在開源圈裡有一個常被拿來討論的指標，叫做「巴士係數」（Bus Factor），意思是：如果專案的核心維護者突然無法繼續參與（不論原因為何），專案還能不能活下去？巴士係數為 1 的專案，代表整個專案的命運綁在一個人身上。這種專案在技術上可能很優秀，但在信任評估上，風險等級應該被大幅調高。
維護者過勞不是抽象的同情問題，而是具體的營運風險。當一個人長期獨力承擔 issue 回覆、安全修補、版本發布與社群協調，他的產能與判斷力都會隨時間下降；更糟的是，他可能因為壓力而做出錯誤決策，或在最需要警戒的時刻失去警覺。永續維護的第一課，就是承認「英雄式奉獻」不可持續，必須把責任分散、把流程制度化、把資金與人力常態化。
授權條款不是萬靈丹，治理與資金才是
很多企業在評估開源軟體時，第一件事是看授權條款：MIT、Apache 2.0、GPL、AGPL……這些確實重要，因為它們決定了你能怎麼用、怎麼改、怎麼散布。但授權條款只規範「法律上的權利義務」，它不會自動幫你修補漏洞，也不會保證專案十年後還在。
真正決定一個開源專案能否長期可信的，是治理與資金。治理回答「誰有權做決定、決策怎麼形成」；資金回答「維護者能不能吃飽、能不能專心」。一個授權再寬鬆的專案，如果沒有穩定治理與資源，長期風險依然很高；反過來說，一個治理透明、有基金會或企業贊助支持的專案，即使授權較嚴格，往往反而更值得放入關鍵系統。這也是為什麼近年來開源基金會、開源專案辦公室（OSPO）與各類贊助機制快速成長——大家都在補「永續」這一塊。
企業與使用者如何判斷一個開源專案「值得信任」？
知道了永續維護的重要性，下一個問題是：怎麼判斷？對一般使用者來說，這可能只是「這個 App 會不會突然沒人更新」；對企業來說，這是採購與架構決策的一部分。以下提供一套實務上可操作的觀察框架。
評估清單：從 commit 頻率到安全回應流程
評估一個開源專案的維護永續性，不能只看星星數或下載量。以下幾個面向值得逐一檢視：
這份清單不需要一次全部達標，但它能幫你把「感覺很可靠」轉換成「可以說清楚為什麼可靠」。對企業而言，把這套評估寫進採購與架構審查流程，是最務實的一步。
SBOM 與供應鏈安全：把信任變成可稽核的流程
近年來軟體供應鏈安全成為顯學，其中最重要的工具之一就是軟體物料清單（SBOM，Software Bill of Materials）。SBOM 的概念很像食品成分標示：它列出一個軟體產品包含了哪些元件、什麼版本、來自哪裡。有了 SBOM，當某個開源套件爆發漏洞時，企業才能快速回答「我們有沒有用到、用在哪裡、版本是否受影響」。
SBOM 的價值不只是事後補救，更在於它把「信任」從口頭承諾變成可稽核的流程。當你能持續產出並管理 SBOM，你就能對每一個相依元件的維護狀態進行盤點，進而優先處理那些「高依賴、低維護」的風險熱點。搭配漏洞資料庫、套件簽章、可重現建置等實務，企業可以把開源信任從「相信它應該沒問題」提升到「我們有證據說明它被妥善管理」。
值得注意的是，SBOM 本身不是萬靈丹。它告訴你「用了什麼」，但不直接告訴你「維護得好不好」。因此，實務上應該把 SBOM 與前述的維護評估清單結合：一邊盤點成分，一邊評估每個關鍵成分的永續性，才能真正把風險降到可控範圍。
讓永續維護成為共識：從個人到生態系的責任分工
講到這裡，可能有人會問：那我一個普通使用者或一家中小企業，能做什麼？答案比想像中具體。永續維護不是只有大企業或基金會的責任，它是一個責任分工的體系，每個角色都有可以著力之處。
企業參與開源的三種務實路徑
對企業來說，最常見的誤解是「我們不是軟體公司，跟開源沒關係」。但只要你用開源，你就是生態系的一部分。以下三種路徑，門檻由低到高，可以依規模選擇：
這三條路徑並不互斥，而且往往會彼此強化：有了 OSPO，才知道該贊助誰；有了上游貢獻，才更容易取得社群信任與影響力。
政策與社群層面的支持機制
除了企業自發行動，制度層面的支持同樣關鍵。近年來已有不少政府與國際組織開始正視開源基礎設施的公共性，例如透過基金補助關鍵專案、建立開源安全標準、要求政府採購軟體揭露 SBOM 等。這些政策的目的不是管制，而是把「維護」這件事從志工的私人負擔，提升為社會共同承擔的公共投資。
在社群層面，健康的專案也應該主動設計「降低巴士係數」的機制：文件化決策流程、培養多位維護者、建立明確的接班安排、對貢獻者給予公開肯定與實質支持。這些做法看起來繁瑣，卻是讓專案能撐過下一個十年的關鍵。當使用者、企業、政府與社群四方都願意為永續維護出一份力，開源信任才不會只是口號，而是可持續的現實。
結語：信任不是免費的，永續維護是每個使用者的共同責任
回到最初的問題：為什麼永續維護是開源信任的核心？因為信任的本質，是對「未來會被照顧」的期待。程式碼透明讓我們能驗證過去，社群治理讓我們能理解現在，但唯有永續維護，才能讓我們對未來抱持信心。當我們享受開源帶來的效率與創新時，也應該意識到：這份便利不是憑空而來，而是無數維護者在有限資源下撐起來的。
對一般使用者而言，這可能意味著在選用軟體時多看一眼專案的活躍度與治理；對企業而言，這意味著把開源視為基礎設施，納入風險管理與預算規劃；對整個社會而言，這意味著承認開源是數位時代的公共財，值得被認真投資。信任從來不是免費的，它需要被維護、被灌溉、被共同承擔。當我們開始把「永續維護」放回討論的核心，開源軟體才能真正成為值得長期託付的基礎建設。
下一次當你按下安裝、匯入套件、或批准一筆技術採購時，不妨多問一句：這個專案，明年還有人照顧嗎？這個問題看似簡單，卻是整個開源信任體系能否延續的關鍵所在。