If you’re reading this article, it means you overcame the first, and hardest part of monetizing your project – the decision to monetize! We’re here to help with deciding how to monetize your open source project.
There are a lot of myths when it comes to making money with open source. For example, there are developers that feel monetization is “anti open source”. Some worry that will require them to form a company or force them to close of their code. Others believe it will take up too much time and may conflict with their day job or other projects. In this article, I will discuss how you can start making money with your open source project, while taking into account these concerns. It’s just a matter of choosing the right monetization model for you and your project.
Before you get to deciding how to monetize your open source project, let’s cover the monetization models available to you. These industry-adopted methods used by large companies to generate revenue with open source. With xs:code’s monetization platform, now you can adopt these options too, within minutes.
Services – Offer your time and expertise to your users.
You can offer services like support, consulting or bug fixing, on an hourly basis. For instance, you can offer two hours of support for $100 by email/phone/chat to help users integrate your code into their project. You can also offer paid bug/issue resolution for users who need a bug fixed. You set the price, the time and how you will provide the service (for example, only on weekdays, 6pm-9pm GMT). If you ask users to contact you before purchasing, you get even more granular control over what jobs you take, for how much and when. We recommend always asking users to contact you before they buy a service.
Ready to get started? Check out our guide, How to offer services on xs:code.
Licensing – Offer another license to paying users
While open source licenses can sometimes be intimidating, they are actually powerful tools you can use as a developer to regulate what users can and cannot do with your code. Using paid licensing is an extremely popular monetization option, and it’s easier to use than you think.
“Dual licensing” allows you to offer two identical copies of your code. Each copy has a different license. The free version has one license, and the paid version has a different license. By assigning a restrictive license (such as a GPL license) to the free version, and a permissive license (such as the MIT license) to the paid version, you incentivize users who need to use your code in commercial setting to pay you. Restrictive licenses place restrictions that commercial companies may not be able to afford. But they are great for community use and for keeping your code open source. Companies that need to use your code can purchase access to an MIT licensed version. They can then use your code freely, without worrying about restrictions.
We recommend offering dual licensing as a subscription. On xs:code, a subscription gives your users access to a git repository that’s locked unless a subscription is active.
Right now you might be saying, “Hold on. If I give away my code with an MIT license, won’t my users freely distribute it as the license permits? Why would anyone pay?” You’re right, but that’s only true for the CURRENT version of your code. A license is only valid for the version that the user downloaded. If your users want to access the latest version, they will need to keep their subscription active. That should also incentivize you to keep developing and maintaining your project.
Using dual licensing will require you to re-license your code. Please read our guide before making any license changes.
Ready to get started? Check out our guide, How to offer dual licensing on xs:code
Premium code – Offer a paid version of your code
No one said open source has to be free-of-charge. You can offer specific features, more frequent updates or provide more support time for those that buy it. While this means you need to keep two sets of code (free and paid), it’s a technique widely used by commercial companies with great success.
It’s up to you to decide what features to include for a paid version, but as long as it provides value to users – people will pay. Keeping a version for free is key to getting the first users to use your project. Once they need the extra features, they will convert to paying users.
With xs:code, you offer your paid version on a private repository on your GitHub account, that is accessible only with a paid subscription.With xs:code, you can offer a paid version on a private repository on your GitHub account. This will only be accessible to those with a paid subscription.
The only exception is for contributors that you can still grant collaborator access. They will still be able to provide contributions to the project.With xs:code, you offer your paid version on a private repository on your GitHub account, that is accessible only with a paid subscription.
Ready to get started? Check out our guide, How to offer premium code on xs:code
Comparing the models
By now, you probably have a pretty good idea of the monetization option that will work for you and for your project. Keep in mind that when you are done deciding how to monetize your open source project, you can mix-and-match different options. For example, you can offer a premium version that includes support hours. You can also offer multiple options, like dual licensing OR support hours. It’s totally up to you and your imagination. Keep one thing in mind. Value is the best business model there is. As long as you provide value to your users – they will pay for it. You can learn more about why companies pay open source developers on xs:code, here.
Enough talk. Let’s get started! Go to xscode.com and sign-up today.
Still not sure? Our community team is here to help at [email protected]
Disclaimer: This article is not legal advice and shouldn’t be treated or relied upon as such. Code licenses are binding legal documents that should be treated seriously. You are exclusively responsible for compliance with the terms of the license under which you use code, and it is always best and advisable to consult a lawyer before making licensing related decisions or use.