hero

城武導讀：ThoughtWorks 兩位資深顧問把開源社群這幾年來隱隱作痛的問題一次攤開——維護者過勞、AI slop PR 海嘯、授權機制被大企業當成合法掠奪工具、以及「規格取代程式碼」這個大膽到近乎危險的新命題。這篇不是那種「開源好棒棒大家要支持」的溫情喊話，而是把經濟學、供應鏈安全和授權歷史拉在一起，指出一個結構性真相：我們把「複製成本為零」誤當成「維護成本為零」，然後把兩者包在一起叫做「開源精神」。以下為全文翻譯。

原文翻譯

我們正活在一個醞釀數十年的架構轉折點上，而生成式 AI 的壓力讓這個轉折急遽加速。多年來，軟體工程產業一直靠著一個舒服——或許該說偷懶——的神話過日子：開源軟體是一種無限、自我再生的公共財，消費它不用花一毛錢，維持它也不需要任何成本。

2026 年六月底在瑞士舉行的「軟體工程的未來」閉門研討會上，討論呈現出一幅更加破碎而急迫的圖像。我們必須面對的現實很殘酷：開源不是單純在經歷演化，而是正在被結構性耗竭、供應鏈戰爭，以及程式碼生成的工業化，三股力量同時碾壓。

耗竭經濟學，與零成本謬誤

當前危機的核心，是對「資產定價」與「人力成本」的根本誤解。有一個聽起來很優雅的經濟學論點常常被拿出來：數位資產的價格應該趨近於它的邊際分發成本——也就是趨近於零。如果複製一個函式庫不花錢，理論上，軟體就應該是免費的。

但這個優雅的理論把其中的人類勞動完全藏起來了。分發確實不用錢，但維護貴得嚇人。那些撐起現代數位銀行、雲端基礎設施和企業平台的 load-bearing 開源套件維護者——那些看不見的支柱——正在被燒乾，而且承受著來自數十億美元營收的消費方心理騷擾，這些消費方榨取他們的勞動卻一毛都不回饋。

我們集體把「寬鬆授權」跟「合法掠奪」搞混了。從雲端時代興起以來，開源倡議者把 MIT 和 Apache 授權歌頌為軟體採用的終極勝利。然而，這個寬鬆授權體制反而成了巨型企業建立私有帝國的基石：把開源程式碼包一層薄薄的 orchestration 就拿去賺錢，卻幾乎不回饋生態系。這套系統對少數幸運者是庇護制，對其他人則是慈善救濟。這當然是根本不可持續的。

雙重壓力：Slop PR 與崩潰中的信任

如果說開源的結構性經濟本來就脆弱，那自動化工具的導入就是把慢性病變成急性發作。維護者現在正面臨雙線夾擊。

Slop 的工業化： 生成程式碼的門檻已經降到零。這固然賦予個人力量，但也讓 repository 的大門被大量低品質、AI 生成的 pull request 淹沒。維護者從寫程式的人，被迫變成全職無薪的 code reviewer，在那些為了刷履歷而丟自動化貢獻的使用者之間篩選垃圾。

這形成了一個惡性循環：心理與情緒負擔迫使維護者乾脆把專案對外關閉，不再接受公開貢獻。而這無意間切斷了下一代正當維護者的進入管道——那些原本會接手並延續專案生命的人。

信任地景的根本改變： 我們不能再信任傳統的開源可信度指標了。專案成熟的時間軸已經崩塌：有些函式庫靠 AI agent 病毒式炒作在幾週內衝到幾萬顆 GitHub stars，但 commit 歷史只有三週。同時，惡意 PR 的產生成本極低。Agent 每天都在找到新的攻擊向量，維護者要維持「這軟體是安全的」的基本信任變得極其困難。綜合來看，開源的信任模型已被嚴重劣化。

授權悖論：從自由到掠奪

當代軟體工程的結構脆弱性，與我們為了保護它所設計的法律框架緊密相連。我們現行的授權模型在不經意間創造出了一個萃取經濟，迫使我們重新審視「寬鬆」開源授權（MIT、Apache）與 copyleft 協議（GPL）之間的根本哲學差異。

歷史共識把寬鬆授權捧為軟體廣泛採用的終極催化劑。藉由降低摩擦、剝除合規障礙，MIT 和 Apache 這類授權讓程式碼得以全球化傳播。

然而，這個無摩擦分發成了一把雙面刃。研討會上一位參與者指出，寬鬆授權是一個深遠的集體錯誤——它作為一種法律機制，讓全世界最大的企業得以合法蠶食志願勞動，把獨立維護者變成數十億美元企業基礎設施的無薪承重柱。

