For reasons that I will blog about in a couple of weeks, several people last week asked me what I think about open core. My answer was that nowadays I don't care much about the topic. Long time readers of this blog might be surprised at such an answer, so I thought this was a good time to reflect on why I don't think it is very important anymore, and more importantly to document the empirical evindence that we now have about open core as a business strategy.

For historical context, an "open core debate" erupted in June 2010 triggered by a Network World interview of Eucalyptus CEO Mårten Mickos. I participated in that debate rather vigorously: Open Core is not Open Source and Open core is not open source and don't trust someone trying to convice you otherwise. I also already then wrote a post that was much in the spirit of how I think today, titled: So if I don't call myself 'open source vendor', then everything is fine? (yes). There are several other posts still if you browse the Business models tag of this blog.

The major motivation back then to argue against open core was that it was a conscious attempt to dilute the open source brand. Open core vendors wanted to call themselves "open source" to gain a marketing benefit, yet sell closed source (ie open core) products to gain a (perceived?) sales benefit. So my own motivation was never to argue against any particular vendor, just to defend the definition of what open source is. And this issue was settled in 2010, for example several directors of the Open Source Initiative published blog posts denouncing open core. Ultimately the arrival of OpenStack on the scene of cloud software powerfully demonstrated where the hearts and minds of ordinary open source developers lies.

Today most new software is open source. The fact that open core and very few fully closed source vendors continue to exist is in my mind uninteresting. The pro's and con's of an open core strategy are already well established by a historical record, and if some vendor feels like it is beneficial for them to pursue such a strategy, I don't really mind. All I care about is that nobody is trying to confuse end users into believing that their closed source software would still somehow be open source, and I don't see this really happening anymore. For example in the database space we have 150 NoSQL databases and most of them are fully or partially open source. Nobody is claiming the spot of "leading open source database" like MySQL used to do, rather the competition is on various new and innovative features. So whether they then are fully open source or only 99% open source is in my view not that important In the grand scheme of things open source is winning, and within the open source world there is a trend of "more open" winning over "less open". So this battle has been won.

It used to be that open source companies like MySQL and Red Hat were challenging the old establishments of Oracle and Microsoft. Today the old proprietary companies are irrelevant, and instead we have a spectrum of "more open" and "less open" companies. So in a bizarre way, open core companies actually represent a big achievement: they didn't replace open source companies rather they have replaced the old, fully proprietary, software companies. (Update: This paragraph was edited to remove a comedic comparison of Larry Ellison and Mårten Mickos, after reader feedback made it clear it was read in the opposite way of what I was intending to say. The substance of the paragraph remains the same without this comedic intermission.)

Speaking of historical track record, now we get to the main point of this blog post. I wanted to use this opportunity to document what we have learned from businesses trying the open core model from 2006 to today. This way any startup VC may weigh the pros and cons based on historical evidence rather than making it into a religious debate, which was perhaps inevitable in early open core companies like MySQL in 2006-2009. As usual, this is heavy on MySQL facts because I know them well, but also because MySQL was a forerunner both chronologically and in terms of financial success.

The Pro

It's too obvious to be interesting, but for completeness we must of course acknowledge that there is a reason companies want to try open core as a business strategy. In a sales situation it is easier to make a sale if the customer will get something exclusive, that is not available for free. Selling support is one such thing, but it is true it only gets you as far. Selling proprietary software is an easy way out of that problem - you might think.

This point is not lost on me. Once when selling MySQL a customer was quite open about it, saying: "Look, we are happy to pay for support and thus support the development of MySQL that we love. But our managers demand that if we are paying, we need to get something exclusive, that is only available to customers. Preferably something with a nice and shiny user interface.

I'm not joking, it is a literal quote, including the last sentence. As a sales engineer I was then lucky I could pull out of my hat a product that was both exclusive and had a nice and shiny user interface!

Ok, we will now embark on documenting a long list of con's. I mean "risks", if we were to use business jargon...

Single vendor approach limits community engagement and goodwill

