Get ahead
VMware offers training and certification to turbo-charge your progress.
Learn moreAs 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.
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.