open source software 2 by lindash


									             The Evolution of Open Source Software

Routine development of software within organizations all over the world remains
highly problematic. The term ‗software crisis‘ was long ago coined to refer to the
tripartite software development problems: namely, that a vast number of software
projects exceed their budget, fail to conform to their development schedule, and do
not work as expected when eventually delivered. In recent times, the open source
software (OSS) 1 phenomenon has attracted considerable attention as a seemingly agile
practice-led initiative that appears to address each of the three aspects of the software
crisis: cost, time-scale and quality. Open source products are freely available for
public download. Thus, the cost issue is immediately addressed. From the point of
view of development speed, the collaborative, parallel efforts of globally-distributed
co-developers has allowed many open source products to be developed much more
quickly than conventional software. In terms of quality, many open source products
are recognized for their high standards of reliability, efficiency and robustness, and
the open source phenomenon has produced several ‗category killers‘ (i.e., products
that remove any incentive to develop any competing products) in their respective
areas – Gnu/Linux, Apache, Bind all spring to mind. The open source model also
appears to harness the most scarce resource of all – talented software developers. The
resulting peer review model, comprising extremely talented individuals, serves to
ensure the quality of the software produced. This is the essence of the argument from
OSS advocates.
However, the OSS concept itself is founded on the paradoxical premise that software
source code—the ‗crown jewels‘ for many proprietary software companies—should
be provided freely to anyone who wishes to see it or modify it. Indeed, the OSS
phenomenon is fraught with tensions and paradoxes, both in its early form, and as it
has evolved to become a more hybrid phenomenon. This paper will consider some of
these tensions in paradoxes in the initial emergence of OSS, including
       The collectivist v. individualist issue: the tension between OSS as a
        collectivist phenomenon and an individualistic phenomenon driven by a
        reputation-based culture
       OSS as a paradigm shift in software engineering: the cathedral v. bazaar issue,
        and the extent to which OSS fundamentally contravenes software engineering
       The alternative connotations of ‗free‘ i.e. zero cost or unrestricted access, and
        the significance of both meanings
We will then consider the recent emergence of the more hybrid form of OSS which
we term OSS 2.0. Again, there are a number of tensions and paradoxes which threaten

 As with many technology-related issues, terminology is a controversial matter. We use the term OSS
here, bowing to contemporary popular usage, but intend it to be an umbrella term covering Free
Software, Libre Software (the more common and less ambiguous term often used in Europe) and Open
Source Software.
its stability. Here we will focus on the alternate connotations of value.

Collectivist v. Individualist?
Within OSS, there is a tension between the altruism of the apparently collectivist OSS
community and the inherent individualism that a reputation-based culture such as
OSS also implies. The OSS movement is often portrayed as a collectivist approach;
Bob Young, the founder of Red Hat adapted the communist manifesto to characterise
it as ―from the programmers according to their skills, to the users according to their
needs‖ (Young, 1999). Certainly, the massive parallel development—the Linux
development community is variously estimated to exceed 40,000 or a staggering
750,000 contributors—and the devotion of time by skilled programmers many of
whom operate without a direct monetary incentive seems to support such a collectivist
view. Also, when Linux won the product-of-the-year award from InfoWorld, the
editors at InfoWorld complained that they were unsure as to whom the award should
be presented as there was no legal owner for Linux. This fuels the collectivist anti-
property perception, although OSS actually is quite strong on property rights—they
are vested in the author through copyright, with very liberal rights granted to others
under license. Indeed, OSS authors are free to revoke rights and distribute code in a
proprietary mode if they so wish.
Another factor in keeping with the collectivist notion is the requirement for modesty
and self-deprecation on the part of the originators of OSS projects as they have to
convince others to volunteer their efforts in the belief that their input is required. That
is, if a developer initiating a OSS project conveys the impression of being on top of
things and no help is needed, then the project will not achieve the momentum required
for a OSS project. In this vein, Torvalds openly and modestly sought help with Linux
from the outset. Also, the suggestion that all contributions are valued reinforces the
appearance of collectivism. Rather than just accepting strong technical coding
contributions, the argument is that those who cannot write code can write
documentation, fulfil the role of testers, or elaborate requirements. Thus, the
traditional hierarchy in IS departments, whereby the program coding activity is
considered ‗superior‘ to the testing and documentation activities, is countered in the
OSS approach, thus ensuring that these vitally important activities are not
Also contributing to the collectivist, public good perception of open source software
is the fact that it is portrayed as of huge importance in the so-called developing
countries who cannot afford the high prices demanded by the vendors of proprietary
software. This ties in with the media portrayal of OSS as a David v. Goliath
phenomenon, where the poor struggle with the fabulously rich.
However, there is also very strong evidence to support the view that OSS is at heart
an individualist phenomenon. The OSS culture is fundamentally a reputation-based
one, and is underpinned by the economics of signalling incentives on the part of
individual developers (Lerner & Tirole, 2000). The signalling incentive term is an
umbrella one capturing both ego gratification and career concern incentives, both of
which are briefly explained next.
The ego gratification incentive operates on the basis of peer recognition. Developers
working on traditional development projects may face long delays in getting feedback
on their work. After all, the average project development lifecycle has been estimated
to be 18 months (Flaatten et al., 1989), and durations of up to five years are not
unknown (Taylor & Standish, 1982). Thus, developers experience a significant ‗rush‘
from seeing their code in use more quickly in OSS projects. Also, the recognition is
from peers they truly respect often, rather than from managers and users within their
own organisation. Bergquist and Ljungberg (2001) discuss the OSS developer
motivational issue also in some detail and they refer to the phenomenon as obeying an
attention economy, in that the more attention a developer can attract the greater the
enhancement of status that is achieved. Thus, in this context, OSS development may
be more akin to Egoist Programming as opposed to Egoless Programming, the term
coined by Weinberg (1971).
The career concern incentive relates to the fact that working on a OSS project may
enhance future job prospects. Linus Torvalds states that his reward for working on
Linux is the fact that he will never have any difficulty in getting a job—his CV, as he
puts it, contains just one word: Linux. Thus, a significant motivator of participation in
OSS development is the belief that it will improve a developer‘s own coding skills
and help improve career prospects. However, reputation may scale far less than first
anticipated in that only a small handful of people may actually achieve widespread
name recognition. One of the findings of the FLOSS large-scale survey of OSS
developers worldwide (Ghosh et al., 2002) was that respondents were as likely to
report knowing fictional developers (names made up for the study) as much as actual
developers when it got beyond the first few well-known names.
Also, the collectivist notion that all OSS contributions are valued, and that literally
thousands of globally-located developers and users contribute unproblematically to
open source products does not bear up to examination. In the case of BSD, McKusick
(1999) admits that 90 percent of contributions were thrown away. In a study of the
Apache project, Mockus et al. (2000) found that almost 85 percent of modification
requests by users were totally ignored. Alan Cox, a central figure in the development
of Linux, has admitted that most contributions are worthless, suggesting that they
actually support the argument that one should need a license to get on the Internet,
and that there are a lot of ―dangerously half-clued people milling around‖, and that
those of proven ability are well known within each product development community
(Cox, 1998). Such evidence is not indicative of a collectivist atmosphere (although
historically one could argue that elitism has frequently bedevilled communism).
Ironically, the ‗engine‘ that drives the surprising success of the OSS model appears to
hinge on successfully managing this tension between collectivism and individualism,
in that the spirit of cooperation among developers and projects is a powerful enabler
to the individual developer heroics that arise due to the healthy competition between
developers and projects.

