Thinking Out Cloud

Cloud Computing and SaaS Models Are About Bottom-Up Adoption

Last week I gave a keynote presentation at the CloudConnect conference in Santa Clara. The title of the presentation was: "Surprise! Your Enterprise is Already Using the Public Cloud."

Regular readers of this blog (or those who work with me) know I go on about this a lot: In the enterprise, cloud computing services (IaaS, PaaS, SaaS) are being adopted bottom-up. In other words, by the rank & file (developers, IT admins, business folk) and not top-down with a big strategic decision by the CIO.

That's what the keynote was about and the title was addressing the CIO, who is the last to know about cloud computing adoption within his or her organization.

If you're interested in this topic you can watch the video of the presentation (you need to scroll down to get to it) on the CloudConnect web site. 

You can also read this very good summary of my talk by Rich Miller on Data Center Knowledge.

UPDATE [March 1, 2012]: Charles Babcock at Information Week wrote a nice piece about CloudConnect, including coverage of my keynote: 4 Cloud Computing Pain Points That Still Hurt.

And finally, here are the actual slides via SlideShare:

CloudConnect 2012: Surprise! Your enterprise is already using cloud computing

View more PowerPoint from gevaperry

 

Public Vs. Private Cloud (yes, that old debate)

Hope everyone in the U.S. had a great Thanksgiving.

This is a quick follow up on my previous post, 10 Predictions About Cloud Computing, which received quite a bit of attention in the cloudosphere. Specifically, my second point there, which stated:

