SpringSource, a division of VMware, recently announced its intent to shift development of the SpringSource dm Server project to the Eclipse Foundation.

In analyzing the announcement, The 451 Group’s Matt Aslett wrote:

“The move to the EPL appears to be motivated by a decision that there is more to gain by encouraging wider doption of OSGi approaches through more permissive licensing and collaborative community development.”

Prior to the announcement, SpringSource offered dm Server under the GPL and a commercial license.  SpringSource now intends to shift from the GPL to the Eclipse Public Licensed (EPL) and no longer offer a commercial license.  SpringSource will offer a support subscription for dm Server instead of attempting to monetize usage through a commercial license.

I was quite surprised to hear about this business model change.  While the support subscription business model has been en vogue since the open source vendor movement began, there has been a dramatic shift towards the open core business model.  The adoption of an open core business model is predicated on the belief that revenue potential is optimized through the sale of commercially licensed products.  I remain convinced that support is not a scalable business model and does not address the issue of customers reverting into free users.  The largest and best known open source vendors have shifted away from support subscriptions to variations of an open core business model.  However, Matt used data from VC investments in open source companies to suggest:

“….that we may be starting to see a return to support and other services, rather than commercial code and licensing, as the preferred mode to monetize open source.”

Is SpringSource an example of a vendor returning to support and other services to monetize open source?  On the surface, yes.  However, I think the dm Server licensing and support changes represent a small piece of a larger vision.  When VMware announced the SpringSource acquisition, delivering and monetizing a cloud platform was a key component of their vision.  It doesn’t take a crystal ball to see that VMware is attempting to drive dm Server adoption through the Eclipse Foundation and monetize the adoption when operations team want to deploy dm Server applications on Cloud infrastructure.  The dm Server support subscriptions are a stop gap until VMware can build out their Cloud offerings and dm Server adoption increases.  This is a perfectly valid strategy, especially when considering the interest in cloud computing and open source.  However, it’s not a proof point against the open core business model.

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

Let me start with a few disclaimers.  By virtue of working in the IBM WebSphere Application Server team, I compete with SpringSource. I know, and like, several of the key people at SpringSource.  I’m happy that their hard work paid of with such a large exit. While I compete with SpringSource, I’m excited that this acquisition will raise the bar for vendors that I care about, and ultimately, customers will benefit the most.

There has been a lot of analysis about VMware’s acquisition of SpringSource.  By in large, the analysis has taken the vision of Clouds and PaaS laid out in VMware’s press release as a likely outcome.  Let me try a different approach by discussing what VMware really bought.

VMware bought SpringSource because “Spring is everywhere”:
Yes, but sadly for VMware, no.  The Spring Framework is widely used in the enterprise Java market.  From my own experience, many WebSphere customers use the Spring Framework on top of WebSphere.  But many WebSphere customers use the competing EJB open standard in place of the proprietary, but open source, Spring Framework.  The most recent Eclipse user survey results found that of the 436 respondents building server side applications, 47.5% were using the Spring Framework and 38.3% were using EJBs.  This data clearly demonstrates that customers exhibit a need for choice significantly higher than proclamations of Spring’s enterprise Java domination would suggest.

With such a high usage penetration, one could expect a significant revenue base for SpringSource.  Yet, SpringSource is estimated to have driven $20 million in revenue, or maybe bookings, mainly from professional services.  This is a very respectable base for a company with 150 employees.  IDC however estimated the 2008 Application Server market at nearly $3.8 billion.  So, while the Spring Framework is widely used, SpringSource has not been able to extract significant market share as a result.

VMware may believe that adding their brand and sales reach to the SpringSource portfolio will drive higher revenue from the Spring Framework and related Spring products.  Redmonk’s Stephen O’Grady subscribes to this view, using the MySQL acquisition by Sun as a proof point.  I disagree because a framework is different than a database and the other Spring products have nowhere close to the penetration of the Spring Framework, as I discuss below.  Additionally, if a customer has been using the Spring Framework for the past 5 years without a support contract or subscription, why acquire support or a subscription now?  The only reason for doing so will be if VMware and SpringSource disadvantage the open source Spring Framework in favor of the enterprise, commercially licensed, Spring Enterprise. The community uproar the last time SpringSource tried this approach leads me to believe that VMware and SpringSource won’t go down this path again.

