I’ve argued that Cloud vendors are in a better position to monetize open source products than open source software vendors themselves.  I’m not alone in this thinking.  In William Vambenepe’s post, “Cloud + proprietary software = love”, there may be yet another reason for open source vendors to drink the Cloud Kool-Aid with caution.

Vambenepe’s writes:

“If Cloud providers get it right and software vendors play ball, the ‘proprietary vs. OSS’ debate may become more favorable to proprietary software in the Cloud than it is on-premise.”

Vambenepe’s argument centers on Cloud computing alleviating buyers from the hassle of license management.

“The removal of license management as a concern may not make a big difference to large corporations that have an Unlimited License Agreement, but for smaller companies it may take a chunk out of the reasons to use open source software. Not only do you not have to track license usage (and renewal), you never have to spend time with a sales rep. You don’t have to ask yourself at what point in your beta program you’ve moved from a legitimate use of the (often free) development license to a situation in which you need a production license.”

With license management being equally unnecessary for open source or proprietary software in the Cloud, buyers can focus on other selection criteria such as costs. Unlike development or unsupported usage scenarios, both open source and proprietary products have an associated license costs in the Cloud.  This is obviously for products delivered and supported by the Cloud provider or the Cloud provider’s partner.  To make Vambenepe’s point, I decided to compare pricing for WebSphere Application Server and the most closely related Red Hat product available on Amazon EC2.  Amazon charges $0.795 per hour to run the IBM WebSphere Application Server on Novell SUSE Linux on a Standard Small Amazon Machine Image (AMI) in the US.  This charge includes Amazon EC2 costs and the per hour license costs of Novell SUSE Linux and WebSphere Application Server.  Alternatively, Amazon charges $1.21 per hour to run JBoss Enterprise Application Platform on Red Hat RHEL on a Standard Small EC2 instance plus a monthly $119 recurring fee.  [UPDATE: 2009-12-11: Rich makes the point I am comparing apples to oranges.  That was not my intention. I simply picked the only two application server Amazon Machine Images (AMIs) that I could easily find pricing for. And in retrospect, my intention was not to compare proprietary versus open source pricing in the cloud, but rather to compare the price differential of proprietary versus open source products in the cloud versus on-premise.] Obviously this is simply one comparison and other comparisons will play out in favor of open source product pricing on the Cloud.  But that’s not the point. As Vambenepe argues, both open source and proprietary products require a license in the Cloud, and the license cost differential doesn’t always favor open source product in Cloud environments.

With license management a wash and license cost differential being much more balanced than one may instinctively think, Vambenepe argues that choosing proprietary software in a Cloud deployment is likely to be an easier decision than on-premise.

Tim Bray wrote “Makes all sorts of sense to me” when tweeting about Vambenepe’s post.

What do you think?

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

I’ve blogged about building native mobile device applications using a Web technology-based framework such as PhoneGap from Nitobi in the past. When I first wrote about the open source PhoneGap project in March 2009 I concluded: “If I worked at RIM, I’d take a trip out to Vancouver to talk to the Nitobi dudes. This framework is exactly what RIM needs to counter the trend of developers targeting the iPhone/iPod as the premier environment for mobile device applications”.

Fast forward seven months and RIM announces a beta of the BlackBerry Widget SDK that:

“allows web developers to package up their web assets into BlackBerry Widgets (small, discrete, standalone web applications that use HTML, CSS and JavaScript). A BlackBerry Widget looks, behaves and has the same security mechanisms as a native BlackBerry application. BlackBerry Widgets can be installed on a BlackBerry smartphone like any native application and can be extended to use device-specific information and data using the BlackBerry Widget APIs.”

Wow, sounds like an enhanced PhoneGap tuned for BlackBerry applications. With fingers crossed I pinged Andre & Dave to ask if RIM was using PhoneGap for this SDK. I’d scoured the BlackBerry Widget SDK website and knew the answer before Dave and Andre replied “nope”.

This was absolutely a missed opportunity for RIM to compete versus Apple, Palm and others using open source. No, I’m not going to suggest that RIM open source the BlackBerry Enterprise Server; that would be silly. Rather, I believe RIM could have saved R&D costs, increased the value of its BlackBerry platform and influenced developers building for the iPhone if RIM had built the Widget SDK on top of the open source project like PhoneGap.

RIM should be utilizing R&D investments more effectively by leveraging exiting open source projects. RIM could have built this SDK for a lower investment by staring with PhoneGap, or another equivalent open source framework. Of course there might have been a feature gap between what PhoneGap offers and what RIM wanted to deliver in version 1.0. However, assigning RIM developers to the PhoneGap project to add these features whilst leveraging all the other APIs in PhoneGap would have saved RIM the work of reinventing the wheel for those other APIs.

