Over the last couple of weeks, many open-source luminaries have written about open-source business models in response to Redis Labs’ modification of their license terms for some Redis Modules. Most of these blog posts dissect one thing: how does one create a business around open source? I actually think that this question, framed as it is, is kind of absurd. It sounds to me a lot like “how do we make money off the horses which have already fled the barn through the doors we left open?” Starting a company off on the wrong foot by giving away all of your valuable IP – and then figuring out how to build commercial products on top of whatever scraps of value remain – is silly. Many such conversations – led by technologists — start first with open-source zealotry and reverse into a business model which is the wrong way to do things. Instead, if you’re considering building a company based around an open-source foundation, first design the business model, and then contemplate how open sourcing certain pieces can serve as an accelerant to that business. If you can’t find an accelerant, maybe your business shouldn’t be based on your IP being open source.
As many blog posts have pointed out, the days of some open-source project emerging from a programmer’s basement and becoming wildly successful are nearly over. Today’s open-source projects are often seeded by large corporations (many of them being cloud providers), or existing companies that have the wherewithal to incubate a project for years before releasing it as a fully-formed open-source project replete with community managers, developer advocates, a marketing budget, a beautiful website, and everything else that practically ensures that as long as the technology isn’t total trash, there will be adoption somewhere. In fact, much of the product and customer development to get to product-market fit has probably been done while the incubating project was not open source.
So why the rush to open source? Sometimes it is mere dogma or philosophy. The project lead, CTO or co-founder strongly believes in Eric S. Raymond’s writings or has some other philosophical bias towards open source. Sometimes, the company has no idea what value there is in the technology and instead of figuring that out, gives away significant IP only to have seller’s remorse about it (hello, Google and Kubernetes). And sometimes it’s purely an “underpants gnome” problem, where company executives look at the supposed success of companies like Red Hat and see step 1 as being open-sourcing something, step 3 being “profit”, and step 2 being some fuzzy middle that they will figure out later. But once a project has been open-sourced it’s impossible to put it back in the box even if the company later determines that step 2 would go more smoothly if the project was not open-sourced.
In other words, projects get open-sourced due to either lack of forethought or too much dogma. Then, investors or executive teams panic and start navel gazing about how to build businesses around open source, and Medium posts ensue. It’s all completely backwards.
Rather than rushing to open source intellectual property and assuming that it should be the default choice, I recommend instead that companies take the opposite tack. Software should default to being closed source unless there’s a good reason to open source it. Otherwise, someone who is better capitalized than you and less altruistic about software being in the public domain, etc. will come along and eat your lunch (i.e. build commercial products or cloud services on top of your project). Meanwhile, you end up having to fix all the bugs and add features while figuring out how you are going to eat.
By the way, there are open-source business models that work. It’s just that as an industry we’ve often backed into them rather than designing them up front. These days, Chef has a couple: one is based on data & analytics, and the other is based on content. Chef Automate is a commercial product that encompasses both: it offers actionable insights for a variety of personas on top of the data generated by open-source engines, breaking down barriers between traditionally siloed teams like ops, dev and security. And Chef Automate also offers a subscription to premium content for the InSpec compliance automation engine so that you don’t have to write thousands of compliance rules yourself; you can just inherit from the proprietary rules that we provide and customize them to your compliance regime.
To be honest, though, we backed into these business models by accident. It was very painful, and we wasted years grasping at monetization straws before finally finding something that stuck from both a “is it going to make money” and “is it valuable to both a user and an economic buyer” lens. Instead, if we’d been more pragmatic and less dogmatic about open source, we might have figured it out sooner and made fewer mistakes.
Hence my motivation in writing this blog post. If you have made an awesome project and on day one you open source it, you will probably get a lot of accolades and developer adoption. Good for you. (Hello, Docker.) But if you haven’t thought ahead about how you and your fellow maintainers are actually going to eat off that, then good luck to you. It’s really tough to tell those horses what to do after they’ve left the barn.