VMWare acquisition of SpringSource: thoughts. August 13, 2009Posted by Sacha in IT, JBoss.
How does WMWare’s acquisition of SpringSource impact the current IT landscape? Here are my thoughts…
The easiest question to answer is certainly: “does this deal make sense for SpringSource?” It certainly does, yes. If you look at SpringSource rumored numbers, they were in the low 20m, heavily biased towards non-recurring revenues (i.e. training and consulting). For that part of the business, a typical multiplier is in the 1x-2x range (and certainly not the ~20x we see here). Consequently, it is clear that SpringSource haven’t been acquired for their revenue*, especially when you compare them with VMWare revenues at a $1.8b run-rate.
Consequently, getting such a price tag could be explained only by two scenarios:
- A bidding war between multiple vendors, or
- VMware was in a hurry to close that transaction and the price “didn’t matter much”
I really don’t believe in the first option: I don’t see many other vendors willing to play with such big numbers these days, nor with the absolute need to acquire SpringSource.
However, I truly believe in the second option. Paul Maritz has been VMware’s CEO for exactly one year now. I imagine he has spent the first 9 months of his tenure at VMWare understanding the market, speaking with partners, competitors, customers and figure out a new strategy for VMWare. Being an ex-MSFT exec, it is very easy to guess that Paul Maritz felt like standing on quicksand with no OS and no middleware under his feet: it was in his DNA, he needed his Windows&.Net back in his new home.
I bet Paul’s team analyzed the possible alternatives and once he made up his mind for SpringSource he went after it with one top priority: timing (not money). On the other side of the table, I bet Rod Johnson wasn’t willing to sell for less than Marc Fleury did, probably some ego-related subtlety. I do not take it as a coincidence that VMWare bought SpringSource for the exact same amount JBoss was acquired by Red Hat (albeit Rob Bearden probably learned the JBoss lesson and got a cash-only deal – which is very sound given VMWare’s volatile stock).
Bottom line: this deal hugely makes sense for the SpringSource team since no IPO or revenue-based acquisition could have led to such a valuation (and the probability their TC Server could have generated any meaningful revenue in the next 3 years was very low).
*) this is not unique, we have other FOSS acquisitions get stratospheric multipliers with even lower revenues: Zimbra @ 350m and XenSource @ 500m for example.
This acquisition makes sense for SpringSource, but is the same true for VMWare?
“My theory”™ is that the market has been moving for several years towards a verticalization of a few key vendors. Translation: the market will be dominated by a few big vendors each owning a full stack, from server hardware to enterprise applications, welcome back in the 80’s.
Consequently, if you want to exist in that game, you need to own an operating system and a middleware layer. Problem: there are only very few solutions/vendors left if you want to get an OS and middleware layer, hence the M&A pressure on the market (BEAS and JAVA acquisitions are an example of this). And building your own OS or middleware layer is not really an option: this is not just about the merits of a technical implementation, this is about having an ecosystem and a big mindshare – this takes ages to build.
IMO, that is exactly what led to this acquisition. VMWare had to own a middleware solution and other options were too costly. SpringSource’s acquisition gives VMWare several quick-wins: a foot in the middleware game, a developer community, a recognized brand in middleware and, last but not least, a seat on the JCP.
Nevertheless, I see VMWare face several challenges:
- First, VMWare didn’t buy a middleware runtime, but just a wrapper. This doesn’t mean they cannot build one with enough time, talent and money, but that just isn’t there today. Yes, there is TC Server, but that is certainly not what the market is expecting in terms of a full fledge and robust middleware implementation – this is merely a cleaned-up Tomcat à la sauce OSGi with no pedigree and that hasn’t been tested in meaningful deployments. Again, this is not impossible, but will take time. Software is like good wine, it takes time to mature.
- VMWare has very low credentials in Open Source and actually has had some tense moments with the Linux teams. Furthermore, in the past I’ve met with people previously acquired by VMWare and the result was… let’s say… below average. I don’t blame them, acquisitions are a difficult art and fast growing companies are usually not the best organized to welcome newly acquired teams. Consequently, this might end up not being an easy ride for the SpringSource team, especially if VMware is not cautious with their FOSS DNA.
- VMWare has no OS (hence, no OS ecosystem) and no proper Java Virtual Machine nor any credentials in that area. This is a big hole in their stack and they will have to fill that gap fast. A solution to quickly obtain an OS ecosystem would be to acquire NOVL, especially with their currently low Enterprise Value (711m USD) -
Consequently, in order for VMWare to benefit from this acquisition, they’ll have to:
- Start (or continue) the development of a proper middleware runtime, hence invest solid money in SpringSource ranks,
- Respect SpringSource’s FOSS DNA,
- Build a proper OS+JVM foundation
That will require a very solid execution.
Back to my Verticalization theory now: I don’t think that VMWare will be one of the few companies owning such a stack, my bet is that they’ll end up being acquired once their OS story will be more solid.
What it means for Java and EE
This is basically good news for Java since another key IT vendor has joined the Java camp. But that is also very naïve: SpringSource always had a love-hate relationship with Java and the JCP. On one hand they have joined the JCP, have a seat on its Executive Committee and participate in several JSRs. But on the other hand, their business plan is based on Java+ EE+JCP bashing: their motto is that you have to use SpringSource products because what the JCP propose is so fundamentally flawed. While it is relatively easy for a small company to play that script, it is much more difficult for a big one. That’s where things will get interesting: will VMWare be a good Java citizen, standardize its technology and embrace common efforts or will they move away from EE and build their own Enterprise APIs?
What is at play here is not just Java and EE, but a much more strategic decision for them: what will their Enterprise API look like? What will VMWare’s Force.com or AppEngine be? My bet is that VMWare will want to create a one-way street towards their “virtualized-OS”, the real money maker (more on this below). For that to succeed, they’ll need:
- To implement the full EE spec (so that existing EE deployments can be moved easily onto their OS)
- To keep implementing proprietary API à la Spring to increase lock-in as developers start using them (and for this, they do not necessarily need to keep Spring Open Source, au contraire!)
Back to my verticalization theory: all big proprietary vendors will have an incentive to use the exact same strategy i.e. provide portability to migrate users off their current platforms and then proprietary APIs and services to lock them in. And, in 3-5 years, once the market share of the various vendors will have settle, we will face a strong increase in non-standardized/proprietary API in order to increase customer lock-in, hence reduce sales cost and increase ASP.
Hint: if you want to avoid that scenario it is your responsibility to only buy standardized technology and participate in standard bodies – don’t just leave standard bodies to software vendors!
What does it mean for Open Source?
VMWare know they are only going to make money if they can sell their entire platform (virtualization + OS + management + middleware ++). They didn’t buy SpringSource just to sell Spring or TC Server standalone: with almost a 2b USD revenue run-rate, selling 5k Spring subscription chips and training is not going to work. Consequently, Spring/TC (and any other runtime they could build) will be used solely to bring more customers to their overall solution.
My bet is that they will do the following:
- Keep most of Spring Open Source and keep developing it to maintain the developer mindshare
- Develop a proprietary runtime (where the cut between the FOSS library and the proprietary core will be part of long discussions IMO) fitting only on top of their core platform
The idea is to maintain the mindshare while making sure Spring runs “particularly well” (or, for some parts, only) on top of the VMWare platform. Consequently, I don’t think we are going to see big changes in the licensing scheme or in what is open source; the changes will be more subtle and will be at the interconnect between the API and their proprietary core.
What does it mean for the middleware market?
In the short and middle term, the market won’t change much. Spring (as a framework) was widely used on top of JBoss+WebLogic+Websphere before this acquisition and will this is not going to change anytime soon. SpringSource (as a company) didn’t have any business impact on the other middleware vendors (ORCL+IBM+RHT) and the VMWare acquisition is not going to change that overnight: VMWare sell mostly to the IT operations, not to the developers/architects, so this will be hard shift for them (ask your average VMWare salesguy to spell “middleware” properly, you’ll see what I mean).
In the longer run, the situation will depend on well VMWare executes. Not just with SpringSource, but their overall OS+JVM+runtime story. So let’s wait and see.