The Future of Open Source, or Why Open Core Is Dead

Let’s get right to the point: nowadays, open sourcing your core business product is a bad idea. If the project you’ve built starts competing too directly with your core offering or enables other players to eat your lunch, you will be left dissatisfied with it regardless (and sometimes because) of its success.

Don’t confuse what I am saying to mean I am against open source in general. On the contrary, as a developer, I use many open source tools, regularly participate by contributing, and have even built several myself.

I believe open source is (and will be) the cornerstone of all modern software stacks.
It’s one of the best ways to enable meaningful conversations, build genuine communities to solve complex problems and promote industry standards (To be adopted by standard associations, or created de-facto as a project becomes increasingly significant). And when it comes to creating communities, you want a community to deliver genuine value. Otherwise, why create it?

So What Changed with Open Core?

Back in the 2010s, companies like Redis, MongoDB, and Red Hat created open source projects that exploded in popularity and became hugely successful, providing additional enterprise versions and professional services on top of their projects. MongoDB’s CEO has stated that at the time, the company spent roughly about 50% of its R&D budget on the core MongoDB open source project.

The thing is, times have changed. Previously it could take years for a project to gain significant traction. This allowed businesses that relied on an open core model to create a project, nurture it, and only then find the correct approach to start a commercial offering on top. Things move much faster these days. Trying to do this now, there’s a good chance you’ll end up racing against your own open source offering, or that someone will build an offering on top of your project faster. Leaving you with only the leftovers of the meal you cooked.

Learn the Hard Way

Docker had a very strong OSS offering that ended up cannibalizing its own go-to-market. Docker’s reaction was to start limiting its own OSS offering in a way that angered the OSS community, creating a conflict between the business and the open source offering.

Elastic grew its OSS very quickly and effectively, but when the OSS became significantly big other companies started offering SaaS on top of it (Like Logz.io, AWS, and Coralogix). Since their market (which they basically created) was severely undercut, they had no choice but to pivot into another space (cybersecurity). The velocity of software adoption today is so much higher compared to a decade ago, that Elastic barely had time to recognize the issue before the market was taken over. Their “home field advantage” became more of a dead weight than anything else.

Recognizing this shift, MongoDB themselves withdrew from the open core model that they initially adopted, changing the terms of the license that governs the free, open source MongoDB project. The more you look at open core projects, the more you’d find companies struggling to stay in balance with their own growth, their project’s pressure to grow, and the accelerating market around.

A Better Way Forward: Open Foundation

So what’s the alternative here? I suggest finding a real problem that your open source solution can help solve that is complementary to your business but isn’t giving away the core value, and doing so in alignment with the market by sticking to these three critical principles:

1. Be Authentic: The project needs to add real value and be genuine about providing it. In a fast-paced and interconnected market, developers easily sniff out “tricks” to push them into other offerings.
2. Avoid conflicts of interest: An open source project shouldn’t place your company in a conflict of interest. As you push to grow your company, you will run into market pressures as demand rises. This could potentially cap your growth or slow you down significantly compared to competitors who use your open source software. Supporting, evolving, and growing open source is a lot of work, and your competitors may easily reap your benefits, potentially resulting in a kiss of death for your company.
3. Make the project independent: A developer should be able to enjoy what the project has to offer without being dependent on other components that don’t adhere to these principles. If your OSS project is valuable, but there are hurdles to tap into it- other projects will dethrone it by reducing said hurdles.

If you adhere to these principles, you can create an open source offering that complements your core product. It empowers, supports, enhances, enables, or is otherwise a part of the product without being the product itself or its core. This will allow you to enjoy all the benefits of an open source community, without the risk of hurting the core offering of your product.

This strategy is already being implemented by dozens of companies.

Netflix (Spinnaker), Google (Kubernetes), and Meta (React) have all created enormously successful OSS offerings that provide genuine value to developers and the community without giving away the core value of their products. Smaller companies are using this model as well — Komodor (ValidKube), Up9 (Mizu), and my own company, Permit.io (OPAL).

When we co-founded our open source project OPAL, we wanted to offer developers a standard way to keep permissions up-to-date with dynamic changes in the cloud. We promote this project and hope people use it regardless of whether or not they ever pay us a dime for our SaaS offering (Permit.io).

The better our open source projects do, and the larger they grow, the better that is for our product, and that’s exactly the kind of dynamic you want when you are thinking about building open source as a business.

Open source is not going anywhere, and open foundation is the next step in the evolution of open source business strategies. I’m excited to see all the amazing communities, products, and standards it brings into the world; and the amazing (well-aligned) businesses that would grow with it.