Planning for sustainability

by Gabriel Hanganu and Ross Gardler on 21 June 2011 , last updated 9 September 2013

Introduction

Most funding bodies encourage the projects they fund to release their software under an open source licence, and to make provision for the sustainability of their software from the outset. This does not mean simply releasing code under an open source licence. It also involves building a sustainability plan at the beginning of the project and maintaining it during the project’s lifetime.

In the first part of this document we describe the most common sustainability issues confronting the projects that we advise. In the second part we list the resources you should consider including in your project budget. This will help you to avoid common pitfalls and increase the project’s chances of becoming sustainable. This document will be most useful when preparing a project bid, but can also be beneficial when a project has just started.

Main sustainability issues

OSS Watch is frequently approached by projects that have failed to address the sustainability of their software appropriately or in a timely manner. Some of the common issues include: failure to attract third party interest, poor management of community infrastructure, lack of project memory and inefficient release management.

Failure to attract third-party interest

Projects are often good at making the community aware of their work, but less good at engaging the community in the project itself. This is crucial to the long-term sustainability of the project. Two key questions to ask when starting to build a project community are: Who is the project community? Do I need to build a new community, or is there an existing one my project should be part of? This means that before doing any other community-related work, you need to explore existing projects to see if you can either leverage their work or contribute to it. By doing so, you will avoid duplication of effort, and by embedding your project in a larger community, you will improve its potential sustainability. OSS Watch may be aware of similar projects to yours, with which you could collaborate.

Planning for continued funding of the core team is rarely sufficient to ensure sustainability. Open source software often becomes sustainable through third-party contribution in various forms. In many cases, third-party developers are funded to work on complementary problems, and the fastest way for them to solve the problem is to work on already existing code. In order to facilitate third-party contributions, you need to ensure that the source code is available from the outset and to provide clear guidance and structures within which people can contribute.

Many projects think that it is not worth the effort involved in building community infrastructure at an early stage, since their project is small, incomplete or covers a niche market. However, experience shows that it is easier and cheaper to do this before the community starts to take an interest. A key activity in this respect is to adopt a governance model. This is a document that clearly describes how third parties are to engage with the project and provides the rules and boundaries that ensure that the project remains manageable within the resources available. OSS Watch provides a number of template governance documents and can work with projects to help them customise these as appropriate.

People are often concerned that adopting a governance model involves too much red tape for a small project team. Again, the issue is not whether the existing team needs it, but whether a new member with independent funding is likely to participate in the project. If red tape is of concern to you, we recommend starting with a really lightweight model, such as the principal investigator has veto and delegation powers, while decisions are made through a process of lazy consensus (these terms are also discussed in our governance models document).

Forking, or taking the source code and setting up a competing project, is another issue open source projects must be prepared to deal with. If there is disagreement within the community, forking may seem to be the most efficient solution in the early stages of a project. However, this may prevent third parties from easily adopting your code, and will, over time, create significant maintenance problems for your team. Indeed, you should not choose this path without fully understanding its consequences.

Poor management of community infrastructure

In addition to indicating the type of licence that will govern your software outputs, as mandated by JISC and other funders, you should clarify how IPR will be managed within the project. It is also vital that you maintain a clear and unambiguous record of all project contributions, both code and non-code. This process will be greatly simplified if you use a version control system, as part of a key set of open development tools and supporting processes.

People often think that an open source project involves spending a huge amount of time informing everyone about ongoing developments. But this need not be the case. If you select the right tools and processes, the external communication will simply be a by-product of the development activities.

Many open source projects that make their software available for download and reuse fail on the documentation front. A true open source project ensures that all the solutions adopted, including the decision-making process used in reaching them, are openly shared and appropriately recorded for later reference. This is because the reasons behind a particular decision are often more important, with respect to project sustainability, than the software itself. Such documentation reduces the chances of repeating past mistakes, and ensures that old ground does not need to be covered repeatedly.

Projects should therefore conduct all development using tools that are capable of preserving project memory. This approach will enable them to focus on development, while ensuring that all decisions are open for comment within the community, having been recorded in such a way that everyone who wishes to understand the project context and the motivations behind each decision can do so.

Lack of project memory

At OSS Watch we encourage projects to create a community environment because this is the way to ensure sustainability for open source software. That is, the software is developed collaboratively by disparate groups funded for overlapping but potentially unrelated projects.

For us, the key to sustainability is to ensure that the project attracts interest from the widest possible community. This means that a project memory needs to be created for those who come after the initial funded effort. Without community infrastructure there is no project memory; without memory the only way to keep the project alive is to get more funding for the originating team. Failing to set up project memory during funded development will affect the creation of new projects based on the old. It also makes it much harder for external potential collaborators to evaluate your project and fully understand the project.

Maintaining project memory involves things like documenting discussions and decisions taken by posting them to the mailing list, recording and prioritising issues in the issue tracker, talking to users to understand their needs, etc. All these are activities that should be undertaken by any project. The only difference here is that this is done in the open, not behind closed doors. The pay-off is that you will be creating a project memory for potential future community members, which saves time if the project becomes successful.

Inefficient release management

In open source projects it is extremely important that software is released early and often. Releasing early and often enables people to try out the software more easily and increases the chances of getting new contributors. A well-defined release management process is crucial for helping developers coordinate their activity towards producing new versions of the software, while addressing the IPR and licensing issues associated with their multiple contributions. A separate document on the technical details of the release process provides some best practice guidelines, along with a checklist.

Sustainability resources

Ideally, a first version of the sustainability plan should appear as early as the project bid stage. OSS Watch can help you to prepare this, as described in Advice for project bids. Thereafter, the sustainability plan should be periodically updated to reflect the expanding opportunities for collaboration and third-party contributions as the project community grows.

Most projects are unable to estimate the amount of time necessary to build a sustainable community. If they do think about it, they tend to over-estimate the amount of time required, or decide that the pay-off will not be worthwhile, and thus drop it from the plan.

However, it is important to acknowledge that most community development work contributes to a well-managed project in many ways. In the short term, it ensures that there is a defined structure for managing the software aspects of the project. In the medium term, it guarantees that time is not wasted on repetitive tasks, such as producing and testing releases. In the long term, it ensures that the project is fully open and contributors are able to engage with the project with maximum efficiency.

To help you plan, the table below lists some of the activities you should schedule into your bid, the benefits they bring to the project and the estimated time required to accomplish them.

Conclusion

Many projects fail to address software sustainability issues appropriately or in a timely manner. Some of the most common issues include failure to attract third party interest, poor management of community infrastructure, lack of project memory and inefficient release management. To prevent such problems in your project, you need to ensure that key items, such as a governance model, infrastructure tools, project memory, and release management are included, and properly budgeted for, in your project bid. OSS Watch can help you do just that.

Further reading

Links

• Producing OSS [http://producingoss.com]

Related information from OSS Watch:

• How to engage OSS Watch in support of your project bid
• Advice for project bids
• Open Source Development - An Introduction to Ownership and Licensing Issues
• Roles in open source projects
• Avoiding abandon-ware: getting to grips with the open development method
• How to build an open source community