Sustainable open source

by The OSS Watch Team on 5 August 2008 , last updated

Introduction

Sustainable open source is an open source project that supports itself.

From the point of view of an organisation that is procuring software, a sustainable open source project is one which is capable of delivering improvements and fixing problems with its products in a timely manner, and that the project itself has a reasonable prospect of continuing into the future.

From the point of view of the project itself, sustainability can simply mean that the project is able to cover the costs it incurs, which can be significant even in a volunteer driven project.

This document examines some of the models by which an open source project can become sustainable, from the point of view of the project and its sponsors. For a look at how to evaluate the sustainability of a project from a procurement or reuse perspective, you should read the companion briefing How To Evaluate The Sustainability Of An Open Source Project.

Reaching sustainability

To be sustainable a project must meet its own costs. These include infrastucture costs such as hosting and supporting services, and also the costs of developing, updating and maintaining the codebase. They may also include the costs associated with the governance of the project, and with marketing and communications.

Many projects have their initial costs covered by an injection of funding from a parent body, a sponsor, an investor, or directly by the founding developer.

However, what happens when this money or resource runs out?

It is unlikely that the original funding stream will remain a viable option indefinitely. At some point either income must be generated or cost savings must be realised. A sustainable open source project is one in which this income or cost saving outstrips the cost of ongoing support and development.

The unfortunate reality of software development is that the vast majority of projects do not become sustainable. This is true of both open source and closed source development projects. In fact it is true of any activity that requires financial support to survive. The reality is that most new ideas fail to reach sustainability, whilst only a small handful succeed.

It is therefore important to ask why projects fail to reach sustainability. In some cases this is because the project fails to achieve what it set out to achieve. In these cases one would expect the project to be allowed to disappear. However, in a worryingly large number of cases the project does reach its initial objectives, yet still fails. This is especially true in publicly funded development work. This kind of failure is usually caused by a failure to plan for success. That is, there is no early plan as to how the project will sustain itself when the initial seed funding runs dry, and consequently no resources are assigned to reaching sustainability.

The conclusion is therefore obvious: to reach sustainability the project must make implementing a sustainability plan one of its initial objectives. It follows that the sustainability plan should be developed at a very early stage of the project’s life. However, in order to draw up this plan it is necessary to understand what options are available to you.

It is not possible to enumerate all sustainability options in this space, there are as many models as there are project ideas. However, the following sections outline some common sustainability models for open source software.

It should be recognised that very few projects fall squarely into one of these models. Most projects are sustainable because they draw on a different combination of factors from each model; similarly there is considerable overlap between models. The following sections are only intended to provide food for thought when you start working on your own sustainability plan. The intention is that they will enable you to approach advisors, such as OSS Watch with some understanding of the opportunities that lie before you.

Product development

A company that bases its business on open source products is no different from any other business. That is, it must invest some of its income in product development. There are four broad types of company able to commercially exploit open source software:

  • services companies who make software available as open source in order to to create as large a market as possible for their paid for products, such as support, training, customisation, search engines, eCommerce operations etc.
  • hardware companies who want to increase the potential market for their hardware, such as printer or mobile phone manufacturers
  • software companies who utilise open source components
  • software companies who have a dual licensing model and release an open source version of their product alongside a proprietary version of their product

A given company is not limited to any one of these activities; similarly, there can be more than one company involved in commercialising each open source software project.

For services and hardware companies the main profit line does not derive from selling the software itself. This makes it possible to release the software under an open source licence in order to benefit from contributions from third parties.

In the case of service based companies the motivations for open sourcing code are very similar. A company selling consultancy or customisation work wishes to ensure that their services are in the widest possible demand, so releasing a core product as open source is a way to seed the market. Furthermore, for companies providing services that are software driven, such as search engines, web 2.0 services or eCommerce operations there is good reason for the non-competitive parts of their software suite to be open source. This allows cost savings on initial and operational development as well as ongoing maintenance through shared development costs. For example, Amazon, IBM, Yahoo!, EBay, Facebook and many more companies use and contribute to the Apache HTTPD web server and GNU/Linux.

In the case of the hardware companies the drive towards open source may be to expand the market for their hardware or it may be to drive down costs of product development. For example, a printer manufacturer may open source their driver software in order to allow it to be customised for different platforms, thus the market to which they can sell the hardware is expanded. Another example is a mobile phone manufacturer who may opt to use open source software as the core operating system in order to share development costs of common functionality with other manufacturers.

Software companies who make their profits from selling software have two models available to them. However, each of these models is only available under certain open source licences. Those companies wishing to embed open source software within proprietary products can do so with the so called ‘permissive’ open source licences (commonly known as the BSD-style licences). Conversely, other companies adopt a dual licensing model for their software products by adopting a so-called ‘copyleft’ licence (such as the GPL) whilst also offering to sell the software under a proprietary licence.

Non-profit open development

