在標題恰如其分的關於 Interface21 的無稽之談中，一名 SourceLabs 員工不同意我關於提交權限對於提供可靠的開放原始碼支援是必要的論點。

在我回覆之前：我想再次完全清楚地說明我已經在我的上一篇部落格中說過的事情，但似乎被一些人誤解了：Interface21 無意阻止其他人從 Spring 獲利。我們的過往記錄證明了這一點。我們歡迎其他人撰寫關於 Spring 的文章並提供 Spring 服務。或者像Matt Raible 的 AppFuse 一樣，以 Spring 為基礎開發產品。我們祝他們成功。Spring 能發展到今天的程度，部分原因是它周圍豐富的生態系統。作為技術人員和一家公司，我們一直並且將永遠支持這一點。

我的重點是對一家特定公司的某個特定個人發表評論，他聲稱開放原始碼是由無償的業餘愛好者編寫的，並且經濟上獎勵開放原始碼 IP 的開發是無關緊要的。

前往部落格

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

這當然是無稽之談。讓我改述一下

Rod 聲稱可靠的汽車維修需要訓練有素的技工。對於世界上所有其他車庫僱用的非技工來說，這一定是個驚喜。總得有人負責銷售和經營業務，修復建築物並保持網站更新，以及尋找新客戶等等。技工無法讓你獲得這些，誰能告訴我這些對於一家成功的車庫來說不是必需的？

當然，可以提供第三層支援的提交者只是支援公司的一部分——沒有人說過不同的話。但與車庫一樣，如果你沒有可以處理棘手問題的人，其他一切都無關緊要。例如：我在那裡維修汽車，接待員效率高、友善（而且很火辣）。那很好。在等候區有漂亮的沙發、咖啡和有趣的閱讀材料。但是接待員和物理環境只是機器的一部分，從根本上保證我訓練有素的技工可以修理我的汽車，並且擁有所有必要的設備來做到這一點，並且可以存取所有需要的零件。

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

儘管 Rod 會讓你相信，但我（或任何其他人）可以提供頂級的 Spring 支援，這要歸功於 Spring 使用的 ASF 許可證。你不需要成為 Spring 提交者來修復其中的錯誤，並且你不需要 Interface21 的許可或認可才能使用它。如果存在影響你的生產伺服器的錯誤，我可以自己找到程式碼中的錯誤，與客戶交談，並弄清楚最佳解決方案是什麼：修補程式、解決方法、客戶程式碼變更等等。我可以做到這一點，因為我可以存取重要的原始碼——客戶正在使用的那個——並且因為我通過仔細而繁瑣的準備工作，了解客戶的需求。

胡說八道。我已經闡述了圍繞商業模式永續性的案例。讓我們從純粹的技術角度來考慮問題。關於開放原始碼的幾個基本要點

1. 非提交者無法保證任何進入專案程式碼庫的內容。
2. 提交權限是贏得的
3. 提交權限代表一種承諾
4. 並非所有提交者都是平等的。承諾和贏得會永遠持續下去。
5. 可靠且永續地完成某件事需要深度。

讓我們更詳細地看看。

1. 非提交者無法保證任何進入專案程式碼庫的內容。 這是顯而易見的。他們可以貢獻修補程式，但不能保證修補程式會被接受。這可能會使你的客戶擁有一種需要在使用下一個版本的產品時重新檢查的修補程式解決方案，從而可能阻止客戶充分利用軟體的演變。即使錯誤報告是正確的並且修補程式確實做了一些有用的事情，但通常我們會看到與軟體整天工作的提交者會選擇一種不同的更好的方式來進行修復。客戶也遇到同樣的問題。客戶不希望使用軟體的派生版本。
2. 提交權限是贏得的。 提交權限是通過長期參與社群、展現的技術技能、提交高品質的修補程式、持續承諾的證據、不僅僅是為了經濟利益而修補偶爾的錯誤，而且是為了為產品的演變做出貢獻的願望而贏得的。例如，現在，我可以想像你的銷售副總裁會閱讀此交流，擔心在銷售情況中遇到棘手的問題，並說“我們不能只找一個 Spring 提交者嗎”？這不會改變你已經有 2 年（或者你的公司存在多久）來表明你對推動 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 領域無與倫比的技術人才隊伍（看看我們的人員頁面），並且以深入的層次參與越來越多的專案。根據你的網站 AFAICT，SourceLabs 僅為 Apache Commons 貢獻了重要力量：幾乎不是企業的核心，並且僅通過一個人。所以基本上你是在抱怨我對我的聲明非常謙虛這一事實。

我希望 Interface21 不僅僅是害怕來自公司的競爭，這些公司了解正確的支援比擁有 SVN 帳戶複雜得多。

我們有很多快樂的客戶，我們的支援銷售額正在創下紀錄，並且擁有非常強大的企業交易管道，因此我們根本不害怕競爭。我之前的部落格解釋了為什麼我們可以真正做好支援，採用全天候支援模式。根據 AFAIK，Interface21 比 SourceLabs 大幾倍，並且增長速度快得多，因此你根本沒有資格屈尊俯就我們。哦，鑑於你個人可以提供一流的 Spring 支援，我以為你會知道 Spring Framework 儲存庫是 CVS，而不是 SVN。

好的，Rod。你想銷售 Spring 的支援，請便。在市場上充分利用你可以利用的每一個優勢，但這是一個市場。如果你想爭辯說控制提交者使你成為最佳支援選擇，那就去做吧，但正如我在上面所說的，這是一個相當薄弱的論點。

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

你想銷售 Spring 的支援，請便。 作為 Spring 的創始人和聯合負責人，我感謝你的許可。非常慷慨。

但那只是我主要觀點的題外話，我的重點是，要以一種永續的方式可信地支持開源，以確保長期生產企業級開源，你不能只是想從支援收入中獲利：你必須投入大量的努力和投資。

我想每個人的立場都已經被重複說明很多次了，並且認為延長討論沒有太多價值。

我歡迎大家透過 Spring 或其他任何東西來賺錢。我只是認為任何企業都應該公開其能夠提供的範圍和品質。