Even if you don’t imagine your open-source project becoming next year’s hottest unicorn, all but the smallest of open-source projects are always at risk of turning into abandonware. As your project grows, so too will the demands it places on your time and finances. At this point you will have to make a choice: either abandon it completely and hope that someone with more resources successfully forks it or begin exploring business models that could provide the resources you need.

In this post I will explore five of the most common business models for web-based OSS projects, without comparing them to one another. But there are certain details you need to consider before deciding on a business model; so although I won’t debate which model is the best, I will highlight some of the points you need to look at.

Defining Success

The title for this post refers to Successful Business Models, but any time you use the term successful you need to quantify how it was measured: what metric did I use to determine that these were successful business models? Did I look at companies that used these business models and decide they were successful based on their revenue, number of employees, number of paying customers, or how many of these customers were Fortune 500 companies? What then of the number of times the project had been forked by other companies that ended up making money off it? Isn’t the number of contributors you have a measure of success too?

Defining success is problematic because although in simple terms it is the achievement of an aim or goal, what that aim or goal is is unique to each person or organization. First, as a developer, you must decide what success means to you.

In 2013 the founder of Automattic, Matt Mullenweg, wrote:

Automattic is healthy, generating cash, and already growing as fast as it can so there’s no need for the company to raise money directly – we’re not capital constrained.

and even though a year later Matt admitted to being wrong (after raising $160 million from investors), Automattic is still somewhat of a poster child for open-source success stories. Matt appears to be happy with what has been achieved so far, and they are still focused on open-source projects, with commercial ventures designed to sustain the company rather than generating massive revenue.

The Business Models

Peter Groen and Roger A. Maduro compiled a list of 16 open-source business models in 2012, and although the number has probably grown since, the key strategy to follow is keeping it familiar. Don’t be afraid to mix and match elements from the different models, but be wary of trying to create something brand new. Your potential clients are more likely to convert if they can clearly understand your model and/or plans, and it seems somewhat similar to what other companies offer.

That said, let’s take a look at some successful business models, where success is determined by popularity, and common use.

1. The Professional Services Model

This model has the software still completely open-source, and freely available to all customers, but services such as consulting, installation, support (basic and/or priority), and training are only available at a fee. Consulting services usually cover the management and implementation of the software within specific industries. Red Hat is a prime example of this model being used successfully.

2. The Software-as-a-Service (SaaS) Model

This model sees your software provided as a centrally hosted service that is only accessible via a paid subscription. Subscriptions are usually user, transaction volume, or time based. SugarCRMs commercial offering followed the SaaS model, and it was only recently that they started offering on-site deployments. Although Heroku follows the as-a-Service model, they offer a platform solution, rather than a software solution.

3. The Open Core Model

This model is similar to the Professional Services model in that the core software remains open-source, and continues to be developed. However, special features and modules that extend or enhance the core product are only available as commercial software, for a fee. Talend uses the open core model to sell value added features for its core modules.

4. The Proprietary Software Model

The terms of the GPL state that the source code of any program that uses GPLed parts needs to be made available under the same license terms. This can be problematic for any company that requires your OSS project to integrate with their own proprietary software. A way around this is to develop a closed-source version that is similar to your OSS version (and does not use any GPL libraries or source code), which is then licensed (for a fee) to enterprise clients. This differs from the next business model in that the open-source version continues to be developed and updated.

5. The Drug Pusher Model

A popular myth persists that drug dealers create a market by giving their product to customers for free, and once the customers are hooked, switching to charging exorbitant prices. Without wanting to speculate about their motivation, there are developers who follow a similar model, and it isn’t a myth. The project starts out as open-source, with regular development, and everything else needed to build traction. But then, once they have established a niche, the OSS project is completely abandoned, and a version similar to the OSS project is now only available commercially. Tough luck for the open-source community, and anyone else who can’t afford the commercial product.

After the suspension of development on the Community Edition, it would be tempting to slot SugarCRM under the Drug Pusher model, but it is unlikely that this was the founders intention way back in 2004. They simply want to focus more heavily on growing their big enterprise client-base, and as you will eventually discover, each business model makes it easier to achieve specific goals.

Next Steps

Once you have set your goals, you still need to follow a few additional steps before compiling a list of possible business models:

• Define your customers. This should be as detailed as you can manage, and should address:
  • what problems they have that your product can solve,
  • what they would be willing to pay for your product, and
  • what type of business model is most likely to appeal to them? It should be remembered that some businesses are reluctant to use cloud-based solutions, or have a specific need for on-site deployment of solutions.
• Define your competitors. This means not only knowing who they are, but also what business model they follow, how much they charge, and what terms and conditions they apply to their products.

Only once you have done all of the above can you compile a list of most suited business models, which you can then discuss in detail with your team, community or advisors.

Conclusion

Choosing the right business model is no simple task, and knowing that your customers won’t tolerate a big change to your model doesn’t make it easier. No model will be perfect from the beginning, but although small amendments and adjustments are fine, shifting to a completely different model later on will put your entire client-base at risk.

Finally, remember to keep the entire process familiar and easy, for your customers, not you. You can look at it as a business model, but they should see it as a simple solution to their problems.