在標題恰當的《關於 Interface21 的胡言亂語》一文中，一位 SourceLabs 員工不同意我的觀點，即提交許可權對於提供可信的開源支援是必需的。

在我回復之前：我想再次完全澄清我在上一篇部落格中已經說過但似乎被某些人誤解的一點：Interface21 無意阻止他人從 Spring 盈利。我們的記錄證明了這一點。我們歡迎其他人撰寫關於 Spring 的文章並提供 Spring 服務。或者像 Matt Raible 的 AppFuse 那樣，將產品基於 Spring。我們祝他們成功。Spring 之所以能取得今天的成就，部分原因在於其豐富的生態系統。作為技術人員和一家公司，我們一直並將永遠培育這種生態。

我的觀點是針對一家特定公司的一位特定個人的評論，該個人聲稱開源是由無償的業餘愛好者編寫的，並且從經濟上獎勵開源 IP 的開發是無關緊要的。

到部落格文章

Rod 聲稱可靠的支援需要對原始碼的提交者許可權。這對於世界上所有其他支援公司僱傭的非工程師來說一定是個驚喜。總得有人負責銷售、經營業務、修復伺服器、更新網站、尋找新客戶等等。提交者許可權並不能幫你做這些，誰會告訴我這些對於一家成功的支援公司來說不是必需的？

這當然是胡言亂語。讓我來打個比方

Rod 聲稱可靠的汽車維修需要訓練有素的技工。這對於世界上所有其他修車廠僱傭的非技工來說一定是個驚喜。總得有人負責銷售、經營業務、修理廠房、更新網站、尋找新客戶等等。技工並不能幫你做這些，誰會告訴我這些對於一家成功的修車廠來說不是必需的？

當然，能做三級支援的提交者只是支援公司的一部分——沒人說過有什麼不同。但就像修車廠一樣，如果你沒有能處理棘手問題的人，其他一切都不重要。例如：我修車的地方，接待員效率高、友好（而且很火辣）。這很棒。等候區有舒適的沙發、咖啡和有趣的讀物。但接待員和物理環境只是整個體系的一部分，這個體系從根本上向我保證，訓練有素的技工能夠修理我的車，並且擁有所有必要的裝置和獲取所需所有零件的途徑。

再說說銷售人員。如果你沒有銷售人員，你就無法發展軟體業務。但如果你有銷售人員卻沒有人能提供真正的客戶價值，你的業務就不可持續。(儘管從短期商業角度來看這很有吸引力——考慮到我們每年數百萬美元的工程預算，我能理解擁有一家不需要進行如此規模投資的公司為何具有吸引力。)

儘管 Rod 想讓你相信，但我（或任何人）都可以提供高質量的 Spring 支援，這得益於 Spring 使用的 ASF 許可證。你不需要成為 Spring 的提交者來修復其中的 Bug，你也不需要 Interface21 的許可或背書來使用它。如果存在影響你生產伺服器的 Bug，我可以在程式碼中自行找到，與客戶交流，並找出最佳解決方案：補丁、變通方法、客戶端程式碼修改等。我能做到這一點是因為我能訪問關鍵的原始碼——客戶正在使用的原始碼——並且因為我透過仔細而繁瑣的準備，瞭解客戶的需求。

胡言亂語。我已經闡述了圍繞商業模式可持續性的論點。讓我們從純技術的角度考慮問題。關於開源的一些基本點

1. 非提交者無法保證任何東西進入專案程式碼庫。
2. 提交許可權是賺來的
3. 提交許可權代表著承諾
4. 並非所有提交者都平等。承諾和賺取是持續不斷的。
5. 可靠且可持續地完成某事需要深度。

讓我們更詳細地看看。

1. 非提交者無法保證任何東西進入專案程式碼庫。 這不言自明。他們可以貢獻補丁，但無法保證補丁會被接受。這可能會使你的客戶使用一個打了補丁的解決方案，該解決方案需要在產品下一次釋出時重新檢查，這可能阻礙客戶從軟體的演進中獲得全部好處。即使 Bug 報告是正確的並且補丁確實有用，通常我們看到整天處理軟體的提交者會選擇一種不同且更好的修復方法。這對客戶來說是同樣的問題。客戶不希望使用軟體的分支版本。
2. 提交許可權是賺來的。 提交許可權是透過長期參與社群；展示出技術技能；提交高質量的補丁；證明持續的承諾；不僅僅是為了經濟利益偶爾修復 Bug，而是渴望為產品的演進做出貢獻而賺取的。例如，現在我想你的銷售副總裁會讀到這段對話，擔心在銷售場合遇到棘手的問題，然後說“我們不能直接找一個 Spring 提交者嗎？” 這不會改變你已經有兩年（或者你的公司成立了多久）來表現出推動 Spring 向前的興趣，而一直滿足於讓其他人承擔所有繁重工作，只要你試圖坐在收銀臺前收錢這一事實。
3. 提交許可權代表著承諾。為一個開源專案提交就像養狗一樣；一旦你選擇養狗，就不能在六週後就厭倦並遺棄它。否則你就是讓別人來為你收拾爛攤子。
4. 並非所有提交者都平等。 在每個開源專案中都會演變出提交者許可權的層級。領導者通常會重寫來自更初級提交者的提交；無法保證他們的更改會保持不變。在任何執行良好的軟體專案中都會發生完全相同的情況。
5. 可靠且可持續地完成某事需要深度。 要提供關鍵任務的 24x7 支援，你需要多人能夠修復軟體並協同工作。

