關於開源的無稽之談是一個競爭激烈的領域。然而，我剛剛看到一篇文章，它提高了（或降低了？）門檻：一篇 OpenLogic 部落格作者題為你的時間值多少錢？的帖子。

這篇文章不長，這很方便，因為它更容易逐段解構。我關注的是企業級 Java，這方面我可以憑經驗發言。

博主開門見山，用一個簡潔的陳述解釋了她為何不理解企業中的開源

從事開源軟體開發的開發者通常有份薪水不錯的工作。所以他們免費為開源軟體工作，而在白天為高薪寫程式碼。

哇，我以為我們多年前就擺脫了這種“業餘愛好者”的想法。讓我引用一些關於 Linux 的統計資料，來自 2004 年的一篇題為Linux 現在是一個企業巨獸的文章。我的重點如下

駁斥 Linux 是由大量獨自工作的孤立駭客拼湊而成的看法，負責管理 Linux 核心的人士表示，目前大多數 Linux 改進來自公司。“人們對典型 Linux 開發者的刻板印象是，一個男電腦極客在他的地下室利用業餘時間寫程式碼，純粹出於對手藝的熱愛。這樣的人大約在五年前還是重要的力量，”負責維護穩定版 Linux 核心的 Andrew Morton 說。Morton 表示，這些愛好者做出的貢獻“正在減弱”。相反，大多數程式碼是由按公司工時工作的程式設計師生成的。Morton 說，大約有 1000 名開發者定期為 Linux 貢獻更改。在這 1000 名開發者中，約有 100 人由他們的僱主支付薪水來從事 Linux 工作。而這 100 人貢獻了作業系統最近 38000 次更改中的約 37000 次。

這意味著 97% 的提交來自那些被支付報酬來從事 Linux 工作的人。這種轉變與 Linux 在企業中日益增長的滲透率相對應。看看企業級 Java 中最成功的複雜專案，如 Spring、Hibernate 和 JBoss，也呈現出類似的景象。所有這些專案絕大部分是由為這些專案背後的公司工作的開發者編寫的。志願者活動只佔很小的一部分。因此，這些產品展現出了快速的進展。

這篇文章現在轉向了經濟學——或者更確切地說，試圖論證開源軟體的開發與經濟學是脫節的

所以這意味著如果我在工作中每小時賺 50 美元，我會寧願免費幫助當地學校設定網路，而不是以每小時 10 美元的價格接受這項工作？聽起來很奇怪，但我認為這是事實。作為免費的志願者，我獲得更多的控制權（我可以隨時離開），更多的聲望（我在幫忙！），更多的認可（我不是一個低微的下屬，我是一個很酷的志願者。）

這正是為什麼部落格中提出的模型沒有意義的原因。如果企業開源依賴於志願者活動，開發者就很容易隨時離開。假設我是一家排名前 10 的銀行。想象一下，我的關鍵任務軟體的開發和維護與愛好者的熱情掛鉤，這會讓我有什麼感覺？至於聲望和認可：當然，這很重要。大多數做出傑出成就的人在一定程度上受到認可的激勵。員工除了薪水外也需要認可。但如果將這作為主要動機，從長遠來看將是一場災難。當某人做的事情令人失望並被重寫時會發生什麼？這個人會生氣地離開嗎？當工作不“酷”，比如寫文件或在一種深奧的環境中重現一個難以理解的 bug 時會發生什麼？當受個人自我驅動的開發者發生衝突時會發生什麼——如果他們是由自我大小自行選擇的，這種情況很可能發生？有許多專案因這種衝突而分崩離析的例子。如果一名開發者不得不熬夜幫助診斷並解決與有支援合同的客戶的一級生產問題時會發生什麼？如果沒有對全天候支援能力的投入，24x7 服務水平協議（SLA）如何運作？

開發高質量的軟體需要一個由敬業的個人組成的有效團隊。這些人需要留下來，這需要一個可行的經濟模式。開發者需要支付房貸、學費、燃油以及現代生活的所有其他費用，試圖迴避這個問題並將其留給提供“日間工作”的僱主是幼稚的（或更糟）。很少有人能夠對支援一個專案做出無限期的個人時間承諾；他們會希望他們的工作能為他們帶來經濟利益。（為什麼不呢：它也為使用者提供了經濟利益？）這件事如此重要的原因在於，開源在企業中的作用變得越來越重要，不能僅僅依賴純粹的志願者活動。正如 Entiva Group 分析師 Alex Fletcher 所寫，“今年早些時候，Gartner DataQuest 報告稱，2006 年至 2011 年間開源軟體的複合年增長率（CAGR）為 43%，將是專有軟體（8%）的五倍以上。該公司還預計 2007 年開源軟體銷售額將達到 42.3 億美元，到 2010 年將增長三倍，達到 131.0 億美元。”除非開源長期以來有可持續的模式，否則潛在的不可靠軟體會非常多。

儘管 Gartner 可能分析數字，但博主聲稱從事開源工作本質上是經濟活動之外的事情

作為廉價的熟練勞動力，我所做的就是降低了我每小時的價值。我現在說我只值每小時 10 美元——我為了微不足道的報酬工作，而不是幫助需要幫助的人。

所以理想情況下，開源開發者不應該獲得報酬，因為那樣會降低他們日間工作的時薪。我們稍後會談到 OpenLogic 的支付模式，但這似乎與此觀點一致。雖然開發者不應該考慮金錢，但 OpenLogic 自然不在經濟活動的範疇之外。

我不是說這完全有道理或者這是一件好事，但我認為這是一個現實。你覺得呢？

我認為幸運的是這並非現實，因為它根本毫無意義，是一件非常糟糕的事情，並可能摧毀軟體產業。

部落格總結道

這是我們努力確保 OpenLogic 專家社群得到公平補償的原因之一。

所以我點選了他們“專家社群”的常見問題連結，想了解這在實踐中是如何運作的。有趣的答案是

成為專家社群成員是否有報酬？ 是的，OpenLogic 獎勵計劃會根據成功解決事件，以積分（可兌換現金或獎勵）的形式支付專家社群成員報酬。OpenLogic 向企業收取支援費用。OpenLogic 內部技術支援團隊解決基本問題。OpenLogic 轉而與社群成員簽約解決更復雜的問題。

對了，它是這樣運作的。OpenLogic 希望企業客戶預先支付支援合同費用。OpenLogic 似乎不相信支付開發者薪水，所以他們預計自己無法內部處理複雜的支援問題。在這種情況下，他們就會尋求“社群”的幫助，只有在事件得到解決後才支付報酬。這就像這樣運作

作為專家社群成員我需要做什麼？ 作為成員，您將可以訪問我們需要幫助解決的客戶事件列表。您可以透過在專家社群成員門戶中“獲取”這些事件來選擇要處理的事件。一旦您註冊了一個事件，我們會要求您儘快處理直到解決。大多數事件將在 4 小時內解決...透過 OpenLogic 獎勵計劃，您解決的每個事件將獲得 100 分。如果一個事件花費了異常長的時間來解決，您可以申請更多積分。積分可以兌換現金（100 積分 = 100 美元）或商品（例如 Xbox 360）。您也可以選擇將積分作為現金捐贈給您最喜愛的開源專案或我們名單上的慈善機構之一。

所以開發者只有在發生事件時才能獲得報酬。儘管註冊了，除非 OpenLogic 自己解決問題遇到困難，否則他們什麼也得不到。然後他們會以每小時 25 美元的名義費率獲得報酬。開發者被激勵儘快修復問題，因為他們不會因為最佳化或重構而獲得報酬。（通常一個事件可能需要大量的返工才能妥善修復。這種模式下不太可能發生這種情況。）開發者自然會爭奪事件，因為報酬是針對個人而不是團隊的，這可能會扭曲優先順序。偉大的軟體需要團隊合作來構建和維護，而這種模式對此沒有任何獎勵。也沒有真正的支援團隊概念。在一個真正的支援團隊中，管理者不僅考慮地理分佈和輪班模式以確保始終有覆蓋，還要確保技能的平衡。例如，如果某個特定領域只有 2 名開發者具備專業知識，很可能會有一個計劃來培養其他人，同時在這段時間內他們不太可能被批准同時休假。你不能對一個志願者說：“抱歉，在我們找到替補之前你不能去度假——但當然，除非我們接到電話，否則我們不會支付你報酬。”

相對於開發者的薪水，每小時 25 美元的臨時工資不算多。然而，這可能也沒那麼糟，因為如果你是一個正在嶄露頭角的開源開發者，你可以加入專家社群。你不需要對專案做出很大的貢獻。我的重點是

加入專家社群需要什麼資格？ 您需要填寫一份簡短的會員申請。我們正在尋找我們支援的 200 多個開源專案的提交者或貢獻者。如果您不是專案提交者，我們會要求您提供一名專案提交者的推薦信或擔保。OpenLogic 的專家社群計劃是提升您對專案的經驗和貢獻的好途徑。

如果我是客戶，這不會讓我感到信心十足。我的“支援”可能來自非提交者。因此 OpenLogic 無法保證以戰略方式解決問題。可靠的支援涉及能夠向主分支提交——有時也包括為特定客戶版本維護的分支。它還涉及團隊，而不是可能非常初級的個人。我不太可能接觸到實際編寫我的事件可能涉及的程式碼的人。

那麼這裡缺少了什麼？讓我們拋開明顯的公平性問題：OpenLogic 樂於從客戶那裡預收固定費用，卻不給做大部分工作的人帶來收入保障。（他們把這留給了日間工作的僱主。）

這個模式有很多缺陷，但有一個巨大的問題足以讓一輛 SUV 穿過。開發者只因解決事件而獲得報酬。沒有人因編寫軟體而獲得報酬。沒有人因創新而獲得報酬。沒有人因文件而獲得報酬。沒有人因重構和改進設計而獲得報酬。因此 OpenLogic 對維持他們希望從中獲利的專案沒有任何貢獻。從 OpenLogic 的角度來看，這沒問題：如果一個專案崩潰了，他們可以轉移到另一個專案，因為他們為所有專案提供類似的“支援”。但這對於企業客戶來說可能幾乎是災難性的，他們可能需要執行今天引入的軟體多年。

常見問題中的關鍵答案是

我是否能透過這個全職工作？ 目前，我們不建議任何人辭掉工作成為專家社群成員。

正是如此。我們正在談論的是一個快速發展的、關鍵任務的軟體產業的一部分。而這種模式並沒有讓任何人能夠透過開發優秀的軟體來謀生。如果開源的影響是人們無法透過開發優秀的軟體來謀生，最終每個人都會受苦。你不能將軟體的維護過程與軟體的建立過程割裂開來。

也許在某些領域這種模式是說得通的。有些產品（主要在企業領域之外，或者在更簡單的技術中）大部分工作由志願者完成。但在企業級 Java 中，這完全沒有意義。問題不在於聚合的概念——如果公司擁有投資和維持專案的資源，或者與擁有這些資源的公司合作，聚合是有意義的——而是認為一個產業可以無視經濟規律而維持，並且用遊戲機而不是收入保障來激勵人們可以為企業級支援提供基礎。

事實證明，開源軟體（不考慮商業附加元件）最可擴充套件的收入來源在於支援。OpenLogic 的模式將這一點與軟體最初的建立完全割裂開來。這絕不是企業開源的未來——除非開源根本就沒有未來。