在題為“關於Interface21的廢話”的文章中，一位SourceLabs的員工不同意我的觀點，即提交許可權對於提供可信賴的開源支援是必要的。

在我回復之前：我想再次把一件事情說得非常清楚，我在上一篇部落格中已經說過，但似乎被一些人誤解了：Interface21 無意阻止他人透過 Spring 賺錢。我們的過往記錄證明了這一點。我們歡迎他人撰寫關於 Spring 的文章，提供 Spring 服務。或者基於 Spring 構建產品，就像 Matt Raible 的 AppFuse。我們祝他們成功。Spring 之所以取得今天的成就，部分歸功於其豐富生態系統的支援。作為技術人員和一家公司，我們一直以來都支援這一點，並且將來也會繼續支援。

我的觀點是評論某一家特定公司中的某一個特定個人，他聲稱開源是由無償的業餘愛好者編寫的，並且在經濟上獎勵開源智慧財產權的開發是無關緊要的。

致部落格

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

這當然是胡說八道。讓我來轉述一下

Rod 聲稱，可靠的汽車維修需要訓練有素的機械師。這對世界上所有其他車庫裡非機械師的員工來說，肯定是個驚喜。有人必須負責銷售、經營業務、修復建築物、更新網站、尋找新客戶等等。機械師並不能帶來這些，誰能告訴我，這些對於一個成功的車庫來說不是必需的呢？

當然，能夠提供三級支援的提交者只是支援公司的一部分——沒有人說過別的。但就像車庫一樣，如果你沒有那些能處理棘手問題的人，其他一切都無濟於事。例如：在我保養汽車的地方，接待員效率很高，很友好（而且很漂亮）。這很棒。等候區有舒適的沙發、咖啡和有趣的讀物。但接待員和物理環境只是一個龐大機器的一部分，它從根本上向我保證，訓練有素的機械師能夠修理我的汽車，並且擁有所有必要的裝置和零件。

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

儘管 Rod 會讓你相信，但我（或其他人）可以提供頂級 Spring 支援，這要歸功於 Spring 使用的 ASF 許可證。你不必成為 Spring 提交者才能修復其中的錯誤，你也不需要 Interface21 的許可或認可才能使用它。如果有一個影響你生產伺服器的錯誤，我可以自己檢視程式碼，與客戶溝通，並找出最佳解決方案：補丁、變通方法、客戶端程式碼更改等。我之所以能做到這一點，是因為我能夠訪問重要的原始碼——即客戶正在使用的那個——並且因為我透過仔細而繁瑣的準備，理解了客戶的需求。

胡說八道。我已經在業務模式的可持續性方面闡述了我的觀點。讓我們從純粹的技術角度來考慮。關於開源的一些基本要點：

1. 非提交者無法保證任何內容能夠進入專案程式碼庫。
2. 提交許可權是贏得的
3. 提交許可權代表著一種承諾
4. 並非所有提交者都一樣。提交者和贏得許可權的努力將永遠持續下去。
5. 要可靠且可持續地完成某項工作需要深度。

讓我們更詳細地看看。

1. 非提交者無法保證任何內容能夠進入專案程式碼庫。 這是不言而喻的。他們可以貢獻補丁，但無法保證補丁會被接受。這可能會導致客戶的解決方案打上了補丁，而在產品下一次釋出時需要重新審視，這可能會阻礙客戶充分享受軟體進化的全部好處。即使錯誤報告是正確的，並且補丁確實有用，通常我們會看到，整天與軟體打交道的提交者會選擇一種不同的、更好的方法來修復錯誤。這對客戶來說也是同樣的問題。客戶不想使用一個分叉版本的軟體。
2. 提交許可權是贏得的。 提交許可權是透過與社群長期互動、展示技術技能、提交高質量補丁、持續投入的證據以及不只是為了經濟利益而修補偶爾的錯誤，而是要為產品的進化做出貢獻而贏得的。例如，我現在可以想象，你的銷售副總裁會閱讀這次交流，擔心在銷售場合會遇到棘手的問題，然後說“我們不能找個 Spring 提交者來嗎？”但這並不能改變這樣一個事實：你們公司已經有兩年（或無論你們公司存在多久）的時間來表現出對推動 Spring 發展的興趣，並且一直樂於讓其他人做所有繁重的工作，只要你們試圖坐享其成。
3. 提交許可權代表著一種承諾。提交給一個開源專案就像養狗一樣；一旦你選擇了養狗，你就不能在 6 周後就厭倦它而拋棄它。否則，你就是要求別人為你收拾爛攤子。
4. 並非所有提交者都一樣。 在每個開源專案中都會演變出一種提交者權威的等級制度。領導者經常會重寫更初級提交者的提交；他們的更改不一定能得以保留。任何管理良好的軟體專案都會發生同樣的情況。
5. 要可靠且可持續地完成某項工作需要深度。 要提供任務關鍵型的 24x7 支援，你需要多人能夠修復軟體並協同工作。

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

