正如 the Register 和 一些 博主 指出的那样，Red Hat 最近宣布了一项防御性举措，其动机是试图迎头赶上 SpringSource。显然，SpringSource tc Server 和 dm Server 的势头让 Red Hat 感到担忧，再加上 Spring Framework 作为企业 Java 事实上的标准组件模型的持续发展。

“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 新闻稿中提到的“不断变化的编程模型”的世界不同，我们看到它稳定增长到无处不在的水平。然而，Red Hat 为 Spring 用户提供了什么？SpringSource 提供了领导力，将 Spring 带到了现在的位置，并继续以清晰的愿景大力推动它的发展，以改善企业 Java。Red Hat 的“企业”Spring 发行版与“Unbreakable Linux”一样可信，即使 Oracle 也未能将其推向市场。

在高级别上，这里有一个明显的战略区别：Red Hat 正在低估开源的价值。虽然在 SpringSource，我们认为开源是创新和提供卓越的联合体验（贯穿整个应用程序生命周期）的强大手段，在构建、运行和管理每个阶段提供强大的领导力，但 Red Hat 正在放弃塑造未来的责任。（“亲爱的开发人员，想出你想要的东西，完成后给我们 Red Hat 开一张支票，我们会尽力帮助你。说真的。”）

通过在应用程序生命周期的每个部分中发挥领导作用，SpringSource 提供了来自核心提交者和思想领袖的深度支持，其质量水平使我们获得了 97% 的订阅续订率。另一方面，Red Hat 正在试图商品化并提供基于他人创新的“足够好”的解决方案。

真正的创新和任务关键型支持对于开源软件和企业软件同样重要。“也许足够好”并不够好，并且低估了开源的价值。