正如《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 试图将其他人的创新商品化并提供“足够好”的解决方案。

真正的创新和任务关键型支持与开源一样重要，对于企业软件也是如此。“足够好”是远远不够的，它低估了开源的价值。