正如 The Register 和 一些 博主 注意到的，Red Hat 最近宣佈了一項防禦性舉措，其動機是試圖趕上 SpringSource。 顯然，SpringSource tc Server 和 dm Server 的發展勢頭以及 Spring Framework 作為企業 Java 事實上的標準組件模型的持續進步讓 Red Hat 感到擔憂。

“JBoss Open Choice 策略”似乎是一種重新包裝，而不是新技術，它試圖將 JBoss 定位為在新需求不斷變化的世界中仍然具有相關性。 這種重新包裝不僅明顯是被動的，而且大部分資訊本身聽起來都是衍生的。 積極的一面是，Red Hat 似乎最終意識到許多開發人員和客戶早已遠離完整的 Java EE 堆疊； 傳統的重量級應用伺服器的重要性已經下降； Spring 程式設計模型對他們的客戶群很重要。 我們歡迎這種驗證，但現在是反思兩家公司之間深刻差異的好時機。

雖然輕量級、模組化和強大的解決方案至關重要，但我與之交談的客戶也意識到，加速價值實現的最佳方式是追求 聯合體驗和願景，從而簡化整個應用程式生命週期的企業 Java。 這解釋了為什麼 SpringSource 在構建階段繼續保持領先地位，擁有 Grails、Spring Roo、現在免費的 SpringSource Tool Suite 和 Spring Framework； 憑藉 tc Server 提供企業級 Tomcat 和 dm Server，在執行階段躍居領先地位，後者是模組化應用伺服器領域的領導者； 並在管理階段提供領導地位，憑藉已建立的 Hyperic HQ 管理產品，該產品不僅為 tc Server 提供可靠的管理和監控基礎，還為管理現代、下一代應用程式基礎設施提供了一個全面的平臺。

但與此同時，Red Hat 似乎仍在試圖弄清楚事情的走向：

“面對不確定的未來和不斷變化的 Java 世界，JBoss Open Choice 策略旨在為客戶提供信心，讓他們選擇適合自己的程式設計和部署模型，而不會犧牲效能，”Red Hat 中介軟體副總裁 Craig Muzilla 表示。 “儘管市場發生了種種變化，但 Red Hat 的目標仍然是成為 Java 市場中有價值且創新的解決方案的可信來源。”

當 Red Hat 舉手談論開發人員的“選擇”時，他們忽略了大多數開發人員已經發聲的事實，重點應該是為開發人員想要的東西提供最佳體驗，而不是採取分散的方法。 Red Hat 正在忽略這個現實，因為它負擔不起承認它的代價。

現實情況是：Red Hat 客戶實際選擇的技術組合依賴於 SpringSource 領導的技術：Spring 專案； Apache Tomcat 和 Apache HTTPD Web 伺服器。 SpringSource 在 Spring 社群中的強大而有效的領導地位得到普遍認可。 然而，許多人可能會感到驚訝的是，SpringSource 員工負責 Tomcat 的絕大多數錯誤修復和大部分程式碼更改； 幷包括 Apache HTTPD 的領先專家和活躍提交者。

讓我們更詳細地瞭解 Red Hat 提到的關鍵現代“選擇”，以更好地瞭解它們的相關重要性。 作為代理，我使用了美國職位列表的聚合

顯然，這裡的佼佼者是 Spring。 遠非 Red Hat 新聞稿中提到的“不斷變化的程式設計模型”的世界，我們看到 Spring 穩步增長到無處不在的水平。 然而，Red Hat 能為 Spring 使用者提供什麼？ SpringSource 提供了 Spring 達到今天地位的領導力，並繼續大力推動其前進，並以清晰的願景重塑企業 Java。 Red Hat 的“企業”Spring 發行版的可信度與甚至 Oracle 在市場上失敗的“Unbreakable Linux”一樣。

在高層次上，這裡有一個明確的戰略區別：Red Hat 正在縮短開源。 雖然在 SpringSource，我們將開源視為一種強大的手段，可以在整個應用程式生命週期中進行創新並提供卓越的、聯合的體驗，並在構建、執行、管理階段提供強大的領導力，但 Red Hat 正在放棄塑造未來的責任。 （“親愛的開發者，自己弄清楚你想要什麼，寫信給我們 Red Hat，當你完成後給我們一張支票，我們會盡力幫助你。說真的。”）

憑藉在應用程式生命週期每個部分的領導地位，SpringSource 正在提供來自核心提交者和思想領袖的深度支援，其質量水平為我們的訂閱贏得了 97% 的續訂率。 另一方面，Red Hat 正試圖商品化並交付一種基於他人創新之上的“足夠好”的解決方案。

真正的創新和關鍵任務支援對於開源和企業軟體同樣重要。 “可能足夠好”是不夠的，並且會縮短開源。