This guide is aimed at helping developers set up an open core monetization model for their open source projects.
What is open-core
Open-core is a well known and widely used business model, created to help monetizing open source projects. It is usually comprised of two versions of a software project - one with basic (or 'core') functionality which is offered for free, and another, feature-rich version, which is offered for a price. For the sake of clarity, we'll refer to the versions as "core" (or "free") and "paid" (or "extended") from now on.
The Open core model allows developers great flexibility in choosing what to offer for free, and what to offer in their paid version. This can differ widely between projects, and it is up to the developer to decide which functionality to include with the paid version in order to incentivize users to pay, while making sure the free version still remains useful.
There are many open source projects out there who use this model successfully. Many of which provide the most basic functionality of their code for free, and adding features, plugins and modules in the paid version. Some open core projects also offer a different license with their paid version. This will be elaborate in the next sections of this guide.
How open-core is applied with xs:code
In order use xs:code to monetize your code with open core, you will need to keep two separate repositories.
- A public repository - which will hold your free version, and is a accessible to everyone on Github. You can use any license for this repository.
- A private repository - which will hold your paid version, only accessible to you, and to users who purchased a subscription on xs:code. You'll need to assign a permissive license (such as MIT) to this repository, or choose one from our approved licenses. Contact our community team at firstname.lastname@example.org for more information.
Purchasing a subscription to your repository on xs:code, grant your users read-only access to the code on your private repository, to pull or clone your code via git.
Before setting up your repositories, you'll need to decide how your free and paid versions differ, and which features would be offered on the paid version.
What can you offer
Software projects vary widely, and each project can have its own core functionality and possible added features. In your paid version, you can offer anything you can think of, including (but not limited to):
- Extra features
- Plugins and modules
- Compatibility with external systems or frameworks
- Additional language/currency/unit support
- Update frequency (bug fixes, new features and updates will be updated more frequently on the paid version)
While we can't provide guidance for every type of project on this guide, consider what is the most basic set of features that is required to provide value for your users.
Usually, users will start with your free version, and when they see it fits their needs, they will consider purchasing a subscription, in order to access the extra features. If your free version is not functional, or lacks significant features that render it useless, it is likely users will not try you free version, leading to less paying users in the long run.
Need help with deciding how to apply the open-core model to your project? Our community team is here to help. Reach out at email@example.com and they will be happy to help and guide you with your decision.
Promoting your open-code project
Since you will be keeping two repositories, it's important to make sure you provide the correct information on each one.
On your public repository
Since most users will find your public code on Github, they will likely read your readme.md file, and repository description before cloning the code itself and experimenting with it. It is very important that you make is clear in your readme file (AND in your description), that another, extended version of your code is available on xs:code.
Be sure to specify exactly what you offer on your free AND paid versions, and include a link to your repository page on xs:code. It important to make it easy for your users to make a well informed decision before trying your code. The more information you provide on your public repository, the more likely people are to try your code.
On your private repository
The readme file on your private repository will be visible to users visiting your repository page on xs:code. Make sure to include a detailed explanation of what your paid version includes, so they know what they will be paying for. You should also include a link to your public repository's page on Github.
For more information about promoting your project, check our our promotion guide for useful tips and tricks to get more users to subscribe to your code.
Accepting code contributions with open-core
Due to the nature of open-core, only your public repository is open to the public. This means that you can only accept code contributions to your public code, which is your free version. For some projects, that is enough, but some developers would still be interested in also accepting contributions to their paid versions as well.
Note: If your public code is licensed with a copyleft license (such as GPL), and you are accepting contributions using that license, please consult our dual licensing guide for information on how to accept contributions using a copyleft license.
You can accept contributions to your paid version in one of the following ways:
Adding contributors to your private repository
Github allows you to add up to 3 contributors to your private repository, giving them the ability to access the code and send you pull requests. This method allows you to add specific contributors to your project, in order to accept their contributions. Also note, that using Github's paid accounts, you can add more than 3 contributors as needed.
Using dual licensed open-core
Using a slightly more complex scheme, you can easily accept contributions to both of your code versions. you will need to maintain 3 repositories.
- A public, free repository, usually licensed with an MIT license, containing the core version.
- Another public repository, licensed with a copyleft license such as GPL, containing the extended version.
- A private repository, containing the extended version under an MIT license.
Using this scheme, allows you to keep the extended version of your code under a restrictive license, making it possible for everyone to contribute. Since it is GPL licensed, it is likely that companies will opt to purchase a subscription in order to obtain the MIT licensed extended version.
If you intend to use this specific scheme, please also consult our dual licensing guide for more information about licensing, and accepting code contributions to GPL licensed code.