OSS as a Paradigm Shift in Software Engineering – The Cathedral
v. the Bazaar?
The proponents of OSS argue that it results in very high quality software, produced in
a rapid time-scale and for free. These three aspects directly address the so-called
‗software crisis‘ mentioned earlier. Some evidence to support this claim arises in the
case of Linux, which began five years after Windows NT with no budget and relying
on voluntary contributions. Yet, new releases of the kernel were being produced at the
rate of more than one per day at one point. Furthermore, proponents of OSS also
argue that feedback is very prompt, the testing pool is global, peer review is truly
independent, the contributors are in the top 5 percent of developers worldwide in
terms of ability, and they are self-selected and highly motivated—code inspection and
critique, for example, even though optional in OSS has been found to far outperform
conventional inspection (Lussier, 2004). Given these factors, the argument becomes
even more cogent that OSS truly is the ‗silver bullet‘ that can solve software
development problems. However, even more surprising is the fact that this ‗silver
bullet‘ seems to arise from a process which at first glance appears to be completely
alien to the fundamental tenets and conventional wisdom of software engineering, to
the extent that OSS might be labelled a paradigm shift in fact. Raymond‘s (1999)
attention-catching metaphor of the cathedral v. the bazaar reflects this. He
characterised conventional software engineering as akin to a cathedral of highly
formalized, well-defined and rigorously-followed development processes. He
contrasted this with a bazaar style of development, which better characterised the OSS
development approach. The bazaar metaphor was chosen to reflect the babbling,
apparent confusion of a middle-Eastern marketplace. In terms of software
development, the bazaar style does not mandate any particular development
approach—all are free to develop in their own way and to follow their own agenda.
There is no formal design process, no risk assessment nor measurable goals, no direct
monetary incentives for many developers, informal co-ordination and control, much
duplication and parallel effort. There is no formal procedure to ensure that developers
are not duplicating effort by working on the same problem unknown to each other. All
of this is anathema to conventional software engineering. For example, duplication of
effort would be seen as extremely inefficient and wasteful. However, in the open
source bazaar model, this optimistic concurrency leads to a greater exploration of the
problem space, and is consistent with an evolutionary principle of mutation and
survival of the fittest, in so far as the best solution is likely to be incorporated into the
evolving software product.
However, 30 years of software engineering research cannot be easily discounted. An
examination of the details of the OSS development process serves to question the
extent to which software engineering principles are actually being fundamentally
overturned. Firstly, the main contributors of the OSS community are acknowledged to
be superb coders. Also, as they are self-selected, they are highly motivated to
contribute. The remarkable potential of gifted individuals has long been recognised in
software engineering. Brooks (1987) suggests that good programmers may be a
hundred times more productive than mediocre ones. The Chief Programmer Team
more than thirty years ago also bore witness to the potential of great programmers.
Also, in more recent times, the capability maturity model (CMM) recognises that
fabulous success in software development has often been achieved due to the ―heroics
of talented individuals (Paulk et al., 1993). Thus, given the widely recognised talent
of the OSS leaders, the success of OSS may not be such a complete surprise.
Furthermore the advancement of knowledge in software engineering has certainly
been incorporated into OSS. Linux, for example, benefited a great deal from the
evolution of Unix in that defects were eliminated and requirements fleshed out a great
deal over the years. Also, some of the fundamental concepts of software engineering
in relation to cohesion, coupling and modularity of code are very much a feature of
OSS. Modularity is critical for the OSS development model for a number of reasons.
Firstly, it allows work to be partitioned among the global pool of developers. Also, as
projects progress, the learning curve to understand the rationale behind requirements
and design decisions becomes extremely steep. New contributors need to be able to
reduce their learning curve below the level of the overall project. Modularity helps
achieve this and is a sine qua non for OSS. Many OSS projects were rewritten to be
more modular before they could be successfully developed in a OSS mode, including
Sendmail and Samba, and even Linux itself. Indeed, the manner in which different
individuals can take responsibility for different self-contained modules within Linux,
is acknowledged as being a major factor in its successful evolution. Configuration
management, another important research area within software engineering, is a vitally
important factor within OSS, and is typically catered for by the Concurrent
Versioning System (CVS), itself an open source product. Also, the software
engineering principles of independent peer review and testing are very highly evolved
to an extremely advanced level within OSS.
These examples illustrate that OSS development does conform to certain fundamental
tenets of software engineering in relation to modularity. Furthermore, while a cursory
inspection might suggest that OSS is characterised by a bazaar development approach,
it is certainly the case that OSS development is not completely homogeneous. There
are significant inter-project differences in the way development is organised in Linux,
Apache, and the various BSD open source projects (Nakakoji & Yakamoto, 2001).
Indeed, the rigorous and ritualistic approaches mandated in some of these projects
would ironically be quite well characterised by a cathedral metaphor. This issue will
be discussed later.
Much of the early rhetoric on OSS was quite evangelical in asserting the high quality
of OSS products, and this is still a feature in some accounts (Norris, 2004). Also, a
rigorous comparison by the Reasoning Inc. group of MySQL, Linux TCP/IP stack and
Sendmail did find these OSS products to have a lower defect density than proprietary
equivalents (Mimoso, 2003). However, universally high quality in all OSS products
can by no means be taken as a given. A study by Stamelos et al. (2001) addressed this
specific issue in relation to the SuSE Linux 6.0 release. Using the Logiscope code
analysis tool, they examined over 600KLOC across 100 modules. In brief, their
overall conclusion was that only 50 percent of the components were of an acceptable
standard as is, with the remaining 50 percent requiring some intervention, including 6
percent of modules requiring a complete rewrite. In the same vein, a study by
Rusovan, Lawford and Parnas (2005) of the implementation of the Address
Resolution Protocol (ARP) in the Linux TCP/IP implementation identifies a nu mber
of software quality problems.
In summary, then, the code in OSS products is often very structured and modular in
the first place, contributions are carefully vetted and incorporated in a very disciplined
fashion in accordance with good configuration management, independent peer review
and testing. Thus, on closer inspection, the bazaar model of OSS does not depart
wildly from many of the sensible and proven fundamental software engineering
principles. The argument that OSS begins as a bazaar with a chaotic development
process and evolves mysteriously into a co-ordinated process with an exceptionally
high quality end-product is too simplistic a characterisation of what actually is taking
place in practice.

The Alternative Connotations of ’Free’
It is a common misconception that OSS is of zero monetary cost. However, ‗free‘ in
this context is intended to connote ‗freedom‘ rather than ‗zero cost.‘ In English the
term is ambiguous, but not in many other languages which have different words for
‗freedom‘ and ‗no cost‘. Thus, Libre Software is term commonly used in Europe,
where FLOSS (Free/Libre/Open Source Software) is a widely-used umbrella term.
The ambiguity of the term free is significant though. Despite the fact that OSS
advocates intended ‗free‘ to mean unfettered or unrestricted, and had no objection to
making money from free software, there was still a widespread perception, especially
in business circles, that free software was zero cost software and more or less
synonymous with freeware. The term ‗open source software‘ was chosen to avoid this
perception. However, in the current climate of severe financial cutbacks, in many
companies, free as in zero cost is a far more compelling reason to adopt OSS than free
access to source code. Indeed, these organisations are not likely to distinguish
between freeware, public domain, shareware and OSS (Fitzgerald & Kenny, 2003),
despite the enormous emphasis placed on such differentiation by OSS advocates.
Even allowing for the fact that ‗free‘ does not necessarily mean ‗zero cost‘, the basic
premise that software source code—the ‗crown jewels‘ for many proprietary software
companies—should be provided freely to anyone who wishes to see it or modify it, is
a major paradox for the software industry which has relied on the fact that compiled
binary software code is unreadable and therefore protected. The change in mindset to
identify profitable business models in the OSS context is significant, and we will
return to this issue later.

