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.

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?

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

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.

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.

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

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

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