摘要：在開源領域，有一個存在很久但始終難以解決的問題——開源維護者全力維護開源項目，卻沒有穩定資金來源，而「用愛發電」註定難以為繼，各種開源項目開始 Bug 頻出。對此，很多人呼籲要對開源維護者提供資助，但這真的能徹底解決問題嗎？

連結

：https://blog.hansenpartnership.com/paying-maintainers-isnt-a-magic-bullet/

聲明：本文為 CSDN 翻譯，未經允許禁止轉載。

作者 | James Bottomley

譯者 | 彎月 責編 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

在過去的幾年裡，不斷有人提出向開源維護人員提供資助的建議。

總體而言，人們提出這項建議有一些很明顯的動機：提高開源生態系統的安全性和可靠性，認為這可以解決維護人員不堪重負的問題，最終還會解決開源領域的「搭便車」問題。

在此，我想通過本文逐個探討一下這些問題，看看提供資助是否真的能解決這些問題。

搭便車問題

簡單來說，搭便車問題指的是：有些公司不勞而獲，免費使用開源軟體，並將其作為利潤的基礎，卻不思回報，賺取不義之財。

事實上，這個問題自古就有，比如「老闆」壓榨「工人」，沒有支付足夠的報酬（或壓根不給報酬）；再比如貪婪的人類毫無節制地掠奪地球上免費且很有限的自然資源。開源軟體特別容易受到這個問題的影響，因為開源的就是免費的，而大多數人都不會花錢購買「免費」的產品。

此外，這個問題的部分原因來自於開源的基本理念。雖然開源的基本理念是自由，而不是免費，但是人們很容易混淆二者（英文單詞「free」既有「自由」的意思，也有「免費」的意思）。事實上，從經濟學的角度來看，開源對軟體行業產生的最大影響恰恰是它的免費。

開源是市場價值的破壞者

很多人認為，開源是市場價值的「破壞者」，但是人們往往不理解，這種破壞性的很大一部分是價值毀滅。我們舉個例子：一個古老的開源系統 Linux。

作為一款作業系統（與 GNU 或其他用戶空間軟體結合使用），Linux 早期與專有的 Unix 展開了鬥爭。然而，與免費軟體競爭利潤是不可能的，最終導致該領域的產品一個接一個退出市場或專注於其他產品，如今除了歷史遺留下來的產品以及一些小眾產品之外，已經沒有專有 Unix 提供商了——本質上，作業系統市場中包含的價值已被摧毀了。

曾經蘋果創建並擁有利潤豐厚的智慧型手機市場，開拓了 80% 的市場份額，然而谷歌憑藉 Android 成功地進入該領域，並擾亂了該市場，基於開源的免費作業系統成功吸引了大量的手機製造商，他們渴望比蘋果更便宜的平台。雖然手機市場的價值並沒有完全被摧毀，但也大大貶值（智慧型手機從高利潤業務變成了中低利潤業務）。

所有這些價值破壞都是通過開源的免費效應實現的，創新者不必承擔從零開發一切的全額經濟成本，他們只需採用免費開源的代碼，然後在此基礎之上進行修改。微軟以及一些公司聲稱開源是智慧財產權的「癌症」，也正是這個原因。

然而，這種觀點也是思想僵化和錯誤導致的，雖然開源破壞了現有市場的價值，但其為新興市場提供了更豐富的多樣性和獨一無二的機遇。從經濟學的角度來看，價值破壞的主要利益在於降低了門檻，為市場創造更多新機遇，並呈現多樣化的競爭（或將壟斷市場轉變為競爭市場）。

嫉妒並不能解決問題

讀完上述內容，你可能會發現，所謂的「搭便車」問題只是開源免費本質的自然結果，就像免費的啤酒一樣（有人用你免費提供的東西創造了一個市場，正是因為他們沒有為此付出代價），這根本不是一個需要解決的問題，我們應該坦然接受，並加以利用（如果你足夠聰明的話）。當然，並非我們所有人都具備商業頭腦來利用這樣的市場機遇，但即便你做不到，也沒必要嫉妒那些「搭便車」的人。

最重要的是，通過某種機制為維護人員提供資助也無法解決這個所謂的「搭便車」問題，因為濫用開源而不思回報的公司並沒有實質性的動力。

維護人員不堪重負

近年來，開源社區維護人員不堪重負已成為熱門話題，網上湧現了許多博客文章和支持小組。根據我的觀察，你是哪種類型的維護者似乎很重要。如果只是業餘愛好項目，在時間允許的情況下維護某個開源項目，那麼也不至於不堪重負。但如果你是一名全職維護者，那麼很有可能被壓垮。

我屬於前者，所以對於後者只能通過觀察，並沒有實際的經歷。但在我看來，如果交付預期超出你的能力，任何工作（不僅僅是開源維護者）都會壓垮你，不斷積壓的工作和口頭抱怨會導致你倍感沮喪。

當有人不堪重負時，常見的解決辦法是減輕負擔或提供幫助，但我發現全職開源維護人員非常不願意放棄項目（大概是因為每個項目都是他們核心價值的一部分），所以提供一些幫助、減輕他們的負擔是唯一可行的干預措施。

