FOSS烏托邦與現實的距離

我見到和使用的所有優秀的開源專案，要麼是由大型企業/組織牽頭進行開發的，要麼九成以上的程式碼都是由高水平的單一開發者編寫的。這些專案與其說是開源，實際上更像是「公開原始碼」，因為外部人員難以介入主要的開發流程。在「大教堂」與「市集」的對立中，這些專案顯然更偏向「大教堂」那一方，儘管它們確實披著「開源」的皮。

我見到的那些廣泛吸納外部開發人員的開源專案，大多數人都可以於開發過程中插一腳的專案，普遍是垃圾箱起火級別的災難。這些是真正的「開源」，在「大教堂」與「市集」的對立中，顯然屬於「市集」的那一方。

有了上述經驗，就很難不對「市集」模式的實踐產生意見。軟體行業的現狀已經證明了，「市集」模式並不適合大多數軟體專案。

捫心自問，你維護過幾個開源專案的分支？你的分支能夠追蹤上游的進度嗎？

大多數由個人/小型組織維護的分支專案會在一小段密集提交之後變成一處遺蹟：

即使對於因意見分裂而產生的，由原開發團隊的部分成員所維護的大型分支，往往也很難持續。證據是再顯而易見不過的：市面上並沒有幾個軟體在出現大型分支後成功維持住平行開發的局面——不需要多長時間，就會有一方勝出。那極少數能夠維持住平行開發的大型分支，要麼其上游是一個幾乎不添加新功能的成熟專案，要麼徹底脫離了對上游的依賴。

專案的主要維護者和「網際網路上的隨機外人」對專案的瞭解程度有天壤之別：若要寫出「正確的程式碼」或者「戰略編程」級別的程式碼，後者需要花費很多時間和努力來增進自己對專案的瞭解。遺憾的是大多數貢獻者並不具備這種等級的開源精神或客觀條件。

開源專案的維護者需要審查「網際網路上的隨機外人」發送來的拉取請求，然後有很高的機率發現大部分拉取請求是不能直接合併的。一個專案越是容易吸引低水平的開發者，就越是容易遇到這種拉取請求。無論是引導外部貢獻者將程式碼改寫以使其達到可以合併的狀態，還是由維護者親自上陣改寫程式碼，都需要投入時間和精力。構建在開源理念之上的溝通和反饋循環通常效率極為低下，以至於在很多時候都不匹配為之付出的努力，維護者值得把時間花在更有效率的地方。

外部貢獻者和開發團隊的目標之間存在差異是很普遍的現象，很多專案因此不需要功能層面的外部貢獻。

對於開發團隊真正關心的功能，官方實現往往又快又好。對於他們並不真正關心的功能，功能請求會在沉寂一段時間後被機器人關閉，拉取請求會石沉大海。或者更糟，一個匆忙的實現被合併，變成了軟體的安全漏洞，在多次修復嘗試之後仍於後續版本裡回歸，反正最後難逃被刪除的命運。

如何在維護開源專案的同時保持優雅？優質解答：我不知道。

影響最深遠的開源專案領導者Linus Torvalds恐怕也不知道。考慮到他管理的專案具有相當高的准入門檻，以至於像我這種小角色甚至不會考慮去做出貢獻，他履行自己職務所需的能力已是常人難以想像的。即使在這些高門檻專案裡，在資訊傳達到Linus眼前已經過多層過濾的情況下，Linus有時也會表現得刻薄殘酷，在批評時極盡譏諷和侮辱——這種現象嚴重到以至於欣賞這些情緒宣洩已經變成一種樂趣。有相當比例的開發人員對Linus的情緒化持正面看法，乃至將其視作Linus良好聲譽的重要組成部分（一定程度上是因為這些資訊更有傳播潛力），因為一個不存在Linus這類技術獨裁者的世界相當容易想像：我們不會得到現在這種質量的軟體，一切只會比現在更糟。對於管理者以外的人來說情況也類似，開源社群不是誇誇群，效率較高的交流方式往往是有毒的。

世界上確實存在著一些超人，能夠在任何情況下保持心平氣和，圓滑地處理好一切，我將之歸功於天賦或藥物。因為假如這種能力是可以傳授的，或至少可以透過修行取得的，那麼應該早就推廣開了，畢竟世界上應該有很多人想要這種情緒控制能力。與此同時還應該注意到，這些超人很少處於技術領域的頂點——技術領域的頂點基本上是由充滿毒性的自大狂所佔據的，你看到的這些人之間的區別主要取決於公關實力的高低。這種相關性將我們引導向一個無法證明，但又似乎客觀存在的規律：良好的開源精神和良好的精神狀態就像魚和熊掌般不可兼得。

除非你已經站在自身領域的巔峰圈層，不然你總有機會見識比你厲害的人：懂得分比你多，想得比你深，做得比你好。最差的工程師與最好的工程師之間的差距不能以「10x工程師」來簡單概括。在細分領域下，伴隨著經驗和專業知識的差距，工程師之間的差距可能遠大於十倍。

僅就開源運動而言，有一種簡單方式來分類具有不同技能水平的工程師：

然而，在開源社群裡，缺乏自知之明的假工程師就好像是為了驗證鄧寧-克魯格效應一樣普遍存在。這些麻煩製造者往往還熱衷於賺取「社交積分」，偏好留下缺乏有效資訊量的文字，以及為了作出貢獻而作出貢獻。兩類工程師之間實際夾著一個過渡階段，被稱作冒名頂替綜合征，這些人往往不參與開源專案，反而危害性很小。

開源中最令人惱火的部分是，能被獨立解決的錯誤、問題、誤會，因為技能水平的差異而從假工程師身上錯誤地轉嫁給真工程師。這純粹是浪費後者的時間。若是人能做到首先懷疑自己，行事保持細心謹慎，那麼即使在技能水平上有差異，大多數此類情況也應該是可以避免的。悲哀的是，這些本應成為基本素養的東西，實際上較為稀缺，而開源運動缺乏把假工程師攔在外面的有效手段。

不論你是否承認，但自由軟體和開源軟體這些概念在面向終端使用者時，意義基本上相同——它們是「免費、安全的軟體」的替代詞彙。

「不付出就能有回報」在行銷層面具有非常強的效果，大多數人無力招架這種誘惑。最典型的例子發生在遊戲行業（同時也是軟體業的一部分），最賺錢的遊戲是所謂的「免費遊戲」。問問自己這個問題，如果它不是免費的，你仍然會選擇它嗎？

有相當比例的「開源專案」，其「開源」標籤作為廣告的價值要遠遠大於「開源」作為模式的價值。這些人要麼清楚地認識到這些專案一旦脫離原始開發團隊就難以存續，只將開源作為領先競爭對手的一種行銷手段；要麼乾脆使用自己定義的「開源許可證」，當一個「開源專案」不使用常見許可證時，不難想像其中的貓膩；一些原本開源的專案在更換為非開源許可證後，繼續以開源名義混淆視聽，你就知道「開源」二字的行銷價值所在。

在人工智慧領域，甚至「開放權重」現在也被稱作「開源」。就像「原始碼可讀」不是開源一樣，「開放權重」也不是開源。能從這種隨意拓寬語義的胡言亂語中受益的只有那些指望將開源作為廣告的人。

開源軟體的醜陋一面經常被浮於表面的「免費」所掩蓋。天下沒有免費的午餐，學習、理解、利用、貢獻開源軟體都是有成本的。由於開源軟體的檔案更稀疏，糾錯和獲得支援嚴重依賴於社群，普遍存在沒有經過實戰檢驗的程式碼等問題，開源軟體實際上經常產生意料之外的成本。當你決定依賴一個開源專案時，你就已經在承受這些成本。

開源軟體唯一免費的部分在於維護者出於理想和使命感的自我奴役，而這很容易導向更大的崩潰。一個暫時運轉良好的開源軟體，並不意味著在未來也運轉良好。維護者可能厭倦，放棄，失去維護的能力，能力不足，甚至只是突發惡疾決定毀掉原來還不錯的專案。因此使用開源軟體不僅有成本，還需要承擔風險。商業軟體由於顯而易見的利益驅動，反而使其比開源軟體有保障。

「但是開源維護者不欠你任何東西！」——希望當你因為供應鏈攻擊和安全漏洞蒙受損失時仍然能自信地說出這句話。即使只是施捨的粥，往裡面撒尿也是不可原諒的。人們對開源軟體的盲目信任和濫用創造了太多往粥裡摻尿的機會，導致任何一個使用外部依賴的軟體都可能因此意外間接引入有問題的依賴項，從而禍害到依賴鏈條下游的所有人。這種信任危機從根本上增加了所有人繼續使用開源軟體的成本，到最後，所有原本輕快的東西都會因為一些不知道從哪裡鑽出來的「試圖解決問題」的人的安全作秀而套上沉重的枷鎖。

LLM的濫用讓FOSS原本就存在的問題徹底且集中地爆發。如果說之前的開源軟體尚且還留有一些利用價值，那麼如今的開源軟體已經完全失去了這種價值：透過程式碼來判斷作者的技能水平和對問題域的瞭解的成本已經變得太高了。尤其是在2025年11月後發布的程式碼，已不再值得哪怕一秒鐘的認真對待，只有把它們全都視作是垃圾來處理才有效率可言。

在我看來，FOSS已經名存實亡，社群的唯一出路是創建一個新的品牌，把那些仍然尊重程式碼質量的人團結在新的旗幟下——這還得是建立在這些人有能力戰勝LLM編程導致的新一代worse is better的前提下。

直到LLM因為新的訓練數據只剩下垃圾而模型崩潰之前，我認為FOSS社群沒有翻身的機會。他們能做的最好的選擇就是認可LLM生成的程式碼的價值，然後假裝一切仍然順利，最後像蘇聯一樣在靜默與窒息中消亡。