幾個月前，我關於開源商業模式的部落格似乎引起了共鳴。我收到了許多積極的回應，並因此收到了一個名為“軟體是如何構建的”網站的採訪請求。我的採訪在這裡。

終於，OpenLogic 的一個人發表了一個有趣的回覆。Bryan Noll 在我部落格的回覆中留下了一些評論，值得認真回應。

首先，我認為您認為，當對某個特定專案沒有真正投入的人提供支援時，這對專案或開源整體而言是不健康的，這是一個有趣的觀點……我以前從未聽過。我認為這個觀點有足夠的有效性，足以讓像我們這樣的公司認真考慮並真正審視我們對所支援的開源專案的責任。在我看來，這項審查的結果將是一項可證明的政策，OpenLogic 將以此來減輕您提出的潛在擔憂。我當然不知道具體會是什麼，所以請允許我此刻保持模糊。不過，這恰好又引出了我與您觀點中的一些問題。

我認為要找到這樣一項“可證明的政策”應該很簡單。OpenLogic 需要理解，Stormy 的帖子中的開場白“開發人員從事開源軟體工作通常有報酬豐厚的工作……所以他們免費從事開源軟體工作，白天為鉅額報酬編寫程式碼”在很大程度上是錯誤的。它需要理解他們希望從中獲利的開源軟體來自何處，進行適當的合作，並設定一個允許真正支援的價格。另一種選擇是停止聲稱提供企業支援，並明確表示所提供的是一種隨叫隨到的開發協助，但不能保證能夠解決關鍵問題。這就回到了我為什麼對 Stormy 的帖子有如此強烈的感受並對其進行解構。

我將聚合模型視為一種超市式業務。我在超市購物時，期望他們從我購買的所有商品中抽取（少量）利潤，以換取他們處理許多供應商，將我想要的所有商品集中到一處，並提供停車場和購物車。我期望大部分經濟價值能夠迴流到生產產品的公司。

OpenLogic 和他們的一些競爭對手擁有一個有效的超市式業務機會。只是他們似乎希望，開源作為一個新市場，允許存在一種超市的概念，這種超市幾乎獨佔所有利潤，而不向供應商支付報酬。這是一個破壞性的模式，無法長期生存。

聚合還有更可持續的途徑。許多全球性的 SI 向客戶提供包含聚合服務的支援合同，為了提供企業客戶所需的質量支援，他們會將合同分包給各種開源公司。換句話說，他們不打算將超市商品的所有利潤都裝進自己的腰包，而是將*真正*的支援納入定價。OpenLogic 也應該這樣做。或許他們不這樣做的原因在於，承認聚合者實際上是中間商，這讓他們在大型 SI 和建立開源 IP 的專業公司之間處於一個尷尬的境地。儘管如此，那裡存在一個可持續的商業機會。

Brian 繼續說

你不能魚與熊掌兼得。你說

我的“支援”可能來自非貢獻者。所以 OpenLogic 無法保證戰略性地解決問題。可靠的支援涉及到能夠提交到主幹——並且，在某些情況下，還要為客戶的特定版本維護分支。

有趣的是，在 Spring 的案例中，Interface 21 將是能夠實現你所提出的唯一實體。（如果我在這裡說錯了，請糾正我。）這對 Interface 21 來說似乎是一筆非常划算的交易。

是的，沒錯。這可能讓你覺得奇怪，但個人和公司希望從數百萬美元的投資、激情、汗水和淚水中獲得回報，這是很正常的。Interface21 維持並開發 Spring，而且我們做得很好。我認為，期望我們能夠利用這項投資在支援市場中獲得優勢，這是完全合理的。我們的財富 500 強客戶也同意這一點。

所以，你似乎在爭辯說，OpenLogic 不能從他人辛勤工作和投資創造的程式碼和社群中獲利，這是不公平的。我不能透過支援 PHP、WebLogic 或 Oracle 來賺錢，這公平嗎？BEA 在 WebLogic Server 維護收入市場佔據主導地位，這難道不是一個“不合理地有利可圖的交易”嗎？

關於“公平”的這個有缺陷的論點忽略了 OpenLogic 是否能夠“戰略性地解決問題”的實際問題。而它不能，原因我已闡述。

