jump to navigation

VMWare acquisition of SpringSource: thoughts. August 13, 2009

Posted by Sacha in IT, JBoss.
trackback

How does WMWare’s acquisition of SpringSource impact the current IT landscape? Here are my thoughts…

SpringSource

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:

  1. A bidding war between multiple vendors, or
  2. 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.

VMWare

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.

About these ads

Comments»

1. VMWare acquisition of SpringSource: thoughts. | Linux Articles - August 13, 2009

[…] the original here:  VMWare acquisition of SpringSource: thoughts. Bookmark It Hide Sites $$('div.d4251').each( function(e) { […]

2. erics - August 13, 2009

Thanks for the insights, very well thought out. But that is what we expect from you! ;-)

3. Pierre-Antoine Grégoire - August 13, 2009

Very good analysis. Though I don’t really see the lock-in of using Spring libraries, as applications can use them and be deployed in any server of the market. This is of course not the case of the dm server.

Sacha - August 14, 2009

The lock-in exist today by virtue that you cannot access their CVS/SVN tree and that forking is not an option for many end-users. But that is indeed a relatively soft lock-in constraint.

You could imagine that in the future, stronger lock-in strategies are put in place, such as:
– the CVS/SVN contributors could decide to not do QA on other application server anymore, except on their own runtimes (“you should really run on DM, it works much better in my experience”).
– they could also decide to not do the mapping from the Spring framework to other application servers (remember, since I don’t have access to the main SVN, the only way to provide this mapping would be to fork it, possibly rebrand it, etc.)
– they could also continue to support other application servers for 90% of the framework but only support their own runtime for the remaining 10%, for carefully selected features and/or optimizations, etc.

I am not saying such things will happen, but it is obvious that in the past SpringSource has thought about ways to move away from the ASL in order to increase vendor lock-in and/or make sure OEM pay a royalty on each deployment (move to the GPL). These moves weren’t done “for the good of the community”, but were pure business decisions. Don’t get me wrong, I understand that a company has to make those decisions, especially a startup, but that just means you shouldn’t necessarily consider the things as they are today as what they will be tomorrow.

Cheers,

sacha

4. Grzegorz - August 14, 2009

“I don’t have access to the main SVN”

and what about https://src.springsource.org/svn/spring-framework/trunk/ ?

Sacha - August 14, 2009

That’s a read-only access, not a read-write. List me 3 competitors of SpringSource who have Write access to SS’s SVN tree. ;)

5. James Cavalera - August 14, 2009

Very insightful post, Sacha. I certainly agree on most part of it. Congrats.

As for the price tag, remember that VMWare also paid for SpringSource’s egoes (which is the only “asset” this big over there…)

Sacha - August 14, 2009

Buying “egoes” is a risky business…

6. Andrig Miller - August 14, 2009

Increasingly VMWare has faced pressure as OS vendors such as Red Hat, Sun (now Oracle), and Microsoft have put virtualization into the OS. With that, I think you are correct, that they have to have an OS story to go along with the middleware. Customers will eventually not consider virtualization an add-on, and be willing to pay a premium for it, as it will be in every major OS out there. The only thing that have kept things going to this point, is their management of virtualization is simply better, but that won’t last much longer. So, if they don’t have an OS of their own, they simply cannot be a major player long-term.

Novell would definitely be the right play for them, but carries a lot of baggage besides the OS, and they haven’t been doing well with the Linux business lately either.

Of course, I really don’t see another option for them in the OS space. Maybe Ubuntu, but they don’t have any traction at all in the enterprise space today.

7. Sacha - August 14, 2009

I agree Andrig.

Ubuntu is an interesting one. Problem: they have a non-existant ISV ecosystem. OTOH, they have increasing traction and that could possibly be leveraged by VMW. Truth is that Mr. Shuttleworth-a-lot will never sell just to sell, he already has what he needs in terms of cash, my bet is that he would only sell if he was to find a real opportunity to x10 accelerate his linux-desktop dream. VMW won’t be that white knight.

8. Harish Pillay (harishpillay) 's status on Saturday, 15-Aug-09 10:33:04 UTC - Identi.ca - August 15, 2009
9. Observer - August 22, 2009

Fwiw VMware paid more for spring than redhat did for JBoss by a good margin. the “apples to apples” would be JBoss 380 vs spring 420 and spring has significant employee retention comp ontop of the 420 to address the execution risk

Sacha - August 22, 2009

Observer,

That is not correct. RHT’s total consideration for JBoss was 350+70m = 420m. As for any retention plan, no public information was ever shared by RHT.

Cheers,

Sacha

10. Lars T - November 7, 2009

My First thought was that they will deliver a BEA LiquidVM Server like product: vm tc Server without any OS. The JavaVM is missing and LiquidVM hasn’t got any updates for years. Maybe they assemble it with a Linux OS and a JavaVM.

11. Si chen - January 21, 2010

This reminds me of a quote from an old Matt Groening comic book called “Love is Hell”:
“Why buy the loaf when you can get slices for free?”

I think it’s great that VMWare wants to offer “Spring-as-a-Service”, but what was the advantage of buying Springsource to do it?

As a counterexample, Amazon’s EC2 offers you Linux in the cloud, but they didn’t buy Ubuntu. They just offered Ubuntu, along with Red Hat, Windows, and any other OS you’d want.

Sorry but did I miss something important here?

Sacha - January 22, 2010

Si Chen,

There is always a “stickiness” to Open Source communities and that is really what VMWare was after. Through that acquisition, they suddenly “exist” for tens of thousands of Java developers (up from 0). The part I like about this acquisition is that if that had acquired an AS vendor, they would “only” get developers working on that specific product. By acquiring SS, they get a share of WS developers, a share of WL developers, a share of JBoss developers, etc. This is really a cross-cutting share of the Java Enterprise market.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers

%d bloggers like this: