We’ve looked in detail at VMware‘s acquisition of SpringSource, but if we’re honest it does remain a bit of a puzzle. The VMware faithful are perplexed and the Open Source community behind SpringSource is feeling a little bruised. OK, SpringSource has some management tools, but so do lots of people, and VMware does a lot of management so why is SpringSource being put into a separate division? And of course, SpringSource has development tools, but what is an infrastructure vendor doing buying a development tools vendor? It doesn’t happen very often, because it generally doesn’t make sense. There are too few obvious synergies.
In fact, there’s a broader question: why is anybody buying a development tools vendor these days? In November 2001 IBM launched the Eclipse Project, to deliver best-of-breed development tools as Open Source technology at no cost. Rational, Borland, Togethersoft, WebGain joined the party and watched IBM load the gun. With 5 years they were either acquired by IBM, dead or out of the development game completely. The vast majority of customers now have such a low expectation of the price of development tools that revenues from the tools cannot sustain the R&D cost of building and maintaining them. IBM maintains Eclipse to promote WebSphere. Oracle maintains Workshop to sell WebLogic,… Development tools have become an expensive luxury, maintained by vendors for one reason, and one reason alone, the promotion of Runtimes.
So, VMware has bought something in order to sell a runtime? What runtime could VMware possibly have that SpringSource can target. With a Spring application clearly you can build a J2EE stack on a Guest O/S on aVMware hypervisor, but surely that can’t be it? VMware owns the Dev Tool, a third party owns the Application Server Runtime, a third party owns the Guest Operating System and VMware owns the Hypervisor. There can’t be that much leverage for VMware here. It’s a bit of a messy sandwich of vendors.
It turns out that there may be a clue in the SpringSource tag-line “Build, Run, Manage”. As we’re talking about Runtimes, let’s focus on the “Run”. In buying SpringSource, VMWare have actually bought three runtimes. They have an enhanced Tomcat Server and an Enhanced Apache Web Server (neither of which are particularly groundbreaking) but there is one other that could possibly shake everything up, the innocently-named SpringSource dm Server, which is an OSGi runtime based on the Equinox runtime which sits at the heart of the aforementioned Eclipse.
OSGi (formerly known as the Open Services Gateway initiative) is a standards body whose acronym now doesn’t actually stand for anything. An OSGi Runtime is a layer of services provided to a java application. You build your java to this API abstraction, rather than the underlying operating system, and as the OSGi runtime is ported to various operating systems, you get instant portability for your application. There are lots of open source modules available for the OSGi runtime to provide standard services to java applications and if you need an Application Server for backwards compatibility, you can run Tomcat inside the OSGi Runtime (at least you can with SpringSource dm Server).
The key thing is that the SpringSoft development tools can directly target the OSGi runtime. Now, since OSGi was initially conceived of in the embedded space, the services required of the base operating system to support OSGi are fairly minimal, so this needn’t be a full-blown operating system in the conventional sense… In fact some basic kernel may suffice… now I imagine this is starting to sound slightly more familiar to the VMware faithful. So, the idea is that you can run the OSGi runtime directly as a guest on the hypervisor. So you don’t need a third-party application server any more. And you don’t need a third party guest Operating System. How convenient, a complete VMware Enterprise Java stack. Has anyone told Oracle, IBM, Microsoft or Red Hat?
Comments are closed.