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.”

“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.

Monty’s explanation of why he founded the Open Database Alliance focused on the Alliance being able to target customers that need more personalized services than Sun/Oracle could provide. This jogged my memory about one of the early benefits marketed around purchasing open source support. Namely, that customers could speak directly with the developers of the product. In this brave new world, of 3 years ago, customers wouldn’t have to explain their issue to one or two levels of support professionals before reaching the actual developer of the code. This was even while most questions related to configuration, settings, or other issues that a level 1 or level 2 support professional could handle easily. But, when it was a tough problem, and/or the customer was down, going directly to the developer definitely had its appeal.

The ability to “speak directly with the developer” could not scale with the growth of an open source software business. Vendors want their developers writing the next feature for the next release, or out doing professional support, not manning the phones to answer configuration questions. I remember struggling with this issue when we were crafting IBM’s Apache Geronimo and WAS Community Edition support offerings back in 2005.

I know some closed and open source companies rotate their developers into the support organization so developers can get customer exposure and better understand how their work and the product is used in the field. However, this staffing procedure is seldom marketed to customers.

I checked the JBoss and MySQL subscriptions to confirm whether they market the ability to speak directly with the developer. As best as I could tell, they do not.

Customers don’t prefer a support triage system. But maybe they’re not willing to pay a premium for it? Or maybe larger open source vendors have acknowledged that this feature does not scale, and hence, aren’t offering it? Maybe it’s a little from column A and a little from column B?

Evans Data Corporation just released a report titled “Application Servers 2008 Ranking”. You can get your hands on the free report here.

Evans asked over 700 developers to rate leading application servers on over 21 attributes including performance, security, DB connectivity, scalability and support. Respondents had to have experience with the app server in order to rate it. Eight products were considered: Apache Geronimo, ColdFusion, JBoss, Netweaver, Oracle WebLogic, Sun GlassFish, WebSphere Application Server and Windows Server.

Apache Geronimo came in at #2, the highest ranked open source application server by developers. This warms my heart since I used to be the product manager for WebSphere Application Server Community Edition (WAS CE). Many of you know that WAS CE is IBM’s distribution of Apache Geronimo. It’s been an uphill battle for the Geronimo community, but this is an achievement they should all savor.

It’s one thing for WebSphere to be ranked highly by IT decision makers. This is an audience that IBM resonates with. But this survey is based on respondents who have actually used the products, namely developers. Yes, early versions of WAS (i.e. v3.5) were not the slickest or easiest to use. But we’ve focused on changing that perception over the past 5 years. The Evans study is proof that we’ve made significant progress. With IBM WAS version 7 released last week, I’m extremely confident that developers, and their peers on the operations team, will be even more impressed with WebSphere going forward.

I do not want this to be a ra-ra-IBM post. Many of you know that I don’t cover IBM news very much here. Additionally, readers will note that I usually write positive things about “my competitors”. I’ve always believed that strong competitors are a customer’s nirvana.

I do however, want to take a minute and repeat what I believe will be the most successful strategy for software vendors over the next decade. Providing customer choice that includes free/open source options.

A keen eye on developer and administer needs has been at the heart of WebSphere’s success. However, by itself, this would not have been enough. I strongly believe that our embrace of free/open source is the reason that WebSphere grew while other closed-source vendors had challenges against JBoss.

Offering Geronimo/WAS CE and the proven WAS family gave customers choice. Outgrowing the market is evidence that choice resonates with customers. The Evans study is icing on the cake that speaks to the quality of products that our customers have been choosing.

[UPDATE 2009-01-05: PLEASE see Eduardo’s comment about the Evans not weighting the results by # of respondents. I think that is a mistake on the part of Evans from a pure market research standpoint].

News from Sacha (and covered by InfoWorld) that JBoss Application Server 5.0 is close to GA kicked off a debate at TSS. Some commented that they were “Suspicious of anything that takes three years to develop”, while others questioned if there was anything new in JBoss AS5 that SpringSource and GlassFish (or for that matter Apache Geronimo) hadn’t already delivered. Others congratulated JBoss on closing in on JEE5 certification and refactoring their runtime to be more flexible.

What caught my attention is the way that Sacha (JBoss CTO) responded to two comments from Douglas Dooley.

When Douglas suggested that JBoss shouldn’t talk about the new microkernel in JBoss AS5 when the real value is in Java EE5 delivered in JBoss AS5, Sacha replied:

“Again, read my blog: we are perfectly aware that many of our customers are using very different APIs to leverage our AS services. Most of them rely on EE, some of them on Spring, etc. And that’s fine. I don’t really mind which “wrapper API” they are using: we are here to support them in their preferred scenarios. What matters is how flexible our underlying foundation is so we are able support these multiple scenarios.”

When Douglas commented that JBoss should ditch their work on other OSes and focus on Linux, Sacha replied:

“No worries, we are doing more than fine. But we are certainly NOT going to ditch support for other OSes: we have a significant portion of our users going in production on Solaris, Windows, etc. and again, that is a matter of choice – we won’t dictate that.”

Why did these responses catch my attention? Well, it’s not because of the technology decisions that JBoss appears to have made. The move towards a flexible app server has been going on for years and it’s where the industry is headed. For example, we’ve been down the flexible foundation path since WebSphere Application Server 6.1 two years ago (with more to come in the next release of WAS due out later this year). The reason is because Sacha focused on customer choice. Even though we compete, I have a lot of respect for Sacha. He’s way to smart to let dogma get in the way of meeting customer needs. The internal decisions that led to JBoss AS5 and the messaging around the product appear to be a direct result of Sacha (and team) understanding what customers truly seek and where they want to head (i.e. JEE isn’t the answer for every problem).

I’ve long written about how WebSphere has been able to grow significantly faster than the market because of our focus on customer choice. At times this focus stretches us a little too far as we try to reach the largest set of customers with whatever makes sense for that customer. This decision is not easy on the internal organization, but it really resonates with customers (as our revenue can attest to).

As a proponent of OSS, I’m very happy to see JBoss moving in this direction. As an IBMer who competes with JBoss AS, I say bring it on ;-)