RIM would have also benefited from new features added by the PhoneGap community. A PhoneGap community member who loves his BlackBerry and wants to “scratch an itch” could contribute a PhoneGap feature that other BlackBerry developers would find extremely useful.

Finally, RIM would be contributing to a framework that developers are already using to develop iPhone applications. RIM needs to figure out a way to entice developers to build BlackBerry applications before iPhone applications. However, RIM should also be working to get developers to port their iPhone apps to the BlackBerry platform. As a PhoneGap contributor, RIM could offer a simple and painless porting option for existing and new PhoneGap-based iPhone applications.

I could come up with additional benefits for RIM, but these three are big enough for RIM to reconsider its strategy for delivering the Widget SDK. RIM could yet contribute all or part of their Widget SDK to an established mobile framework open source community and build its Widget SDK product from the resulting open source community code.

I suggest this strategy because I’ve witnessed IBM using it with great success. In the WebSphere division, we contribute to countless open source projects, including the Apache HTTPD, Dojo Toolkit and Eclipse Equinox projects. We then utilize code from these projects with IBM enhancements inside of WebSphere Application Server. This strategy allows us to, with less, do more.

I hope friends at RIM can learn a lesson from IBM’s use of open source for competitive differentiation. With Dion & Ben at Palm, you can bet that Palm is thinking about using open source more effectively within its strategy.

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

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.

Since we’ve discussed #2 in the rankings, let’s turn to numero uno. The #1 application server as ranked by developers is…drum roll please…WebSphere Application Server (WAS).

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 ;-)

I usually try very hard to not write about IBM. But the following from Matt Asay requires a reply.

Regardless, IBM isn’t in the habit of open sourcing technology in which it has a lead or at least a strong position, such as it does with DB2. IBM strategically invests in open source to undermine the margins of its competitors, not its own.

Really? Take a look into OSGi, SCA, Apache HTTP Server or the countless other open source projects that IBM has open sourced technology into. This technology didn’t undermine competitors; it helped customers and competitors alike (and let’s not forget that competitor contributions helped IBM).

Take OSGi for example; virtually every application server is going to be built on OSGi technology. We helped found the OSGi Alliance and contributed a significant amount of the code for various OSGi implementations since Release 1.

IBM did this because the open standard (OSGi in this case) delivered customer benefits. Like all standards, they’re only useful if they are widely supported. What better way to convince other vendors and competitors alike to support and contribute to a standard, than through the use of open source around an open community?

The attention that OSGi technology is generating today is helping to raise all boats, especially IBM WebSphere, the first application server built on OSGi technology over 2 years ago.

Was the move to open source OSGi technology strategic for IBM? Absolutely. Did it undermine competitors? Not that I know of (but hey, I don’t know everything).

IBM (and all smart vendors) strategically invests in open source. But strategic doesn’t have to mean “undermine competitors”.

Last week I learned that Sun has put its 3 database groups (Java DB, MySQL, PostgreSQL) under Marten Mickos. First off, who knew Sun had such a broad database portfolio???? Second, smart move putting them all under Marten.

In speaking with Marten’s Java DB team I gave them a small nugget of advice that has served us incredibly well with WebSphere Application Server Community Edition (WAS CE). Simply put win with the strengths of the family, not individual products.

I’ve written about customers wanting choice and flexibility and the challenges of trying to position any product, OSS or not, as the answer to every problem. As a result, we’ve shifted from competing with WAS CE by itself to competing with WAS CE as an integral member of the WebSphere family of app servers. The results speak for themselves. Today, some customers use WAS CE alone, and others use WAS CE and then move up to the broader WebSphere app server family. A growing number are using WAS CE and the broader WebSphere app server family together to achieve different things within the same project. By bringing the family to the table we are able to win deals that start with either WAS CE or any member of the WebSphere app server family.

Sun has a similar opportunity. If the customer wants an embeddable Java database, Sun has Java DB. If the customer is looking for a really easy to use database for web-based CRUD apps, Sun has MySQL. If the customer is looking for a higher-end database or looking to replace some Oracle instances, Sun has PostgreSQL. Positioning the three options to go after three different usage situations will help reduce confusion. It also prevents a “one size fits all” mentality, which customers rarely subscribe to. The challenge for Marten and team is to tie the family message together by making it easier to use all three databases together in a larger application/project. This will be a critical step to ensuring that a MySQL customer can also be sold Java DB etc. Common tooling (to the degree possible) will go a long way towards making the family story a reality.

Good luck guys. Win with the family.