Differences between revisions 35 and 36
Revision 35 as of 2011-05-26 13:58:12
Size: 13098
Comment:
Revision 36 as of 2013-04-15 13:56:21
Size: 13104
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 37: Line 37:
||Governance model||20||Customising one of our templates [http://wiki.oss-watch.ac.uk/GovernanceModel governance models] for your project||Defines scope of project and decision-making process for strategic management.||
||Infrastructure set-up||10-30||Configuration, documentation and [http://wiki.oss-watch.ac.uk/CommunityTools integration of management tools]||Streamlines management of software aspects of the project and channels community members into the management process||
||Governance model||20||Customising one of our templates [[http://wiki.oss-watch.ac.uk/GovernanceModel|governance models]] for your project||Defines scope of project and decision-making process for strategic management.||
||Infrastructure set-up||10-30||Configuration, documentation and [[http://wiki.oss-watch.ac.uk/CommunityTools|integration of management tools]]||Streamlines management of software aspects of the project and channels community members into the management process||
Line 40: Line 40:
||Release management||4 hours per month||Development and maintenance of release build scripts||Efficient management of the [http://wiki.oss-watch.ac.uk/ReleaseEarlyReleaseOften release early, release often] requirement for sustainable open source. Facilitate third-party engagement by ensuring they can build the project software easily|| ||Release management||4 hours per month||Development and maintenance of release build scripts||Efficient management of the [[http://wiki.oss-watch.ac.uk/ReleaseEarlyReleaseOften|release early, release often]] requirement for sustainable open source. Facilitate third-party engagement by ensuring they can build the project software easily||

Intro

Most academic funding bodies require that the projects they fund release their software under an open source licence, and that they make provision for the sustainability of their software from the outset. This does not mean simply releasing code under an open source licence and adopting open development practices. It also involves building a sustainability plan at the beginning of the project and maintaining it during the project's lifetime. Ideally, the initial 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 [link to "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.

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 provide concrete guidance on the resources that you should consider including in the budget of your project, in order to avoid such pitfalls and increase the project's chances of becoming sustainable.

Main sustainability issues

OSS Watch is frequently approached by academic projects who have failed to address the sustainability of their software appropriately or in a timely manner. Some of the most common issues include a lack of appropriate community assessment, superficial IPR management, poor software management, lack of project memory and failure to attract third-party contributions.

Lack of appropriate community assessment

Two key questions to ask when starting to build a project community are: Who is the project community? [link to COMMUNITY DOC] 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, some of which may also be at bid stage, with which you could collaborate.

Superficial IPR management

In addition to indicating the type of licence that will govern your software outputs, as mandated by JISC and other funders, you should also clarify how IPR [LINK TO IPR Doc] 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 and supporting processes [link to tools and processes doc].

Poor software management

People often think that an open source project involves spending a huge amount of time informing everyone about the ongoing developments. But this need not be the case. If you select the right tools and processes to use them, the external communication will simply be a by-product of the development process. [LINK to ESSENTIAL TOOLS DOC] Another software management issue that may create problems in open source projects is forking. Forking, or taking the code and setting up a competing project, may seem 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. [LINK TO Governance model]

Lack of project memory

Some open source projects that do 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. [Link to ROLES doc]

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.

Failure to attract third-party contributions

It is usually not sufficient to plan for continued funding of the core team in order to ensure sustainability. Open source software usually becomes sustainable only through third-party contribution in various forms. In many cases, third-party developers are funded to work on complimentary 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 and project history are available from the outset. You also need to provide clear guidance and structures within which people can contribute. [link to GOV MODELS doc]

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 [LINK to GOV MODEL DOC]. 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.

Sustainability resources

Most projects are unable to estimate the amount of time necessary to build a sustainable open source 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. Each item in the table is discussed in more detail in the following sections.

Title

Hours

Activities'

Benefits

Governance model

20

Customising one of our templates governance models for your project

Defines scope of project and decision-making process for strategic management.

Infrastructure set-up

10-30

Configuration, documentation and integration of management tools

Streamlines management of software aspects of the project and channels community members into the management process

Project memory

8 per week

Documenting all activity in a visible way

Record project memory and encourage third-party engagement

Release management

4 hours per month

Development and maintenance of release build scripts

Efficient management of the release early, release often requirement for sustainable open source. Facilitate third-party engagement by ensuring they can build the project software easily

Governance model

You might be tempted to think that your new project is too young to need a governance model and decide to start it informally instead. The problem with starting informally is that it means you have no documented contribution process and thus potential contributors will be discouraged from engaging with the project. You need to clearly indicate what you will be giving back to contributors so that they can see value in investing time. This is discussed further in the 'Project is too young' section of our document on governance models. [LINK]

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).

Infrastructure set-up

Here 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 (see next section) needs to be created for those who come after the initial funded effort. Without the tools, there is no project memory; without the memory, the only way to sustainability is to get more funding for the originating team. Failing to set up and use a suitable community infrastructure during the funded development means no community memory and thus problems with the creation of new projects based on the old.

Does this mean that by creating a project memory one is limiting one's own opportunities to get further funding? No, one is actually improving the chances of further funding, since new projects are likely to want to engage the originating team in some way. In addition, they will add new functionality to the project, making it more useful and thus more likely to receive funding for further development.

Project memory

Maintaining a project memory involves things like recording and prioritising issues in the issue tracker, documenting design decisions by posting them to the mail list, 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 it 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. This saves time if the project becomes successful. In other words, you are spending eight hours doing what you would normally do, just doing it in a different way. It is not an additional eight hours.

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 chance of getting new contributors. An 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.[link to Release management doc]. To help with the more technical bits of the release process, we have produced a document [link to Best practice in release management] that describes some best practice guidelines along with a checklist.

Conclusion

Many academic projects fail to address software sustainability issues appropriately or in a timely manner. Some of the most common issues include a lack of appropriate community assessment, superficial IPR management, poor software management, lack of project memory and failure to attract third-party contributions. To prevent such problems in your project, you need to ensure that key items, such as a governance model, infrastructure set-up, project memory, and release management are included, and properly budgeted for, in your project bid. [link to BID WRITING DOC]

Resources

Docs from OSS Watch

How to engage OSS Watch in support of your project bid Advice for project bids Essential tools for running a community-led project Governance models Open Source Development - An Introduction to Ownership and Licensing Issues What kind of licence should I choose? How to build an open source community Roles in open source projects

OSSWatchWiki: PlanningForSustainability (last edited 2013-04-15 13:56:21 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.