VMware bought SpringSource because SpringSource now has a “Build-Run-Manage” story:
Yes, but sadly for VMware, no.  Trying to build a significant business selling support subscriptions to the large number of Spring Framework users proved to be a tough nut to crack.  The key insight for SpringSource was that customers paid for runtimes and integrated administration and management of runtimes, not for frameworks.  SpringSource responded by acquiring Covalent and Hyperic in order to deliver two runtimes, SpringSource tc Server and SpringSource dm Server with administration and management capabilities via Hyperic.  SpringSource has introduced a “build-run-manage” marketing campaign which always makes me chuckle as I recall IBM using Build-Run-Manage back in the early 2000s.  I understand that SpringSource is attempting to educate the market that they are no longer only a framework provider, but rather, now have not one, but two, runtimes that customers can purchase.

It’s arguable that one or both of these products will become the basis for VMware’s beachhead into the middleware market.  So what are the prospects for tc Server and dm Server?

Since tc Server is aimed at Tomcat usage, it’s important to ask what customers running large Tomcat environments used before tc Server came to market?  Well, some used Tomcat without support.  Others used JBoss, Geronimo, GlassFish and WAS Community Edition which deliver Tomcat inside.  Finally, others purchased Tomcat support from Covalent, OpenLogic etc.  For the most part, customers who have not purchased Tomcat support or management for 5+ years are not going to buy a product now.  If the customer was missing some of the management capabilities that tc Server provides, by now, the customer has built this capability in house. I know of several large Tomcat users that fall into this situation.  The customer now has to consider the sunk costs of their custom code versus the cost of acquiring a new product.  Next, customers that have purchased Tomcat support are targets for tc Server.  But these customers are also being targeted by JBoss, Geronimo, GlassFish and WAS Community Edition.  Finally, tc Server can compete against JBoss, Geronimo, GlassFish and WAS Community Edition.  It’s not yet clear that tc Server provides differentiated value that will allow it to win disproportionately against the other products.  The important insight is that very few Tomcat users are using just Tomcat.  They use other parts of a Java Enterprise Edition (JEE) stack, such as JMS messaging or Web Services.  So given the choice of tc Server with just Tomcat runtime features or a JEE product which includes Tomcat and other JEE APIs is not as cut and dry as SpringSource’s marketing would suggest.

In the nearly 10 months since dm Server became generally available, I’ve frankly heard of virtually no customer usage.  But don’t take my word for it.  As your neighborhood Java developer if they’ve heard of dm Server, or if they’ve used dm Server.  The key issue with dm Server is that it’s proprietary.  Developers and their managers were comfortable using the Spring Framework because, while the framework was proprietary, they could easily move their applications across multiple standards-based JEE application servers.  Protection from vendor lock-in was delivered by the runtime application server.  Customers continue to expect this.  If you build a dm Server application, there is exactly one runtime it will run on.   Hence, dm Server fails the vendor lock-in test, and its adoption is a testament to this failure.  This is however a fixable problem for VMware.  dm Server could be evolved to meet the forthcoming JEE 6 Web Profile specification, which Geronimo, GlassFish, JBoss, WebLogic and WebSphere are all expected to support.

VMware is going to find that broad usage of a framework or having a Build-Run-Manage story does not easily translate into customers migrating off their existing Java standards compliant application server runtime to a proprietary runtime.

VMware bought SpringSource because of the Cloud & PaaS angle:
Yes, but we’ll see.  Cloud and PaaS are the two reasons that VMware and SpringSource have claimed as motivations for the acquisition.  I couldn’t say it better than Redmonk’s Stephen O’Grady:

“In time, yes, quite possibly. And there’s little question that SpringSource offers VMware an intriguing opportunity to be what 10gen, Project Caroline, et al have to date failed to be: the EngineYard or Heroku for Java, permitting seamless deployment of Java applications to on or off premise cloud infrastructure. But this is, to me, a longer term revenue opportunity, as VMware’s cloud pieces are still coming together and its hardware and datacenter capabilities are neglible relative to competition such as Amazon, IBM or Microsoft.”

