Red Hat Reacts to SpringSource Leadership

Engineering
Rod Johnson
June 03, 2009

As the Register and several bloggers have noted, Red Hat recently announced a defensive move motivated by trying to play catch-up with SpringSource. Clearly the momentum of SpringSource tc Server and dm Server has Red Hat worried, along with the continued advance of the Spring Framework as the de facto standard component model for enterprise Java.

The “JBoss Open Choice strategy” appears to be a repackaging, rather than new technology, which attempts to position JBoss as still relevant in a brave new world of changing requirements. Not only is the repackaging obviously reactive, but much of the messaging itself sounds derivative. On a positive note, it appears Red Hat has finally realized that many developers and customers have long since moved away from the full Java EE stack; that the traditional heavyweight application server has declined in importance; and that the Spring programming model is important to their customer base. We welcome the validation, but this is a great time to reflect on the profound differences between the two companies.
While imitation is the sincerest form of flattery, imitations tend to be inferior to the original. In this case, Red Hat is missing the broader vision behind our product offerings, delivering the next generation of middleware.

While lightweight, modular, and powerful solutions are essential, the customers I talk to also realize the best way to accelerate time to value is to pursue a joined up experience and vision that simplifies enterprise Java throughout the application lifecycle. This explains why SpringSource continues our leadership in the Build phase, with Grails, Spring Roo, the now-free SpringSource Tool Suite and the Spring Framework; has risen to leadership in the Run phase, with tc Server providing enterprise grade Tomcat and dm Server the leader in modular application servers; and offers leadership in the Manage phase with the established Hyperic HQ management product that not merely provides solid management and monitoring underpinnings for tc Server but provides a comprehensive platform for managing modern, next-generation application infrastructure.

But Meanwhile, it appears that Red Hat is still trying to figure out where things are headed:

“With an uncertain future and the ever-changing world of Java, the JBoss Open Choice strategy is designed to provide customers with the confidence, to choose the programming and deployment model that works for them without sacrificing performance,” said Craig Muzilla, vice president, Middleware, Red Hat. “Despite all of the market shifts, Red Hat aims to remain a trusted source for valuable and innovative solutions in the Java market.”

While Red Hat throws up its hands and talks of developer “choice,” they’re ignoring the fact that most developers have already spoken, and the focus should be on providing the best experience for what developers want rather than a scattergun approach. Red Hat is ignoring this reality because it can’t afford to acknowledge it.

The reality: The combination of technologies that Red Hat’s customers are actually choosing is dependent on SpringSource-led technologies: Spring projects; Apache Tomcat and the Apache HTTPD web server. SpringSource’s strong and effective leadership in the Spring community is universally acknowledged. Yet it may be a surprise to many people that SpringSource employees are responsible for the vast majority of bug fixes for Tomcat and the majority of code changes; and include the leading experts and active committers on Apache HTTPD.

Let’s look at the key modern “choices” Red Hat mentions in more detail to better understand their relative importance. As a proxy, I’ve used aggregate US job listings:

Framework jobs, USA

Clearly the big dog here is Spring. Far from a world of “ever-changing programming models” mentioned in the Red Hat press release, we see steady growth to ubiquitous levels. Yet, what does Red Hat have to offer to Spring users? SpringSource has provided the leadership that got Spring to where it is, continues to drive it forward vigorously and with a clear vision to reshape enterprise Java for the better. Red Hat’s “enterprise” Spring distribution is as credible as the “Unbreakable Linux” that even Oracle failed in the market with.

At a high level, there is a clear strategic distinction here: Red Hat is selling open source short. While at SpringSource we see open source as a powerful means to innovate and deliver a superior, joined up experience throughout the application lifecycle, providing strong leadership in each of the build, run, manage phases, Red Hat is abdicating responsibility for shaping the future. (“Dear developer, go figure out what you want, write us, Red Hat, a check when you’re done and we’ll do what we can to help you. Honest.”)

With leadership in each part of the application lifecycle, SpringSource is providing deep support from the core committers and thought leaders, at a level of quality that has earned us a 97% renewal rate for our subscriptions. Red Hat, on the other hand, is trying to commoditize and deliver a “good enough” solution on the innovation of others.

True innovation and mission critical support is just as important with open source as it is for enterprise software. “Maybe good enough” is not good enough, and sells open source short.
We’re pleased to see Red Hat follow our lead, and we encourage JBoss customers and prospective customers to look at what they are really building their stacks on and compare the offerings from Red Hat and SpringSource on merit. Clearly Red Hat is deeply worried about SpringSource; it’s time for JBoss customers to come and learn why.
comments powered by Disqus

translate：
翻译：

正如Register和几位博主所指出的，红帽最近宣布了一项防御举措，其动机是试图赶上SpringSource。显然，SpringSource tc-Server和dm-Server的发展势头令人担忧，同时，Spring框架作为事实上的企业Java标准组件模型也在不断发展。
“JBoss开放选择策略”似乎是一种重新打包，而不是新技术，它试图将JBoss定位为在需求不断变化的新世界中仍然具有相关性。不仅重新打包明显是被动的，而且消息本身的许多内容听起来都是派生的。一个积极的方面是，Red Hat终于意识到，许多开发人员和客户早就离开了完整的Java EE堆栈；传统的重量级应用服务器的重要性已经下降；Spring编程模型对他们的客户群很重要。我们欢迎验证，但现在是反思两家公司之间深刻差异的好时机。
虽然模仿是最真诚的奉承方式，但模仿往往不如原作。在这种情况下，Red Hat缺少了我们产品背后更广阔的视野，它提供了下一代中间件。