Note that this risk is not limited to the open core business model, rather any IPR centric, single vendor developed product. This certainly materialized in the case of MySQL, and indeed was the case already before the introduction of the open core business model in 2006.

My personal observation is that the problem is in organizational inertia: The companies suffering from this problem were never interested in developing a strong open source community around them in the first place. Product roadmaps and project plans are internal to the company, where engineering staff executes on the plan, using internal mailing lists and chat rooms (or physical offices, where applicable) for communication. Now and then an odd outsider may still be able to produce a useful patch (despite the lack of help from the lead engineers) and tries to contribute it to the upstream codebase. Often these were completely ignored - there simply wasn't anyone in the organization with responsibility to respond to such outsiders as all engineers had been assigned their own tasks to work on internally.

While organizational inertia is by nature unintentional, we should note that there might even be a perceived incentive for such an open source vendor to specifically not encourage outside developers to work on their code base, as it might be seen as an advantage that the vendor is in control of all of the product development by way of employing everyone that is working on the code base. Longer term, this is probably a counterproductive view as outside engagement will happen anyway if the product is successful.

Originally it seems to me outsiders were still relatively willing to engage and contribute to single vendor developed open source products, and the obstacles were really on the part of the vendor. Today, much thanks to the widespread practice of the open core model, there seems to be more distrust towards vendors centralizing IPR ownership. Even if the product would be fully open source today (like Canonical, say) you never know what will happen tomorrow. Hence there is now a relatively strong reluctance to contribute to and engage with such single vendor projects with centralized IPR ownership at all.

No single vendor project has ever grown really big

This is kind of the same point as the previous one, except the evidence if more of statistical nature than just personal experience.

I wrote about this in 2010 and even presented it at Oscon in 2011 in a study titled How to grow your open source project 10x and revenues 5x. It's a fact that no single vendor project has ever been able to attract the same amount of R&D investment, nor sales that is the case for a group of open source projects that are all governed by non-profit foundations: Linux, Apache, Mozilla, KDE, Gnome, Eclipse, Drupal, GNU and CPAN. Since the publication of that study also OpenStack and CloudStack as well as the Hadoop ecosystem have solidified this proof to the extent I personally now believe it is a law of nature that an open source project cannot grow beyond a certain limit if it is governed by a single vendor.

At the same time it is worth noting that this is not relevant to all (or in a long tail sense: most) open source projects. For a 10 person startup it is completely irrelevant to discuss how to nurture an R&D effort of over a thousand developers, nor is there a multi-billion dollar market to capture (at least not yet, and for some never).

For example, I recently worked together with a small company that develops Galera replication for MySQL. By this stage the Galera replication library is already quite mature in terms of feature completeness. It is a small library and what it does is certainly not trivial, it is not something that requires thousands of developers, it will likely always do fine with just 3-5 developers on the core library. At the same time, if the MariaDB team ever gets their foundation going, that could be very prosperous to the whole MariaDB community, including to Galera and everyone else that is a part of that ecosystem. So it is a matter of perspective and chosen strategy: sometimes you are a part of a large community rather than trying to create your own. (For clarity: note that Galera is in fact 100% open source and not open core, however it is still a single vendor developed product.)

The statistical evidence suggest that this limit is somewhere above 100MUSD annual revenue and 100-200 full time developers. The large foundation governed projects otoh amass thousands of developers and serve markets with billions in annual revenue.

Open core invites and even funds competition

For an open source vendor it is only a matter of time that some smaller competitors will emerge. After all, as the software is open source, anyone is free to offer commercial support around it.

For MySQL it seems the first serious competition emerged in 2006 with Percona and Proven Scaling in the Silicon Valley area, and Open Query in 2007. SkySQL was founded in 2010 as a direct reaction to Oracle's acquisition of MySQL. Today Percona and SkySQL are global vendors competing with Oracle MySQL, with Percona remaining larger and growing faster (AFAICT). All of the mentioned competitors came to publish their own forks of MySQL (Percona Server, Dorsal Source, OurDelta and MariaDB).