說到這裡，雖然有時候最初的本意可能是提供幫助，但我們往往會面臨不恰當的需求，從而導致負擔又加重：

• 開發者提出問題：「我們人手不足，項目已經落後於計劃六周了。」

• 管理者暗自分析：「我不能加人，也改變不了交付日期，只能無視。」

• 開發者得到的結果：「他希望我們匯報每天的進度，直到狀況有所改善。」

令我震驚的是，一些備受推崇的開源系統，比如 GitHub，也有一些類似的反面案例，比如鼓勵維護人員通過 Star 數展示代碼庫的價值，統計每日的 PR 以及問題數量，展示每一位訪問者，以及去年你為每個項目做出的貢獻。

說回重點，我認為提高收入並不能減輕維護人員的負擔。雖然金錢能給維護人員帶來短暫的幸福感，但日漸積累的工作量很快就會淹沒這種幸福感。

如果維護人員已經盡了最大努力，那麼給他們更多的錢也不能讓他們承擔起更多重任。而對於像我這樣的業餘愛好者，我已經將所有業餘時間都投入到我的維護項目中了，即使你給我的報酬超過我的工作收入，我也無法再投入更多時間了。

安全性與可靠性

每個人都希望維護人員提供安全可靠的代碼，並在一定的 SLA（服務水平協議）內處理錯誤報告。但很顯然，開源維護人員一般都會儘可能提供安全可靠的代碼，但他們不會考慮 SLA 之類的要求，因為沒有這個必要（許可中也提到了「無法保證……」），所以付錢給他們也無法提高代碼的安全性和可靠性；如果他們已投入所有時間，那麼就更無法保證及時響應錯誤報告了。

那麼，如何才能提高開原始碼的安全性和可靠性呢？維護人員真正能做的是讓保持代碼處於最新版本。如果向一個項目提出建議，告訴他們為了安全性，應該將數萬行 C 語言代碼用 Rust 重寫一遍，這不僅是無禮的要求，而且毫無意義。

保證軟體安全性與可靠性的關鍵方法之一是，運行檢查程序並進行廣泛的單元測試和集成測試。這樣做的好處在於，這項工作可以單獨進行，不必影響主要的維護工作，當然前提是有人分類並修復發現的問題。

修復是這項工作的關鍵，如果只是簡單地將問題匯報給已然不堪重負的維護人員只能讓情況更加糟糕，還會導致越來越多無法解決的問題。因此，如果你正在考慮提供檢查程序或測試的資源，請同時考慮如何解決發現的問題，不要加重維護人員的負擔。

圍繞安全性與可靠性的商業模式

檢查並測試代碼有一個歷史悠久的商業模式，即讓發布者來承擔這些工作。一些優秀的發布者會向上游發送補丁，他們的商業模式是出售軟體（或者提供支持）。但是，這種方式也存在一定的問題，主要是其經濟模型上的問題。

首先，你希望得到支持的產品必須是通過某個發行版提供的，這意味著該產品必須有足夠多的用戶，能夠支撐起一個發行版。其次，你最終需要按照實例支付使用成本，也就是發行版中包含的一切的平均成本。其中最大的問題在於每個實例的成本，特別是當你需要超大規模應用的情況下。也難怪有人呼籲將按實例付費改成按項目付費。

如前所述，維護人員需要的是更多的幫助，而不是金錢。一個良好的幫助方式是添加測試和檢查（包括修復錯誤和向上游發送補丁）服務。這必然需要與維護人員聯絡（並且可能涉及酬金），但我們的目標是輔助維護人員，並避免維護人員被沉重的負擔壓垮。

專業維護人員

上述大部分內容都假設維護人員已將所有時間都投入到了項目中。如果維護人員只是利用業餘時間做開源項目，或者他們是公司員工，部分收入來自於開源項目，部分來自其他收入，那麼就向他們支付全額工資，讓他們成為全職維護者（這樣的話他們就不得不離開當前的工作了），讓他們把花在「其他事情」上的時間轉移到開源項目上，這看似是一個很好的解決方案。

然而，我們不能忽視從公司員工轉變為獨立的合同工所帶來的各種成本（如醫療保健、稅務申報、會計等），這會占用維護人員大量的時間。此外，從兼職轉為全職更有可能會進一步加重維護人員的負擔，特別是他們需要花費更多時間來管理開源項目，以及諮詢業務等相關問題。

總結

通過上述探討，我們可以得出一個很明顯的結果：為維護人員提供更多資金支持並不能達到預期的效果。當然，這只不過是通過最終結果來看待問題。我們不能忽略的一點是，為維護人員提供更多資金肯定會增加維護人員的收入，並讓維護開源項目成為他們的謀生手段。

以前，開源維護人員獲取收入的唯一方式是積攢好口碑（某個公司付錢讓你為他們提供維護服務，或者維護人員展現某個公司所需的技術力），但是如今維護人員多了一個選擇，即成為專業的開源維護人員。因此，鼓勵大家為開源維護人員提供金錢支持，這可以吸引更多人進入開源生態系統。

總的來說，我認為，為維護人員提供更多資金支持是一件好事，但這應該成為幫助開源貢獻者獲取報酬的開端，而不是最終方案。