We really need to stop it with posts intended to proffer the secret to open source success (TL;DR be like Confluent). It turns out that market dynamics determine the right model for a given company. The industry wasted a decade trying to ape the Red Hat model. It didn’t work. As Peter Levine, general partner at the venture capital firm Andreessen Horowitz, wrote back in 2014, there will never be another Red Hat. If he were to write that post today, he might also argue that there will never be another Confluent.
This is not to say that there won’t be more billion-dollar open source companies. That sort of unicorn seems to be in proliferation mode these days (Databricks, Redis, GitLab, etc.). The point is simply that the right business model for a given open source company depends on various factors. There is no one true way to build a business around open source.
Blinded by the Red Hat
Even to this day, people pine for the good ol’ days of Red Hat. You know, a company that works completely in open source, that contributes back to the communities on which it depends (like Linux, like Kubernetes). I love Red Hat. I’ve always admired it. But its business model works for basically no other company (or project) on the planet. There’s a reason you’ll find few Red Hatters running other successful open source companies. It’s not that they’re not smart. No, it’s that they tasted success with a model that simply doesn’t apply beyond Red Hat’s product suite.
Don’t believe me? It’s worth listening to Red Hat’s former CTO who made this clear back in 2006: “Red Hat’s model works because of the complexity of the technology we work with. An operating platform has a lot of moving parts, and customers are willing to pay to be insulated from that complexity. I don’t think you can take one finite element—like Apache—and make a business out of it [using our model]. You need product complexity.”
Companies tried for years to be the “Red Hat of category X,” and every single one of them failed. Zero exceptions. Instead, we saw these same companies (I worked for one of them, Alfresco) start to be mostly open source, also known as “open core.” The idea was that you’d have 90% or more of your code licensed under an open source license and hold back just enough (in areas of security, management, or other things) to nudge a small percentage of your project users to become product buyers.
That model is much maligned, but it has generated billions of dollars in market returns, which helped fuel more open source innovation. As I’ve written, open source is hard work. No one is giving it away for free. If a developer or company is investing in open source, it’s because they expect a return on that investment. Given that we have finite resources, this is how life (and open source) works.
This is one reason I have little patience with those who dourly denounce the venture capitalists who have funded so much of the open source we enjoy. (See Tim Bray’s comment: “I have little sympathy with modern VC-driven business models.”) These sentiments invariably come from people who work for big companies and have never had to make open source pay, never had to pay their mortgage by turning open source into sustenance.
The one true open source business model
For those who have chosen to turn open source code into a career or, better yet, are funding others’ careers with a (yes, VC-funded) business, you’ve likely already figured out that there’s no simple way to turn free software into a profitable business. You look to Confluent and see a team that built Apache Kafka while funded by LinkedIn, then left to turn extant open source adoption into a viable business. Confluent has done this with proprietary code and proprietary operations (read: cloud). A range of other companies has followed a similar model with positive results, though sometimes with license changes, as a new Battery Ventures report highlights:
Before you jump to the (mostly correct) conclusion that cloud is the answer to open source money woes, consider that sometimes a particular project doesn’t lend itself to a cloud-delivery model. For example, EDB has built a great business around PostgreSQL, but has done so for a customer base that still largely prefers to run PostgreSQL on premises, as CEO Ed Boyajian recently told me.
Even among managed service providers, there are distinct differences. Take the world of Kubernetes. Red Hat, following its traditional model, offers OpenShift, which is a distribution (or version) of Kubernetes. And, Red Hat being Red Hat, all that code is open source. Google, the pioneer of Kubernetes, and AWS, which came later to Kubernetes, both offer their own managed Kubernetes services and their own distributions so that enterprises can run a rough equivalent of Amazon Elastic Kubernetes Service (EKS) in their own data centers.
Why “rough equivalent”? Because if you want to run EKS the way AWS does, you’re going to need AWS’ infrastructure, operational expertise, etc.
You’re probably not AWS. Or Google. Or Confluent. Yet there are principles you can follow that can help build a successful business around a successful open source project, thereby inviting more investment and greater developer (and customer) happiness. The right open source model for you depends on the dynamics around your project and potential customers. By all means, learn from Confluent’s success, just as we once looked to Red Hat. But don’t be blinded by another company’s success. Your open source mileage may vary.