While 2006 was also the year that MySQL first introduced closed source software related to the open core business model, I'm not aware that any of these companies were founded as a counter reaction to that. However, over time especially Percona has become known for duplicating the feature set of MySQL closed source features in products like XtraBackup or Percona Toolkit and several monitoring templates, which originally have been funded directly by Percona's customers. This essentially has provided Percona with an important revenue stream while building the company - Percona never took VC funding. Also, all of these forks took upon themselves to serve the demand of integrating so called "community patches" that - as documented in the previous point - MySQL AB was too slow to receive upstream.

Hence, while we cannot directly attribute the birth of any of these companies to the open core strategy of MySQL (well, MariaDB and then SkySQL to some extent were motivated directly by that) the closed source MySQL software bits certainly provided a good marketing and revenue opportunity for these companies to grow into. By reading old blog posts by the entrepreneurs in question, it is easy to verify they all were vocal critics of some of MySQL AB's practices, and clearly some of their early customers (and still today) have been motivated by choosing a "more open" alternative. Also the poor handling of community patches by MySQL AB created an opportunity for competing forks to satisfy demand. Over time these products also offer other strategic advantages to their creators that are discussed separately below.

I do not have first hand information of the size of the MySQL market in 2006, but it will have been still below 50 MUSD / year. This is probably an imporant figure. I assume it is natural for an open source company to experience competition from small and organically growing consulting companies as soon as the market is large enough to be attractive.

Hence the conclusion is that emergence of competitors is a natural phenomenon, however the increasing closedness of MySQL AB did provide a fertile growing ground, or perhaps an easy "attack vector" for its competitors.

Increasing amount of customers strategically reject closed source software

While open core exists due to those customers that feel they should get "something exclusive" for what they are paying, it is also true that an increasing number of companies strategically reject usage of closed source software (or are at least very, very reluctant to use any). This has all the time been the case with many Silicon Valley web companies like Google, Facebook and Twitter who are happy to even build infrastructure software themselves, as long as they don't become dependent on a piece of proprietary software from a vendor.

Some years ago I was involved in doing a study of a large European corporation that provides many web services but is much more a traditional corporation that Google and Facebook. Guess what, their entire software stack was 100% open source. The only exceptions were a) in the database layer a few Oracle RAC and Microsoft SQL Server's remained, and they did use some industry specific specialist software. Apart from that, everything else was Tomcat, Apache httpd, Memcached, RabbitMQ, Zabbix, Django, Drupal, MySQL, PostgreSQL, MongoDB... You name it, if it's open source, they probably have it somewhere.

Understanding this trend is important because it is the opportunity capitalized by the competition as explained in the previous point. For some of them staying with open source is a clear strategic decision, for others it may just be a series of tactical decisions due to the fact that for a large enough customer funding the development of an open source Zabbix/Nagiod/Ganglia/Cacti plugin by Percona is in any case cheaper than paying even just a single year of Oracle's MySQL Enterprise Monitor subscription.

Finally of course many open source fans will choose the "more open" vendor purely to support open source ideals - a fact that many managers at open source vendors still don't seem willing to accept.

You fall in love with the closed source bits and they become a liability

Finally the ultimate outcome of the open core strategy can already be seen in the MySQL ecosystem.

First Percona was able to grow partially thanks to the revenue stream of large MySQL users funding them to develop XtraBackup, as an open source replacement to InnoDB Hotbackup, the closed source tool that does the same thing. For several years InnoDB Hotbackup did not have any competition, and MySQL sales loved it. Any serious database customer of course needs to take backups and are willing to pay for it. However, as XtraBackup is open source, it of course has taken the spot as the ubiqutious default backup tool that any MySQL DBA is now using - a position an exclusive closed source tool of course can never achieve.

In this situation however Oracle, the vendor of InnoDB Hotbackup, is slow to react to this change in competitive landscape. Since selling the closed source InnoDB Hotbackup has been such a success, it is hard for anyone to argue the business case that it would be more important to offer it as open source. Essentially, what was once a strategic differentior is now a commodity, but due to the existing revenue stream it is impossible for Oracle to accept this fact and take appropriate action.

