Not All Open Source Is Created Equal
A lot of confusion seems to be surrounding the term “open-source” these days. The CEO of Hashicorp went as far as to predict “OSS-free Silicon Valley” recently. The claim is of course debatable to say the least, but that’s not what I wanted to write about today. As a founder of an open-source company, I spent a lot of time trying to understand the commercial models in open-source. A lot is written on the topic; but within open-source, there is nuance that in my view can make 2 open-source companies almost polar opposites. Much of that nuance I was not able to find as public knowledge; what follows is my attempt to fix that gap based on my own conclusions from an ongoing attempt to build an open-source company.
Bias acknowledgement: I cannot possibly be unbiased, since my company Digger is a) solving the same problem as Terraform Cloud and b) one of the handful of early backers of OpenTofu. The ideas I’m about to share however have little to do with Hashicorp. If I’m right, Hashicorp is just one of many companies struggling to acknowledge what kind of open-source they really are. Our open-source is of the “hostable backend” kind, which you will read about in this article
Open-source isn’t charity. While making a useful product that’s free and open-source is admirable, the goal of the business behind it is still to make money. But not all companies make money from open source in the same way. To me it looks like there are at least 4 distinct open source business models, each with its own set of tradeoffs.
The RedHat model — “premium services”
RedHat were the pioneers of commercial open-source. They demonstrated to the world that open-source can in fact make money, and a lot of it. In 2019 IBM paid $34 billion to acquire RedHat. So how do they make so much money?
RedHat’s flagship products are RHEL (linux distribution) and OpenShift (cloud application platform on top of Kubernetes). Both are infrastructure software at the extreme end of complexity. And in my view it’s the complexity that enables monetisation. Yes the product’s source code may be available, it may even be technically free. But you can’t make much use of it without deep expertise. And who has the deepest, most up to date expertise? The people who created it of course!
If the open-source product is extremely complex, the company behind it can sell a lot of professional services at high margin. The margins won’t be competed away, unlike with a traditional software consulting business. This makes the model highly profitable, and if the product is also scalable to thousands of enterprises, that’s what makes it VC-backable.
The bar for “extremely complex” is high though. Only truly gigantic things like operating systems or cloud infrastructure platforms pass it. Such products are built by thousands of engineers, and used only by large enterprises. Otherwise it’s just software, perhaps complex — but not extremely. With smaller open-source products the “premium services” model breaks. If it was built by a few dozen engineers, a large enterprise might choose to build internal expertise instead of hiring a “premium services” vendor.
The MongoDB model — “hostable backend”
Companies like MongoDB and Gitlab found another way of making money from open-source. Sometimes it’s also called “fauxpensource” because the money-making part of the business looks surprisingly a lot like SaaS — the customer pays per unit (user-seat or some usage metric) and consumes the software as a web application or API.
Just like in SaaS, these companies have pricing tiers. On the free tier, the user signs up and logs into a managed cloud version (or gets an API key). On mid-range tiers, it’s still fully managed but with more features. The enterprise tier is the most feature-rich; also the most expensive with compliance, dedicated support etc. Again, pure SaaS.
How is this open-source then? That’s the tricky part. Often the source code is split into “community edition” and “enterprise edition” parts. Sid Sijbrandij, founder of Gitlab, calls this way of splitting “buyer-based open-core”). So the user technically doesn’t have to use the cloud version; they can also self-host the community edition. But it is just more convenient, and also cheaper for smaller organisations.
This business model works for a similar reason to the RedHat model — complexity. The underlying mechanics is almost the same, except that services revenue is replaced by subscription revenue. Mission-critical pieces of backend infrastructure (databases, queues, secret stores) are complex enough that maintaining their self-hosted versions is not a trivial job. So it makes sense to pay the creators to maintain a single highly available cloud instance of it. And on the upper enterprise tiers, the vendor would happily maintain a dedicated instance of their product for the high-ticket customer, or even deploy and maintain it on premises.
The only real competition for “hostable backend” companies are major cloud providers. They have effectively unlimited engineering resources; and if they choose to provide a managed offering of an open-source backend application as part of their cloud services, the creators might well go out of business. But even then, the creators have an upper hand — as demonstrated by MongoDB and Elastic switching to BSL. Fair game — enterprises and startups alike are happily using their cloud offerings, while communities still thrive.
The Altruistic model — “no way to make money”
Many open-source products that are supposedly commercial belong in this category, but their creators are failing to acknowledge it. The reason is again complexity.
If your open-source product is not complex enough for high-margin services, and is not a mission-critical backend application to be provided as a managed cloud service, why would anyone pay for it? They can just use it as-is for free; maintenance is not too hard. And if you are charging $X for an “enterprise edition” anyone else can fork your community edition, build the missing features and charge $0.5X — you’re instantly out of business.
Languages, frameworks, compilers, command line tools are all in this category. Companies behind them often make some money off their brand on consulting, but not the RedHat kind of money because it’s just not as complex. Plenty of engineers know the internals of popular frameworks well enough to never need the expertise of their creators. There’s also nothing you can centralised as a cloud version because every user needs their own copy of the code.
So building a great product does not always lead to a great business. Creating value is one thing; capturing some of it is another. If you want to build an open-source business, then in addition to making a great tool you need to ensure that to its users it makes more sense to pay you than to not pay you. And this can be challenging if your product is neither extremely complex nor centrally-hosted.
The Vercel model — “best infra for X”
At first I was going to only cover the 3 models above, but then thought of Vercel and realised that their model could also be viewed as open-source. Sort of. It is certainly not as clear-cut as the other 3 but still worth covering.
At Vercel model, the open-source product (Next.js) has little to do with the revenue-generating product (the hosting for it). But because the hosting platform is so good (many say best in class), and Next.js is so popular, Vercel is the #1 choice when it comes to hosting a Next.js app.
Fundamentally Vercel’s offering is a “vertical” platform-as-a-service optimised for frontend web applications. Next.js itself is not making money; but it serves as an “acquisition product” for the PaaS that hosts it. Frameworks tend to be sticky (it is not often that teams switch frameworks) which naturally leads to good retention on the hosting platform.
So what are Hashicorp?
I think they are running with a mix, varied by product. Most likely they know it full well but trying to not make the distinction explicit for the sake of public company optics.
Vault is clearly in the “hostable backend” category. It is mission-critical and complex enough to provide as a centrally managed cloud service, or enterprise on-prem + maintenance services.
But Terraform, unfortunately for Hashicorp, is in the Altruistic category. It is not complex enough for RedHat-style premium services (although Hashicorp did try). And it is a command-line tool / language that requires every user to have their own copy of the code. That makes it impossible to provide Terraform as a managed cloud service.
What is Terraform Cloud then? In Hashicorp-speak, it’s all “Terraform”, one product. This makes sense for sales and marketing; but it is not an accurate reflection of reality. Backends in Terraform are optional by design, and you can run it wherever a CLI can run. Terraform Cloud wants to be “Vercel for Terraform” — but the Vercel model only works when the product is so good that it dominates competition. This cannot be said about Terraform Cloud. Like-for-like competing products exist and many consider them better (Spacelift, Scalr, Env0).
I believe Hashicorp is banking the shop on Vault, while with Terraform they simply chose to maximise short-term revenue. If this is true, then the BSL change starts looking almost logical. There wasn’t nearly as much frustration in the community about Vault or Consul as there was about Terraform. Because Vault and Consul are “hosted backends” — just like MongoDB or Gitlab.
As for Terraform, imagine if Vercel decided to focus all their efforts on a different product and maximise short-term revenue from Next.js. They could update the license of Next.js so that only Vercel is able to charge for hosting. The next day someone launches OpenNext.js and it becomes industry standard in a few years. But for the next couple of quarters, Vercel could report growing revenue from Next.js.
