Red Hat Reacts to SpringSource's Leadership

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 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:

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.

from http://blog.springsource.com