Gartner Blog Network

OpenStack, community, and commercialization

by Lydia Leong  |  August 15, 2011  |  7 Comments

I wrote, the other day, about Citrix buying, and I realized I forgot to make an important point about OpenStack versus the various commercial vendors vying for the cloud-building market; it’s worthy of a post on its own.

OpenStack is designed by the community, which is to say that it’s largely designed by committee, with some leadership that represents, at least in theory, the interests of the community and has some kind of coherent plan in mind. It is implemented by the community, which means that people who want to contribute simply do so. If you want something in OpenStack, you can write it and hope that your patches are included, but there’s no guarantee. If the community decides something should be included in OpenStack, they need some committers to agree to actually write it, and hope that they implement it well and do it in some kind of reasonable timeframe.

This is not the way that one normally deals with software vendors, of course. If you’re a potentially large customer and you’d like to use Product X but it doesn’t contain Feature Y that’s really important to you, you can normally say to the vendor, “I will buy X if you had Y within Z timeframe,” and you can even write that into your contract (usually witholding payment and/or preventing the vendor from recognizing the revenue until they do it).

But if you’re a potentially large customer that would happily adopt OpenStack if it just had Feature Y, you have miminal recourse. You probably don’t actually want to write Feature Y yourself, and even if you did, you would have no guarantee that you wouldn’t be maintaining a fork of the code; ditto if you paid some commercial entity (like one of the various ventures that do OpenStack consulting). You could try getting Feature Y through the community process, but that doesn’t really operate on the timeframe of business, nor have any guarantees that it’ll be successful, and also requires you to engage with the community in a way that you may have no interest in doing. And even if you do get it into the general design, you have no control over implementation timeframe. So that’s not really doable for a business that would like to work with a schedule.

There are a growing number of OpenStack startups that aim to offer commercial distributions with proprietary features on top of the community OpenStack core, including Nebula and Piston (by Chris Kemp and Joshua McKenty, respectively, and funded by Kleiner Perkins and Hummer Winblad, respectively, two VCs who usually don’t make dumb bets). Commercial entities, of course, can deal with this “I need to respond to customer needs more promptly than the open source community can manage” requirement.

There are many, many entitities, globally, telling us that they want to offer a commercial OpenStack distribution. Most of these are not significant forks per se (although some plan to fork entirely), but rather plans to pick a particular version of the open source codebase and work from there, in order to try to achieve code stability as well as add whatever proprietary features are their secret source. Over time, that can easily accrete into a fork, especially because the proprietary stuff can very easily clash with whatever becomes part of OpenStack’s own core, given how early OpenStack is in its evolution.

Importantly, OpenStack flavors are probably not going to be like Linux distributions. Linux distributions differ mostly in which package manager they use, what packages are installed by default, and the desktop environment config out of the box — almost cosmetic differences, although there can be non-cosmetic ones (such as when things like virtualization technologies were supported). Successful OpenStack commercial ventures need to provide significant value-add and complete solutions, which, especially in the near term when OpenStack is still a fledgling immature project, will result in a fragmentation of what features can be expected out of a cloud running OpenStack, and possibly significant differences in the implementation of critical underlying functionality.

I predict most service providers will pick commercial software, whether in the form of VMware,, or some commercial distribution of OpenStack. Ditto most businesses making use of cloud stack software to do something significant. But the commercial landscape of OpenStack may turn out to be confusing and crowded.

Additional Resources

Category: industry  

Tags: citrix  cloud  open-source  openstack  

Lydia Leong
VP Distinguished Analyst
16 years at Gartner
23 years IT industry

Lydia Leong covers cloud computing and infrastructure strategies, along with a broad range of topics related to the transformation of IT organizations, data centers, and technology providers.Read Full Bio

