正如 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 仍在試圖弄清楚事情的走向：

Red Hat 中介軟體副總裁 Craig Muzilla 說：“在不確定的未來和不斷變化的 Java 世界中，JBoss Open Choice 策略旨在讓客戶有信心選擇適合他們的程式設計和部署模型，而不會犧牲效能。 “儘管市場發生了所有變化，Red Hat 仍致力於成為 Java 市場中有價值且具創新性的解決方案的可靠來源。”

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

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

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

顯然，這裡的大佬是 Spring。 遠非 Red Hat 新聞稿中提到的“不斷變化的程式設計模型”的世界，我們看到穩定的成長達到普遍水平。 然而，Red Hat 可以為 Spring 用戶提供什麼？ SpringSource 提供了讓 Spring 發展到今天的領導地位，並繼續以清晰的願景積極推動它向前發展，以更好地重塑企業 Java。 Red Hat 的“企業”Spring 發行版的可信度與甚至 Oracle 在市場上都失敗的“Unbreakable Linux”一樣。

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

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

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