Has SpringSource gained influence over the runtime?

The floodgates have opened on acquisitions, as they say. Today SpringSource, the company behind Spring commercially, had Rod Johnson announce its acquisition of Covalent. Covalent provides services around the popular Tomcat server and contributes widely to projects in the Apache family.

Not only does Covalent bring Apache leadership, but our combined company now has significant leadership on Apache Tomcat and HTTP. Two weeks ago, Sun paid $1bn for the “M” in LAMP. Now that Covalent’s outstanding Apache expertise and services are part of SpringSource, we are strong leaders in the “A”.

Among the articles that just recap the event, I found three interesting points that deserve a closer look. The first two include comments from Rod Johnson.

Can we expect Tomcat with OSGi support?

The Spring Dynamic Modules for OSGi Service Platforms project went 1.0 final last week and combines the Spring component model with the OSGi modularization model. SpringSource is a leader in the server-side takeup of OSGi, which now has strong momentum. We’re also actively involved in development of OSGi standards, and involved in the Equinox OSGi runtime at Eclipse. We think that OSGi is a big part of the future of enterprise Java, so it’s a key direction for us.

Who will buy SpringSource?

We believe that this acquisition helps us continue to grow a strong independent business. Being a one-stop shop for many customers helps us to control our destiny, rather than just be a juicy M&A opportunity.

The most interesting piece, though, is Emmanuel Bernard’s SpringSource’s strategy. It reads as though it was written before the Covalent acquisition (if so, I admire the author). I’d summarize its main points as follows:

• SpringSource is focused on selling consulting. To keep growing it needs a runtime, which unfortunately it didn’t have until it bought Covalent. Of course buying Covalent didn’t buy Tomcat itself, but it brought considerable influence over how Tomcat will develop.
• With control over a runtime, SpringSource can take on the implementation of one of the probably minimalist profiles of the forthcoming J2EE 6 specification. Its direct involvement in J2EE 6 helps here. See Will J2EE change its face? and J2EE 6 — A step in the right direction.
• This strategy was probably in preparation for some time. If we put Johnson’s statements in chronological order, they make sense. Heated rhetoric against J2EE, taken in its full context, gave way to partnerships with major middleware players BEA (now Oracle) and IBM, then to participation in J2EE itself. There’s a sharp stance against JBoss and, on the other side, complete support for Tomcat and a burying of the hatchet with Sun. See participation in J2EE 6 and the praise for GlassFish and the MySQL acquisition.

What’s the aim of all this? With the way J2EE 6 is taking shape, including profiles and more pluggable SPIs, SpringSource could have certified J2EE components as well as its own runtime and influence over it. That would mean a much bigger market for services across the whole portfolio.