聲稱你能提供與實際編寫程式碼的人員相同質量的支援是荒謬的。你能在多快的時間內找到修復 Bug 的最佳方法？那些人整天都在研究它，並且做了最初的設計。讓我們考慮一個具體的支援問題。一位 SourceLabs 員工甚至附和了一位 Spring 使用者報告的問題。這個問題最終由 Spring（和 Interface21）的聯合創始人 Juergen Hoeller 解決。

你不需要成為 Spring 的提交者來修復其中的 Bug，你也不需要 Interface21 的許可或背書來使用它。

這是這篇文章中的幾個稻草人論點之一。我哪裡說過你需要我們的許可或背書才能使用 Spring？

檢視你的網站，SourceLabs 似乎比 OpenLogic 對開源專案貢獻更多（儘管對 Spring 沒有任何貢獻）。這使得你不同意我的文章顯得很意外。

但話又說回來，我的主要觀點是：即使這種在不對專案做出深度承諾的情況下試圖從支援中獲利的模型能起作用（這並不可靠），你對專案零貢獻，除了當出現問題（並且你有一個付費客戶）時。 你對推動軟體向前發展沒有任何貢獻；你依賴其他人來做這件事，以便你能從中盈利。你希望這些人足夠天真，會免費去做，而你完全忽視了需要大力推動專案向前發展以創新並滿足使用者基礎不斷變化的需求。再說一遍，如果其他人做這些事情，那是件好事。

好的支援意味著你與客戶建立了個人關係。你知道他們需要什麼，他們正在使用什麼其他軟體，他們最擔心什麼，並且你與他們建立了信任關係，讓他們相信你會一直在他們身邊。這遠遠超出了給他們一個尋呼機號碼然後說“如果壞了就給我打電話”。

顯然。所有這些都很重要，並且是完整圖景的一部分。這與當前的討論無關，因為沒有人說過不是這樣。我們的客戶對我們所有的服務都給予高度評價：支援、培訓和諮詢。

Interface21 的任何人都不能認真聲稱自己積極參與完整的 Java 企業堆疊的其他部分；Spring 儘管很棒，但它是一個框架，而不是一個堆疊。它不能提供企業客戶所需的一切，只支援 Spring 對於那些還需要 Hibernate 或 Struts 幫助的公司來說是不夠的。事實上，Rod 不得不說，如果你確實需要 Java 解決方案其他部分的幫助，Interface21 無法幫助你，因為他們不控制這些專案的原始碼。

Interface21 所做的是對客戶誠實地說明它提供什麼和不提供什麼，在哪裡可以提供堅實的支援，在哪裡不能。我還應該指出，我們在企業 Java 領域擁有無與倫比的技術深度（看看我們的團隊頁面），並且正在越來越深入地參與越來越多的專案。據我從你的網站上了解，SourceLabs 對 Apache Commons 做出了顯著貢獻：這幾乎不是企業的核心，而且只通過一個人。所以本質上你是在抱怨我對自己的主張非常謙虛這個事實。

我希望 Interface21 不僅僅是害怕來自那些理解做好支援比擁有一個 SVN 賬戶複雜得多的小公司的競爭。

我們有很多滿意的客戶，我們的支援銷售創下了季度記錄，並且有一系列非常強大的企業交易待處理，所以我們根本不害怕競爭。我之前的部落格解釋了為什麼我們確實能夠做好支援，採用“跟隨太陽”模式。據我所知，Interface21 比 SourceLabs 大好幾倍，而且增長速度快得多，所以你根本沒資格對我們擺出高高在上的姿態。哦，考慮到你個人能夠提供一流的 Spring 支援，我以為你應該知道 Spring Framework 的程式碼庫是 CVS，而不是 SVN。

當然，Rod。你想賣 Spring 的支援服務，請便。在市場上盡情發揮你的所有優勢，但這是一個市場。如果你想爭辯說對提交者的控制使你成為最好的支援選擇，儘管說，但就像我上面說的，這是一個相當站不住腳的論點。

當然這是個市場。我從未說過不是。我只是在解釋為什麼我們的 Spring 支援是無與倫比的。

你想賣 Spring 的支援服務，請便。 作為 Spring 的創始人兼聯合負責人，我很感謝你的許可。真是太慷慨了。

但那只是附帶的，我的主要觀點是，要以可持續的方式可信地支援開源，確保長期生成企業級開源，你不能只想著從支援收入中獲利：你必須投入大量的精力和投資。

我認為到目前為止，每個人的立場都已反覆闡述，延長討論沒有多大價值。

我歡迎人們圍繞 Spring 或其他任何事物賺錢。我只是認為任何企業都應該公開說明其能提供的服務範圍和質量。