替代方案——限制性授權或雙重授權——則經常引入完全不同類型的運作失敗：

  • 採購瓶頸。 試圖用非商業或「個人免費」條款保護程式碼，往往等於替專案的採用率宣判死刑。企業開發者放棄這個工具，不是因為它沒用，而是因為授權變更觸發了複雜的企業採購審查和行政文書流程，工程師直接拒絕去跑這些程序。

  • 企業杯葛。 即使雙重授權門檻經過謹慎校準——例如 Akka 轉向針對營收超過一億美元的組織收費的授權——企業仍慣常選擇杯葛而非遵守。一個被引用的案例中，有企業明明負擔得起，卻刻意放棄一個關鍵相依套件，純粹為了避免建立「付錢給開源社群」的先例。

  • 執行負擔。 對某些純粹主義者而言，任何授權限制都會引入行政負債。從這個角度，加上商業限制等於強迫維護者變成執法者，把創作行為變成法律苦差事。

  • 重新實作繞道。 這不只在倫理上有疑慮，還有實務問題：重新實作需要時間和金錢，而且可能引入新的安全或可靠性問題。

產業已經大致上消滅了「可以自由修改的軟體」與「消費時不用付錢的軟體」之間的區別——也就是常說的 free speech 與 free beer 的差異。

開源定義當初之所以出現，正是因為傳統自由軟體被認為不夠 business-friendly。而當我們一切以 business-friendly 為最高指導原則優化到底，就走到了一個奇怪的境地：企業贊助被視為一種可有可無的慈善，而不是一種基礎結構義務。

讓這場危機更惡化的是維護者在試圖修正路線時所承受的情緒與心理代價。當一個 load-bearing 專案進行防禦性授權轉向時，社群反應往往是敵意的。維護者面臨來自他們支撐多年的生態系的聲譽與心理反噬。我們現在處在一個「改授權被視為侵略行為，利用授權被視為標準商業操作」的環境裡。

生態系崩潰與維護者誘因危機

我們已經到了生態系可能崩潰的臨界點。維護專案的誘因正在消失，而更廣泛的產業就業壓力，讓即使是最有動力、最熱情的軟體開發者也難以參與開源。

「公地悲劇」——描述公共資源因為自利行為者不斷提取而枯竭的現象——是討論中常被引用的概念。乍看之下，開源確實是公地悲劇的絕佳案例。但這個概念雖然有幫助，套用在這裡卻無法說明其中的不對稱性。首先，如果開源軟體是某種公地，它不是一個自然存在、任何人都能伸手進去提取的資源；它是由純粹基於社群精神的人類建造和維護出來的。其次，提取的過程正在由擁有立即商業誘因的行動者以大規模進行。

早期的開源時代大致是靠「有一個開發者社群」和「互利」的感覺在維持的，但今天的軟體經濟讓價值一旦被提取、被捕獲，就再也無法流回當初讓它誕生的生態系。

規格 vs. 程式碼：接下來往哪裡走？

在這些壓力的交匯處，一個激進的命題浮現了：開源的未來，是不是規格，而不是程式碼？

隨著 LLM 能夠按需生成專用程式碼，企業工程團隊開始質疑引入幾萬行的外部相依套件到底還有沒有意義。如果使用外部函式庫會引入無法管理的供應鏈風險和無止境的修補循環，那從經濟邏輯上，用 AI 只重新實作恰好需要的功能片段、包在一個本地的「安全泡泡」裡，反而更合理。

  • 「傳統」模型 → 消費外部程式碼庫 → 繼承供應鏈風險與維護
  • 新興模型 → 研究開放規格／想法 → AI 生成本地重新實作

然而，這個「重新實作」命題有其極限。複雜的工程任務——例如加密函式庫或跨瀏覽器 UI 框架——需要極深的工程嚴謹度，自動化模型無法可靠複製，硬來只會變成一場徹底的災難。

更進一步，這也否定了參考函式庫的原創者應得的 credit。對有商業目標的組織來說這可能不是優先事項，但如果那個認可就是維護者的動機來源，當它消失了會發生什麼事？

完全放棄共享程式碼庫、轉向本地碎片化程式碼，還可能創造出一種菁英分化：擁有硬體和資金執行精密本地 AI 架構的人，與完全沒有軟體可用的人。

給軟體工程師與架構師的問題

要在這個地景中航行，工程團隊必須從被動消費轉向提出更艱難、更刻意的問題：

  • 我們的相依足跡有多大？ 我們是不是為了一個只需要 200 行邏輯就能解決的問題，引入了一個兩萬行的第三方函式庫？如果是，我們準備好承擔這個相依套件的安全與維護生命週期了嗎？
  • 我們如何定義與維護者的關係？ 如果我們的生產系統依賴一個由志願者或迷你團隊維護的開源工具，我們回饋物質資源的機制是什麼？
  • 我們在哪裡畫下規格與實作的分界線？ 在接下來的專案中，我們是該為了架構模式和規格來參考開源，還是為了它的實際二進位檔？

未來幾個月的行動指引

