The business of open source

by Matthew Langham, Indiginox on 3 February 2009 , last updated 9 September 2012

Introduction

Even today, mentioning the words ‘business’ and ‘open source’ in the same sentence can solicit strange remarks from an audience not yet accustomed to the fact that there is indeed a large business economy around open source software. It isn’t that long ago that companies using open source software commonly thought that any kind of support or other services around the ‘free’ software should also be available without charge. Whilst free support was not expected it was widely assumed that professional support was never available. At the same time, open source communities sometimes found it difficult to interact openly with commercial entities.

However, things have changed and these days we can see open engagement between open source communities and companies commercialising the software produced by those communities. Companies have also begun to recognise that making money from open source software while not giving anything back to the community or project is likely to ultimately result in the failure of their open source related products. Organizations that have been established around open source projects, such as the Mozilla Foundation, the Linux Foundation, the Eclipse Foundation and The Apache Software Foundation have worked hard to foster engagement between both sides and this has produced some results that would have, until very recently, been considered ‘impossible’. For example, Microsoft, historically the most vehement opposer of the open source development model, has been contributing to, and sponsoring, some of the key open source software development communities since 2008.

Over the last few years many different business models have evolved around open source software and so it has become important for a potential open source vendor to think carefully about which business model may be the most suitable for sustaining the product and target market in question.

This article provides an overview of the various components of open source business models. A complementary document explores sustainability issues associated with building business models around open source projects.

Open source is not a business model

The first, and perhaps most obvious, thing to point out, is that open source itself is not, and never has been, a business model. Vendors should be wary of using the term open source as if it were a way of doing business. Open source, to put it simply, is a way of developing and distributing software.

As more commercial organizations began to understand the advantages of using and engaging with open source, it also became clear that there were barriers open source vendors needed to overcome before they could actually begin to replace established enterprise solutions with their products:

Unclear dependencies on other software components and difficult installation mechanisms
Lack of commercial-grade support and services around integration and adaptation of the software
Unclear roadmap and often a very ‘dynamic’ project
Lack of necessary skill-set within the enterprise
Need for training, documentation and education

To overcome these barriers, open source vendors began to establish business models that met the needs of commercial customers. These business models are built around open source software and are defined by the way revenue streams are generated. The choice of what sort of streams can be generated depends largely on the open source software in question and because of this it has to be stated that there is no such thing as ‘The open source business model’ or ‘The best open source business model’. Building a sustainable business model will differ depending on whom you are selling to, what you are selling and what the market expects.

Revenue streams

The different ways of generating revenue can be roughly split into the following areas:

Packaging and distribution
Offering an alternative paid licence to an open source product
Providing services and support around an open source product

In addition to revenue generation there may also be opportunities for cost reduction through shared development of core software components. Further examination of this topic is out of scope for this article.

Packaging and distribution

The first open source business model to become popular was that of packaging and distributing open source software in a way that makes it easy to install and start using. The various distributions of Linux, an open source operating system, are examples of this business model.

Even software that falls under the reciprocal¹ GNU Public License (GPL) can still be sold for a fee² . Usually, companies will charge a fee for packaging and distributing the software on a medium such as a DVD.

Other ways to package open source software include:

Bundling the software with an appliance
Building and distributing a complete ‘stack’ of open source components

Examples of the appliance approach are the popular Linux based network routers. In cases where the underlying software is licensed under a reciprocal licence such as the GPL, the vendor must make the source code of the software available to the customer – at no extra charge. Failure to do this can mean that the vendor may eventually find himself in court³.

In the ‘stack’ model, a vendor compiles a complete package of open source software to meet a specific business domain need. This could, for example, be a compilation of the open source components necessary to install and run an enterprise document management system. This model is also used to generate revenue from services, as we will see later.

All of the packaging and distribution models seek to address two of the five concerns facing open source adopters (see section 1), specifically:

Unclear dependencies on other software components and difficult installation mechanisms
Unclear roadmap and often a very ‘dynamic’ project

Commercial alternatives

If a vendor owns the complete IP (intellectual property) of an open source project, then he is free to choose how the software is offered to customers. Often, a vendor will provide a version of the software under a reciprocal open source licence (often called a ‘community version’) while at the same time providing a commercial version (or ‘enterprise version’) of the same software⁴. This is commonly referred to as ‘dual licensing’ and has been made popular by companies such as MySQL. Differences between the commercial and community versions could be that:

Bug fixes are applied more frequently and the software is released more frequently
Certain modules of the community version are replaced with “better” alternatives
Additional components are contained in the software package that allow for integration into a commercial environment
The commercial version comes with a bundled support package

An open source vendor provides access to the code of the software, therefore allowing a potential customer to also adapt and extend the software for individual use. If the customer can ‘make do’ with a community version (e.g. by being able to support the product internally) then, a community version may be enough. If not, then the customer can opt to purchase the commercial version that then comes with support.

Open source projects licensed under permissive licences such as the Apache Software License, allow re-licensing of the software under any other licence, including a commercial licence. This allows a commercial vendor to take a permissively licensed project and distribute the code under a commercial licence. This can happen, for example, when a software vendor incorporates open source components into a larger commercial product. For example, IBM integrated the Apache project Xalan, an XSLT processor, into its commercial offering WebSphere.

Providing services

Providing services around an open source product is a popular way of generating revenue. The range of services that can be provided is wide and differs according to the vendor’s skills.

Potential services that can be offered to customers include:

Consulting (i.e. helping the customer to understand the benefits and risks of the specific product)
Integration work (i.e. integrating the open source solution into an existing environment)
Training (i.e. providing workshops and/or on-site training to help a customer get up to speed on the open source product in question)
Development (i.e. adding a new feature or fixing particular bugs)

Because of the nature of open source products, a customer will expect the vendor of services to be engaged with the underlying project and to be visible as having the relevant knowledge around the software. A vendor can emphasize his expertise by active participation in the open source project and by being vocal through blogs and articles in relevant publications.

The service model of commercialisation seeks to address the remaining concerns that adopters of open source have (see section 1), specifically:

Lack of commercial-grade support and services around integration and adaptation of the software
Lack of necessary skill-set within the enterprise
Need for training, documentation, and education
Inability of the customer to contribute code directly to the project

Impact on the community

Regardless of the originators of the actual open source product, each one relies in some form or another on a ‘community’ of people who drive the product forward. That community can be a diverse set of people or limited to a few employees from different companies. However, regardless of how the community is made up, each member has put time and effort into driving the open source product to its current position.

Any business model built around the open source software will therefore, in some way, affect the community. Any vendor thinking about building business around the software needs to take this into account before rushing to splash his business proposition across the Internet. It could quickly backfire if the community thinks he is attempting to control or own the project and its community, especially if the vendor has not been actively engaged in the project up until this point. The strength of an open source community is that it can ‘vote with its feet’, meaning that it can choose to walk away and start another project using a fork of the open source project, potentially damaging any business model built around the software. Any business engaging with an open source project must therefore be sensitive to the community’s needs and desires and work with the community to ensure that, as far as possible, all interests and concerns are satisfied.

Finding additional advice

As we have seen in this article, choosing a sustainable open source business model is more complex than just choosing the software licence. An open source business model can be made up of different components depending on the software and the needs of the consumers. Therefore, the vendor needs to understand the implications of each component and how they can be applied to the open source software in question.

For a vendor looking to release a product in an open source version it makes sense to obtain additional consulting and guidance when choosing the business model.

In January 2009, OSS Watch held a one-day workshop entitled Business and Sustainability Models Around Free and Open Source Software. The workshop report provides more information on commercial business models.

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.