Avoiding abandon-ware: getting to grips with the open development method

by Paul Anderson on 2 June 2009 , last updated 8 November 2013

Introduction

Open source is more than a style of licence. While it’s true that the formal Open Source Initiative (OSI) definition lists a number of licences and distribution-related points, the big picture summary on the OSI’s homepage paints a rather different picture:

‘Open source is a development method for software that harnesses the power of distributed peer review and transparency of process.’

This definition puts a different slant on the distinction between open source and proprietary (or closed source) software. By highlighting the social manner in which software is actually created (the involvement of a wide range of people, including software developers, researchers and users, and the public way in which they work) it moves the focus away from licensing and distribution. As open source becomes increasingly popular, with more and more people wanting to label their software as open source, this distinction is important. It is becoming necessary to return to the founding principles of open source in order to explain the original vision more completely.

Introducing the Open Development Method (ODM)

Open development is an emerging term used to describe the community-led development model found within many successful free and open source software projects.

The term open development method (ODM), or sometimes community-led development, has been coined to describe this collaborative way of working¹. In this model, there is primary emphasis on collaboration and the role of a community. Gianugo Rabellino, former CEO of SourceSense, a leading European open source services company says: ‘To me, open development really is what open source [has always] been. So, open source was intended as a development methodology, as a way to build artefacts, which happen to be software, in a collaborative way which is based on transparency, on meritocracy and on neutrality [over ownership] and you need all of them.’

In fact, some researchers argue that open source projects can be placed on a continuum that stretches between ‘fully open’ and ‘fully closed’, based on an evaluation of the project’s management and governance styles and an appraisal of the ‘openness’ of the project itself rather than the software produced (Capra and Wasserman, 2008). ODM-based projects sit at one end of this.

This view is backed up by practitioners actually working on open source software, some of whom argue that a distinction between what are loosely called ‘open source’ and ‘open development’ projects is beginning to emerge. Developers involved in the former remain focused on licensing and distribution issues, while in the latter it is the processes of the project that matter. Justin Erenkrantz, fomer President of the Apache Software Foundation², says: ‘You are really starting to see perhaps not a split but kind of two camps: you have the open source but on the other hand you have the open development.’

Justin cites the fact that all the work takes place in public as being the important distinction. He says: ‘What we are seeing is some projects and entities who are saying here is the source code, it is under Apache licence or GPL or whatever, but the decisions about how the code got to that state are behind some wall – it is not in public.’ This, he argues, is detrimental to the process of coding. Although the end product might be formally classed as open source, it is not a good way to develop sustainable products. He says: ‘You can use it and you have all the rights, but what you don’t have as a developer is an understanding of how the code got that way. So you run into some bug and you say, “Why is the code this way?” There is no historical context or archiving or rationale.’

For Gianugo, this public way of working means that ODM represents a re-balance of the power between developers and users. He says: ‘I am not going to collaborate on something that I don’t feel any sense of belonging to … There is no open development if I cannot influence and have my say in what we do and what we are trying to build. That is not open development, that is free labour!’

Ross Gardler, fomer Manager of OSS Watch³, believes that ODM can be formalised by looking at a number of key attributes that characterise an open development community, namely:

a deep level of user engagement: if you don’t have users then there is no point having a project.
transparency: being open in what the community is undertaking and the way decisions are made.
collaboration: a means of working within a diverse group of people, something that the Internet has obviously made easier.
agility: once work begins and there is a serious engagement with users, ideas and plans may need to change.
sustainability: having the capacity to keep developing an application solution over the necessary period of time.
tools: wikis, bug- and version-trackers and email lists to support the development of the community and keep track of intellectual property rights, if relevant.

For Gianugo, agility is an interesting issue with regard to open development. He thinks that on the surface it does not look as though agile development methods and open development work together very well. He says: ‘If you think that one of the key ideas of agile is the unity of time and location – you need to be in the same place at the same time and doing a lot of discussion face-to-face – and then you have open development which is based on asynchronous, distributed working, etc., then it looks like oil and water – they don’t mix.’ He says this is an ongoing issue for developers and that SourceSense is working to find a set of common practices that might make open source more agile and agile development methods more open.

ODM and the Apache Software Foundation (ASF)

Many people cite the importance of the ASF to the emergence of the open development method and Gianugo, an Apache member, concurs. He says: ‘I believe that Apache is a sort of poster-child when it comes to open development, but this is not to say that there are not other organisations doing it - for example, Eclipse, and Mozilla to some extent. But if you look at Apache, what we want is really durable communities because we know that durable communities will keep on producing code.’ He likens these communities to diverse ecosystems whose survival is in part guaranteed by the very diversity of developers, service providers, technical writers, users and researchers involved in a typical, large Apache project.

Justin Erenkrantz traces the beginnings of the ODM back to the earliest days of the Apache webserver, which was to become the foundation’s first open source product. An early webserver being built at the National Center for Supercomputer Applications (NCSA) in Illinois was left unsupported when the staff moved to Netscape and the server’s technical users were left stranded. Informally, a group of concerned users started to share problems and fix bugs by email. Justin recalls: ‘They started trading patches and stuff. Independently all these guys were trying to maintain this kind of ball of mud. So they said let’s work together so that we can make something better than each one of us individually could make on our own.’ Making decisions and documenting them in public became a very important part of this ethos, as the developers wanted to make sure that the same thing could never happen again.

Education and the ODM

What are the implications of the ODM for higher and further education? At first it may seem that its most likely impact would be on the way in which e-learning, research and business systems software is developed. But the ODM way of working can be expanded beyond software. Juan Mateos Garcia and W. Edward Steinmueller, from the Science and Technology Policy Research Unit at Sussex University (SPRU) at the time of writing, note that: ‘The broader relevance … is the possibility that it might be a model that is applicable to a much broader range of activities involving the creation of common or public information goods’ (Garcia and Steinmueller, 2003). They argue that the Internet provides the capability to assemble large virtual communities that can support collective endeavour and that these endeavours need not be limited to software. They suggest different ways in which open development methods can be used for collective authoring, research projects and collaborative collection of information. This takes open source beyond the crafting and distribution of code and into the realms of new ways to undertake innovation.

For Gianugo, the ODM presents a significant challenge to education, which he argues is in danger of missing out on the opportunities offered by the open development method. He agrees that this goes far beyond the way in which software is developed for research, e-learning or administration projects. It also has implications for the ways in which universities create new knowledge.

A new research model

Gianugo points out that the existing research model of dissemination through peer- reviewed journal-paper publication (and academic reward schemes based on these outputs) may need to be reviewed in the light of recent developments. He says: ‘The problem is that this research model is clearly colliding with what the collaboration world is telling us. There is a risk of becoming less relevant.’ Universities have to do much more to encourage reach-out from their research work, to engage the wider public and, most importantly, to allow others to build on what they have achieved. Continuing with traditional communication routes means that important research material may not see the light of day, experimental data may not be shared and software projects might become what he calls ‘abandon-ware’. This is especially true of research projects that make use of code, which should be developed using the same development environments and source code versioning systems as open source code anyway. It is a short step to opening this up to others. He says: ‘I can’t imagine anyone doing any serious [software engineering] work without software configuration, versioning tools and so forth and so at that point, since you need it anyway, why not do it using the open methods?’

A way forward?

For Gianugo, there is merit in exploring ways in which experimental data and early research results could be shared before formal publication. If this is seen as a bridge too far, then he suggests that institutions experiment with an internal community of researchers that uses the open development method. He goes further, though, arguing that this needs to be tackled strategically and that the way in which academic reward is distributed needs to be rethought. There should be more interest in widening the peer-review process to reach out from the university world. He says: ‘On the strategic side, if the whole rating system, star ratings, is broken, well let’s fix it. The Internet is paving the way for an entirely new recognition system, an entirely new ranking system. I don’t see why the Internet shouldn’t be harvested to sort of rate whether a researcher is doing a good job in terms of out-reach.’

Gianugo also argues that researchers need to make more use of the tools and techniques that are now common in open source development. He says: ‘Forums, mailing lists, the whole idea is that here is the source code, here is the repository, so everything goes there and by the way here is a Wiki attached to it and a mailing list. It doesn’t really matter if no one subscribes to it [at first], but eventually there will be someone willing to do that and I would say education needs to make more use of these tools.’ Andrew Savory, former Open Source Manager for the LiMo Foundation⁴, warns, however, that the quality of this kind of support infrastructure has to be high. He says: ‘I’ve worked in some environments where the checklist had been done - licence, wikis, mailing lists, code repository, issue tracker – but the infrastructure put in place was simply not up to scratch. This can kill a community before it has a chance to start!’⁵

Towards a long-term solution

Introducing the ODM to the education world may, however, be a significant challenge. Andrew advises that education needs to understand the benefits and drawbacks of the ODM and to work hard to determine when and where it’s most appropriate to use it. He also notes that: ‘It takes a particular type of person, and not everyone can cope well with the mindset required.’ Gianugo thinks that this will require long-term thinking and he argues that the key might be to focus efforts on training the next generation of researchers and education-based code developers in the new techniques. He cites the Google Summer of Code initiative as one example to follow.

The Open Development Method offers a new way of developing both software and other knowledge-related products. Its focus on openness and community should chime with the general ethos of education and it presents a significant opportunity to develop more sustainable knowledge products and avoid ‘abandon-ware’. But changing the requisite educational working practices is a long-term process that requires commitment and planning. Even when education really wants to change it will need help in understanding the lessons learned from open source software development. It appears that the challenge is as much to the open source community to offer this kind of help as it is to education itself to change.

References

CAPRA, E. & WASSERMAN, A. (2008) A Framework for Evaluating Managerial Styles in Open Source Projects. IN RUSSO, B. (Ed.) Open Source Development, Communities and Quality. Milano, Italy, Springer.

GARCIA, J. & STEINMUELLER, E. (2003) The Open Source Way of Working: a New Paradigm for the Division of Labour in Software Development. SPRU Electronic Working Paper Series. University of Sussex.

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.