當我們更深入這個代理時代，工程組織應該對開源採取防禦性但高度有意識的姿態：

  1. 從被動消費轉向主動擁有。 把每一個開源相依套件當成你實質上雇進組織的程式碼，而不是免費禮物。如果維護者明天就撒手不幹或關閉 PR，你的團隊必須有能力在內部審計、修補或 fork 那個程式碼庫。

  2. 實施嚴格的供應鏈審計。 鑑於供應鏈威脅增加了 400%，加上長期社交工程攻擊的現實，少依賴 star 數或新舊程度。實施自動化沙箱測試、驗證套件來源，並建立嚴格的內部 registry，而不是直接從未審查的公開鏡像拉取。

  3. 制度化開源貢獻與贊助預算。 如果你的商業模式建立在開源軟體上驅動營收，就建立一條正規管道來資助那些專案。這不是企業慈善，這是基礎的風險控制——防止那些撐著你底層基礎設施的人被燒乾。

開源不會消失，但那個不審查、不贊助、完全寬鬆的免費午餐時代，正在走到盡頭。在未來幾年中存活並茁壯的團隊，會是那些以真正的結構性基石所應得的尊重、批判與物質支持，來對待開源的人。

城武觀點

ThoughtWorks 這篇寫得很紮實，把開源生態的經濟學、信任危機和授權歷史串得很清楚。但有三件事，文章點到了卻沒有追到底。

第一，AI slop PR 是症狀，GitHub 的設計誘因才是病根。

文章把矛頭指向 AI 生成的低品質 PR，說這讓維護者變成無薪 code reviewer。這當然是真的——但真正該被追究的，是 GitHub 自己的 PR 機制。任何一個能讓陌生人在三秒內送出 code change request 的介面，在 AI 時代就是攻擊向量。GitHub 不是不知道這件事。新帳號限流、AI PR 自動標記、可疑 pattern 的 rate limit——這些都是很簡單就能實作的機制。但它們選擇不做。為什麼？因為 PR 數量是 GitHub 的 engagement metric。每一個 AI slop PR 在 GitHub 的 dashboard 上都是一筆「社群活躍度」。維護者被淹沒的痛苦，在 GitHub 的商業敘事裡被轉譯成「開源生態蓬勃發展」。

這不是 oversight，這是 incentive alignment 的問題。GitHub 的商業利益跟維護者的心理健康，從一開始就是對立的。而 ThoughtWorks 的文章沒有點名這件事——也許是因為 ThoughtWorks 自己也是 GitHub 生態系裡的大型參與者。

第二，「規格取代程式碼」是全篇最大膽、也最危險的命題。

文章提出一個願景：未來我們不 import 外部函式庫，而是「研究開放規格 → 用 AI 重新實作」。這聽起來像是供應鏈風險的解方，但其實是把風險往上推一層。規格也是人寫的，也有歧義、也有 bug。你今天信任 numpy 的實作有問題可以開 issue，明天你信任某份規格文件有問題要找誰？

更危險的是 credit 的問題。文章自己也承認：重新實作否定了原創者的 credit。但它在下一段就輕輕放下——「對有商業目標的組織來說這可能不是優先事項」。這句話本身就說明了問題的全貌：規格被提取、想法被吸收、原始程式碼被丟掉、credit 被抹除，然後企業說「這不是我們的優先事項」。這不是供應鏈改革，這是學術掠奪模式的工業化版本。而且它以經在發生了——LLM 的訓練資料裡有多少開源程式碼被「重新實作」成模型權重裡的機率分佈，原作者連名字都不會出現。

第三，開源需要的是 infrastructure-class funding，不是 corporate patronage。

文章呼籲企業「制度化開源贊助預算」，這個方向是對的，但沒有問一個更基本的問題：為什麼開源要依賴企業的良心才能存活？這不是 charity problem，這是 infrastructure funding model 的結構性失敗。

如果我們認為道路和橋樑是公共財、應該由稅收支應，為什麼那些撐起全球數位經濟的 load-bearing 開源軟體不能有一樣的地位？OpenSSL 在 Heartbleed 之前只有一個全職維護者，這件事到今天聽起來還是很荒謬——但更荒謬的是，Heartbleed 之後的「改革」，也只是讓更多企業「自願」捐錢。結構本身沒有變。企業贊助是 good to have，但在經濟下行時第一個被砍的就是這筆預算。xAI 不會因為 Grok 底層用了多少開源套件就覺得自己有義務養那些維護者。

城武的立場很清楚：開源需要的是類似國家科學基金會那樣的公共資金機制——不是求大公司行行好。而且這件事的 urgency，遠比文章最後那三點「行動指引」所暗示的要高。因為維護者燒乾的速度，比任何企業建立贊助預算的速度都快。

城武的未解檔案——當你的基礎設施靠一群不支薪的人維持，而你稱這個狀態為「生態系蓬勃發展」，那崩潰就不是會不會發生的問題，而是誰先倒下的問題。