OSS Watch is an open source software advisory service for the UK higher and Further Education sector. We are funded by the Joint Information System Comittee (JISC), that means our services are free to the HE and FE sector.
We help institutions and education related projects in the use and development of free and open source software. We provide a variety of services including:
In 2003 when OSS Watch started there was very little understanding in the UK academic sector about what open source is and how one would engage with it. OSS Watch was set up to examine the state of play and to make recommendations that would enable the sector to fully benefit from open source software.
Over the years the focus has moved from creating a base level understanding, through to detailed legal, procurement and engagement advice and support. More recently we have emphasized how open source software can be sustained, and how business models can be built to ensure that software developed in HE and FE is available, customisable and supported with minimal costs for as long as possible.
We regularly blog (also available as RSS feed) about everything we do. When we publish a new article on the site, we will tweet about it. We have RSS feeds for interesting news and events we come across. And every month we publish a newsletter that contains the highlights of our content. The newsletter, amongst other things, will be announced on our mailing list.
Almost certainly yes. We are always keen to talk to people about the issues surrounding open source software, and will do our best to schedule in any speaking requests. We speak mainly at UK events, but regularly travel across the EU and have attended events in the US in the past.
Yes, it is actually better to contact us as early as writing the project proposal. This way we can help you address key software development issues often ignored by projects, such as licensing, community, governance, sustainability, and budget for them accordingly. Advice for project bids provides an overview of how we can help in this respect.
We'd be delighted to, provided it is of interest to people in further and higher education in the UK and relevant to open source.
Provided your news or event is relevant to open source software and the educational sector in the UK, we are delighted to add your event or a link to your news item on our news or events page. Please contact us with your request.
For OSS Watch open source software is software that has been released under an Open Source Initiative (OSI) certified licence. OSS Watch uses this OSI-approved list as a means of avoiding debates over interpretation of the open source definition and which licences do or do not conform to it. By recognising the OSI as the appropriate final authority in this issue, much confusion is avoided.
The expression open source has wide application. For the OSI it also refers to the distinctive software development methodology employed by many open source software projects. The OSI home page starts with "Open source is a development method for software that harnesses the power of distributed peer review and transparency of process."
Open development is an emerging term used to describe the community led development model found within many succesful free and open source software projects.
This methodology contrasts with many of the principles of software development normally taught in academia. The model focusses on fast iterations of development and distributed, self managing teams. Contribution to the project is encouraged from all interested parties while a clear governance model is defined to ensure the project does not descend into chaos.
Open source software, strictly speaking, may or may not be developed using an open development methodology. The choice of this or any other development methodology is dependent upon a project's chosen route to sustainability.
No, you do not need internal IT staff. Your reliance on staff is largely the same as it would be for a closed source solution. To customise an open sorce solution you need either internal or contracted staff. In the case of closed source you only have the option of contracted staff for many customisations.
In general, yes. There are many examples of open source software that has been developed by and for researchers, e.g. TexGen. An open development culture can also be very beneficial in a collaborative research environment.
Many projects don't start a new software product, but instead add to or improve an existing software product, in such cases the most sensible licensing choice is probably to use the same licence, indeed in some cases you have no choice.
Many projects are part of (or plan to be a part of) a larger community of projects, such as the Apache Software Foundation, Free Software Foundation, Debian or Ubuntu. Many of these limit the licensing choice available. Get to know the community you wish to integrate your project into and understand how your licence choice will affect your engagement with that community.
Some projects may have commercial partners who wish to commercially exploit the software outputs of the project. If this is the case a licence which allows the chosen commercial exploitation model should be chosen since most licences have a direct impact on the suitability of different exploitation routes.
If there is no clear choice for your project licences, you may choose to license your code under multiple licences, a practice called dual licensing. Projects such as the Mozilla Project use dual licensing to resolve licensing tensions.
There are over 70 OSI-approved licences, although only a handful of these are commonly used. Your decision should be based upon whether you wish to allow others to re-use your code in projects that are not open source themselves, or whether you wish that your code can only be used in other projects that are in themselves open source.
If you are re-using code developed by someone else then you will need to be careful that you use a licence compatible with that code. Some licences come with patent clauses or require that modifications to source code are fed back to the initial developers. Please see our Intellectual Property Rights (IPR), Licensing and Patents section to learn more about individual licences. Do get in touch with us if you'd like to discuss your choice further.
It is likely that your employer will own the copyright in the software you create, and that therefore you will need their permission to make it available as free or open source software.
Take a look at our document on contributing code to an open source project for more detailed information on contributing to an existing project. You might also like to read our Introduction to Ownership and Licensing Issues for more detailed information on this topic.
If the non-software deliverables are bundled or packaged with the software deliverables and unlikely to be usefully reused without them, it makes little sense to license them separately.
If, however, there are non-software deliverables that are likely to be independently reusable or redistributable, it may make sense to consider licensing them separately. The Creative Commons licences are probably the most widely used licence for content. OSS Watch has documented the process that led to our use of the Creative Commons (we previously used the GNU Free Documentation License).
We provide advice on open source licensing of software. It is important to note that open source is not the opposite of commercial, it is the opposite of closed source. In addition to open source licensing advice we also provide advice on business models applicable to open source software. If we can be of assistance in understanding these models as they apply to your project please don't hesitate to contact us.
We would advise against it very strongly. Open content licences applied to executable software make no requirement for the corresponding source code to be made available. Open content licences applied to source code do not require any executables built from the source to have their source published. All in all open content licences are poorly adapted to the special circumstances that surround the making and changing of computer software.
All major hosting providers provide categorisation and searching facilities. For example, you can search Google Code which lets the projects themselves define labels to categorise their projects thereby making them better findable. SourceForge uses categorisation that allows you to drill down through the categories based on what type of software you are searching for.
There are also aggregation sites like Ohloh, which allows you to search across many different repository websites. OSS Watch is involved in the development of a project registry framework named Simal. On the public project registry you can browse and search for projects, most of which are in the academic realm.
You can download or purchase TheOpenDisc from their website. The Ubuntu website also provides details about how to download or purchase CDs of their popular distribution as does the Knoppix website. MacOS X users can download the FreeSMUG Suite CD. Also of potential interest is Portable Apps, free and open source software adapted to run directly from USB keys, and EduApps, which takes a similar approach to open source and freeware for educators, learners and assistive technology applications.
We can certainly help you maximise the chances of getting the most from your initial investment in creating the software by managing it as an open source project. In return for your effort of adopting a governance model, setting up some basic software development processes and tools , and clarifying the project's IPR framework, you maximise the opportunities for contributing to your software in an open development fashion. The key to making your project sustainable in the long term is building a thriving community of users and developers around it by reducing barriers to adoption and encouraging and rewarding all forms of contribution.
A governance model is a public document that describes how a project is managed. In particular it describes the structure of the team including individual roles and clearly describes how others may contribute to a project. It also outlines the processes that are followed when performing project activities.
While there is potential for an infinite variety of governance models they tend to fall somewhere on a scale between the two commonly recognised extremes known as the 'meritocratic' and the 'benevolent dictator' models. The difference between these two models is, in fact, not so great and mostly concerns the the mechanism for resolving conflict in the decision making process.
There are a number of possible routes. It's all about finding the right community home for your project, so your choice will depend on the nature of your project.
Public repositories like SourceForge and Google Code are convenient and highly visible, but they are crowded with dead or dying projects.
Private infrastructure is another possible route, but this needs to be managed and maintained, as does search engine visibility. Some people opt for something like RedMine, TRAC or gForge, applications that allow you to host a SourceForge-like environment on your own private infrastructure. In our opinion, there is little advantage in hosting on your own infrastrcture, other than branding and ownership.
Foundations are yet another option. This route provides proven management structures and can add a level of quality and branding not easily generated by other means. See Apache Cocoon: a case study in sustainability and Sakai: a case study in sustainability.
We sure can, but the reality is that there are too many variables for most projects to address without a proper consultation, which we provide free of charge to UK HE and FE institutions.
The starting point is open sourcing your code. However this is only part of the process of managing the software. Just slapping an open source licence on it will not result in an active community. Making your software sustainable in the long term is closely related to choosing a project governance matching an appropriate business model.
While having access to the source code is one of the key benefits of open source, developers can run into difficulties when making changes. This is especially true if the full implications of those changes are not carefully considered. Typically, extensive local changes can lead to expensive merging operations when upgrading to a new project release or installing new modules that are incompatible with local customisations.
One way to avoid this expense is to work with the software architecture and restrict changes to a 'plug-in'. This can be managed as a separate project with few dependencies on the core code. Such plug-in code is less often effected by project changes. An even more effective approach is to work with the project community to adopt the changes into the core project. The changes are then maintained by the project and will be automatically included in the next release. The extra effort involved is often outweighed by the reduced maintenance costs, or by the improved reputation of developers and institution as a result making contributions.
We try to ensure that everything on our website is accurate and non-biased, but occasionally information becomes out of date, and, alas, we are not infallible. Please email info@oss-watch.ac.uk with any corrections or qualifications.
It is licensed under the
Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
OSS Watch is funded by the Joint Information Systems Committee.