正如 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 正试图商品化并交付一种基于他人创新之上的“足够好”的解决方案。

真正的创新和关键任务支持对于开源和企业软件同样重要。 “可能足够好”是不够的，并且会缩短开源。