The cloud killed open source as a distribution model
I’ve been struggling to make sense of open source since college. I remember installing Linux for the first time and marveling that I could get an operating system for free. Why are people giving away something so valuable?
This came to the fore when I joined Sentry. I was the first business hire in 2015. Open source seems ‘proven’ today but back then Mongo and Elastic had both not yet IPO’d and Red Hat seemed stagnant. Yes, Sentry was doing well as a business, but it wasn’t obvious that it could become a billion dollar business. Red Hat had “made it”, but a lot of their margin stemmed from licenses…something that made vastly less sense with Sentry, where the product was wholy open source and actively being used at a lot of the tech giants. At the time, no one at the company believed that anyone would ever pay us more than $100,000/year. I hardly believed it myself.1
I previously posited that open source helps ideas spread faster. The unexpectedly rapid migration of enterprise to the cloud in the last two years has made this a lot less relevant, massively driving down the adoption cost of new software. Previously, open source circumvented thee normal procurement/assessment/deployment process — engineers just quietly did their own thing and assumed responsibility for their actoins. Movement to the cloud has simplified the assessment/deployment whereas the increasing importance of security has added process to adopting open source software. Finally, software is becoming less the wild west of script kiddies and unless the software is well-written, documented, tested, and adopted, experienced developers do not want to be responsible for software they didn’t write.
This is really underlined for me by Snowflake. I once assumed that of all the categories, the data warehouse space would be dominated by open source vendors. Like Linux or git or React, a data warehouse is a pretty universal company need, so a popular project (like Hadoop or Spark) would benefit from contributors from other companies. Hosting data is tricky business, so the transparency of open source would engender trust. Finally, companies would always compare their costs to the base S3 costs, so open source companies would be best positioned to offer price-competitive services. Fast forward a few years and Snowflake is an almost 100B company and growing faster than any other company in the market.
Open source isn’t the untapped distribution channel it used to be. And IaaS players have made it clear they’re not afraid of offering directly competitive services using your code. Multiple players have now switched to BSL-like licenses. Instead, open source has started to feel a bit like “organic” food. Vaguely “good for you”, but it doesn’t mean that you still won’t get a Five Guys burger if it’s nearby and you’re craving it.
There isn’t just one reason to open source. Lowering an individual actor’s development cost, like git.2 Helping with trust and community, like mongodb. Sharing control of critical infrastructure, like Android. Collaboration across companies building towards a similar standard, like Webkit. In addition to these practical benefits, Open source is great ferment of ideas. And while most of those ideas are bad, the public sphere gives the best ideas the opportunity to be discussed and adopted. Large companies will pay hundreds of thousands of dollars to send their developers to conferences in the hopes of incorporating some of the latest industry thinking, but it’s incredibly hard to actually incorporate those ideas once you’re back. The engineer discipline need to modularize and open source internal code speaks to a strong engineering culture. Leadership is able to weigh a quantitative cost against a qualitative benefit. A engineering culture has become especially in B2B services. As most business processes get automated, having a robust API, good security practice, and near-perfect uptime is as important a selling point as feature or price, often even more.
Not all code should be open source. In fact, unless code explicitly benefits from open source, it’s still probably better to default to closed source. Great open source is usually tightly focused, single-purpose libraries, whereas most products are necessarily sprawling, complicated compromises of various customer and business needs — difficult to explain and impossible to reuse.
Open source was critical to the success of companies like MongoDB, but going forward, I don’t believe that it’s vital for all companies, even in developer tooling, to open source their products. The barriers of adoption that open source surmounted have been lowered by the cloud. This is the same calculation made by Mongo, Sentry, Redis Labs, and so many other open source companies in recent years in adopting less permissive licenses. Startups like Render or Vercel or Replit haven’t even bothered to open source, despite being PaaSes. The cloud killed open source as a distribution model.
This actually affected my early work at Sentry. We assumed that 100k/year was a soft cap on customer ACV. Counting backwards, you figure your average ACV will probably never be more than $10k, so to support a billion dollar business, assuming normal 6x multiplier, you’d want about 1b / 10k / 6, you’d need 17k customers. At the time, we had 1k, so I concluded that getting broad adoption was our only path to success. This turned out to be wrong (Sentry has since gone on to build up a good-size list of 100k+ customers) and Snowflake has made it obvious that a hosted service can even command eight-figure contract sizes. ↩
Yes, git was not “created” to share costs between companies, but Linus disliked the cheap VCS and could not afford to keep using BitKeeper. ↩