The ultimate outcome of the open core strategy therefore is that today Percona's backup tool is ubiqutious among MySQL users while Oracle's is not. This becomes a liability when these vendors are competing to sell a support contract: Oracle will stubbornly refuse to support a technology from a competitor, while a Percona support contract will cover the backup technology most DBAs are using. Hence the MySQL user cannot buy Oracle's support if they want their backup tool to be covered. What was once a strategic differentiator has become a liability.

Your own employees feel misled by you as employer

A very common root cause for a lot of the criticism against open core at MySQL was personal. Many developers joined the company happy to have landed a job in the leading open source company at the time. Maybe they even chose MySQL AB over some better paid but less meaningful job at a proprietary software company. Quite naturally such developers were rather dissatisfied when they realized after the fact that none of the code they personally wrote would ever be open source. A lot of the games and politics experienced in the MySQL world can probably be attributed to - or were at leasted fueled by - this problem alone.

This was also the case for me, as I joined MySQL in 2008, ie 2 years after the introduction of the open core business model, yet the day I signed my contract I was completely unaware that my task was to sell closed source software. In practice I would mostly sell to the dual-licensing kind of customers, which were not using or given access to the closed source bits at all, so most of the time it didn't cause a moral dilemma to myself, but I certainly understand the widespread confusion and disappointment in the company.

The way to avoid this risk from materializing should be obvious: Be open about what you are doing, at least - for gods sake - when recruiting!

Thinking about it now, MySQL didn't handle this very well. It shouldn't have been possible for us to be recruited that way. Arguments in favor of open core usually came in two forms. A literal quote from an account manager "those developers just want to be nice and give away everything for free, yet I'm the one putting bread on their tables too" (ie the "stop whining" argument). The better managers would perhaps try to come up with some less arrogant and more constructive arguments, for example Mårten's "with selling closed source software we are able to fund development of more GPL software too" (ie "the end justifies the means" argument). While the latter is still a weak argument from an ethical point of view (which is the point of view held by the disappointed developer-employee), I've come to appreciate it's at least short-term a factually true statement.

Losing to a more open competitor

The ultimate showdown between proponents of the open core business strategy and a more pure open source approach didn't happen in MySQL land, rather between the two cloud implementations Eucalyptus and OpenStack. In a nice twist of history though, it did involve some of the same players with former MySQL CEO Mårten Mickos at the helm of Eucalyptus and OpenStack founder Rackspace employing several of the more fanatical open source advocates that were previous MySQL and Drizzle developers.

Basically, the lesson here is that you don't want to repeat the mistake of Eucalyptus. Cloud is one of the biggest disruptions in IT ever, and Eucalyptus had several years of a "first mover advantage" into the private cloud business ignored by Amazon. (I'm ignoring VMWare here as a cloud vendor they are somewhat "retrofitted" and also they are not open source.) OpenStack was explicitly born as a counter reaction to Eucalyptus pursuing a single vendor strategy and in 2-3 years completely overtook the leadership position. For example studies from QyJohn document the shift in developer engagement and the choices of Ubuntu and Red Hat to side with OpenStack are also significant.

What happened to Eucalyptus is a direct consequence of the "law of nature" I referenced above, that single vendor open source projects never grow above a certain limit (about 100MUSD and about 100 developers). While it is understandable that a small and fast growing startup might feel that an open core strategy is the best way to rapidly capture the potential in front of them, the lesson here is that if the potential is really big, open core is the wrong strategy.

By 2010 Eucalyptus had raised (correct me if I'm wrong) somewhere above 30MUSD of funding. It must have been exciting to think that HP, Dell, Rackspace, NASA, Red Hat and IBM were each looking into investing hundreds of millions into building their own clouds. Imagine that Eucalyptus could get all of that money! The imbalance in these numbers should have set off an alarm: dream on baby, it ain't gonna happen, ever!

I don't know if Eucalyptus is still doing well, I assume the cloud market is big enough for many to succeed. But they lost the market leader position purely to choosing a strategy that was the wrong fit for such a big opportunity. I'm willing to predict nobody will ever succeed in what Eucalytpus failed with, because it goes against a law of nature.