你不必成為 Spring 提交者才能修復其中的錯誤，你也不需要 Interface21 的許可或認可才能使用它。

這是帖子裡幾個稻草人論證中的又一個。我什麼時候說過你需要我們的許可或認可才能使用 Spring？

檢視你們的網站，SourceLabs 對開源專案的貢獻似乎比 OpenLogic 更多（儘管肯定不是對 Spring）。這使得你不同意我的帖子顯得有些令人驚訝。

但同樣，這又回到了我的主要觀點：即使這種試圖透過支援來賺錢，而又沒有對專案做出深度承諾的模式能夠奏效（實際上是無法可靠奏效的），除了在出現問題時（並且你有付費客戶）之外，你對專案沒有任何貢獻。你對推動軟體前進沒有任何貢獻；你依賴其他人來做這件事，以便你有東西可以變現。你希望那些人足夠天真，可以免費為你做這些，而你則完全放棄了推動專案蓬勃發展以創新並滿足使用者不斷變化的需求的必要性。同樣，如果其他人能做到這一點，那也很棒。

良好的支援意味著你與客戶建立了個人關係。你知道他們的需求，他們正在使用哪些其他軟體，他們最關心什麼，並且你與他們建立了信任的紐帶，讓他們知道你會一直在那裡支援他們。這遠遠超出了給他們一個尋呼機號碼並說：“如果出了問題就給我打電話”。

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

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

Interface21 所做的就是誠實地告知客戶它提供什麼和不提供什麼，它可以在哪裡提供堅如磐石的支援，又在哪裡不能。我還應該指出，我們在企業 Java 領域擁有無與倫比的技術人才深度（可以看看我們的人員頁面），並且正日益深入地參與到更多的專案中。據我從你們的網站上了解，SourceLabs 僅在 Apache Commons 專案中做出了顯著貢獻：這 hardly 是企業核心，而且是透過一個人完成的。所以基本上你在抱怨我過於謙虛的宣告。

我希望 Interface21 並不是害怕來自那些明白做好支援比擁有一個 SVN 賬戶複雜得多的公司的激烈競爭。

我們有很多滿意的客戶，我們正經歷著創紀錄的支援銷售季度，並且擁有非常強大的企業交易渠道，所以我們 hardly 害怕競爭。我之前的部落格解釋了為什麼我們真的能做好支援，透過“天涯比鄰”模式。據我所知，Interface21 的規模是 SourceLabs 的數倍，並且增長得更快，所以你 hardly 有資格教訓我們。哦，而且鑑於你個人能夠提供一流的 Spring 支援，我認為你本應知道 Spring Framework 的程式碼庫是 CVS，而不是 SVN。

當然，Rod。你想銷售 Spring 支援，請便。在市場上玩弄你所有的優勢，但這是一個市場。如果你想爭辯說控制提交者使你成為最佳支援選項，儘管去做吧，但如我上面所說，這是一個相當薄弱的論點。

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

你想銷售 Spring 支援，請便。 作為 Spring 的創始人兼聯合負責人，我很感激你的允許。這非常慷慨。

但這與我的主要觀點無關，我的主要觀點是，要可信地支援開源，並使其足夠可持續，以確保長期生產企業級開源產品，你不能只是試圖從支援收入中獲利：你必須投入大量的精力和投資。

我認為大家的立場都已反覆陳述，而且我認為延長討論的價值不大。

我歡迎人們圍繞 Spring 或任何其他東西賺錢。我只是認為任何企業都應該對其能提供的範圍和質量保持開放。