In many cases software developed by an organisation is, in itself, not part of the revenue stream. In this case it can often be beneficial to release the code as open source in order to spread the costs of development. In these circumstances it may be worth considering the creation of a non-profit organisation that will manage the software development. This has two effects; firstly it allows many of the infrastructure and governance costs to be absorbed by the non-profit organisation. These costs are supported by contributions from those companies capitalising on the products managed by the non-profit organisation. Secondly, it encourages more organisations to participate in the project since they are assured that the project outputs will always be available to them and will be managed in the interests of all contributors. That is there are no commercial interests ‘interfering’ with project management strategy, nor are there any ‘bought’ seats able to control development.

Perhaps the best example of such an organisation is The Apache Software Foundation (ASF), a non-profit organisation that shepherds projects such as the Apache web server (HTTPD) and a great many XML and Java based projects. The ASF is supported financially by charitable contributions from individuals and companies and provides an infrastructure for developers working on Apache projects. The work is carried out by individuals who are often employed by companies using the Apache code as part of in-house developments or offering customised versions for sale.

For example, the Apache Rave portal framework was initially proposed by a number of academic and commercial partners as a project within the Apache Incubator, and was successful in attracting many more developers from beyond the set of initial participants, graduating as a top level project at the ASF in 2012.

Other examples of non-profit foundations include:

Consortia

When a core group of organisations collaborate on a given project they may form a consortium to maintain that software. This is similar to creating a non-profit organisation (see above). The key differentiator between a consortium and a non-profit organisation is that consortium members have more control over the direction of the project than sponsors of a non-profit organisation will typically have. In the case of a non-profit organisation the software is being managed for the good of all, in the case of a consortium it is being managed for the good of the consortium members (and anyone with aligned interests).

One of the strengths of the consortium model is that the consortium is able to more closely manage the direction of the project by dictating what the resources (time and money) are spent on. However, this very fact may make the project less attractive to those who are not a member of the core group. This is particularly important when we consider that tomorrow’s developers are today’s users and therefore users should be encouraged to participate from an early stage. Unfortunately, the consortium model often make users feel excluded because they are not members.

It is interesting to note that many projects that start with seed funding often start life as a benevolent dictatorship or a consortium but then have to migrate to some other structure as the seed money runs out. This is a very difficult migration to manage.

The DSpace project is an example of a successful consortium project within education. Other examples of consortia include Apereo Foundation and the Kuali Foundation. However, DSpace and Apereo are both moving towards a more open model.

Contributions to realize cost reduction

An organisation may choose to adopt an open source software product for many reasons. In some cases they may have done so in order to enable new processes to be implemented, to make existing processes more efficient or to reduce software licensing costs. Having adopted an open source software product an organisation may also choose to contribute to that open source project in order to gain further benefits. For example, a new feature may be added in order to further streamline internal processes, or a bug may be fixed so that the employees can operate more efficiently.

In this scenario there are two key incentives to contribute back to the project. Firstly, by contributing back the organisation is helping to ensure that the software they depend upon continues to be active. Secondly, by contributing back they ensure that any future upgrade path will be as smooth as possible, that is they will not need to replicate those same local modifications after upgrading.

An example is the APLAWS open source Content Management System developed to assist UK local authorities deliver services online.

Education and research funding

In the UK, and in much of the rest of the world, educational institutions are encouraged to make their software outputs available under an open source licence. Funding for open source projects within universities and colleges may come from funding bodies or from the university/college itself. Where there is a direct benefit to the institution, it is quite possible this funding will continue, at least in part, indefinitely.

The institution may benefit in a number of ways. Perhaps the most significant benefits are internal cost reductions and brand recognition with respect to contributions to the wider educational community. One such project is Exim from the University of Cambridge. Philip Hazel maintained Exim since its inception in 1995, remaining in the employ of the University of Cambridge’s Computing Service until his retirement in 2007. Another example of such a project is MailScanner from the University of Southampton, the employer of Julian Field who is the benevolent dictator of the MailScanner project.

Open development is a proven method of collaboration for parties with diverse interests and expertise, especially when developing open source software. In the commercial sector we are seeing large scale interest in the concept of ‘open innovation’ as a means to develop new and exciting products. With careful planning and management open innovation enables a controlled and managed process in which commercial or social exploitation of outputs is encouraged whilst the academic project teams can remain focused on the localised problem rather than business planning. For example Apache Wookie was developed by the University of Bolton but has attracted developers from outside academia, becoming an Apache top level project in 2012.

Philanthropists and other funding organisations

Several philanthropic organisations are significant funders of open source. Examples include:

Volunteers

There is a great deal of educational value, not to mention fun, in participating in open source projects. As a result it is not uncommon to find people contributing to open source in their spare time. Volunteer effort can be harnessed alongside any of the above models and can be found in the majority of open source projects.

There are now many ways in which a project can work utilising free-of-cost infrastructure for hosting and related functionality such as issue tracking and community engagement, for example SourceForge and GitHub. This means that a project can become sustainable by effectively having zero ongoing costs, provided that it can continue to maintain a viable community that is able to keep developing and releasing the software.

Users (as volunteers) are also critical to an open source project with respect to raising requirements and testing. As long as you manage user expectations with any given release it is possible to release open source software in beta or early adopter forms for testing which can considerably reduce your costs before a stable release.

The OSS Watch document How to build an open source community provides a practical overview in building an inclusive and diverse community.

Further reading

Links:

Related information from OSS Watch: