Open source business: differentiation and success

by Randy Metcalfe on 7 February 2006 , last updated 16 February 2009

Archived This page has been archived. Its content will not be updated. Further details of our archive policy.

Introduction

How do you measure success? In some spheres the metrics are obvious. In football the scoreline tells us who won, whether we’ve seen the game or not. In business, the bottom line is also a scoreline that is relatively easy to evaluate in terms of profit or loss. How do we measure success in the world of businesses working with open source software?

Criterion of business success

Open source businesses are businesses. As such their criteria of success are exactly the same as any other business. Success here is generally a matter of money. If the business survives and prospers it is a success. If it fails to become profitable or begins to take on unsustainable losses, it has not succeeded. There need be no special favours or conditions on our evaluations of open source businesses.

Business models

Although their criterion of success may be the same, there is usually a world of difference between the business models of companies working with proprietary, and with open source, software. Note that we are mainly discussing here those businesses which own the software used in the business, rather than consulting companies working with proprietary software from other companies. The key difference is that a proprietary software business may have access to a revenue stream from selling either perpetual or subscription licences for its software. This option is precluded for open source businesses (though see below for a discussion of dual licensing as a business model). Even for proprietary software businesses, licence fees are less frequently the sole or indeed main revenue source. Most proprietary software firms now also provide consultation, business process analysis, implementation support, bespoke module development, and ongoing support, training and hosting contracts. All of these are also typical components in the business plans of open source businesses.

The motivating difference between proprietary software businesses an open source businesses is the availability of the source code under and open source licence. This means that all of one’s competitors have access to the same base product that your business does. And this, more than anything else, influences the range of business models available to open source businesses.

Access to the base product of one’s competitors might suggest that base product differentiation will not be a mechanism for competitive advantage in open source software businesses. However, this is not the case.

Some open source licences require that all redistributed code is made available under the same open source licence as the original code. That is an organisation cannot modify the code and then redistirbute this code under a non open licence. In such circumstances it is difficult to see where product differentiation may occur. However, product differentiation is still possible, as we shall see later in this document. Examples of such projects include the Linux kernel and the MySQL database.

Other open source licences allow for organisations to make customisations that remain private, even when redistributed. This allows a company to differentiate itself from competitors by customising an open source product. The open source software is sustained through contributions to the code base that are not part of the differentiating features of the company’s products. This improves the quality of the common code but allows a more traditional business model based on seeking to satisfy a specific portion of the market’s need by adding value to the open source product. Well known examples include any of the Apache projects or the Eclipse development platform projects.

Customer facing services

When two businesses are competing with the same base product, product differentiation cannot be a mechanism for competitive advantage. In such cases competitive advantage may be achieved instead through those customer facing services mentioned above: consultation, business process analysis, implementation support, bespoke development, and ongoing support contracts.

Again, there is no constraint on size for open source businesses. Some customers will prefer small support companies that may be able to provide a closer customer relationship. Other customers may prefer the scale available in large corporate service contracts. Consultation, for example, depends upon breadth of knowledge of the industry alternatives and the ability to comprehend the business practices and needs of the client. There is no particular reason to assume that such skill or knowledge is evenly distributed across open source businesses small or large. Thus there is plenty of room for competition between rival open source businesses.

Relationship to the code

Customer facing service businesses can be built around proprietary software as well. Indeed many such businesses exist. Sometimes competitive advantage can be leveraged by associating one’s business closely with the development of the product itself. This happens in the proprietary software world when a company in effect pays for the privilege of gaining access to some portion of the underlying code in order to participate in the ongoing development of the product. In such a case, the advantage in marketing, pre-sales and direct service support is clear.

The same competitive advantage can be leveraged by open source businesses that contribute a portion of their resources in the form of developers to the further development of the product. Quite apart from the marketing and public relations value this may provide, the practical advantage is that such a business’ technical staff will undoubtedly be more expert with the product, know more about the current strengths and weaknesses of the product and how best to exploit or circumvent these, and they will have a clearer insight into the roadmap for further development which will aid such a business in positioning itself appropriately to take best advantage of the changes ahead. They may even, depending on the level of commitment, be able to directly shape that roadmap.

At one extreme the level of commitment may become exclusive. That is, the situation may arise where all development of the base product is contributed by a single business. Of course there may be tremendous advantage to be gained from this, especially where dual licensing business models are being deployed. But there are risks as well. The price of exclusivity may be a rival development built on exactly the same the code base.

The permanent possibility of a code-fork

The open source licence guarantees others access to the source code of the product. It ensures that they have the right to modify that code and to distribute the modified or unmodified code. Where a proprietary software business can lock down and lock in development, an open source business faces the permanent possibility of a fork of the code base.

Open source businesses are driven back at every juncture to the community that uses and may potentially further develop the product on which they base their business model. They cannot abuse the trust or goodwill of that community. Or rather, they do so at their cost.

To appreciate how powerful the normative influence of the permanent possibility of forking is, one only needs to consider the number of cases of prominent projects that have forked. That number is exceedingly small. Of course a fork does not in itself mark the end of a project. Four possibilities exist:

both forks may persist and flourish
the initial branch of the development may wither and die
the new branch may be stunted
both forks may perish

The subject of forking is worthy of substantial consideration in itself. Here it is enough to note that that the risks of poorly managing one’s relationship to the wider open source community are comparable for all open source development projects. Any open source business model that ties itself intimately to the development of the code base (potentially to the exclusion of others’ participation) is thus open to substantial potential risks. However, those risks only become active when that community relationship is indeed abused, which may be a comforting thought.

Product differentiation

When two businesses have access to the same code base, that code base cannot be a mechanism for competitive advantage. There are, however, routes to differentiation. Two businesses might both build specialised products that facilitate the use of the shared code base in different ways. For example, many dynamic websites can be constructed using MySQL as their database server. Some might use PHP as their scripting language. Others might use Perl, or Python, or something else. Here, product differentiation occurs at a different point than at the level of the database server.

Another route to product differentiation lies in specialisation. There are numerous successful open source database servers: MySQL, PostgreSQL, Sleepycat, etc. Why might this be the case? One reason is that the range of actions to be performed by a database server is sufficiently broad that specialisation may occur. Sleepycat is especially good at working with XML. MySQL is very lightweight and easy to use, but possibly may not scale as well as PostgreSQL.

At present these database servers do compete though largely their competition focuses on assisting the customer in realising what their special needs are in each case. Presumably if differentiation were carried to an extreme, there would not be meaningful competition between the products any more.

Dual licensing

Finally, something must be said about dual licensing and its relationship to open source business models. Dual licensing typically occurs when a single legal entity owns the copyright on all of the code in a product. In such a case, as the owner of the copyright, that legal entity may choose to license the code in multiple ways for different users. Typically the code would be released into the free and open source community under the GNU General Public License (GPL). At the same time the code may be licensed under a non-free and non-open source licence to a customer who may not wish to be constrained by the conditions of the GPL. In such a case that customer will pay a licence fee for the use of the code in exactly the same way that they would with any other proprietary code.

In some sense, perhaps, dual licensing might be considered not to be an open source business model. If the sole revenue stream were to flow from the licence fees garnered from the non-open source code, then this business model would appear to be straightforwardly proprietary.

Two points tell against this. First, the code that is licensed and charged for is exactly the same code as that which is released under an open source licence. The business therefore is built upon this open source code. Any business whose business model depends upon the use or development of open source software is an open source business. Second, such a business still depends upon the good will of the open source community. Having sought to garner the support of that community with its GPL licensed release of the code, it now takes on the full risk of a code-fork if that community suspects its development motives. The advantage of owning copyright on all of the current code in the product which makes possible the option to license it in multiple ways does not remove or lessen the permanent possibility that the code could be forked and a sizeable portion of the community could follow and use the new branch of development. No doubt this would not collapse a large business in the short term, but in the long term such abuse and disregard of the open source community would surely be unsustainable.

Conclusions

To the extent that open source businesses are businesses, their criterion of success is the same as other businesses, i.e. profit or loss.

Any business whose business model depends upon the use or development of open source software is an open source business.

Open source businesses must face the permanent possibility of a code-fork. They lessen this risk by engaging with the open source community directly and honestly, working to build that community and strengthen it.

There may be as many different open source business models as there are open source businesses. Only time and the market itself will identify which are the sustainable open source 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.