Gain contributors, improve code and achieve sustainability

by Simon Hettrick, OMII-UK

Back to index page

Previous article: Access Grid move into further education

Next article: BioCatalogue: a curated catalogue of Web Services for the life sciences

Imagine a team of contributors writing new and improved code for your project. Add to this an ever-expanding knowledge base and the elusive goal of sustainability, and it’s easy to see why many projects are attracted to open development – including OMII-UK’s OGSA-DAI and Diaser projects. If you want to know more about open development, there are few better people to speak to than Ross Gardler, the Manager of OSS Watch. Aside from being an advocate for open development, Ross benefits from a long history of contributing to open-development projects and is also a member of the prestigious Apache Software Foundation.

There is no formal definition of open development, with different groups choosing to define the term in different ways. Ross bases his definition on the benefits ‘open development is a very effective way of producing software that satisfies the needs of the users that you have, and those that you don’t know about’. This sounds too good to be true, but with each new contributor comes new knowledge and expertise. The result is a broad knowledge base that would be difficult and expensive to produce by conventional means. However, it is probably the promise of sustainability that is the main attraction of open development. Closed-development’s reliance on a fixed team of developers means that the departure of a developer can be a major set back – or could even spell the end of the project. By contrast, the fundamental design criterion of open development is that contributors can come and go. The loss of a contributor may be unfortunate, but the project will continue.

Although the term itself may defy easy definition, there is more agreement on what is needed before one can assume the mantle of open development. In order to get your message out to your users, you will need a dissemination device. This is generally a website. An issue tracker is necessary to allow feature requests to be made and bugs to be tracked. A revision-control system provides access to the latest development source code and allows multiple developers to work on the same code base simultaneously. Finally, there must be a communications’ channel, typically a mailing list, that allows anyone to contribute regardless of geographical location. The communication channel is also important for building up a project memory. This legacy allows new contributors to look into the project’s history, and find out why decisions were made or new features were added.

Contributors are the lifeblood of an open-development project. But how does one attract them? Ross follows a simple equation ‘It’s basic economics’ he says ‘the key thing is to make sure that you give every single contributing member more back than they give you’. Ross takes his own experience as an example. He first experienced open development as a Ph.D. student when he used software that was based on Apache Forrest. Ross wrote an enhancement for the software, which he submitted to Apache. Apache benefitted when they received the new code, but Ross benefitted more, because he started off with robust software that he didn’t need to code from the ground up.

There’s a third beneficiary too. The community benefitted, because other people could now use Ross’s new code. It is mutually beneficial encounters like this that help an open-development community to grow around a project. This is certainly the case for Ross, who continues his collaboration with Apache to this day.

Many closed-development companies are becoming more open to being open, and this trend looks set to continue. Modern software development is becoming more collaborative, and it is this reliance on collaboration that will fuel further uptake of open development. As Ross explains ‘If you don’t have open development, you don’t have transparency. If you don’t have transparency, you don’t have trust. And if you don’t have trust, people cannot collaborate.’

www.oss-watch.ac.uk

www.tinyurl.com/kupogg