Thoughts on OpenStack, community, and commercialization

  1. Dave Lane says:

    Hello Lydia,

    I think it’s worth pointing out that open source is not distinct from commercial software. You mention “commercial” as if it and “open source” are opposites ends of the software spectrum.

    Many businesses (including mine) are commercial open source businesses. Rather than “commercial” you mean “proprietary” (that’s what we in the open source business world use to describe non-open source software).

    I think your characterisation of OpenStack as leading to a “confusing and crowded” commercial landscape is quite capricious, and the implication that “commercial requirements” for timeliness and milestones are not possible with open source (but are reliably achieved by proprietary developers) is also an unjustifiable generalisation:

    I know of many open source projects (Mozilla Firefox leaps to mind as does Ubuntu Linux) that have well defined road maps and routinely meet commercial release dates, as well as many proprietary software companies who have ill-defined road maps and routinely miss deadlines and dashed market expectations (Microsoft leaps to mind).

    As always, there’re a wide variety of entities engaged in either/both proprietary and commercial open source software development, and it’s impossible to generalise the commercial credibility of either camp.

  2. Lydia Leong says:

    Note that I draw distinctions in my post between commercial distributions and proprietary extensions; I’m not confused about the distinction between commercial open-source vendors, open source, and proprietary software.

    The issue with OpenStack is that you have a general community core, and then what looks to be a splinter of a good dozen or more commercial distributions, to judge by the number of vendor conversations that I’m having. It’s not about commercial *credibility*; it’s about the landscape that is created, as well as a customer’s ability to get the features he needs without ending up splintering OpenStack so broadly that the differences between the distributions become problematic.

  3. Dave Lane says:

    Thanks for your clarification, Lydia, your meaning was certainly not clear to me upon reading the article.

    Regarding the “splintering”, the open source way in which to handle that is, for any given commercial entity who has a customer needing a divergence, to have that vendor fund the development of the divergent behaviour and contribute it back to the project. The mainstream project can then choose to incorporate or not (in my experience, if a contribution is of sufficiently high technical quality, it will be incorporated, and made an option if it’s not a general improvement), thus normally elevating the capability of OpenStack for all interested commercial vendors. That’s how the Linux kernel (among other FOSS projects) works.

    Of course, if companies create proprietary extensions, then they’re inevitably creating a rod for their own backs, and, more importantly, a liability for their customers.

    For what it’s worth, large proprietary developers (with development partners and sales channels) have *exactly* the same challenges, but these are mostly hidden from market scrutiny behind corporate doors and NDAs.

  4. Greg Knieriemen says:

    What a ridiculous article. The open community approach is not better or worse than a proprietary approach.

    Your assumption that proprietary vendors would instantly leap at feature enhancements for the sake of a single sale is absolutely wrong. It happens, but not often. I could give you any number of examples where proprietary vendors would not add “Feature Y” because it would create competitive vulnerabilities. Feature enhancements typically come about from a number of large customers demanding an enhancement and it’s not always a quick process.

    Also, revenue recognition is typically not the driver for feature enhancements. Anyone in sales management with a publicly traded vendor will tell you that a sale contingent on a feature enhancement is practically useless to them and they almost always run from such stipulations. 10 years ago, before Sarbanes-Oxley, you could get away with it and your assumptions would be right. If a vendor can’t recognize revenue that quarter, the sale doesn’t exist and the motivation for feature enhancements gets thrown in an engineering ‘to do’ list.

  5. Lydia Leong says:

    Note that I am not generalizing about open source, commercial or otherwise, and proprietary software. I am talking about OpenStack in particular and the competition for the “cloud stack” market, and I am not talking about theory, for the most part — I am talking about actual observed behavior from both vendors and customers.

    VMware aside (which has been prompt at responding to server provider requests, by and large, without contractual incentive), most cloud stack vendors are tiny software companies that, like many tiny software start-ups, can and do promise feature enhancements to customers either as a handshake agreement or as a contractual obligation. (Revenue recognition is still important to these guys, however, because they generally have to meet targets for their investors.)

  6. Ben Kepes says:

    Lydia – I wasn’t going to chime in, but I will. Mainly because I’m not a hand waving opensource guy and so my views won’t be seen as the mere rantings of some sandal wearing long haired freak (and BTW, Dave Lane who I know and respect has shortish hair, doesn’t wear sandals more regularly than the rest of us and is anything but a freak).

    Anyway – I have to concur with Dave here the entire concept with OSS is that this “splintering” that you hold up as being detrimental to all is in fact a fantastic opportunity to offer the very best bits of independently created functionality back to the community – it’s the essence of “from all according to their ability, to all according to their need” without the hammer and sickle flags everywhere.

    I also agree with a couple of points that others have made – there seems to be some kind of utopian vision where proprietary vendors meets customers needs at the drop of a hat – last time I looked this wasn’t exactly a common experience but what does happen is that customers choosing a FOSS product have the ability to obtain feature enhancements on their own back and contribute them back to the community…

    Judging by the response to this post on various channels it has certainly touched a nerve – as I say I’m not uptight one way or another about FOSS but it just seems to me that what you suggest as a problem for OpenStack is potentially an opportunity…

    But that’s just my 2 cents (oh and for the sake of full disclosure I’m doing some cloud education work sponsored by Rackspace, but that’s not altering my view at all, hell, just want organizations to be able to achieve the outcomes they need)…

  7. Lydia Leong says:

    I’m deeply pro-open-source, myself, but I also think that just like commercial software, all OSS strategies are not created equal. Every bit of OSS that enters the marketplace faces a unique set of dynamics, and of course those dynamics will change over its lifespan.

    In writing these posts, I intended to discuss just the circumstances of OpenStack in particular; it was not intended in any way to be a generalization to other OSS or to other proprietary software in general. I absolutely agree that there’s no utopia of responsiveness in commercial vendors, but I also know, from direct service provider commentary, that the cloud stack vendors *have* been doing what has been necessary to get a sale. VMware excepted, most of those vendors are sub-$5m, and many of them are sub-$2m. Every sale counts, and if it means realigning the stars to make the sale, that’s what they’re doing right now. The nascent stage of the market makes this unique right now, particularly when you couple it with OpenStack’s still-embryonic state.

    What concerns me (and others at Gartner who are watching OpenStack) is the vendor conversations we’re having around OpenStack distributions — the nature of the forks, the nature of the extensions, what will and won’t be contributed back, fundamental disagreements about how some core functionality should be implemented, etc. It makes us concerned that there will be such differences in OpenStack flavors that it will be material for third-party tools support, for instance, as well as the functionality that one can commonly expect from OpenStack clouds, which is important for hybrid clouds.

    I’m not ragging on the OpenStack project. I believe that it’s the most likely long-term alternative to a VMworld universe. But I also think that there are things that could certainly hurt the project’s long-term success — things that are not being said in public, from a wide array of vendors around the globe, whose current contribution levels to OpenStack vary widely, from organizations are actively committing major blocks of code, to organizations who are doing active major development but are not currently contributing anythign back at all. Being an analyst sometimes results in the ability to have a unique behind-the-curtain perspective, and I think this is one of those times when what I’m hearing under NDA, in aggregate, is important.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.