The Emergence of OSS 2.0
We contend that in recent times, the commercial orientation in OSS has become
especially pronounced. We term it OSS 2.0 here, and identify a major tension in the
value for money proposition versus appropriate community values. The term ‗value‘
has several meanings, two of which are of central concern to OSS 2.0—value for
money and acceptable community values. The integration of OSS into the commercial
arena and the associated desire to create value and profit represents a constant source
of tension, given the concomitant need to achieve balance with the collectivist, public-
good community-values.
‘Value for Money’ v. ‘Acceptable Community Values’
OSS 2.0 can dramatically alter the economic dynamics of the marketplace. Despite
the vast sums of money involved and the enormous economic potential of OSS 2.0, it
is a fact that it erodes certain hitherto profitable markets, the multi-billion dollar
operating system market being the most obvious example. Red Hat who have been by
far the most financially successful company distributing Linux have annual revenues
of about $90 million. However, this pales into insignificance beside Microsoft‘s $32
billion dollar annual revenue. Linux may be creating massive revenues in the
hardware server market place, but not for operating system software. A similar
scenario is likely to occur in the erosion of the MS Office market-share by Open
Office. Thus, OSS 2.0 decimates the traditional profitability of many sectors.
As OSS 2.0 emerges, those involved are seeking pragmatically to make money from
their endeavour. While OSS 2.0 organisations may not aspire to Microsoft-like annual
revenues, or even to match Red Hat annual revenues, they are seeking to make payroll
and earn a reasonable livelihood. Both the customer and the developers need to
perceive value for money in OSS 2.0. Free as in zero cost is replaced by a value for
money concern, and OSS 2.0 customers are prepared to pay for a professional service.
This is very evident in the fact that many companies are prepared to pay a fee for Star
Office with associated support and warranty, rather than the zero-cost Open Office
alternative. Furthermore, OSS 2.0 product installation will become more user-friendly
to the mass-market, eliminating the need for in-depth technical knowledge to get
products up and running, which has all too frequently been the case up to now—
requiring a consumption of time that exceeded what time-impoverished users were
prepared to commit.
While OSS 2.0 is perceived as attractive due to the need for cost reduction in
organizations, one must bear in mind the complex socio-political context in which
OSS 2.0 products are deployed. Cost reduction may not be appreciated to the same
extent by all stakeholders. A case study at Beaumont Hospital (Fitzgerald & Kenny,
2003) reports how the hospital managed to achieve considerable savings by deploying
an X-ray system using open source components. However, there was some resentment
to the new system in the radiology department. This is a complex issue but some staff
felt somewhat ‗short-changed‘ in that they expected to spend about €4m on an X-ray
system, just like their counterparts elsewhere using proprietary systems, and the
deployment of a much cheaper open source alternative was perceived as ‗devaluing‘
the radiology department to some extent.
A similar issue arises in the relation to OSS in developing countries. The seemingly
obvious attraction to poorer institutions there is especially interesting as the issue is
actually not as simple as it is often portrayed. An excellent description of failed
attempts to initiate OSS projects in Ghana by Zachary (2003) identifies fundamental
problems due to the widespread belief among Ghanaian programmers and users that
nothing of value could be done for free, and concludes that OSS concepts would need
to be considerably ‗Africanized‘ in order to have a chance of success. Indigenous
software developers there could not accept that an initiative which was based on free
software could have any value. They aspired to a software industry based on the same
profit and market values as in developed countries. Value depends on values, and the
above examples illustrate that this varies considerably across cultural and
organisational contexts.
Acceptable Community Values
Maintaining OSS-compatible community values will represent a very significant
balancing act for OSS 2.0. Large commercial organisations are not always well
perceived within the OSS community. This issue will become even more important as
organisations seek to profit financially with OSS 2.0. They will have to adhere to a set
of acceptable community values. This represents a very interesting dilemma for
companies. We have already seen in the discussion of patents that IBM can be both
hero and villain at the same time to OSS developers. Also, the quintessential patron of
OSS, Red Hat, could struggle in future as its policies increasingly conflict with
community spirit and values. The use of subscription agreements and effectively
locking customers in with confidential service bulletins are probably moving close to
the boundary of acceptable community values. Many complain of Red Hat seeking to
become Microsoft, but such attempts to generate revenue are inevitable in OSS 2.0.
Nevertheless, the power of community should not be underestimated. A telling
example of this was the attempt by Caldera (now SCO) to sell its Linux distribution
which failed due to the extremely negative reaction of the OSS community.
In the Beaumont Hospital case, two examples of positive value-laden behaviour were
evident. Firstly, Beaumont are making a suite of in-house developed applications
available in an open source mode. They recognise that realistically they will not be
able to make significant code contributions to many of the products they use—
GNU/Linux, for example. However, they can and are willing to contribute in areas
where they have specific expertise. If this initiative was repeated in other cases it
would serve to grow the OSS 2.0 model in vertical domains where hackers might not
perceive ‗an itch worth scratching‘ otherwise. Overall, this could lead to significant
expansion of the OSS 2.0 phenomenon as more applications become available to
organizations in new vertical markets.
In Beaumont, what has also been particularly striking has been the sense of ownership
that the nursing staff have developed for the nurse rostering system which is being
made available as open source. These end-users have been very active in
demonstrating the system to other hospitals. Interestingly, their nursing counterparts
in other hospitals have been swayed very much by the positive attitudes of their
professional colleagues. Ironically, as already mentioned, female participation in OSS
development has been minuscule—the linuxchix initiative notwithstanding
( Given the predominance of females among the nursing staff
and the enthusiasm with which they have embraced the ideology of OSS, this suggests
that the movement overall could leverage this sector of the population to a greater
In a similar fashion, the spirit of OSS 2.0 can lead to some very positive network
externality effects. In the Beaumont Hospital case, users of the same products from
other countries travelled to Beaumont to volunteer support and offer extra
functionality that they had developed. The expectation was that Beaumont would
reciprocate by making available any extra functionality they developed. Cooperation
of this nature is pretty much unheard of in the proprietary marketplace.
Again, just as maintaining a healthy balance between collective cooperation and
individualist competition was the engine for OSS, the engine that will drive OSS 2.0
will be the balance between achieving an appropriate value for money proposition
while still satisfying the scrupulous community values required by the development
community to commit support and maintain credibility for the brand.

While the main impetus behind the success of OSS has not been that it is a paradigm
shift in software engineering—it is not, in fact. Rather, the main driver has been the
competitive element among developers and projects who have sought to excel to
impress in the reputation-based individualist culture, while also taking advantage of
the network –enabled collaboration which has provided the platform on which to
build this achievement. However, a further driver in OSS 2.0 will be the effective
resolution between achieving value for money as both developers and customers seek
to make a livelihood from OSS 2.0, while also adhering to the accepted values of the
development community.

To top