關於開源的廢話生產是一個競爭激烈的領域。然而，我剛剛看到了一些東西，它提高了（降低了？）門檻：一篇由 OpenLogic 部落格作者撰寫的帖子，題為你的時間值多少錢？

它不長，這很方便，因為它更容易逐段解構。我專注於企業 Java，對此我可以根據經驗發言。

博主立即切入正題，用簡潔的宣告表達了她不理解企業級開源的原因

從事開源軟體開發的開發人員通常都有不錯的日常工作收入。因此，他們免費從事開源軟體開發，並在白天編寫程式碼以獲取高額報酬。

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

為了消除 Linux 是由大量孤立工作的獨立駭客拼湊而成的看法，負責管理 Linux 核心的個人表示，大多數 Linux 改進現在都來自公司。“人們對（典型 Linux 開發人員的）刻板印象是一個男程式設計師宅在地下室，利用業餘時間編寫程式碼，純粹出於對技藝的熱愛。這類人直到大約五年前都是一股重要的力量，”Andrew Morton 說，他的職責是維護 Linux 核心的穩定版本。Morton 說，來自這類愛好者的貢獻“正在減弱”。相反，大多數程式碼是由按公司考勤鍾工作的程式設計師生成的。Morton 說，大約有 1000 名開發人員定期為 Linux 貢獻更改。在這 1000 名開發人員中，大約有 100 人由他們的僱主付費為 Linux 工作。而這 100 人貢獻了作業系統最後 38000 次更改中的大約 37000 次。

這意味著 97% 的提交來自受薪為 Linux 工作的人。這種轉變與 Linux 在企業中日益普及相對應。檢視企業 Java 中最成功的複雜專案，如 Spring、Hibernate 和 JBoss，也顯示出類似的景象。所有這些專案絕大多數都是由為專案背後的公司工作的開發人員編寫的。志願工作所佔比例很小。因此，這些產品表現出快速發展。

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

那麼，這意味著如果我在工作時每小時賺 50 美元，我寧願免費幫助當地學校搭建網路，也不願以每小時 10 美元的價格去承擔搭建網路的工作嗎？雖然聽起來很奇怪，但我認為這是真的。作為一個免費提供服務的志願者，我擁有更多的控制權（我可以隨時離開），更多的聲望（我在做貢獻！），以及更多的認可（我不是一個卑微的打工者，我是一個很酷的志願者）。

這恰恰解釋了部落格中提出的模型為何不合理。如果企業開源依賴於志願服務，那麼開發者就會隨時可能離開。讓我們假設我是一家排名前十的銀行。想象一下，我的關鍵任務軟體的開發和維護竟然依賴於業餘愛好者的熱情，這會讓我作何感想？至於聲望和認可：當然，這很重要。大多數做出傑出事情的人在一定程度上都受到認可的驅動。員工也需要認可，而不僅僅是薪水。但如果將此作為主要動機，那將是長期的災難。當某人的工作令人失望需要重寫時會怎樣？那個人會賭氣離開嗎？當工作不“酷”時又會怎樣，比如寫文件或在晦澀的環境中重現一個難以捉摸的 bug？當由個人自我驅動的開發者發生衝突時又會怎樣——如果他們是根據自我大小自我挑選的，這種情況很可能發生。有許多專案因這種衝突而分崩離析的例子。如果一個開發者必須熬夜幫助診斷和解決簽訂了支援合同的客戶遇到的 1 級生產問題，又會怎樣？沒有對“全天候支援”能力的投入，24x7 的 SLA 如何運作？

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

雖然 Gartner 可能會進行數字分析，但博主聲稱從事開源工作本質上就是經濟活動之外的範疇。

作為廉價的熟練勞動力，我所做的就是降低我的時薪價值。我現在說我的價值只有 10 美元/小時——我在廉價工作，而不是幫助那些需要幫助的人。

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

我不是說這有道理，也不是說這是好事，但我認為這是現實。你怎麼看？

我認為這並非現實是幸運的，因為它一點道理都沒有，是一件非常糟糕的事情，並且有可能摧毀軟體行業。

部落格總結說

這也是我們努力確保 OpenLogic Expert Community 公平補償的原因之一。

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

我能從加入專家社群中獲得報酬嗎？ 是的，OpenLogic Rewards 專案會根據成功解決的事件向專家社群成員支付積分（可兌換現金或獎勵）。OpenLogic 向企業收費以提供支援。OpenLogic 的內部技術支援團隊會解決基本問題。OpenLogic 反過來又會與社群成員簽訂合同，以解決更復雜的問題。

對，它是這樣運作的。OpenLogic 希望企業客戶預先支付支援合同的費用。OpenLogic 似乎不相信支付開發者薪水，所以他們預計自己無法處理複雜支援問題。在這種情況下，他們會聯絡“社群”，並且只在事件解決後才支付。它的運作方式是這樣的：

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

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

與開發人員的薪水相比，25 美元的臨時費率並不算高。然而，這也許不算太差，因為如果你是一個想出頭的開源開發者，加入專家社群是有可能的。不像你需要為專案做出重大貢獻。我的重點是

加入專家社群需要具備哪些資質？ 您需要填寫一份簡短的會員申請表。我們正在尋找我們支援的 200 多個開源專案的提交者或貢獻者。如果您不是專案提交者，我們將要求您提供一位專案提交者的推薦信來贊助或擔保您。OpenLogic 的專家社群計劃是提升您經驗和專案貢獻的絕佳途徑。

如果我是一名客戶，這不會讓我感到有信心。我的“支援”可能來自非提交者。所以 OpenLogic 無法保證戰略性地解決問題。可靠的支援涉及提交到主幹的能力——以及在某些情況下，為特定客戶版本維護的分支。它還涉及團隊，而不是可能非常初級的個人。我不太可能接觸到實際編寫與我事件相關的程式碼的人。

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

這個模式有很多缺陷，但有一個巨大的問題，你可以輕鬆地繞過它。開發者只有在解決事件時才能獲得報酬。沒有人得到報酬來編寫軟體。沒有人得到報酬來創新。沒有人得到報酬來記錄。沒有人得到報酬來重構和改進設計。所以 OpenLogic 對他們希望從中獲利的專案的貢獻是零。從 OpenLogic 的角度來看，這沒關係：如果一個專案崩潰了，他們可以轉向另一個專案，因為他們為所有專案提供類似的“支援”。但從企業客戶的角度來看，這可能幾乎是災難性的，因為他們可能需要執行他們今天引入的軟體多年。

常見問題解答中的關鍵答案是：

我能賺到足夠全職工作的錢嗎？ 目前，我們不建議任何人辭職成為專家社群成員。

沒錯。我們談論的是軟體行業中一個快速增長且至關重要的領域。而這種模式並沒有給任何人帶來從開發出色軟體中謀生的能力。如果開源的後果是人們無法從開發出色軟體中謀生，那麼每個人都將遭受損失。你無法將維護軟體的過程與建立軟體的過程分離開來。

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

事實證明，開源軟體（不考慮商業附加元件）最具可擴充套件性的收入來自支援。OpenLogic 的模式將這一點完全與最初的軟體建立過程分離開來。這並非企業開源的未來——除非開源沒有未來。