我幾個月前關於開源商業模式的部落格似乎引起了共鳴。我收到了許多積極的回應，並引來了來自一個名為“How Software is Built”的網站的採訪請求。我的採訪內容在此。

最終，OpenLogic 的某人發表了一篇有趣的回應。Bryan Noll 在我的部落格回覆中留下了一些值得正式回應的評論。

首先，我認為您關於那些對某個特定專案沒有真正投入的人為其提供支援，對該專案或整個開源生態來說是不健康的說法很有趣……是我以前從未聽過的觀點。我認為這個觀點有足夠的說服力，足以讓我們這樣的公司考慮並認真審視我們對所支援的開源專案的責任。在我看來，這種審視的結果將是 OpenLogic 為了緩解您提出的潛在擔憂而制定的一項可證明的政策。我確定我不知道具體會是怎樣的政策，所以請允許我在此處保持模糊。不過，這恰好與您所說的一些我存在異議的問題不謀而合。

我認為找到這樣一項“可證明的政策”會非常簡單。OpenLogic 需要明白，Stormy 的文章中的開篇評論“從事開源軟體開發的開發者通常有報酬不錯的工作……所以他們免費從事開源軟體工作，白天為高薪編寫程式碼”在很大程度上是錯誤的，需要理解他們希望從中獲利的開源軟體來自何處，建立適當的合作伙伴關係，並設定一個能夠提供真正支援的價格點。另一種選擇是停止聲稱提供企業級支援，明確說明所提供的只是某種隨叫隨到的開發協助，不保證能夠解決關鍵問題。這讓我回到了為何我覺得 Stormy 的文章如此重要，需要進行剖析的原因。

我認為這種聚合模式就像超市生意。當我在超市購物時，我期望他們會從我購買的所有商品中收取（很小的一部分）提成，作為回報，他們與許多供應商打交道，將我想要的所有商品都集中到一處，並提供停車場和購物車。我期望大部分經濟價值會迴流到生產產品的公司。

OpenLogic 和他們的幾個競爭對手有機會開展超市式的業務。只是他們似乎希望，作為一個新市場的開源，允許一種超市模式，即幾乎保留所有收入，而不向供應商支付報酬。這是一種破壞性的模式，長期來看無法生存。

有更可持續的聚合途徑。許多全球性的系統整合商（SI）向客戶提供包含聚合服務的支援合同，並且為了提供企業客戶所需的支援質量，他們會將部分工作分包給各種開源公司。換句話說，他們的目標不是保留超市裡商品的所有收入，而是將提供真正的支援計入價格。OpenLogic 也應該這樣做。他們不這樣做，也許是因為承認聚合商實際上是經紀人，會讓他們在大系統整合商和建立開源智慧財產權的專業公司之間處於尷尬境地。儘管如此，那裡存在一個可持續的商業機會。

Bryan 繼續說道

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

我的“支援”可能來自非提交者。因此 OpenLogic 無法保證策略性地解決問題。可靠的支援包括提交到主分支的能力——以及在某些情況下，維護針對特定客戶版本的獨立分支的能力。

值得注意的是，對於 Spring 而言，Interface 21 將是唯一能夠做到您所提出事情的實體。（如果我錯了，請糾正我。）這對 Interface 21 來說似乎是一筆不錯的交易。

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

所以您似乎在爭辯說，OpenLogic 不能從他人的辛勤工作和投入創造的程式碼和社群中賺錢，這 somehow 是不公平的。我無法透過支援，比如 PhP、WebLogic 或 Oracle 來賺錢，這公平嗎？BEA 主導 WebLogic Server 維護收入市場，這對於 BEA 來說是否是一筆不合理的“甜蜜交易”？

這種圍繞“公平”的站不住腳的論點忽略了 OpenLogic 是否能夠“策略性地解決問題”這個實際問題。出於我所描述的原因，OpenLogic 無法做到這一點。

