Building an open core company requires more than great open source software. It requires commercialization. Open source is the distribution and R&D strategy, while proprietary features are the monetization strategy. When they work together, you can achieve scale while maintaining the trust and engagement of the open source community.
There is no perfect playbook, but there are proven strategies you can use to build open core businesses that scale with the support of the community. I recently shared these strategies with the Open Core Ventures portfolio companies, summarized below.
You need proprietary IP to monetize—it's not negotiable
If you don't have any proprietary IP as a software company, you're in for a bad day. Without proprietary features, you're essentially competing on support and services, which rarely leads to venture-scale outcomes.
I see this mistake often. Founders think they can build a business entirely on open source software. If you keep all the code open source, then not only will your competitors compete with you, but if you get popular, other people will start offering the same thing as a SaaS solution. This applies even when you're not the original maintainer of the upstream project. You must create differentiated value through proprietary features that solve real customer problems.
Make all code source-available
This might seem counterintuitive, but transparency in your proprietary code creates significant advantages. I recommend that all OCV companies make all their code source available so anyone can contribute, even to the proprietary parts. I don't think there's a great reason not to do this. Maybe competitors are copying you, but I've never seen a startup die because of this. Startups die because no one cares enough about them, no one is using their product, and their product is not improving fast enough
Automate yourself out of a job
Every time you run into a problem or need to hold someone's hand, improve the code, improve the docs, and make it so that hands-on support is no longer needed. Many open source companies fall into the trap of building their business around support and implementation services. This is a dead end for venture-scale growth.
It’s tempting not to automate yourself out of a job because you think, “then they won't need us next time.” But integration and automation are what unlocked the growth of GitLab. The installation became much, much simpler. Resist the temptation to build a support/services business around your open source project.
Keep all code in a single repository
I cannot stress this enough: separate repositories are technically clean, but drastically reduce monetization potential. Instead, integrate both open source and proprietary code into a single repository using subdirectories with separate license files. Make it available for both self-hosted and SaaS deployments. Use OCV’s licensing template. This makes it very clear which parts are proprietary and which parts are open source while maintaining the tight integration necessary for effective development and monetization.
Integrating the code is where I see the most resistance, and it's where companies make their biggest mistakes. Put everything in the same repo. The companies that opt for “technically clean” over a single repo are often the companies that fail.
Offer both self-hosted and SaaS options
Most companies should offer a SaaS version of their software. This isn't about replacing self-hosted options but rather providing customers with choice and creating an additional revenue stream. Keep your SaaS version and your self-hosted version as similar as possible.
Typically, the SaaS version will have all of the open source features offered in a free tier, but with usage limits like "no more than three users per team" or other restrictions. The code itself should still be visible and modifiable. Make the proprietary features available in both options. If you create them in the SaaS version, make them source-available in the self-hosted version, too.
Distinguish between open source version and free SaaS tier
This is a crucial distinction that many founders miss: There can be a big difference between your open source version and your free SaaS version. The open source codebase should not have artificial limits built in—that would be antithetical to open source principles. Someone would just send a PR to remove that limit. But you can build a free SaaS version and impose limitations. This applies to proprietary features, too. A free SaaS version may offer limited access to some proprietary features, creating an on-ramp to paid features.
When you don't control the upstream repo, build trust first
Ideally, you're in control of the repository, but many open core companies build on existing open source projects they don't control. If you're not the maintainer of the upstream project, focus on becoming an active contributor before seeking integration. You should be contributing to the open source codebase to the extent that project maintainers see you and your company as a positive influence. Once you've established yourself as a trusted contributor, consider asking the upstream maintainers if you can add your proprietary code directly to their repository.
This approach hasn't been tested widely, but I believe it could work because you don't necessarily need control of the repo. You just need someone's OK to have a subdirectory in there. The key is demonstrating that maintaining separate repositories is creating extra work and inefficiency.
Improve the open source code faster than before
A common community concern when companies form around open source projects is that development will slow down as resources get diverted to proprietary features. It’s important that the open source part of the codebase expands more rapidly than it did before the company existed. Most of the people at your company are net new. As long as one of them sometimes adds something to the open source codebase, the open source codebase should be better off.
Focus on value creation over reputation management
Many founders get paralyzed by concerns about how the community will perceive their commercialization efforts. The best way to maintain community trust is to consistently deliver value through your open source contributions and maintain transparency in your approach. If you're contributing meaningfully to the open source project and being transparent about your business model, the community will generally respond positively.
Use buyer-based open core for feature segmentation
The buyer-based open core model is straightforward: Ask for money for features that managers and up want, and make the features that individual contributors want open source. Consider the user persona rather than the technical implementation. Management features like access controls, audit logs, and compliance tools naturally fall into the proprietary category, while individual contributor features often belong in open source.
When in doubt, don't default to making a feature proprietary, thinking you can open source it later. Feature placement decisions are sticky. Once something is proprietary, internal reluctance to open-sourcing it grows over time.
Make sharing free, monetize the control
Don't put barriers around fundamental behaviors that drive growth. Sharing is a viral thing. Keep that free. But after sharing comes the complications. Managers will ask, "Can we limit public sharing? Can we get an overview of what documents are shared with whom? Can we prevent people from sharing documents outside of our organization?" Make sharing wide open by default, but charge for the governance and control features that managers and executives need.
Become the obvious choice
Make your software more user-friendly than alternatives. Make your open source offering better than other open source options in the same space. When you become the default choice for open source users, converting them to paid plans becomes much easier. You want people to come to you regardless of whether they are looking for open source software or a paid product.
Don't be afraid of competition. If a large company like Microsoft is adopting your technology, embrace it and use it to establish yourself as the expert. If competitors are white labeling your software without attribution, make sure everyone knows it is based on what you made. Make a page on your website that lists all the companies building on your software. Make your company look as big as possible. Then, look at what they're selling, as it’s probably an indicator of demand. Look at which ones are successful and what they are selling, and go build that.