The Evolution of Open Source Software Introduction 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 principles 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 1 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 undervalued. 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 (www.linuxchix.org). 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 extent. 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. Conclusion 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.
Pages to are hidden for
"open source software 2"Please download to view full document