幾個月前我在我的部落格上發表的關於開源商業模式的文章似乎引起了共鳴。我收到了許多正面的迴響，並促使一個名為「How Software is Built」的網站要求採訪。我的採訪在這裡。

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

首先，也是最重要的，我認為你的斷言，即當對特定專案沒有實際投入的人為其提供支援時，對專案或一般的開源碼而言是不健康的，這是一個有趣的觀點……一個我以前從未聽說過的觀點。我認為它具有足夠的有效性，可以讓像我們這樣的公司考慮它，並真正檢視我們對我們支援的開源專案的責任。我認為，這次檢視的結果將是 OpenLogic 為了減輕您提出的潛在疑慮而制定的一項可證明的政策。我相信我不知道那到底是什麼，所以請允許我在這一點上含糊其辭。儘管如此，這與我對你所說的一些問題完美地吻合。

我認為找到這樣一個「可證明的政策」會非常簡單。 OpenLogic 需要理解 Stormy 的文章中的開頭評論說「從事開源軟體開發的開發人員通常都有收入不錯的正職……所以他們免費從事開源軟體開發，白天為大公司編寫程式碼」在很大程度上是錯誤的，了解他們希望從中獲利的開源軟體來自何處，適當地建立合作夥伴關係，並設定一個允許真正支援的價格點。另一種選擇是停止聲稱提供企業支援，並明確表示所提供的是一種隨時待命的開發協助，不保證能夠解決關鍵問題。這讓我回到了我為什麼對 Stormy 的文章感到有足夠強烈的感覺以至於要解構它的原因。

我將聚合模型視為超市式業務。當我在超市購物時，我期望他們會從我購買的所有東西中抽取（小）額費用，以換取與許多供應商打交道，將我想要的所有商品集中到一個地方，並為我提供停車場和購物推車。我期望大部分經濟價值將回到生產產品的公司。

OpenLogic 和他們的幾家競爭對手確實有一個建立超市式業務的機會。只是他們似乎希望開源碼作為一個新的市場，允許超市的概念保留幾乎所有的錢並且不補償供應商。這是一種具有破壞性的模型，從長遠來看無法生存。

有更多可持續的聚合途徑。許多全球系統整合商向客戶提供支援合約，其中包括聚合服務，並且為了提供企業客戶所需的支援品質，將其外包給各種開源公司。換句話說，他們的目標不是保留超市中所有商品的錢，並且他們在價格中包含提供真正的支援。 OpenLogic 應該做同樣的事情。他們不這樣做的原因可能是因為接受聚合商實際上是一個經紀人讓他們處於大型系統整合商和創建開源 IP 的專業公司之間的尷尬境地。儘管如此，那裡仍然存在一個可持續的商機。

Brian 繼續說道

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

我的「支援」可能來自非提交者。因此 OpenLogic 無法保證從戰略上解決問題。可靠的支援需要能夠提交到主樹的能力——以及在某些情況下，為客戶的特定版本維護的分支。

有趣的是，在 Spring 的情況下，Interface 21 將是唯一能夠做到你所提議的事情的實體。（如果我說錯了，請糾正我。）對於 Interface 21 來說，這似乎是一筆不錯的交易。

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

因此，你似乎在爭辯說，OpenLogic 無法從他人辛勤工作和投資所創造的程式碼和社群中賺錢，這在某種程度上是不公平的。我無法從支援 PhP、WebLogic 或 Oracle 中賺錢，這是否不公平？主導 WebLogic Server 維護收入市場對於 BEA 來說是否是不合理地「甜蜜的交易」？

這種圍繞「公平」的錯誤論點忽略了 OpenLogic 是否能夠「從戰略上解決問題」的實際問題。由於我描述的原因，它不能。