Additionally, whether VMware and/or SpringSource will acknowledge it, customers are already deploying Java applications to a dynamically provisioned and policy-based managed cloud.  This isn’t a two or three years from now capability.  As we speak customers are using IBM WebSphere CloudBurst Appliance with WebSphere Application Server and WebSphere Virtual Enterprise to achieve what VMware CEO claimed is: “something our partners aren’t doing yet” when asked by a financial analyst if this deal would alienate partners.  The point is not to discuss IBM products, but rather to highlight that the VMware and SpringSource future vision is already a reality.  And it’s a reality that is driving significant IBM WebSphere revenue around an on premise cloud environment. Again, this is a today statement.

Lastly, since an application runtime environment is critical to a PaaS or Cloud deployment, I’d go back to the fact that SpringSource’s runtime environments, tc Server and dm Server, are starting from a standstill in an uphill battle for revenue share.  While VMware works to establish tc Server and dm Server penetration, VMware will have to be careful not to alienate their application server partners; the ones whose products are driving virtually all of the application server spending today.  This level of coopetition is doable, but not easy.  But hey, VMware has 420 million reasons for doing difficult, but necessary, things.

VMware bought SpringSource because of Microsoft:
Yes. Larry Dignan’s excellent analysis of the acquisition highlighted some very interesting data from a financial analyst, Pritchard:

“In our view the acquisition highlights the vulnerability VMware has in its exposure to Microsoft. We estimate north of 80% (may be as high as 90%, with the rest being Linux) of VMware virtual machines are running Windows server and an application developed in Microsoft’s .NET environment. This is a key strategic vulnerability as Microsoft has a history of absorbing functionality such as VMW that is essentially a layer in the Microsoft stack. Ultimately SpringSource technology may enable VMW to add enterprise Java workloads to diversify away from Windows.”

Microsoft is clearly going after VMware with HyperV inside of Windows Server 2008 R2:

“We’ve got a great solution. It’s a sixth the cost on average of what we see in the marketplace. Evangelizing the tax that VMware is getting from the product is something we look forward to competing with in this environment. Again, it’s about getting specific. It is about getting aggressive, and that’s where we’re headed.”

In an effort to guard against Microsoft marginalizing VMware’s core virtualization business, the SpringSource acquisition puts VMware at odds with Java runtime vendors who collectively represent the approximately 50% of the enterprise market not associated with .NET.   I don’t see how SpringSource helps VMware versus Microsoft in the estimated 80 percent of VMware environments where the application has been developed on .NET as Pritchard suggests.  If the application is .NET based, and the hypervisor is running on top of a Windows host, then this is Microsoft’s customer to lose to or win back from VMware.  VMware is clearly looking past its current deployments where Windows and .NET dominate, to a new Java-based Cloud and PaaS environment. But we already covered that aspect and the competitive hurdles in the Cloud/PaaS portion of this post.

It’s not just Microsoft that is marginalizing the value of a hypervisor.  As mentioned above, IBM WebSphere CloudBurst Appliance and WebSphere Virtual Enterprise treat the hypervisor as an infrastructure component of equivalent value to the host operating systems.  Said differently, the hypervisor, like the operating system has little impact on the application performance, reliability, availability or TCO.  Those application characteristics are enabled through the runtime application server and the dynamic provisioning and management framework around the application server.  This is how IBM’s Cloud solution is designed.  I’ll wager that Oracle and Red Hat’s offering will push value up the stack, beyond the hypervisor layer itself.

VMware bought SpringSource because of the great people at SpringSource:
Yes.  There is solid talent at SpringSource.  VMware has set aside $60 million in retention funding for the approximately 150 SpringSource employees over the next four years.  This $60 million was discussed on the VMware investor call and is in addition to the acquisition price.  This will clearly help VMware retain SpringSource talent.  SpringSource employees will also want to stick around to bring their vision of world domination to fruition ;-)

