正如《Register》和多家部落格作者所指出的那樣，Red Hat 最近宣佈了一項防禦性舉措，其動機是試圖追趕 SpringSource。顯然，SpringSource tc Server 和 dm Server 的發展勢頭讓 Red Hat 感到擔憂，同時 Spring Framework 作為企業 Java 的事實標準組件模型的持續發展也引起了 Red Hat 的注意。

“JBoss Open Choice strategy” 似乎是重新包裝，而不是新技術，它試圖將 JBoss 定位為在需求不斷變化的嶄新世界中仍然具有相關性。這種重新包裝不僅明顯是被動的，而且大部分宣傳口號聽起來也很陳舊。值得肯定的是，Red Hat 似乎終於意識到，許多開發者和客戶早已不再使用完整的 Java EE 堆疊；傳統的重量級應用伺服器的重要性已經下降；並且 Spring 程式設計模型對其客戶群體很重要。我們歡迎這種肯定，但這正是反思兩家公司之間深刻差異的絕佳時機。

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

但與此同時，Red Hat 似乎仍在試圖弄清楚發展方向：

Red Hat 中介軟體副總裁 Craig Muzilla 表示：“在未來不確定的 Java 世界和不斷變化的 Java 環境中，JBoss Open Choice 策略旨在為客戶提供信心，讓他們能夠選擇適合自己的程式設計和部署模型，而無需犧牲效能。”“儘管市場發生了各種變化，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 新聞稿中提到的“不斷變化的程式設計模型”的世界相去甚遠，我們看到了穩步增長到普及的程度。然而，Red Hat 能為 Spring 使用者提供什麼？SpringSource 提供了促使 Spring 走到今天的領導力，並繼續以明確的願景積極推動它，以期為企業 Java 帶來更好的改變。Red Hat 的“企業級”Spring 發行版，就像 Oracle 曾經失敗的“Unbreakable Linux”一樣，缺乏說服力。

總的來說，這裡存在明顯的戰略區別：Red Hat 低估了開源的價值。而 SpringSource 將開源視為創新的強大手段，並在整個應用程式生命週期中提供卓越、統一的體驗，在構建、執行、管理等各個階段提供強大的領導力，Red Hat 則在迴避塑造未來的責任。（“親愛的開發者，你們自己去弄清楚你們想要什麼，寫好程式碼，然後給我們 Red Hat 打錢，我們會盡力幫助你們。真心實意。”）

SpringSource 在應用程式生命週期的每個部分都提供領導力，並透過核心貢獻者和思想領袖提供深度支援，其質量贏得了我們 97% 的訂閱續訂率。另一方面，Red Hat 試圖將其他人的創新商品化並提供“足夠好”的解決方案。

真正的創新和任務關鍵型支援與開源一樣重要，對於企業軟體也是如此。“足夠好”是遠遠不夠的，它低估了開源的價值。