Open Development Method

From P2P Foundation
Jump to navigation Jump to search

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

Note: "Open Development Method or Community-led development should not be confused with the Community Source Development model (a specialised solution commonly found in HE, in which an initially closed group of universities collaborate on a software application and then choose to open it up at a later point)." [1]


Paul Anderson:

"The term open development method (ODM), or sometimes community-led development, has been coined to describe this collaborative way of working1. 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 Foundation2, 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." (

More Information

Via [2] :

  • 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.
  • SourceSense [3]
  • Meritocrats, cluebats and the open development method: an interview with Justin Erenkrantz
  • From a trickle to a flood: building wide open communities in open source - Community and Open Source Development Workshop, Oxford, 20 October 2008
  • Roles in open source projects
  • Readers who are interested in a ‘warts and all’ story of open development based on an educational institution are referred to JÄRVENSIVU, J. & MIKKONEN, T. (2008) Forging a community - Not: Experiences on establishing an open source project. IN RUSSO, B. (Ed.) Open Source Development, Communities and quality. Milano, Italy, Springer