Summary:
There is much opportunity and risk for VMware with this acquisition.  If VMware can execute well, they’ll have saved the company from peril at the hands of Microsoft and Hyper-V and application server vendors who are minimizing the value of a hypervisor to the level of the underlying operating system itself.

This acquisition raises the competitive bar for vendors with application server and/or hypervisor offerings.  That’s something customers should be happy about. Fun times ahead!

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

On the heels of Rob Bearden’s move to SpringSource, it seems that another JBoss executive alum, Shaun Connolly, is following suit.

Anyone who’s observed the interactions with JBoss & SpringSource over the past 2+ years may, like me, begin to wonder if the “friction” between the two companies is going to end.  Like me, avid readers of TSS (where the throw downs typically culminate), likely hope not.  The public debates are fun to read ;-)

In all seriousness, Shaun is a great guy and I wish him the best at SpringSource.  Rod and team, great choice!

SpringSource announced that it’s acquiring G2One, the company behind Groovy and Grails.  Groovy is an open source dynamic scripting language that runs inside a Java Virtual Machine.  Groovy uses Java-like syntax, so it’s often positioned as the scripting language of choice for developers who already know Java (and/or don’t want to learn a scripting language like PHP).  Some have even gone as far as suggesting that Groovy will become the dominant language for the JVM (ahead of the Java language).  Grails is a Groovy-based framework.

SpringSource is joining the list of Java application server vendors adding support for Groovy.  IBM has been supporting Groovy with WebSphere sMash, and Project Zero since July 2007.  Sun’s GlassFish recently added support for Groovy in GlassFish v3 Prelude.  JBoss has integrated Groovy with JBoss Seam.  I couldn’t find any product specific info from Oracle or BEA about Groovy.  Oracle/BEA offers developer documentation that describes how to use Groovy, but nothing about Groovy support within an Oracle/BEA product.  (Oracle/BEA readers, please correct me if I’m wrong).

What does this acquisition mean for customers (considering or using Groovy)?  According to the SpringSource acquisition FAQ:

“SpringSource has built a global support and governance operation for the Spring Framework. This infrastructure, coupled with G2One’s experts and some investment, can deliver a 24×7, worldwide support network for enterprises investing heavily in Groovy and Grails. Additionally, there will be some immediate product enhancements and we will be investigating the creation of enterprise grade Eclipse tools for Groovy and Grails development.”

Selling support for Groovy (a language) or Grails (a framework) doesn’t sound like a great business to me.  Look at Zend, the company behind the PHP language.  They’re making money from ancillary products around the PHP language, not simply from supporting the PHP language.  Next, there isn’t a whole lot of revenue to be had from support of a framework.  SpringSource knows this better than most vendors.  The Spring Framework is widely used, but the majority of customers are in production without any support from SpringSource.  This is why SpringSource has introduced Spring products, because as I’ve been saying, products are valuable, support, not so much.  But maybe SpringSource will introduce enterprise grade products with Groovy & Grails?

It’ll be interesting to see how the acquisition plays out. Best of luck to G2One and the SpringSource team.

SpringSource, the company behind the Spring Framework, recently announced that it has doubled revenue growth for the third consecutive year.

I would love to know how much of that revenue is coming from professional services vs. products vs. support.  We all know that professional services revenue does not have the scale benefits or profit margins of product revenue.  A reliance on professional services is, in my mind, a crutch to any open source company that wants to be in the business of selling products.  The crutch is necessary when the vendor is starting out, but relying on it too much, or for too long, will impact the shift towards products.  While doubling year-on-year revenue is spectacular, as an open source proponent, I want to see revenue from products based on open source.

In other news, Matt reports that Neelan Choksi has left his post as COO of SpringSource.  Neelan is a class act and helped grow and mature SpringSource in his 2 years with the startup. I hear that Neelan’s (to be announced) replacement is pretty solid.  Also, Neelan is staying on as a board member and advisor.

It seems that Neelan is going to do something (his LinkedIn profile lists his title as “TBD”) with Lexcycle.  Interesting to see that Lexcycle isn’t an open source company.

In any case, kudos to SpringSource and best wishes to Neelan.

Follow

Get every new post delivered to your Inbox.