Oh Snap! SpringSource vs. Redhat
A couple of days ago, Redhat announced their JBoss Open Choice strategy and the first thing that popped into my mind was "interesting....Redhat is starting to recognize that SpringSource is a threat too..." Yesterday, SpringSource CEO Rod Johnson blogged about it and, boy, it was harsh! This was Wrestlemania-worthy trash talking!
I'm a customer of redhat/jboss and I was a customer of covalent back before covalent spun off hyperic, merged with springsource, and then bought hyperic back and I agree that Open Choice for a large part is purely defensive but not necessarily just a defensive move against Springsource. Granted, for customers thinking of migrating to SpringSource platforms purely for enterprise support of Spring, Redhat can say, "Oh, don't bother. We support Spring, too, as well as Struts, apache, tomcat, blah, blah, blah" but also because Oracle's acquisition of Sun. It's all about the stacks and now Redhat can say that they have one and the one they have isn't bad at all.
I am very interested in seeing what Redhat winds up doing as far as their technologies go because Redhat does utilize stuff that SpringSource now serves somewhat in the role of steward for. For example, the JBoss Web Server is a repackaged version of tomcat with some neat additions like a mod_rewrite implementation and some PHP stuff. Jopr, JON, and RHQ are all based on Hyperic's HQ but geared towards managing your JBoss 'stack'.
Redhat might have some success with Torquebox if they can integrate that well with the JBoss Web server for those folks who want to develop Rails apps but don't want JBossAS and are frightened of Mongrel, Phusion Passenger, or Rack. Maybe Redhat could buy Scala, if that is even possible, in order to answer Springsource's acquisition of the Groovy and Grails stuff. What Redhat/JBoss seems to lack right now is that wild-eyed base of fans that SpringSource seems to enjoy. Spring framework developers really, really seem to love Spring. I have yet to witness many (any?) rabid Seam developers.
I have not used SpringSource's tc server so I can't say whether or not it really contains 'enterprise-class' features but if anyone from SpringSource reads this, I have two simple questions about tc server:
- If I start up a default instance, will the server halt if I deploy a JSP that contains System.exit(1); and
- Will a PCI scanner complain about the tomcat version that is being written in the Server header and/or within default error page footers because we inadvertently wanted the whole world to know what potential vulnerabilities are exploitable in our sites
As far as SpringSource's dm server goes, I have to confess that I don't yet "get" OSGI so the whole "we rock because we have an OSGI-based container and jboss doesn't" argument from a few months ago was lost on me.
If anything, there are interesting times ahead for those of us who like to steer clear of the larger, traditional commercial vendors. I can't wait to read Redhat's reply!