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.
1. 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
-- OSS Watch wiki
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
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 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, 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
Ross Gardler, 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.
2. 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.
3. 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.
4. 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?'
5. 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, 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
6. 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.
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.
8. Further reading
Related information from OSS Watch:
This document is © Intelligent Content 2009.