There is no handbook to guide you should you ever decide to move your software product from open-source to a commercial model. If there were, it would come with a large disclaimer:

Results may vary

If you are diligent, you may have several meetings with your co-founders and developers to discuss strategy; you may even compile a big fancy document in which you try to predict all possible obstacles, and detail how you may manage them. Even then, you would still need to include a large disclaimer:

Results may vary

As recent events at GitHub have shown, these obstacles and challenges are more than simple teething problems, and they can affect any organization regardless of size, pedigree and age.

Why Switch to a Commercial Model?

Developers have their own motivation for switching from a pure open-source model to a commercial or open-source/commercial hybrid model. A long-term study by Charles Schweik and Robert English found that of the nearly 200,000 open-source projects they reviewed, nearly half were abandoned before they even reached release stage, and 37 percent were abandoned after the initial release. Success, and ongoing development, were not dependent on funding (75 percent of the successful open-source projects reviewed had no funding), but on the need for the software. Ongoing development of open-source projects is largely driven by a user-centered need, and the more a developer (and users) need a specific bit of software, the more motivated they are to continue working on it.

But there is always a risk that what started out as a side-project will grow to a stage where any further improvements will require a full-time commitment. And this usually requires funding.

What remains important, regardless of your motivation for going commercial, is that your reasons are reflected in how you market, license and maintain the software. Don’t say that you are going commercial so that you can offer improved support, but the support you end up offering is no faster than before; and don’t offer an open-source/commercial hybrid, only to abandon development on the open-source version.

Going commercial does not necessarily entail abandoning open-source: like Handsontable, Talend‘s core set of features are all open-source, with a set of pro features, and dedicated support, available as commercial add-ons if necessary.

Similarly, Canonical has a vested interest in several open-source projects (principally Ubuntu), but there is a commercial side offering technical support and centralized management of Ubuntu systems.

Navigating the Challenges of a Commercial Model

Switching your open-source project to a commercial model will see you faced with various challenges. Some of these challenges are quite obvious, but some will surprise you and test your courage.

It all depends on which new business model you intend applying to your product – are you only going to offer a commercial license, or are you going to follow the open-source/commercial hybrid route? This is not a decision to make without considering that:

• It is unlikely that your open-source users will switch to being paying customers. Your paying customers will most likely be a whole new segment of users who had little exposure to your open-source product.
• You risk frustrating a lot of users by completely abandoning an open-source license. Although some of these users are unlikely to ever convert to paying customers, they would have been loyal to you through much of the open-source development cycle – contributing bug reports, suggesting features, and indirectly influencing your future growth potential through informal word-of-mouth marketing.

So the challenge here is not only properly assessing the risk each licensing option exposes you to, but also establishing how you will manage the fallout if you completely abandon the open-source license. If you opt to follow the hybrid route, you have to decide whether you are going to offer two slightly different versions of the same software – which will require concurrent development – or are you going to offer value added features that more-or-less bolt onto the open-source version.

Another considerable challenge is that of short-term sustainability: for how long can the company operate without a steady income? Without wanting to discount the value of your time, it is possible to run a purely open-source project at almost no cost. But this definitely changes once you start trying to generate an income, and can vary from the obvious – such as rent, salaries, furniture & equipment, and marketing – to the not-so-obvious – such as legal expenses, insurance, and costs related to servers, data security, and your e-commerce platform. The question you need to truthfully answer is:

“How long can I continue to cover these expenses without making a single sale?”

Conversely, you also need to look at how quickly you can scale your operations should you start making sales; your commercial customers are going to be quite different to your open-source users, generally expecting faster responses to support and feature requests.

Conclusion

These are not the only challenges you will face when trying to make money off your open-source project, but the purpose of this article is awareness, not fear. What is happening at GitHub should also not scare you, but rather help shape the decisions you make when trying to keep both enterprise clients and open-source users happy. It is possible to make money off an open-source project without disregarding the core principles of open-source, and being aware of some of the challenges will certainly help guide you.

I’d love to hear about your own experience when switching to a commercial model, so if you have the time, please share it.