如果你開源你的東西，而且它是一個很棒的產品，像你的一樣非常受歡迎，你真的期望市場上沒有其他人會嘗試從事與其相關的業務嗎？當然不會……舉另一個例子，只要看看關於 Spring Framework 的書，不是由在 Interface 21 工作的人寫的，或者無數的開發人員因為學習了你開源的框架而具有很高的市場價值。他們是否也要對專案的健康狀況感到內疚？ Interface 21 被允許獲得如此巨大的好處，因為該產品 A) 很棒，而且還因為該產品 B) 正在大規模地交付到市場，因為你已經開源了它並使其免費。雖然並不完全相同，但這個論點有“沒有其他人應該能夠製造和銷售汽車，因為我發明了它們”的感覺。

其他公司和個人將不可避免地從事圍繞該產品的業務，這很棒。但是，檢視他們提出的任何聲明都是公平的。

讓我們看一下事實：Interface21 的 Spring 團隊一直以來都支持外部人士撰寫的書籍，例如 Craig Walls。我們鼓勵人們撰寫關於 Spring 的書籍。像 Craig 這樣的人有必要的經驗來撰寫這樣的書籍，我們祝他們因此取得巨大的成功。（順便說一句，Craig 有第二版的 Spring in Action 即將推出。購買它，我保證我不會對你生氣。）

至於因為學習了 Spring 而更具市場價值的開發人員，這很棒。我為自己創立了一個專案而感到自豪，該專案幫助為我的開發人員同仁創造了一個市場（並使他們的工作更加愉快）；我為我的公司繼續投入到我們產品中的投資繼續擴大這個市場而感到高興。現在每天都有數千個職位空缺列出 Spring 作為一項必需技能，並且它們正在迅速地向上發展；祝願申請者在回答關於 Spring 的問題時一切順利。

作者和數千名這些開發人員通過他們的傳道來為專案和社群的成功做出貢獻。這是一種重要的貢獻方式。 OpenLogic 沒有；它只是旨在從他人建立、傳道並方便地維護和增強的專案中賺錢。現在那是一筆“甜蜜的交易”。

我的文章涉及提供企業級支援。這是一個不同的問題。 OpenLogic 不僅聲稱它可以以這種方式提供關於 Spring 的知識，或幫助在 Spring 上交付專案；它聲稱它可以為許多專案提供企業支援級別的支援。我詳細闡述了為什麼它不能這樣做的論點。

請注意，我的部落格正在解決關於開源碼企業支援品質的更普遍問題。雖然我現在正在直接解決你關於 Spring 的問題，但這個模型中的缺陷適用於許多專案。

你的段落的第一句話值得另一個回覆

如果你開源你的東西，而且它是一個很棒的產品，像你的一樣非常受歡迎，你真的期望市場上沒有其他人會嘗試從事與其相關的業務嗎？

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

其次，雖然我再次承認我認為你對潛在的專案健康影響提出了很好的觀點，但另一個推動市場聚合支援的事實仍然存在。企業今天為了獲得對他們正在開發和部署到生產中的軟體的支援所必須做的事情是一個艱苦的過程……管理跨越 y 個煙囪式部門的 x 個專案的支援合約的想法對我來說似乎是一個低效的惡夢。從企業的角度來看，聚合這些服務是有意義的，無論你認為它多麼短視。如果一個市場存在商機，你不能責怪有人突然湧入並利用這個機會。

我並沒有爭辯說聚合沒有價值。只是低品質服務的聚合沒有多大價值。一條鏈條的強度僅取決於其最薄弱的環節。

「為 x 個專案，跨 y 個各自為政的部門管理支援合約」這個想法，帶出了另一個問題。整合商需要誇大開源生態系統的複雜性。實際上，少數產品比其他產品更重要。為重要的產品取得真正企業級的支援；然後再擔心次要的產品。客戶不能藉由想像與整合商簽訂「支援」合約，就意味著他們可以自由放任地使用開源軟體，來迴避管理其開源軟體使用的責任。這個問題與商業軟體沒有太大區別，儘管開源軟體可以免費獲得，但在這種情況下會產生危險。

讓我引用我原始文章的結論

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

事實證明，圍繞開源軟體（不包括商業附加元件）最可擴展的收入來自支援。OpenLogic 的模式完全將其與軟體的創建分開。這不是企業開源的未來——除非開源沒有未來。

我堅持我的評論。