John Mark Walker is the Open Source Ecosystems Manager at Red Hat.
This is the second article in a series all about open source business models, specifically around open source platforms. Before I go any further, I need to make two disclaimers:
-
I work for Red Hat, but the opinions expressed in these articles are mine alone and not those of my employer. There are literally hundreds of talented people at Red Hat who work in product management. I am not one of them. The insights in this series are gleaned from many experiences I’ve had over the last 16 years working with a wide variety of products, projects, communities, companies, developers and end users.
-
In the previous article, I dove into a discussion about open source platforms without actually defining what they are. I will remedy that now.
What is a Platform?
Platforms are tricky things. Lots of companies aspire to create a world-beating software platform, and it’s easy to see why – a platform implies something that supports lots of other things that stand on top of it. Take away the platform, and the whole house of cards falls flat. At least, that’s what lots of software vendors want you to think, hence the rush to describe their products as “platforms.”
In software, a platform isn’t necessarily something that holds other things up. To oversimplify a bit, it’s something that connects multiple pieces together with some type of logic and rules. These pieces are usually described as being “above” or “below” the platform, with “above” denoting software components that are closer to a human interface and “below” being software components further away from human interaction (and closer to the hardware interfaces). Other descriptions include “northbound” vs. “southbound” or “up the stack” vs. “down the stack.” See below for a hopefully helpful diagram:
Lots of things could fill the platform box, above, including the Linux kernel and Linux-based distributions, to name just two. I have a theory: the more components that need to be managed by a platform without human intervention, the more likely that platform is to be open source. The corollary would be: the more a platform requires human interaction, the less likely it is to be open source. I believe this is why WYSIWYG tools are more likely to be proprietary, whereas core infrastructure software, such as many of the tools that make up cloud computing services, are open source. This will help inform much of the discussion that follows.
Now that we understand a bit more about platforms, let’s continue with some analysis of various open source approaches taken by software vendors.
The Open Core Approach
As mentioned in the previous article, “Open Core” is basically a proprietary approach with some open source software thrown in for sales and marketing lead generation. Now I will add some more detailed analysis about this approach.
Many venture-funded startups with enterprise software product ambitions are directed away from the pure open source approach almost from the beginning, as soon as they start to take seed capital and certainly by the time they take an “A” or “B” round. The idea is simple: if you have software that can be loosely construed as a “platform”, you should, in order to maximize your revenue stream, give away the platform and make money on proprietary additions to the platform. With ubiquitous platform adoption comes the ability to capitalize on the sales of add-ons, apps, plugins, extensions and even vertical market products based on the open source platform. It *sounds* simple enough and certainly less scary than the prospect of selling pure open source code that can be obtained for free. There are several advantages and disadvantages to this approach. First, the positives.
Open Core: Advantages
The most important aspect to an open core approach, for better or worse, is control of the platform ecosystem. In this model, the open source platform becomes a freemium loss leader for the other products sold around it. This entices the company that created it to keep it tightly constrained. With constraints comes almost total control over the open source community and ecosystem that spring up around it. This means that almost all core engineers will work for the vendor responsible for the platform. Consequently, the application ecosystem around the platform will consist almost entirely of the efforts of the platform vendor. This means that this vendor can control a near monopoly of the revenue derived from this ecosystem.
The goal in this scenario is pretty straightforward: create a large enough user and developer base around the platform, and a vendor can lay claim to a large potential customer base, at which point it’s the vendor’s job to convert some percentage of them into paying customers. The bottom line is that an open core approach is a siren song to investors and entrepreneurs, luring them with its promises of revenue and world domination.
Open Core: Disadvantages
There is a flipside to this quest for total control, and it comes at the expense of the advantages normally conferred from an open source development model. By controlling all the developers and consequently almost the entire ecosystem, there is a strong tendency towards creating a crippled open source platform. The goal becomes creating a ubiquitous platform that’s good enough to spread far and wide to millions of users and developers, but not so good that it encourages them not to buy the “real” product. As a result, there’s a constant tug-of-war between opposing factions within the vendor as to what should be part of the proprietary applications and what crumbs to leave for the “freeloaders”. Various factions win out depending on how well the revenue is looking for a given quarter or fiscal year. There’s also a tendency, in this quest for control, to want to own the copyright of all code so that it can be licensed commercially and sold as part of a product. Thus, anyone who wants to contribute to the project must ordinarily assign copyright to the vendor, further limiting the potential contributor base.
In the end, an open core platform is functionally the same as a proprietary freemium upsell model, with very modest benefits from the open source project: very few contributions, almost none to the core code base, and only participation on the fringes. In fact, the approach is so limiting on the open source side of the house, that one wonders why the vendor bothered to open source any code at all. With a diminished upside for the open source code comes a diminished number of potential customers, resulting in diminishing potential revenue. In fact, the open core model seems like a way to guarantee that the resulting product will be limited in scope.
Open core was all the rage in the mid-2000s, when several software vendors were able to score millions of dollars in venture funding with that strategy. What happened next was not pretty: many failed spectacularly, some limped along for years, and a very lucky few were acquired. There has, to date, never been a successful open core company. That is, none have ever reached profitability with their own products.
Above-mentioned limitations also served to limit the adoption of the open source pieces, severely restricting their influence to only a very few number of projects and products. Even in those projects that did have a significant influence, ie. MySQL, they were bailed out by spectacular acquisitions. While they were likely never destined to be profitable, they were valuable to their suitors because of their large user bases. In those cases, the respective startups were much better about pushing a fully-functional free version but still found capitalizing on products derived from them to be a difficult task.
The primary problem with open core is that, in addition to being very difficult to capitalize on, it left a bad taste in the mouth of investors, leading them to conclude that this open source thing isn’t very profitable. Indeed, the number of funded pure open source software vendors has declined in recent years, and the takeaway from the investor and even the entrepreneur community is that “open source doesn’t pay.” The result is that whenever a company shows up with an open source product, they are immediately pushed into the open core model, even with its history of failure, or a hybrid approach, which I’ll describe in detail in the next section. The fundamental question to the open core approach is thus: Even with a highly successful open source “core”, is there a means to drive enough revenue from the derivative product to sustain the growth of a company? The answer, thus far, is “no”.
A Hybrid Approach
In the wake of the open core failures, the next generation of open source software vendors took a slightly different approach that attempts to combine the best of the open source and proprietary worlds. Instead of creating a severely limited (and probably unsuccessful) open core platform, the newer open source software vendors have been much smarter: create proprietary products based on collaboratively-developed open source platforms. This approach carries several advantages over open core. Instead of working so hard to spread a limited platform not usable by most people, take a successful open source platform and build applications, services or management on top of that. These applications can be proprietary, open source or even open core, but the platform from which they derive their relevance is fully open source and open to all collaborators. This approach is popular with many companies that have built tooling around various pieces of the Apache Hadoop and OpenStack ecosystems. At the center of this approach is an open source platform that is produced in a truly collaborative sense, open to all comers and, most importantly, nurtures the seeds of innovation that come from a variety of sources.
There are quite a few companies currently attempting to create products around these and other ecosystems, and time will tell which of them will be successful. There are open questions as to whether a proprietary product, even one built on top of an open source ecosystem of projects, can, much like its open core cousin, be successful enough to sustain a growing company. The early results suggest that it’s quite challenging, although it’s too early yet to say one way or the other. There are certainly benefits from such an approach, but subject to some of the same limitations as open core. The final results are not in, but we have yet to see a company fully succeed on its own, without acquisition, and turning a profit that sustains growth over time. I suspect that the difficulties of the open core approach will rear their ugly heads here, too. If the open source platform is given away for free, are all derived products seen as limited offerings that don’t offer enough value to command high revenue from customers? I don’t know yet, but I have doubts about the approach.
The beauty of the hybrid approach is that the base open source platform is not limited in scope and can build a strong community identity. The downside is that it is not yet clear if simply adding management or other pluggable pieces on top of an open source platform is enough to create a product for which a vendor can charge significant revenue. The exception to this is if the open source pieces utilized do not define (limit?) the product being sold and are themselves small components that plug into a larger whole. In fact, this describes the vast majority of successful proprietary products sold by vendors today: they all incorporate open source components to some extent.
Open Source Platforms have Value
My biggest problem with the open core and hybrid models described above is that they both assume there is no intrinsic value in the platform itself. (Pay attention! This is probably the key to the entire series of articles.) In both the open core and hybrid models described above, it is assumed that no one will buy the platform and that all product value stems from the additional applications, whether proprietary or open source, that the vendors have created and applied to the platform. In other words, these two models assume that open source software is composed only of commodity bits that no one will pay for; that anything open source is not something worth spending money on. I believe that assumption is false.
Will customers pay for an open source platform without proprietary applications or tooling? Everyone who invested in or started an open core or hybrid application company seems to think not, but let’s consider the evidence. If open core and hybrid approaches have never actually delivered an outright success story, does it not lead one to believe that perhaps both approaches are lacking? If that is true, and if open source is truly at the center of data center technology innovation, which I believe it is, what does that leave? I am not discounting the added value of proprietary software on top of open source platforms; I am suggesting that the open source platforms themselves are inherently valuable and can be sold as products in their own right, if done correctly. More details on that in the next installment!
Read part one: How to Make Money from Open Source Platforms
Read part three: Creating a Product