Public Rules: Internal clouds will be niche. In the long-run, Internal Clouds (clouds operated in a company's own data centers, aka "private clouds") don't make sense. The economies of scale, specialization (an aspect of economies of scale, really) and outsourcing benefits of public clouds are so overwhelming that it will not make sense for any one company to operate its own data centers. Sure, there need to be in place many security and isolation measures, and feel free to call them "private clouds" -- but they will be owned and operated by a few major public providers.

A coouple of weeks ago I had an interesting conversation with Marten Mickos, CEO of Eucalyptus (and of MySQL fame), a private cloud platform provider. I explained that I believe that Internal Private Clouds (i.e., clouds operated on a company's own servers), will become a niche in the long run.

Surprisingly, Marten did not disagree, but he made the following very good point. If we look a few years ahead, let's say 2015, the IaaS market in total will be a roughly $20 billion market according to estimates by IDC and others. If private IaaS is anywhere between 10% to 20% of that, certainly within the bounds of the definition of a "niche", we're still looking at a multi-billion dollar market. Enough to sustain the success of several startups and large vendors.

Point well taken.

The other follow up on this topic is a reference to my friend Nati Shalom's post on the topic. It's a good read with good arguments.

10 Predictions About Cloud Computing

Next week in Tel Aviv I'm going to participate in a panel about "the future of clouds", moderated by the legendary Yossi Vardi. In preperation, I wrote down a few of the concepts I've been thinking about for the past several years and I thought I would share them with my readers to get some feedback. Keep in mind these are long-term predicitions and trends (in no particular order).

1. PaaS Rules :IaaS becomes niche. In the long-run, IaaS doesn't make sense, except for a limited set of scenarios. All IaaS providers want to be PaaS when they grow up.


2. Public Rules: Internal clouds will be niche. In the long-run, Internal Clouds (clouds operated in a company's own data centers, aka "private clouds") don't make sense. The economies of scale, specialization (an aspect of economies of scale, really) and outsourcing benefits of public clouds are so overwhelming that it will not make sense for any one company to operate its own data centers. Sure, there need to be in place many security and isolation measures, and feel free to call them "private clouds" -- but they will be owned and operated by a few major public providers.


3. Specialized Clouds: There are many dimensions to an application: the pattern of its workload; the government regulations it must adhere to; the geographic access to it; the programmig language and framework it supports; the levels of security, performance and reliability it requires; and other more specialized requirements. It's not a one-size-fits-all world. At least, not always. There will be big generic clouds, and then, many specialized clouds. I've written about this in the past.


4. Government Regulation: The largest cloud providers will become nationally strategic infrastructure (like utilities, financials, telcos, airlines and shipping companies in the past). Given my "public rules" prediction above, cloud providers will become crucial infrastructure to the economy and the interests of their respective nations. They will become "too big to fail". Any change in their pricing will have a profound effect on the economy. And they will also hold the risk of a "cloud run" (similar to a "bank run", a sudden surge of demand they haven't anticipated. Not to mention the fact that they will maintain the sensitive data of consumers, corporations and government agencies. Any way you slice it, it spells regulation. But if history teaches us anything, this regulation will only come after "The Great Cloud Catastrophe" (use your imagination to figure out what that will look like). 


5. The Control vs. Freedom Debate: This sums up the story of cloud computing so far. Freedom is the catch-all phrase for drivers of cloud adoption (no upfront costs, on-demand, self-service, empowerment of the rank & file - e.g., developers), but control (or lack thereof) is the catch-all phrase of barriers to adoption by large enterprises. Every democratic country experiences this: there is sometimes a contradiction between the so-called sacred principles of rule-of-law and personal freedom. It's a matter of drawing the line -- and we're just in the beginning stages of understanding this issue when it comes to cloud computing. This debate will be with us for years to come and will shape the variety of enterprise cloud computing offerings.


6. Cloud Federations - While AWS has enjoyed tremendous international success, in any business that relies heavily on trust, such as IT, nothing beats a local brand. So people will flock to the cloud of their trusted national telco or big IT provider. But on the flip side, they will need to reach a global audience and will want servers around the world. As a result, we will see the formation of cloud federations, similar to what we see in airline alliances, such as Star, SkyTeam and Oneworld.


7. Financial Efficiency and Sophistication: Computing is a commodity, and every commodity ends up being traded, future-traded, brokered, arbitraged, speculated and manipulated with derivative instruments. The good: the market becomes very efficient. The bad: the market becomes complex and opaque. We are already seeing spot markets 


8. Cloud Standards: About two years ago there was a strong wave of interest and discussion about the need for cloud standards. I wrote then, and still believe, it is too soon. But it is also inevitable. We will, however, see multiple competing standards. At least one formal stanard specification from a standards body and several de facto standards from large commercial players such as Amazon and VMWare. 


9. The Ecosystem Wars: I've recently written about the importance of ecosystems in cloud computing. Success in building an ecosystem will be a determining factor in who wins and loses in the cloud. It is not just about the size and breadth of the ecosystem, but how well it all works together. In many ways, Amazon has done a poor job of this so far, but it has the one big compelling factor for an ecosystem: a very large install base. 


10. Horizontal and Vertical Consolidation: As with any industry, as cloud computing matures, it will consolidate. This will happen both horizontally, for example large IaaS players will roll-up regional and smaller IaaS and hosting providers, as well as vertically, for example IaaS providers will acquire cloud management system providers such as RightScale and enStratus.

I'd love to hear some feedback on these trends. Do you agree? Disagree? Have I left something out? Please let me know in the comments.

Two Computerworld Articles on Cloud Computing

Yesterday a couple of Computerworld pieces in which I'm quoted came out. They are both authored by Beth Schultz.

The first is about Cloudonomics, or how can enterprises figure out the potential cost-savings and other financial effects of cloud computing. My basic take was that it's difficult to measure the exact financial impact of cloud computing because one of it's major benefits is business agility. See the full story.

The second is about the plethora of Cloud Services available to enterprises and how to choose among them. My take on this one was that it's not a one-size fits all game and organizations will need different tools for different tasks. Read the full story.

Shopping the Cloud: Pricing (or Apples and Oranges in the Cloud)

In Shopping the Cloud: Performance Benchmarks I listed a number of services and reports that compare cloud provider performance results, but the truth is that in computing (cloud included) you can throw money at almost any performance and scale problem. It doesn't make any sense, therefore, to talk about performance alone, you want to compare price/performance.

But here's the rub: it is becoming increasingly difficult to compare the pricing of the various cloud providers.

Problem #1: Cloud providers use non-standard, obfuscated terminology

About a year and a half ago I wrote What Are Amazon EC2 Compute Units? in which I raised the issue of how difficult it is to know what it is you are actually getting for what you are paying in the cloud. Other vendors use their own terminology, such as Heroku's Dynos. I'm not just picking on these two, everyone has their own system.

Problem #2: Cloud providers use wildly varying pricing schemes

In addition, the pricing schemes by the various vendors include different components. Take storage as the simplest example, which clearly illustrates the point. Here's a screenshot from the Rackspace Cloud Files pricing page:

 

It is fairly straightforward, but also contains many elements that are extremely difficult to project (especially for a new application), such as the Bandwidth and Request Pricing. That's OK - you have to make some assumptions. 

But here's my main point -- now compare it to Amazon S3 pricing:

Good luck with that.

Problem #3: Not all cloud offerings are created equal

To make things worse, not all cloud storage services were made equal. They have different features, different SLAs, varying levels of API richness, ease-of-use, compliance and on and on.

Problem #4: Cloud computing pricing is fluctuating rapidly

Another big problem with dealing with pricing is that the market is very dynamic and prices change rapidly. Fortunately, most of the movement right now is downwards, due to the increased competitiveness (especially in the IaaS space) and thanks to vendors benefiting from economies of scale and increased efficiency due to innovation.

Andrew Shafer from CloudScaling wrote a blog post a couple of weeks ago in which he shows how Amazon pricing is constantly shrinking. Check out this graphic he created:

What to do about it?

So what do you do in such a complex landscape? There seems to be no escape from creating a test application and running it on multiple services to see where the cost comes out. Then again, that may turn out to be a very time-consuming and expensive effort that may not be worth it -- at least not initially. So you should be prepared to have to move your app across cloud providers if and when the costs become prohibitive (which I am seeing happening to more and more companies).

Hopefully, the cloud benchmark services will also start paying attention to pricing and provide a comparison of price/performance and not just performance.

APIs and the Growing Influence of Developers

On June 17 I gave a lightning presentation at the Open API Meetup, along with Evan Cooke of Twilio and Oren Teich of Heroku. It was a really nice event, well-organized by Sam Ramji and Shanley Kane of Sonoa/Apigee, and hosted at Twilio's beautiful new digs.

The title of my presentation was "APIs and the Growing Influence of Developers".  The gist of my presentation takes many of the elements I have written and spoken about in the past and puts them together in the context of the meetup's topic like this:

Just as we have seen with B2C, we are increasingly moving towards a "frictionless business model" with B2B products, including those targeting enterprises. This means that as a vendor you are trying to remove any barrier from the customer to acquire and succeed with your product.

To succeed with the frictionless business model, you have to adhere to a couple of principles:

Zero Touch

The idea here is to look at every phase of the customer interaction -- from demand generation, through customer acquisition and product delivery to customer success -- and eliminate touch points which create friction. A zero touch model has several benefits: it removes friction for the prospect/customer, making it easy to buy and use your product, and it also significantly reduces customer acquisition costs (CAC) and operating costs.

In the demand gen phase you want to rely heavily on inbound marketing such as SEO/SEM, social media etc. You're then bringing the prospect to your web site where they should be easily able to self-educate (with short video tutorials, easy documentation, etc.), sign up for a free trial and get up and running with something that provides value within minutes. You also remove barriers by providing flexible pricing (such as pay-as-you-go).

In the last phase, which I'll call "customer success", you want to find ways to provide low-touch/no-touch support, upgrading and up-selling/cross-selling.

There is a lot more to say about this topic and it's probably worth several dedicated blog posts, but you get the idea. I will add that although it sounds fairly obvious, it is not trivial to implement successfully.

Bottom-Up

This principle is less obvious. One of the implications of the frictionless model is that it relies on bottom-up adoption. So you are targeting not the CIO, business executives or central IT, as in the old days of enterprise software sales, but on the rank & file, whether business users, IT ops personnel or developers -- depending on the nature of the product.

With this point, I wanted to establish the fact that developers are becoming increasingly important when marketing your software (something I have written about several times before).

Product Delivery and the Frictionless Model

Given that the meetup was about APIs, I focused my presentation on product delivery. Over the years, software delivery has changed, increasingly removing friction from the process.

We can generally think of three main periods, I'll call them: High-Touch, Open and Cloud.

High-Touch Era

In this "classic enterprise" era, folks at big companies who had an interest in a certain software product couldn't touch that product without talking to a sales rep from the vendor. In addition, pricing was never revealed on the vendor web site and contracts were always one-offs that required prolonged negotiations.

You can easily see how this is a top-down model. It requires the involvement of legal, procurement, management authorizations, budgets, etc., and that's only to run a proof-of-concept.

But the delivery of the software product itself was an extremely high-touch approach. Software vendors "darkened the sky"¹ with professional services folks in an implementation project that would take weeks, months or sometimes years.

Open Era

But slowly, things started to change, especially as the Internet had started to become a mainstream, commercial medium. Some startups, such as WebLogic² (before it was acquired by BEA, before it in turn was acquired by Oracle), started offering B2B software for downloads on their web site. And as they did that, they were targeting developers, not executives. And they had to make it easy for people to help themselves with documentation freely available online (a novel concept then) and with easy access to support via email (another innovation).

I intentionally called it open era and not open source era, because source code was just one element of making B2B software products more easily accessible to developers. but certainly, the open source movement is an important part of this phase.

It is because of the removal of these adoption barriers that developers had access to software like never before. First, they downloaded and played around with it, the started developing with it -- next thing you know it's in a production application. I call this phenomenon "enterprise creep-up"³, and it explains much of the success of open source software such as MySQL and JBoss.

Cloud Era

(Not to be confused with Cloudera) 

Eventually, as both the business thinking evolved and web technology matured, we came to the realization that software doesn't need to be "delivered" at all. Instead, it's provided as a service. With the concepts of Infrastructure-as-a-Service, Platform-as-a-Service and Software-as-a-Service, the idea expanded to raw IT resources, infrastructure software (OS, VMs, middleware, databases, etc.) and applications.

With this phase, almost any friction involving product delivery is removed. The user/customer does not need to download, install, configure and maintain software. There are no issues of OS and hardware versions. There is no hassle in upgrading -- upgrades happen behind the scenes and you benefit from them every time you log in.

This explains the massive success of Amazon Web Services, and particularly EC2. Developers had unfettered access to IT resources, which they could pay for by the drink and expense to their credit cards, without the need for any approvals. They started by kicking the tires, the prototyping, then developing -- next thing you know, there is a production application on the public cloud.

Software Delivery Models in the Cloud Era

So we now have a range of software delivery options, many of which I listed in Software Delivery Models in the Era of Cloud Computing. The list goes something like this:

• Professional Services 
• CDs 
• Downloads 
• Physical Appliances
• Virtual Appliances 
• Images for Internal Cloud 
• Images for External Cloud 
• Add-on/Plugin/Extension
• Software-as-a-Service/Platform-as-a-Service via Client 
• Software-as-a-Service/Platform-as-a-Service via GUI 
• Software-as-a-Service/Platform-as-a-Service via API 

Developers and APIs

As we are moving to a world where software is delivered as a service, if you want developers to use or integrate your service with their applications, the preferred access method is an API (and as other speakers mentioned at the meetup, a RESTful API at that). An API is a programmatic (i.e., automated) way to access the service, and therefore, the most frictionless delivery method of all (at least when it comes to developers).

Tying It All Together

So with all this background out of the way, the point of my talk was quite straightforward: As developers are growing in influence in the purchasing cycle of software, and as we are trying to move to a frictionless business model, and as APIs are the most frictionless approach to deliver your service to developers -- providing an API to your cloud service is critical.

What's your take on this? As a developer? As a vendor? Let me know in the comments.

Footnotes:

Footnote 1 - At the meetup I mentioned that I borrowed the phrase "darken the sky with professional services" from former Sun Microsystems CEO Scot Mcneally, who used to say this about IBM. That phrase always reminds me of the screaming flying monkeys from The Wizard of Oz so I showed the picture below.

Footnote 2 - As I mentioned at the meetup, a few months ago I exchanged some emails about this with my friend Weblogic co-founder Bob Pasker. As a homage to the Weblogic guys I showed a screenshot of their web site circa 1996, which I picked up from Archive.org:

 As a footnote to the footnote, someone on Twitter got excited by the use of Papyrus font!

Footnote 3 - At the meetup I had a slide titled "The Tale of PTB". PTB, or Ponytail Boy, is JBoss founder Marc Fleury's nickname for former Sun Microsystems CEO Jonathan Schwartz (the only Fortune 500 CEO in history with a ponytail). I talked about this blog post from Schwartz that describes the "enterprise creep-up" phenomenon nicely:

I was with a big customer of ours last year, and reading through my account briefing before the meeting, I knew we were doing well. An analysis of their download activity showed they were heavy users of Solaris and OpenSolaris, and they had a large internal community of MySQL users, as well. In the meeting, their CIO said "we love where Solaris is headed." I then asked if we could help with MySQL, and he said... "I banned it."

Not exactly a buying signal.

I was stunned. I asked, "why?" He responded, "Oracle is our global standard, and with 20,000 developers, people need to follow the rules." I said we had a very good relationship with Oracle, and started talking about how fast Oracle runs against our new Open Storage products. Until he interrupted me, "...but my ban failed." What? "We hire lots of people out of college every year, and they all come in knowing MySQL. All my prototypes are written to MySQL, and now I have a big base of MySQL apps I don't want to port, and a bunch of MySQL programmers I don't want to retrain. So I'd like a commercial relationship."

In a nutshell, that's adoption in action. Change in IT isn't just a top down phenomenon - it's more often bottom up*.

Librato: Squeeze More Out of Your Cloud Instances

One of the complaints I've heard from users of public cloud users, and especially of those who use Amazon EC2, is that the instances available are not provided in a wide enough range of sizes and jump from one size to another in steps that are too large.

The problem with this is that the user ends up not utilizing all of the available resources of the machine they are paying for, which is somewhat ironic given that one of the biggest benefits touted for cloud computing is better utilization (as you are supposed to be paying only for what you use).

Librato (Twitter: librato) is a start-up attempting to attack this problem with their newly beta-released Silverline product. I spent some time with Fred van den Bosch (CEO) and John Wernke (VP Marketing) and was impressed.

Once you deploy Silverline (which takes a couple of minutes) on your Amazon instances (or any other instances in internal or external clouds), it "sponges up" unused cycles so that you can run apps that are non-time-sensitive such as analytics apps or various batch processes. And the beauty is that you are doing this on a resource you were paying for anyway.

Check out the video demo below. I'm curious to know what you think of this and what you think could be interesting use cases. They are now offering sign-up to a free beta. 

Please share your thoughts in the comments.

 

Migration to the Cloud: CloudConnect Panel

The excellent CloudConnect conference is coming up in Santa Clara, California, March 15-18. There is a lot of excitement around this event, as the content seems excellent and many people are coming into the Bay Area for this event.

As a matter of fact, the San Francisco Cloud Computing Club is also having a meetup around the event on Tuesday, March 16 at 6:30 pm with many "clouderati" expected to participate. Should be fun.

Back to CloudConnect, on March 16 at 1:30 PM, I'll be participating in a panel moderated by Randy Bias (@randybias), which is part of the Cloud Computing Migration track at the conference. Below are the official details and Randy provides additional background on the CloudScaling blog.

Moving to Clouds: It's Not All or Nothing  - Panel

You're ready to embrace cloud computing. You can move your IT to on-demand public clouds, and reap the benefits of elasticity; or you can create on-premise clouds that make you more agile and efficient while keeping control of data. The only thing you can't afford to do is keep using old-fashioned IT. But when it's time to adopt a cloud strategy, the options can be daunting. Do you need a public cloud? Private? Both? Should you use a platform or an infrastructure cloud? Which applications are candidates for cloud deployment?

In this opening session, you'll learn the differences between public and private clouds, and the factors you need to consider when planning a migration to cloud-based IT.

Moderator Randy Bias, Founder, Cloudscaling

Speaker Ellen Rubin, VP of Products, CloudSwitch

Speaker Geva Perry, Author, Thinking Out Cloud

Speaker Victoria Livschitz, CEO, GridDynamics

Speaker Tom Gregory, CTO, Presidio Health

Cloud Computing as Commodity

My partner in crime on the Overcast podcast, James Urquhart, published a nice blog post today titled: Cloud computing and 'commodity'. Read the post and come back. I'll wait.

Done? OK.

James seems to be responding to what is apparently some kind of controversy, which I don't understand because there is truly nothing new under the sun. Read Clayton Christensen's 300-page book Seeing What's Next and come back. I'll wait.

Done? Good.

All products are in a constant commoditization process always, or a "race to the bottom" as James refers to it. Period. Therefore, in order to maintain differentiation smart vendors continuously innovate and add additional features and "crust" capabilities, which over time will themselves be commoditized. Rinse and repeat. Therefore, in economic theory, all industries are destined to become commodity industries (known as the Industry Lifecycle).

Let's see how this plays out in cloud computing (intentionally simplified greatly to make a point):

• Amazon is first mover with server and storage API provisioning on-demand and pay-per-use pricing
• Everyone and their brother offers the same at similar prices
• Some differentiation in API capabilities is created (could be richness, coverage of corner cases, ease-of-use, features such as auto-scaling, etc.)
• A formal API standard emerges and everyone again offers exactly the same
• Rackspace differentiates with better SLAs (Rackspace: The Avis of Cloud Computing?)
• Everyone matches their SLAs
• VMWare and Microsoft start offering higher-level components moving towards a platform-as-a-service
• Salesforce.com differentiates its PaaS by building a large ecosystem around its platform
• Amazon acquires several start-ups and offers the same...

You get the point.

At some point the market reaches an equilibrium. Meaning that there is no longer room to innovate in that particular product category -- because customers are no longer interested in better, faster, more options, etc. We are many-many years away from that happening in cloud computing in general, although not so far away in the sub-category of infrastructure-as-a-service.

To demonstrate that there is nothing new here, take a look at the Java application server market. In the late-nineties, the product category was created by a small company called Weblogic. Two other competitors emerged: NetDynamics and Kiva. Initially, they each had wildly different capabilities and features, but over time they converged to what the market needed. Then all three were acquired at about the same time (Weblogic by BEA, NetDynamics by Sun and Kiva by Netscape). The two latter acquirers screwed things up and BEA emerged victorious, only to face a new competitor in the form of IBM with WebSphere.

At some point the J2EE standard was introduced and both large players -- IBM and BEA -- complied with it, as well as many other smaller ones. Given that they were all working on the same standard, each of the vendors started adding features that were outside the standard. Many of these features were not needed by customers and so did not really create any differentiation. This opened the perfect opportunity for a low-cost commodity player to come in: Enter Apache Tomcat. The rest is history. There is barely any commercial J2EE app server market anymore (the majority of the revenues are related to services and support, not new licenses). It took about 10 years, maybe 12.

The same process occurred with relational databases and the SQL standard (enter MySQL) and many other product categories.

Here's an even more extreme example from the shipping business as I wrote it in the blog post Beware of Premature Elaboration (of Cloud Standards): 

Consider the case of the shipping container as described in the excellent book The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. Before standardized shipping containers, sending a shipment from, say, Kansas City to Tokyo was extremely expensive and inefficient. There was no way to send the shipment in one container as a whole. Trains used containers of certain shapes and sizes, trucks used different ones and ships used different ones. In fact American ships and trains used different containers from European and Asian ones. Sometimes, even within the U.S. or Europe, different kinds of containers were used. That also meant they were extremely difficult to stack and secure, and the goods being transported had to be moved multiple times to different containers. The effect on international (or even cross-region) shipments was chilling. Furthermore, many companies in the shipping business had to maintain infrastructure and equipment to serve multiple proprietary container specs.

By standardizing on uniform container specifications, the industry removed the barriers to long-distance shipping and greatly increased the demand for it, while reducing their own costs. A boon to everyone involved.

What I didn't mention in that blog post is that those differences in containers were not (always) accidental. They were intentional because the design, material, size, shape of the container was considered a competitive advantage.

Interestingly, today shipping companies freely use each other's containers as they move them around. In fact, there is one big pool of boxes and it doesn't matter who's box you use.

Going back to a different kind of "box" -- the virtual server -- one can easily imagine how one cloud provider, if it requires additional capacity, will use another provider's boxes. And it won't matter one bit because the real value will be in the management and monitoring capabilities and other ancillary services, the internal operational efficiencies of the provider, the SLAs, the level of customer service, the brand and the ecosystem around that provider's offerings.

Also see my Purpose-Driven Cloud series for other differentiators. 

If you want to learn more about these basic industry dynamics, read any of Michael Porter's books that discuss his Five Forces model. Go ahead, I'll wait.

Cloud as Monetization Strategy for Open Source: SpringSource

I came across an interesting post by Savio Rodrigues from IBM. Savio writes about the recent announcement by SpringSource (now a division of VMWare) that they are proposing to move their dm Server product (the OSGi app server) to the Eclipse Public License (EPL). Until now the dm Server was offered with a dual-license model: free in GPL or with a proprietary license for a fee, also known as the "open core" model.

Rodrigues refers to a blog post by The 451 Group analyst Matthew Aslett in which he says that SpringSource is abandoning the GPL license (and therefore the dual license model), because the EPL is more permissive and therefore encourages adoption. Rodrigues then brings up the possibility that the change in licensing is due to a change in business model -- generating revenues for sale of support subscriptions instead of license sales.

But he pretty much ends up dismissing that as the main motivator and then truly hits the nail on the head: the real plan is to monetize this and other SpringSource products with cloud computing offering (presumably some kind of PaaS) -- as this was the original rationale given for the SpringSource acquisition by VMware.

Rodrigues writes:

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 monetization of open source software through cloud is something I've talked and written about before. And we can expect to see a lot more of it. Oh wait, we already are.