Compiere just released version 3.0 of its namesake product with “well over 150 improvements“. If you’re not familiar with Compiere (hey, how many of us purchase ERP products), think of Compiere as an open source alternative to SAP or Oracle’s applications. Judging by a quick look at their product line and Compiere’s customer success stories, Compiere is squarely targeted at the SMB customer segment. As such, this would put Compiere up against Microsoft, more than it would against SAP or Oracle.

Compiere offers 3 editions, a free “Community Edition”, a “Standard Edition” priced at $25/user/month and a “Professional Edition” priced at $50/user/month. Maybe it’s the pricing class that I just took this weekend, but I really like how Compiere has been able to differentiate the 3 offering based on features that will lead the buyer to pick “A” vs. “B”. I also like how the “Standard Edition” and “Professional Edition” are following the gated access to OSS products business model that has worked so well for Red Hat and others.

Give Compiere V3.0 a try and let us know what you think. (Personally, I’m not a fan of registering to try out an OSS product. We tried that with WAS CE and some of the contact info we received was quite amusing, not remotely close to PG-rated, but amusing…folks at Compiere: maybe make the info optional, and hence reduce a barrier to trials?)

BTL posted a ‘highlight’ of an interesting interview that Mary Jo Foley did with Iain McDonald, director of project management for Windows Server.

In the interview, McDonald describes “Windows 2000″ as the worst-run project of all time. McDonald says that “stupid decisions” and “7-day weeks for 30 weeks in a row” helped the Windows 2000 project earn that title. Keep in mind that McDonald’s statement is from a project management standpoint, and we shouldn’t equate it to “Windows 2000 was the worst product of all time”.

Larry Dignan goes on to ask:

“Was Windows 2000 really a worse run project than Vista, which had a do-over in the middle of the project?”

If “do-overs” and “stupid decisions” make for the “worst project of all time”, can the OSS development methodology guard against these pitfalls for OSS community projects?

It can be argued that truly open, open source development requires “do-overs” at the core of the project. Well, maybe not “do-overs”, but “do multiple times”. For example, Linux with KDE & Gnome or Apache Geronimo with Tomcat & Jetty. In OSS circles, we talk about better ideas coming from several solutions to the same requirement, but what about the wasted time and effort?

I’d suggest that “stupid decisions” happen in the OSS & Traditional software world at equal proportions. In the OSS world, anyone can reduce the impacts of a “stupid decision” by writing code that addresses the same requirement, without the “stupidity” and let the community pick a winner. But then, we get back to the question of duplicate work.

We’ve seen analysis of what the Linux kernel would have cost to develop inside a Traditional software company. A view of the wasted time and cost would be an interesting adjunct piece of data.

Now, let’s ask if “do-overs” and “stupid decisions” can be minimized at an OSS vendor.

I’d argue no, or yes, but not nearly enough to matter. My premise for this argument is that when a single OSS vendor is driving a project, the majority (90%+) of OSS development work, where the “do-overs” and “stupid decisions” really hit home, is done by internal developers. I’m not saying that the community doesn’t ever contribute valuable code. But if you spend a little time on the mailing lists or Jira’s for some hot OSS vendor-backed OSS products/projects, you’ll find how little the community contributes to the development. (The community definitely contributes in other ways: docs, helping newbies, finding bugs, etc). So, if 90%+ of the core development work, and as a result, core development decisions, occur inside the OSS vendor’s walls, shouldn’t “do-overs” and “stupid decisions” occur at rates similar to those at Traditional vendors?

When I was checking for the Feed Stats option on the wordpress.com Dashboard and realized it was gone. After some digging, I found this post from Matt at WordPress:

“(It’s) important to us to be constantly adding new features and functionality for you guys, sometimes we have to retire or prune things that just didn’t work out or that we don’t have time to focus on right now.”

From the 2 replies (out of 200+) I read, half seemed to understand and half were upset with the decision.

It would be nearly impossible to do something like this in the traditional software world. Products and features rarely die without a replacement/alternative nearby. Paying customers don’t want to use your software if they can’t trust product/feature continuity with releases.

In the open source world, it’s much more common to add a feature, only to drop it in a future release. Or to add two implementations of the same feature and see which one users like more. For example, Apache Geronimo recently passed 100% of the JEE5 TCK tests using the CXF Web services stack. However, I hear they’re planning to ship CXF and the Axis2 Web services stack when a JEE5 certified Geronimo 2.0 ships later this summer.

The “see if it sticks to the wall” approach used within most open source projects helps drive innovation. It can also be a pitfall for a customer that picked a “didn’t stick” technology/feature. Sure, you have the code, so you could support yourself on the technology/feature, but that’s not realistic for most enterprises.

Definitely a double edged sword, but still very cool to see in action!