如果你開源你的程式碼，並且它是一個偉大的產品，像你的一樣大受歡迎，你真的期望市場上沒有人會試圖圍繞它開展業務嗎？肯定不會……再舉一個例子，想想那些關於 Spring Framework 的書籍，它們不是由 Interface 21 的人寫的，或者那些因為學習了你開源的框架而具備高市場價值的開發者。他們應該對專案的健康狀況感到內疚嗎？Interface 21 能夠獲得如此巨大的收益，是因為產品 A) 很棒，而且也是因為產品 B) 透過開源並免費提供給市場，得以大規模交付。雖然不完全相同，但這個論點有“我發明了汽車，所以別人就不應該能夠製造和銷售汽車”的感覺。

其他公司和個人不可避免地會圍繞產品開展業務，這很好。然而，檢查他們所做的任何宣告都是公平的。

讓我們看看事實：Interface21 的 Spring 團隊一直支援外部人士編寫的書籍，比如 Craig Walls。我們鼓勵人們寫關於 Spring 的書。像 Craig 這樣的人具備編寫這類書籍的經驗，我們祝願他們取得巨大成功。（順便說一句，Craig 的《Spring in Action》有第二版即將出版。買它，我保證你不會因此生氣。）

至於那些因為學習了 Spring 而具備更高市場價值的開發者，這很好。我為自己創立了一個專案，幫助我的開發者同仁創造了市場（也讓他們工作更愉快）感到自豪；我很高興我的公司對我們產品的持續投入能夠不斷壯大這個市場。現在每天都有*數千份*招聘資訊明確要求 Spring 技能，並且它們正在迅速呈上升趨勢；祝願申請這些職位的求職者在回答 Spring 相關問題時好運。

作者和這數千名開發者透過他們的宣傳為專案的成功和社群做出了貢獻。這是做出貢獻的重要方式。OpenLogic 則沒有；它僅僅是為了從他人已經構建、宣傳並方便地維護和增強的專案中獲利。這才是真正的“血汗錢”。

我的帖子 concerned 了一般性的企業級支援問題。這是一個不同的問題。OpenLogic 不僅僅聲稱它能夠以這種方式提供 Spring 方面的知識，或幫助交付 Spring 專案；它聲稱它能夠為許多專案的企業支援提供同等的支援水平。我已經詳細論證了為什麼它不能。

請注意，我的部落格討論的是企業開源軟體支援質量的更普遍問題。雖然我現在直接處理您關於 Spring 的問題，但這個模型的缺陷適用於許多專案。

您段落的第一句話值得再次回應

如果你開源你的程式碼，並且它是一個偉大的產品，像你的一樣大受歡迎，你真的期望市場上沒有人會試圖圍繞它開展業務嗎？

現在我想知道，它為什麼是一個偉大的產品？為什麼它如此受歡迎？是偶然發生的，還是大量持續投資的結果？

其次，雖然我再次承認我認為你關於潛在專案健康影響的觀點很有道理，但驅動市場聚合支援的另一個事實仍然存在。如今，企業為了獲得他們正在開發和部署到生產環境的軟體的支援，必須經歷一個極其繁瑣的過程……在我看來，管理跨多個孤立部門的 X 個專案的支援合同，就像一場低效的噩夢。從企業的角度來看，聚合這些服務是有意義的，無論你如何聲稱它目光短淺。如果市場上存在商業機會，你不能責怪某人乘虛而入並利用這個機會。

我並不是說聚合沒有價值。只是說低質量服務的聚合沒有什麼價值。鏈條的強度取決於它最薄弱的環節。

“管理跨 X 個專案的 Y 個孤立部門的支援合同”的想法又引出了另一個問題。聚合商需要誇大開源生態系統的複雜性。實際上，少數產品比其他產品更重要。為“大象”獲取真正的企業級支援；然後擔心“狗和貓”。客戶不能透過想象與聚合商的“支援”合同意味著他們可以為所欲為來逃避管理開源使用的責任。這個問題與商業軟體的情況大不相同，儘管開源軟體是免費獲取的，這在當前情況下造成了危險。

讓我引用我原帖的結論

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

事實證明，開源軟體（不包括商業附加產品）中最具可擴充套件性的收入是支援。OpenLogic 的模式將這種支援完全與軟體的建立本身分開了。這並非企業開源的未來——除非開源沒有未來。

我堅持我的評論。