如果你開源了你的東西，而且它是一個像你的產品一樣大受歡迎的優秀產品，你真的期望市場上沒有人會試圖圍繞它開展業務嗎？當然不是……再舉個例子，看看那些不是由 Interface 21 員工撰寫的關於 Spring Framework 的書籍，或者市場上無數的開發者，他們因為學會了你開源的框架而變得非常有市場價值。他們也應該為專案的健康狀況感到內疚嗎？Interface 21 之所以能夠獲得如此巨大的利益，是因為該產品 A) 很棒，而且因為該產品 B) 被大規模地推向市場，因為你已經將它開源並使其免費。雖然不完全相同，但這個論點帶有“因為我發明了汽車，所以其他人都不應該製造和銷售汽車”的感覺。

其他公司和個人不可避免地會圍繞產品開展業務，這很好。然而，審查他們提出的任何主張也是公平的。

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

至於那些因為學習了 Spring 而更具市場價值的開發者，這太棒了。我為建立了一個幫助為我的同行開發者創造市場的專案（也讓他們的工作更愉快）感到自豪；我很高興我的公司持續投入到我們的產品中，繼續壯大這個市場。現在每天都有成千上萬的招聘資訊將 Spring 列為必需技能，並且它們正在迅速呈上升趨勢；祝願所有申請這些職位的應聘者，在他們回答 Spring 相關問題時一切順利。

作者和成千上萬的這些開發者透過他們的推廣佈道為專案的成功和社群做出了貢獻。這是一種重要的貢獻方式。OpenLogic 則不然；它僅僅旨在從他人已經構建、推廣並維護和增強的專案中賺錢。現在，那才是一筆“輕鬆的交易”。

我的文章關注的是企業級支援的提供。這是另一回事。OpenLogic 不僅僅是聲稱他們可以以這種方式提供關於 Spring 的知識，或者幫助交付基於 Spring 的專案；它聲稱可以為許多專案提供企業所需的支援水平。我詳細闡述了為什麼它做不到這一點。

請注意，我的部落格關注的是一個更普遍的問題，即開源的企業級支援質量。雖然我現在直接回應您關於 Spring 的問題，但這種模式的缺陷適用於許多專案。

你段落的第一句話值得再回復一次

如果你開源了你的東西，而且它是一個像你的產品一樣大受歡迎的優秀產品，你真的期望市場上沒有人會試圖圍繞它開展業務嗎？

現在我想知道它為什麼是一個優秀產品？為什麼會大受歡迎？這是偶然發生的，還是大量持續投入的結果？

其次，雖然我再次承認您關於潛在的專案健康影響的觀點很有道理，但推動市場聚合支援的另一個事實依然存在。如今企業為了獲得他們正在開發和部署到生產環境中的軟體支援，需要經歷一個艱辛的過程……在我看來，在 y 個各自為政的部門管理 x 個專案的支援合同就像一場低效的噩夢。從企業的角度來看，聚合這些服務是有意義的，無論您認為它多麼目光短淺。如果市場上存在商機，您就不能責怪別人抓住並利用這個機會。

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

“在 y 個各自為政的部門管理 x 個專案的支援合同”這個想法引出了另一個問題。聚合商需要誇大開源生態系統的複雜性。實際上，少數產品比其他產品更重要。為“大象”產品（指重要的、廣泛使用的產品）獲取真正的企業級支援；然後再去擔心那些“貓貓狗狗”（指不那麼重要或小眾的產品）。客戶不能指望透過與聚合商簽訂“支援”合同來逃避管理其開源使用的責任，以為這樣就可以隨意使用。這個問題與商業軟體沒有太大區別，儘管開源軟體免費獲取的事實在此情況下帶來了一定的風險。

讓我引用我原文的結論

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

事實證明，圍繞開源軟體（不包括商業附加元件）最具可擴充套件性的收入來自支援服務。OpenLogic 的模式完全將支援服務與軟體的建立本身割裂開來。這不是企業級開源的未來——除非開源沒有未來。

我堅持我的觀點。