The Open Source Business Model is Under Siege

By Paul Dix / Use Cases, Developer
May 12, 2017

A few weeks ago I gave the Day 2 opening keynote at PerconaLive, a conference focused on Open Source Databases. My talk, titled “The Open Source Business Model is Under Siege,” is about the existential threat that Open Source Database companies, or any open source software infrastructure, are facing from cloud vendors like Amazon Web Services, Google Cloud, and Microsoft Azure. The talk is based on my own experience building a business around open source over the last three and a half years with InfluxDB and our other projects. Here’s the video of the talk along with a summary of my points and my thoughts after the reaction from conference attendees. I touch on a few things in the talk that I won’t cover here and have a few incendiary words for some vendors, but you’ll have to watch for that.

The first thing I acknowledge in the talk is that open source isn’t a business model. It’s a way of developing and delivering software. I would argue that it’s a vastly superior method in all facets to closed source development save but one: making money (and with it being able to continue to invest in further development). The development of open source software is always subsidized. Either through programmers’ free time when they’d be doing something else, investor dollars, donations, or some other successful business, like a search advertising business, for example.

The question we must answer as developers attempting to turn open source into a sustainable business is: Where will our subsidy come from? Some of the more common methods are consulting & professional services, support & training, production tooling & monitoring, open core, and Software as a Service (SaaS). Each of these has their problems.

Consulting doesn’t make sense because you end up having many of your consultants working non-billable hours while they write open source software. In a normal consulting company you’d like to have everyone billing hours to clients 90% of the time or more. If you have half of your developers writing open source software instead of billing, the best utilization you can hope for is 50%! You’d be better off starting a consulting practice around some already successful and large open source project. Then you can be the experts and bill hours while only contributing back patch fixes that your customers pay for directly. That’s definitely not ideal since we’d like to find a way to spend the majority of our time writing open source directly.

Support is difficult to sustain because it doesn’t provide a forcing function for people to buy. This was certainly our experience with InfluxData. We offered support for nearly a year before moving to open core, and in that time, we signed up only a few customers. Further, support creates perverse incentives between you and your community and users. Ideally, your software should be easy to use and run in production. You want others in the world to become experts on your project. However, both of those goals make it more difficult to sell support. Finally, the renewal rates on support contracts is abysmal. After a few years, your customers will get a level of expertise and comfort with the project and start to question why they’re paying for support in the first place.

I think production tooling and monitoring is what most open source software vendors over the last 15 years have been holding out as their business model. The problem with this model is that you’re now competing against other monitoring vendors and, more importantly, you’re now competing with the cloud vendors that offer to host your freely available software. Take AWS’ hosting of Elastic for example. They have no commercial relationship, and for customers running ElasticSearch on AWS, they have no reason to buy support or monitoring software from Elastic.

These dynamics led us to go with the open core model last year. That is, we have an open source project at the core and a closed source commercial fork of it that adds more functionality (in our case HA, clustering, and advanced security). A few years ago the concept of open core made me cringe. It goes against what I love about open source software. Free code to do with as you want: build a business, learn, add and modify, and generally advance things without writing everything from scratch yourself. It was a difficult decision and one I still struggle with to this day. The fact that we’ve always developed everything out in the open until this point made it more difficult because it meant we were taking something away from the community that we had worked so hard to develop and embrace.

However, immediately following our decision to go open core, we had inbound commercial interest. People were contacting us and offering to pay for our software. This time last year was critical for us as a company. One of the motivating factors to be more aggressive on the commercial aspect was that I knew we’d have to go raise our series B round of funding within a few months. Put simply, we needed to have a reasonable story for how we would turn this project into a sustainable business that could return an investment. Even though it was a tough call, I’m certain that if we hadn’t made that decision, we wouldn’t be around as a company today and thus not contributing any open source software of any kind.

The last model I haven’t touched on yet is SaaS. I think this is where the future of open source software lies. But the successful SaaS model more closely resembles open core if it is to be successful. Take Databricks or Redis Labs. Both have significant investments in closed source software for their managed SaaS platforms. These represent real moats and hurdles to would-be competitors in the cloud that would take either Spark or Redis and host them.

The cloud vendors’ aim is to make infrastructure software easy. First you didn’t need to worry about servers and network gear. Then you didn’t need to worry about managing your database or a scalable object store. The age of companies running their own infrastructure is in structural decline, just like buildings running their own electricity a hundred years ago. As the cloud vendors mature they’re going more horizontal AND more vertical. They’re targeting infrastructure software of all kinds while rolling out software in verticals like collaboration, analytics, monitoring and countless other areas. And they’re using open source as their building blocks.

This means that companies attempting to build businesses off open source infrastructure software must find new methods for making money. Support and tooling won’t cut it. Consulting isn’t an investible business. Open core and the SaaS flavored version of open core are the only viable options I see here. A more restrictive license is one option, but that doesn’t target the open source ideal: that others can freely modify and use your code without restriction. This kind of free use is exactly what is driving the innovation we’re seeing in cloud and infrastructure software. Twenty years ago, no single vendor could hope to provide all of the services that the current vendors support because of the sheer volume of code and investment required. The open source dream is that we enable others and ourselves to stand on the shoulders of giants to move the state of the art forward.

Don’t get me wrong, I don’t hate the cloud vendors. Quite the contrary, I’ve built exclusively on cloud platforms for the last ten years of my career. Before that time, I was firmly ensconced in the Microsoft camp in the old days when they considered open source a dangerous virus. I’m happy building in the cloud on Open Source Platforms. But given cloud vendors’ large and obvious ambitions, open source developers looking to build a long-term sustainable business must have a clear plan for making money while continuing to invest in open source software.

I see more companies going the open core and SaaS route. InfluxData, Mongo, DataStax, Elastic, Databricks, RedisLabs, Pivotal (Cloud Foundry), Hashicorp, Docker, and many more. Even Confluent, the company behind Kafka, launched their cloud offering earlier this week. It’s where the industry has decided to go. The problem we’ll continue to grapple with is where to draw the line. What should be open source and free and what should be closed and commercial? At Influx we continue to put more than 75% of our development effort into open source software. We invest heavily in open source, and it continues to be a point of pride for myself and the entire company. Last week we launched the first official version of Chronograf, an entirely open source project that is the UI for our entire stack.

After giving the talk I had many people at the conference came up to me. I was quite nervous delivering it because I knew that many in the audience had spent more than a decade building open source projects and companies around them. Many people from different projects said that they had also had the same struggles over the course of their development. I talked to many developers from MySQL, some of whom had been there for 15 years. They said they went through each of these phases and even tried some other crazy ideas that didn’t stick (like selling advertising on docs pages and selling branded gear).

It was great to hear that we’re not the only ones working through these issues. I came away from the conference more energized than ever and bullish on the outlook of open source software, despite the dire click-baity title of my talk. At InfluxData, we’ll continue to invest heavily in open source while making sure that we have a real business model behind the project to ensure its longevity.