JISC funding calls recommend that OSS Watch are engaged to ensure that open source software and open development options are considered at the bid stage. The reason for this is that projects often fail to consider the resource implications of implementing the JISC Open Source Policy.

It is a very common misconception that making software available under an open source licence will be sufficient to satisfy funders requirements to address sustainability during bid stage. There is much more to it than that. One needs to engage in 'open development' by addressing IPR management, community engagement, project governance and exploitation options. All this requires planning and resources. Fortunately, these activities will contribute to the running of a well managed software project as well as to the potential sustainability of any outputs.

By consulting with OSS Watch you ensure that you consider the resource implications of producing sustainable open source software at the earliest possible moment. You also give OSS Watch the opportunity of giving your project StrategicProject status.

What we do

If your project is to produce software outputs it is important that you contact OSS Watch during bid writing so that we can help you plan and resource your project with respect to the engagement with and production of open source software. It should be noted that the default position of this policy is that any software development funded by the JISC will be released as open source software and will be developed using an open development model unless specified otherwise in the bid.

OSS Watch are a non-advocacy open source advisory service. Our goal is to help you understand if open source/open development is appropriate for your project and, if it is, understand how best to budget for the management of such a project. In providing advice at bid stage we consider issues such as:

The first step is to email us as soon as possible with details of your project and a draft proposal if you have one. We can then work out how best to support you, including the following activities

Aout this document

This document is, like all documents in the wiki, in development. It is intended to provide guidance for those writing a bid and will help you consider what is needed in order to plan for the development of a sustainable open source project. Most of the issues in this document are discussed in more detail elsewhere in OSS Watch documents. in particular [OpenSourceYourCode] deals with the legal issues and [StartYourProject] deals with actually getting a project underway.

Common Issues

This section contains examples of common issues we raise when a draft bid is submitted for review. You may find it useful to review these before submitting a draft to OSS Watch for review, each section also links to a number of related resources that you will find useful.

Identify Community

You do not indicate the type of licence you intend to use for software outputs. The JISC request that an open source initiative approved licence is used unless an alternative is justified at bid stage. It is not necessary at bid stage to indicate what licence you intend to use, it is sufficient to simply state that an OSI approved licence will be used. OSS Watch will provide one on one consultation to help you choose a licence model most appropriate to your project once it has been funded.

You should also address how IPR will be managed within the project. It is vital that you have a clear and unambiguous record of all contributions to your code. This can be greatly simplified by using a version control system and supporting processes.


Reuse of Existing Open Source Code

You indicate that you will be using open standard XYZ, but do not address the utility of any open source reference implementations or libraries relating to these standards. How do you intend to support these standards? Are existing open source implementations and libraries of use in your project? If not why not? If you intend to reuse libraries do you expect to have to engage with the donor project? If so what will this engagement look like?

It is important that your project does not fork existing open source code. This may seem like the most efficient option in the early stages of a project, however, this will prevent third parties from easily adopting your code and will, over time, create a significant maintenance problem for your team.

Existing communities and projects

You should also explore existing projects to see if you can either leverage their work or contribute to it. This will help avoid duplication or forking and by embedding in other larger communities yours will have gained improved sustainability. Plus you are likely to be able spend more effort on your project's value proposition (USP). OSS Watch may be aware of other projects, some also at bid stage, that you may be able to collaborate with.


Sustainability Beyond Funded Life

Most projects fail to plan for the sustainability of software outputs beyond the funded project. It is usually not sufficient to plan for continued funding within the core team. Open source software becomes sustainable through third party contribution in various forms. That is a third pary is funded to work on a complimentary problem and the fastest way for them to solve the problem is to work on existing code (see "Reuse of Existing Open Source Code" above).

In order to enable third party contribution it is necessary to ensure the source code and project history is available from the start of the project and to provide clear guidance and structures within which people can contribute. Many projects think that it is not worth the effort of building in community infrastructure at an early stage since their project is small, incomplete and covers a niche market. However, experience shows that it is easier and cheaper to do this before the community starts to take interest. Furthermore, community tools are useful in managing even the smallest project teams and thus there is an immediate pay-off for the vast majority of projects.

A final preparation for the production of sustainable open source software is to clearly describe how third parties are to engage with the project. This comes in the form of a governance model. This describes how the project will engage with third parties and provides the rules and boundaries that ensure the project remains manageable within the resources available. There is no need to define the governance model during bid stage, but an indication of the awareness of a need for one is considered important. OSS Watch provide a number of template governance documents and will work with funded projects during their set-up phase to customise these as appropriate.

Sustainability of project memory

Most projects develop software and believe that by making the software available this will become sustainable. However, it is also important to document and demonstrate the solution implemented, including the decision making process in reaching that solution. Often the reasons behind a particular decision are more important, with respect to sustainability of software, than the software itself. This is because such documentation reduces the tendency to repeat past mistakes and also ensures that there is no need to cover old ground repeatedly.

To this end projects should conduct all development in the open using tools to record project memory. This approach will enable the project team to focus on development of the prototype whilst ensuring that all design decisions, and the justification for them, are open for comment within the community and are recorded appropriately for those wishing to understand the motivations behind each decision. This approach is the one recommended by OSS Watch and is consistently found within sustainable open source projects.


Budgeting for Community Development

Most projects fail to consider how much time is involved with creating a sustainable open source project. When they do consider the time they tend to over estimate or decide the pay-off will not be worthwhile and thus lose it from the plan. However, it should be recognised that most community development work contributes to a well managed project in many ways, not just in community development. This time is not wasted in any way, in the short term it ensures there is a defined structure for managing the software aspects of the project, in the medium term it ensures 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.

In order to help with your planning the table below lists some of the activities your should budget for in your bid. Each item in the table is discussed in more detail in the following sections.





Governance Model


Customising one of our template governance models for your project

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

Infrastructure setup


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

The temptation is to consider a new project too young to need a governance model and thus it will start informally. 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. One has 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.

People are often concerned that this is 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 the Red Rape issue is of concern to you we recommend starting with a really lightweight mode, such as Principle Investigator has veto and delegation powers whilst decisions are made through a process of lazy consensus (these terms are discussed in our document on GovernanceModel.

Infrastructure Setup

Our justification for encouraging projects to create this community environment is that it is how one reaches 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 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 ones own opportunity for further funding. No, actually one is 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

This is involves things like recording and prioritising issues in the issue tracker (project management). 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 in any project. The only difference here is that it is done in the open not behind closed doors. The pay-off is that one is creating a project memory for potential future community members. This saves time if one finds the project becoming successful. In other words, one is spending 8 hours doing what one would normally do, just doing it in a different way. It is not an additional 8 hours.

Release Management

[FIXME: explain release early, release often]

OSSWatchWiki: GetOSSWatchFundingAdvice (last edited 2013-04-15 13:56:20 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.