關於開放原始碼的胡言亂語的產出是一個競爭激烈的領域。 然而，我剛剛看到一些提高了（降低了？）標準的東西：OpenLogic 部落客的一篇文章，題為 你的時間值多少錢？

這不是一篇很長的文章，這很方便，因為它更容易逐段解構。 我專注於企業 Java，我可以根據經驗談談。

這位部落客以簡潔的陳述，直接點出了她不了解企業開放原始碼的原因

從事開放原始碼軟體的開發人員通常都有薪水很高的正職工作。 因此，他們免費從事開放原始碼軟體工作，並在白天為大公司編寫程式碼以賺取大筆金錢。

哇，我以為我們幾年前就超越了這個“業餘愛好者”的想法。 讓我引用一些關於 Linux 的統計數據，來自 2004 年的一篇文章，名為Linux 現在是一隻企業野獸。 強調是我的

為了消除 Linux 是由一大群孤獨的駭客隔離工作的刻板印象，負責管理 Linux 核心的人士表示，現在大多數 Linux 的改進來自企業。「人們對（典型 Linux 開發人員）的刻板印象是一位男性電腦怪傑，在地下室工作，利用閒暇時間編寫程式碼，純粹是出於對這門技藝的熱愛。 這樣的人在大約五年前還是一支重要的力量。」Andrew Morton 說，他的職責是以穩定的形式維護 Linux 核心。 Morton 表示，來自這些愛好者的貢獻「正在減弱」。 相反，大多數程式碼是由打企業時間卡的程式設計師產生的。 大約有 1,000 名開發人員定期貢獻 Linux 的變更，Morton 說。 在這 1,000 名開發人員中，大約有 100 名是受僱主支付薪水來從事 Linux 工作的。 而且這 100 人貢獻了最近 38,000 項變更中的大約 37,000 項對作業系統所做的變更。

也就是說，有 97% 的提交來自受僱從事 Linux 工作的人。 而這種轉變與 Linux 在企業中的日益普及有關。 看看企業 Java 中最成功的複雜專案，例如 Spring、Hibernate 和 JBoss，可以看到類似的情況。 所有這些專案絕大多數都是由為其背後公司工作的開發人員編寫的。 志願服務幾乎沒有發揮作用。 因此，這些產品取得了快速進展。

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

那麼，這是否意味著如果我在工作中每小時賺 50 美元，我寧願免費幫助當地學校建立網路，也不願接受一份以每小時 10 美元的價格建立網路的工作？ 聽起來很奇怪，但我認為這是真的。 作為一名免費的志願者，我獲得了更多的控制權（我可以隨時離開）、更多的聲望（我在幫助！），以及更多的認可（我不是一個卑微的僕人，我是一個很酷的志願者。）

這就解釋了為什麼部落格中提出的模型沒有意義。 如果企業開放原始碼依賴於志願服務，那麼開發人員將很容易隨時離開。 假設我是一家排名前 10 名的銀行。 想像一下，我的關鍵任務軟體的開發和維護與業餘愛好者的熱情聯繫在一起，我會有什麼感覺？ 至於聲望和認可：當然，這很重要。 大多數做傑出事情的人都會在一定程度上受到認可的激勵。 員工也需要認可和薪水。 但如果你把這作為主要動機，從長遠來看，這就是災難的根源。 當某人所做的事情令人失望並被重寫時會發生什麼？ 這個人會生氣地走開嗎？ 當工作不“酷”時會發生什麼，比如編寫文件或在深奧的環境中重現一個晦澀的錯誤？ 當以個人自我為動機的開發人員發生衝突時會發生什麼——如果他們是通過自我大小來自我選擇的，這很可能發生？ 有很多專案因這種衝突而崩潰的例子。 如果開發人員必須整夜熬夜以幫助診斷和解決客戶的 1 級生產問題（客戶有支援合約）會發生什麼？ 如果沒有對追蹤太陽的支援能力進行投資，24x7 SLA 如何運作？

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

雖然 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 的模式將完全與軟體的創建分開。 這不是企業開放原始碼的未來——除非開放原始碼沒有未來。