<aside>

Keep all the code in a single repository whenever possible and make it available for both self-hosted and SaaS deployments. The alternative is two distributions with separate licenses, which adds friction when a user wants to use proprietary functionality. Not only do they have to get a license, but they also have to reinstall the software. That’s a big hindrance that can slow the adoption of the commercial software. Separate repositories are technically clean, but reduce monetization potential.

One distribution with two licenses

The ideal scenario is to have one distribution that includes both the open source and proprietary code. The entire distribution is publicly available and available for download. The proprietary code is source-available, and the features in the proprietary codebase are activated by a paid subscription.

This is easiest when you are both the author of the open source project and the founder of the company. If you aren’t the author of the project, you will need to get permission from the people running the project to add proprietary code.

Activating proprietary features

To activate the proprietary features, the customer instance talks with your entitlement service. They report statistics (customer id, number of users, aggregate usage numbers of certain features) and you report to them how many users they are entitled to. Don't have license files, it should be an online check.

  1. Use Unique ID for each customer (probably, UUID)
  2. Customer ID comes from your sales software (Zuora, Salesforce, etc.)

If you don't control the upstream repo, build trust first

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. The key is demonstrating that maintaining separate repositories creates extra work and inefficiency.

Problems with separate repos

  1. Changes need to be made in multiple places, duplicating efforts
  2. If a user has a problem, they have to figure out the right repo to submit a PR to
  3. If a user has a feature request, they don’t know where to send the request because they don’t know whether it will be open source or proprietary

Maintaining a soft fork

If you are working with a community or foundation-owned open source project and can’t integrate the proprietary code into the upstream project, combining source code into a single repository may require maintaining a soft fork and pushing features upstream. It’s a “soft fork” because the open source part stays the same. You just add the /proprietary subdirectory and a few hooks to load those files. Any open source improvements or features are upstreamed.

This does require a significant amount of resources and the responsibility of keeping in sync, but the result is a better experience for the end-users of your open core product. Stay heavily involved with the community to reduce the risk of the forks splitting. You will have more influence over the overall direction of the project if you are a well-respected contributor and can more easily mitigate potential issues between the upstream fork and your downstream version.

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.