Open Source Software
A Literature Review
Introduction
This literature review paper will assess the existing research in the emerging topic of open source software, identifying the common trends amongst the research in an attempt to find a common body of knowledge; it will also attempt to identify areas that need to be researched further, and better methods of research to be performed in areas suffering from the bias-like enthusiasm typical of a new field. Areas as different as academic discourses of open source theory and ideals, and the application of open source development to proprietary software in existing multinational corporations will be covered, and recommendations made as to what is relevant or not to the future of Open Source Software research.
Changes In Open Source Software
Similar to the general market for Information Systems, the market for Open Source products has changed a lot over the years, this has lead to changes in what Open Source development can do for organisations. The days of Free Software where the developers were generally users of the software are gone (Dahlander & McKelvey 2005), these days Open Source Software is more organised in the development phase, running along the lines of the commonly adopted SDLC. This is because Open Source Software is being increasingly implemented in complex vertical domains where the business requirements are not universally understood. Contrast this with older Open Source developments which were mainly software for horizontal domains (e.g. Operating Systems , Database Management Systems and Web servers) where the requirements are more obvious (Fitzgerald & Kenny, 2004).
The original development life cycle consisted of:
· Planning or perceiving ‘an itch worth scratching’.
· Analysis, which was mainly conventional, agreed upon knowledge between community members.
· Design which was based primarily on principles of modularity to achieve separate outcomes.
· Implementation, including coding, reviewing from the Open Source community, testing and parallel debugging.
The planning, analysis and design was mainly carried out by a single developer or a core group of developers. Modern Open Source Software follows this life cycle but the requirements are far more complex and tie in with organisational strategies, so much so that, in an increasing trend, developers are being paid for their work (Fitzgerald & Kenny, 2004).
Opening Proprietary Systems – The Hybrid Model
In 1999, Apple Computers, having suffered a torrid decade at the hands of their competitors took an unusual step in the development of their next generation of operating systems: they made it open source. Or rather, they allowed a degree of the open source ethos in the development of a better proprietary system. Fittingly they named this radical method of software creation "Darwin”.
Apple did not adhere to the free distribution and free editing espoused by the Free Software Movement, but they wished to ensure the embracing of their new platforms by the third party developers who had recently deserted them for a Windows monopoly environment. They stand out amongst the literature as one of the highest profile companies to follow this relatively new strategy (West, 2002, Bonaccorsi, 2003, and Wheeler 2005). Other high profile names to follow suit are IBM and Sun, each following different methods of melding OSS with in-house productions.
Apple and Sun both develop operating systems and systems software, and both have seen fit to use OSS as a leverage factor in catching up with their monopulous competitor. Examined in detail in the seminal paper “How Open is Open Enough?” (West 2002), their differing strategies provide an insight into the broader issues within ‘Hybrid Model’ development (Bonaccorsi, 2003). Where Apple made some parts of OSX/Darwin free-to-all, Sun made all of Java/SunOS partly free. The case studies performed by West do focus on each company as a single unit rather than the whole field of OSS theory and development, but when viewed with brief prior knowledge of the topics, it is clear his research offers very valuable evidence of justification for, and the benefits and costs of adopting “Free” software as a keystone of a multi-billion dollar firm.
Apple’s experience with OSX/Darwin development fell short of its hopes of user contribution. By 2002 it had 48 identifiable contributors, a long way short of the thousands involved in true open source operating systems such as Linux. By only opening the areas of the code that would benefit themselves most, they minimised the driving factor behind the majority of open source development – usefulness to the contributing parties. “By opening only part of its technology … Apple made it less valuable to user contributors. The fewer users that contributed to the Darwin sources, the less benefit Apple realized” (Bonaccorsi, 2003). We can see further evidence for the futility of this strategy in OSS theory essay “The GNU Operating System and the Free Software Movement” (Stallman, 1999) and more business orientated papers (Leading Edge Forum, 2005).
Sun faced similar problems retaining their dominant status within the server systems software market in the late nineties. Faced by increased competitive pressure from Microsoft following the explosion of the internet, Sun found its previous strengths – a high cost, RISC-platform dependant strategy useful for making as much money as possible from the relatively few large companies with use for its systems – were now used against it by Microsoft and other systems software developers. Sun’s bold move was to realign the company to a new strategy, and attempt to directly knock Microsoft’s grip from the market. By creating the platform independent Java and SunOS projects, Sun had unleashed an unknown quantity upon the market. Entirely open source, and available to be copied, edited and reused but with various complex licenses forbidding unauthorised reuse in proprietary software or distribution of its products, these “all open, partly free” projects allowed everyone to develop the tools they wanted, as long as it ultimately fell under the banner of Sun Microsystems. Java programming was intended to hurt Microsoft by allowing greater mobility of software solutions that would compete with Microsoft’s dominant applications, the prime example being StarOffice, later known as OpenOffice. This campaign to “free” businesses from conforming to Microsoft’s proprietary applications and file formats was closer to Richard Stallman and the Free Software Movement’s definition of free (free as in speech, not free as in beer) (Stallman, 1999 and West, 2003). The plethora of quantitative evidence of the benefits of entirely open source code compiled by “Why OSS? Look at the Numbers!” (Wheeler, 2005) supports the superiority of this form of the Hybrid Model, compared against partially open code á la Apple.
Critical Mass
“Products with big market shares get applications, trained users, and momentum that reduces future risk” (Wheeler 2005)
Network externalities, described in “Why Open Source Software Can Succeed” (Bonaccorsi, 2003) as “being caught in a virtuous circle”, are the affect on diffusion and adoption of a product caused by its current market share. The classic example is facsimile machines. Nobody wants to be the first person to buy a fax machine, as there is nobody to send messages to. With each additional fax machine sold, the usefulness of the machines increases and as such so does the rate of adoption. Eventually, a critical mass stage is reached, where it is in fact harmful to not own a fax machine.
Closed source projects and applications developed by firms as proprietary software can afford to spend sometimes enormous amounts of money marketing and providing support for new or emerging products. In the majority of cases, this cannot happen with open source projects. Network externalities affect open source software a good deal more than proprietary software – the more fellow users, the better support available, the faster development becomes, as more people are motivated to contribute to a project beneficial to themselves, and hence the quicker increase in market share. At some point, critical mass is reached, and everyone must sit up and take notice. (Bonaccorsi, 2003) The quintessential example of this in recent open source software projects is Mozilla Firefox.
Founded and aided by the former Netscape Browser team, Mozilla Firefox has proven an example of how innovative and user friendly a community-driven development can be. In 2001, Microsoft’s much maligned (and in retrospect, illegal) web browser Internet Explorer was the face franca for the world wide web – 96% of all web traffic was being displayed via its Windows-integrated interface. Web applications or websites that did not conform to Internet Explorers largely proprietary standards of HTML and other web technologies were destined for early extinction.
Mozilla's Firefox pitch was simple - fast, free and safe. These values made it immediately preferable to Internet Explorer, whilst more technologically aware users would appreciate its advanced features such as tabbed browsing and plug-in extensions. From the time of the release of version 1.0 in mid-2004 to the time of writing, Firefox was downloaded 250 million times. This 12% share of the market represents the software having passed a critical mass milestone; applications or wesbites can no longer be written without considering compatability with Firefox. In fact, with the release of Internet Explorer 7, which represents an improvement in IE's standards compliance, Microsoft were writing for compatability with sites which had adopted w3 and Firefox's standard. Firefox is expected to reach 25% of the market with the release of Firefox 3 in 2007 (Wheeler, 2005).
How did an open source, free application cut down a seemingly unbeatable application that was pre-installed on 99% of home PC's sold around the world? Different papers give different opinions, each with valid points. Open source software does not suffer from the same corporate policy restrictions or closed-group prejudices. While proprietary applications may be updated with stable releases at intervals of months or years, the motto in the open source community is "Just patch it". (Leading Edge Forum, 2004). Many OSS projects release "nightly builds" - todays version, today. The almost immediate remedy of bugs and security weaknesses means that the free software can be much safer for an industrial environment than tried-and-mistrusted systems such as Microsoft. As more users collaborate in the development of a project, even just by being unwitting bug testers, the pace of development increases, and critical mass can be reach with exponential speed. Despite clear quantitative evidence to the contrary (Wheeler, 2005) new open source projects are seen as a risk by industry leaders, who wish to be provided with official support and warranties. It is argued in several papers that the point of critical mass can be identified as the moment in time when industry no long considers an application as a project, instead as a product with a viable support community.
Free Software vs. Value for Money
Before Open Source Software, initiatives were referred to as ‘Free Software’ (this was before the Open Source term came about). This led to confusion over the term ‘free’, the term is meant to indicate free as in 'libertas', e.g. freedom of speech. It is not intended to mean free as in gratis, e.g. free samples at a supermarket. For the commercial community, the latter connotation was generally assumed because the commercial community stood to save more money from free software. Thus, the Open Source Software term, meaning software development whose source code is freely accessible in the worldwide community of users and developers, was created to end this confusion (Feller & Fitzgerald 2000). This in turn led to a split between the Free Software Foundation and the Open Source Initiative. Although the two organisations are at odds over basic ideology, they don’t see each other as enemies, to an extent. The Free Software Foundation sees Open Source as ambiguous and they (the FSF) pride themselves on being the creators of the anti-propriety software community (http://www.gnu.org/philosophy/free-software-for-freedom.html).
However, the Open Source Software products are differentiating themselves from the Free Software Foundation ideology by focusing more on Value, (i) value for money and (ii) value for accepted (Open Source) community values (Fitzgerald 2006). These Open Source Software products should not be confused with ‘freeware’ products, ‘shareware’ products, ‘use-restricted’ products, or ‘royalty-free’ products (Feller & Fitzgerald 2000).
Value for money is based around the impact that Open Source Software can have on the economic dynamics of a marketplace (Fitzgerald 2006). Even though Open Source Software products have enormous potential for money to be made, this comes at a cost to previously profitable markets, for example, the market for Operating Systems. This market is dominated by Microsoft to an extent that the following mantra has evolved: “If you can’t be the number one product in the sector, then open source it.” Ideologically, developers of Open Source Software are not looking to recoup massive profits from their products but seek to earn a reasonable livelihood for their work (Everitt 2004). So both the developer and the customer of an Open Source product must have what is referred to as a ‘perceived value for money’ for the product. Customers are willing to pay for Open Source Software but along with the software itself, there needs to be something of value included. For example, many organisations are willing to pay for a version of Sun’s StarOffice that comes with technical support, troubleshooting and warranty as opposed to adopting the free version that doesn’t include these features alternative (Fitzgerald 2006 and Fuggetta 2003). This is an example of choosing Open Source Software with an associated value as opposed to choosing free software.
Popular opinion would have it that in order for Open Source to be pushed forward there must be a core group (or community) of ideological followers to maintain success (Walker 2006). Companies that develop Open Source Software (RedHat and Novell) as well as companies that are increasingly moving towards it (HP and IBM) must still meet certain criteria with regards to acceptable values of this community (Fitzgerald 2006). This is one of the most difficult parts of developing Open Source Software, as many of these large corporations are not always well perceived within the Open Source Software community. For example, HP and IBM support some Open Source initiatives and innovations but are at odds with Open Source ideology as they support patents in relation to these products (Chae & McHaney 2006). The use of customer subscriptions is also at odds with the Open Source community, for example, MySQL recently decided use the SCO groups OpenServer platform but they decided to charge people for the privilege.
Although it made financial sense and generated substantial profits for SCO, this move was met with a lot of criticism from the Open Source community. The reaction of the OS community is not something to be made light of; this can be seen by the failed attempt of Candera to sell its Linux distribution (Fitzgerald 2006).
Reasons for Adopting Open Source Software
Before Open Source Software, organisations had two choices when acquiring software, to buy or to build. My research shows that Open Source Software provides a very viable and attractive alternative. Over the last few years the amount of Open Source initiatives has dramatically increased to such an extent that it draws a comparison to Moore’s Law (Fitzgerald 2006). This section takes a look at some of the reasons why this trend is occurring.
Modern Open Source Software has created a market for itself through a loss leader approach; it is sold for less than its true value in an effort to stimulate future sales and business. For example, IBM recently moved its Eclipse Integration Development Environment (IDE) to open source. Even though this move caused a general sense of surprise in the market (the source code was reputed to be worth in the region of forty million dollars) it substantially improved IBM’s image and popularity (especially within the Open Source community) for this environment, ensuring IBM could expand the market for complementary products and reap the commercial benefits (Fitzgerald 2006).
Another reason for adopting Open Source Software is the flexibility it offers. For example, in 2003 when China, Japan and South Korea announced that they would develop and promote Open Source Software as well as showing preference to Open Source Software over propriety software, one of the main reasons cited was so they could develop software to support Asian languages (that typically have more characters than Western languages). As most proprietary software is based in the Western world (e.g. Microsoft, Sun and HP), it is prone to be a little culturally insensitive, Open Source Software can be specifically tailored to remedy these concerns (Chae & McHaney 2006).
Security is paramount in any software initiative, especially in relation to software developed for government services and administration. Since governments are one of the principle users of IT in the world (Dahlander & McKelvey 2004 and Chae & McHaney 2006), the security standards of their Operating Systems and Data Storage software they use is one of their primary IT related concerns. It is popular opinion that Open Source Software is more secure than propriety software (such as Microsoft Windows and SQL Server), but the facts are that recent events such as the ‘Blaster’ Worm (which highlighted the inherent security flaws in Microsoft Windows) and the ‘SQL Slammer’ worm (which showed security flaws in SQL Server and caused a 12 hour internet blackout in South Korea) have seriously damaged Microsoft’s reputation (Chae & McHaney 2006). Open Source Software, on the other hand, has an excellent reputation, in general, for being resilient to these threats. It is a case of the Open Source community and those who develop Open Source Software having a large proportion of hackers amongst their ranks, who better to develop the most secure applications in the world? (Arne 2006).
The reasons generally given as to why open-source software is the way forward are generally and quite plausibly based on past successes in other much publicised software development projects. The most popular web server has always been OSS since such data has been collected. For example, Apache is currently the number 1 web server with over three times the market share of its next ranked competitor (Wheeler, 2004).
The open source licenses generally have the advantage of forcing the code into the public domain (B.Kogut and A.Metiu, 2001) This is the primary reason for its success as incrementally, innovations can be contributed to improve code and add functionality.
"Almost all of the most widely-known and successful OSS projects seem to have been initiated by someone who had a technical need that was not being addressed by available proprietary (or OSS) technology" (Feller and Fitzgerald, 2002, p. 139).
Kippenberger’s paper called “Giving it away for free” gives many reasons why we should choose open source over commercial products, he mainly puts it down to commercial products unreliability. In it he writes “it is full of bugs and is subject to frequent failures. Each new release is more complex, and more unreliable then its predecessor. Even the biggest commercial software developers – like Microsoft – do not have the resources to create the reliability needed”. To back up his point Kippenberger refers to Eric Raymond’s essay, “The Cathedral and the Bazaar”, bible of the field of study, noting four critical pieces of internet software that are also open source. Bind, Perl, Sendmail and Apache are all critical to the smooth running of the internet. Kippenberger uses this fact to back up his point that open source is more reliable otherwise such critical software would be commercial.
Galem Gruman writes in his 2006 paper “The odds are good that the LAMP stack is running somewhere inside your company. The acronym refers to the foundational foursome of the open-source movement: the Linux operating system, Apache Web server, MySQL database and, collectively, the Perl, PHP and Python programming languages.” It’s a logic step then to consider open source in other areas. When writing about JBoss Gruman says “JBoss has also gained popularity—and trust—especially now that major vendors such as IBM, BEA Systems and Borland have adopted or supported them commercially.”
The advantages of open source include widespread component reuse, better access to underlying code to customize interfaces across applications, and less complex systems to manage. "We're heavy users of proprietary [software], and that won't change, but there are times you need a motor scooter, not a truck," says Gruman when quoting Charlie Brenner, senior vice president of the Fidelity Centre for Applied Technology, Fidelity's technology incubation group.
Originally it was exasperation and disenchantment with the growing reliance on internal proprietary software that spurred developers on to expand open source software development communities. An example would be the overwhelming response received upon the posting of the code behind the first version of a Unix kernel . Relatively quickly a non trivial, operating system kernel was developed. This large community of developers willing to offer up valuable information is something of great interest to any company embarking on a systems development project. It is afterwards that one must consider carefully where to exercise proprietary claims on the systems use and further development. (B.Kogut and A.Metiu, 2001)
Upon hearing such success stories one might assume that Open Source Software is the answer to everyone’s prayers. Of course caution has to be exercised.
There are occasions when software projects are not amenable to open-source development. For example a software system that is tailored to supporting trading activity on a specific stock market would be an unlikely candidate. What would benefit is a system that provides rapid improvement and has a low catastrophic risk. (B.Kogut and A.Metiu, 2001) The code for the trading system as highlighted would be too specific and the catastrophic risk would be too high.
A product that is not modular would also not be appropriate (B.Kogut and A.Metiu, 2001). Any product where the changing of a single component would drastically alter its other properties may not be suitable for open-source development. When opening proprietary systems to the concept of Open Source Software it is important to firstly give an accurate assessment of its suitability and possible pitfalls of adaptation. One may be approached with open-source software being offered like some silver bullet to solve all problems. However it has to be considered whether or not the concept will work or your specific project. A small project may arouse very little interest in industry and feedback may be minimal. Other developers may not be able to see the big picture or have no vested interest.
Open source presents a new path for software development. Simon Forge gives UNIX as an example of proprietary free ware’s inefficiencies when he writes “UNIX has 30 different marketed versions, each slowly failing as competing gets tougher, each hiding differences in their various advances that the other suppliers can’t use.” The major model so far has been to sell proprietary binary only, however the new model is to deliver free software, but also to make money out of that action (S Forges, 2000).
What lies at the heart of the argument for open source is that commercial software is unreliable. For a proprietary software company that is finding it difficult the next step to consider might be going open source. In his article “Setting Up Shop” Frank Hecker discusses why the change to open source should be made and how to go about this. In it he writes “Once you've accepted the possibility that releasing source code for one or more of your products might be a component of your overall business strategy, two questions then arise: How does distributing source code create value for customers, and how can your company convert that value into revenue and profits (i.e., money)?” Hecker goes into the areas of which licence choice should be made and discusses a number of business models to be adapted in order to earn profit. These profit earning models are:
Support Sellers
This models earns money via the offering of services such as technical support or physical goods like software media and documentation.
Loss Leader
This approach is based on the theory that the the customer will buy other products sold by the company under traditional licence fees. It is interesting to note that this was a large factor behind Netscape’s move to go open source.
Widget Frosting
From Heckers description of this model one can compare it to the selling of a physical good which requires software to come with it. The decision to make this software free can save that company a lot of money. For example before Internet Explorer became free, PC manufacures shipped netscape navigator with their computers. In this case software is a cost and the PC is the profit centre.
Accessorizing
Producing books which document and explain the source software can create revenue for a company. O’Reilly & Associates are a good example of this.
Service Enabler
If a company offers an on-line service which generates revenue. It may be a good idea to provide free software to enable they to use this service more frequently thus generating more revenue.
Quality Assurance, or the lack thereof: Practices in Open Source Software Projects and Reliability of Open Source Software
Quality Assurance
It is this aspect of Open Source Software that is often regarded as the driving force behind the method. Quality can reach very high standards in industry and productivity levels can rise. A critical question raised in the development of any open-source software development project is whether there are sufficient incentives for developers to contribute to the system. A claim is made that developers contribute out of a sense of ‘altruism’. (B. Kogut, A. Metiu, 2001). Nevertheless this can and often does contribute greatly to Quality Assurance on OSS projects.
As work on open-source projects is voluntary, developers work on the topics that interest them and this may well not include features for novice users. The importance of incentives in OSS participation is well recognised (Feller and Fitzgerald, 2002; Hars and Ou, 2001). These include the gaining of respect from peers and the intrinsic challenge of tackling a hard problem. Adding functionality or optimising code provides opportunities for showing off one's talents as a hacker to other hackers. (Nichlols and Twidale, 2003) It is this competition than can often improve system quality dramatically. It is also important to note that if OSS participants perceive improvements to usability as less high status, less challenging or just less interesting, then they are less likely to choose to work on this area. (Nichlols and Twidale, 2003)
The interesting thing is that freeware – open sourcing – will increase the quality of software as its availability increases (S. Forge, 2000) This is due to the Network effect. This ensures that there is a constant quorum of quality, in the number of competent critiques and workers who update and fix the bugs.
In an article by Simon Forges, the quality assurance of the open source product is likened to a bottle of water. “Most people prefer to buy branded bottles of water at reasonable cost, as it is a life giving essential, then to trust the water company”(Which is free) “The same goes for open source. This idea ties in with the Free Vs. Value for money theme I have noticed in mt other articles. The brand may be Red Hat for Linux , rather then Evian for water.”(S. Forges, 2000) Th majority of people would be happy to pay a reasonable amount for say Linux then to get it for free as they will have more technical support with the product and will have someone to complain to if it goes wrong. Much will depend upon people’s readiness to exchange their trusted yet expensive, brand names for a product which, at present, is considerably less polished (S. Forges). This is a very true statement and one which has its merits. People do find it very difficult to change from what they know and people are often sceptical about ‘free’ products.
Lack of Quality Practices
While conducting a literary review of Open Source Software there were some common acknowledgements made. It was easy to find a lack of quality practices and the reliability of the OSS to be reoccurring features. In recent years it seems there has been a massive growth and success in the field of Open Source Software projects and the quality in which they are created. A review of existing research concludes that OSS development can produce software of high quality and functionality. Examples of this include the Linux operating system and the Apache server. In contrast to this not all OSS projects are a success. According to its proponents, one of the most acclaimed advantages of Free/Open Source Software (F/OSS) is its superior quality. However, this suggestion is an open issue, since there is little concrete evidence to justify whether F/OSS quality is indeed better or worse than that of proprietary software products (Samoladas & Stamelos).
There seems to be a common acknowledgement that Open Source Software exhibits two characteristics that have important implications on quality assurance. First, they are distributed, in many cases all over the world. Second, the participants of free (OS) software projects are generally unpaid volunteers (Probert & Michlmayr, 2005).
The basic structure of the development process of OSS systems is that they are built by potentially large numbers of volunteers, work is not assigned; people undertake the work they choose to undertake, there is no explicit system level design and there is generally no project plan, schedule, or list of deliverables [Mockus, Herbsleb & Fielding 2002]. While there are many benefits to OSS projects, there is a large number of abandoned projects and low quality software out there. [Probert & Michlmayr, 2005] expand by suggesting the high level of quality found in some free software projects is related to the open development model which promotes peer review.
While the quality of some free software projects is comparable to, if not better than, that of closed source software, not all free software projects are successful and of high quality. Some quality problems which exist in the free software community and have yet to be solved include: unsupported code, configuration management, attracting volunteers and lack of documentation. Wu and Lin (2001) and Cubranic and Booth (1999) focus on cooperative work and configuration management to support distributed development. Cubranic and Booth (1999) discuss major issues of coordinating open source development projects, including collaborative communication mediums and configuration management tools.
Criticisms about the lacking of high-level coordination approaches in open source community are raised, emphasizing that the most successful open source projects have a centralized control structure (e.g., Linux, Apache server). Indeed Mockus, Herbsleb & Fielding agree but feel OSS development is still superior to that of traditional types “Despite the very substantial weakening of traditional ways of coordinating work, the results from OSS development are often claimed to be equivalent, or even superior to software developed more traditionally.”
Reviewing the literature available, there seems to be a general consensus that the barriers to the implementation of Open Source Code which cause project failures are due to a lack of project management skills (Barnes, 2003). There is also a lack of research in regards to practices and processes which assure and further improve quality in free software projects (Zhao & Elbaum, 2003). They go on to say “Our preliminary survey on open source explored quality assurance activities in open source. The results indicated that testing takes a significant portion of the software life cycle, planning is not regularly done, and user participation usually did not include looking at the source code.”
In an ever evolving industry it is important to have an ever evolving development policy. It has been established that Open Source Software offers this although the difficulties this method can cause with regard to patent and authority issues are often understated and can be diminished in rousing, enthusiastic and sometimes almost promotional descriptions circulating in industry and literature. It remains to be seen whether or not Open Source Software will survive the onslaught of patent applications (Wusteman, 2004). Improvements in the usability of open source software do not necessarily mean that such software will displace proprietary software from the desktop; there are many other factors involved, e.g. inertia, support, legislation, legacy systems etc. However improved usability is a necessary condition for such a spread (Nichlols and Twidale, 2003).
It is also worthy of note that of he main dangers with open-source software development is “the potential of fragmenting the design into competing versions” (B.Kogut and A.Metiu, 2001). Often referred to as ‘forking‘. I found that the discussions on this particular issue in the literature reviewed had an overly negative view on the prospect of this happening. It may prove to be resistant to development or even possibly detrimental but it may also prove beneficial. If the change in the thought process of one party causes a division competition may ensue which could prove to speed up productivity and bring further innovation.
Reliability of Open Source Software
Miller studied the reliability of several UNIX utilities and services, which included several applications that are now open source (Miller et al., 1995). The study consisted of providing random input streams to the applications in order to measure failure rate. The Gnu and Linux distribution were among the evaluated systems. Results indicated that the reliability of the ‘‘freely distributed’’ products was superior to those of commercial vendors (Zhao & Elbaum, 2003). Indeed Samoladas & Stamelos agree “there is enough evidence to support that OSS is more reliable than proprietary software.”
The Free Software Foundation concludes that a reason why OSS is more reliable than proprietary software is that free software gets the whole community involved in working together to fix problems. Users work together, conversing by email, to get to the bottom of a problem and make the software work trouble-free. The FSF also concludes that developers really care about reliability. Free software packages do not always compete commercially, but they still compete for a good reputation, and a program which is unsatisfactory will not achieve the popularity that developers hope for. What's more, an author who makes the source code available for all to see puts his reputation on the line.
An important factor that directly affects reliability is the frequency of bug discovering. Indeed, feedback about bugs and incorrect implementations in OSS is direct and immediate: Once a version of software is released, it is a matter of days, hours or even minutes before the first bug is reported and the official fix is announced (Schmidt & Porter, 2001). The status of OSS in bug discovering is described by the famous Eric Raymond (2002) diagnosis: “Given enough eyeballs, all bugs are shallow”.
In 1997 a denial-of-service (DoS) attack against the Linux operating system was reported. A flaw in the Linux kernel's IP stack caused the system to crash, when a special IP packet was received. What made this attack more interesting is that it was also affecting another well known closed source operating system, making Teardrop a case of a heterogeneous attack. For the Linux case, the vulnerability was fixed within few hours. Moreover, the patch which fixed the bug contained a fix for another bug, which developers observed, but attacker didn't. The patch, which was originally aimed at the first bug, immunized the system against the second bug as well. This rendered Linux resisting future attacks of not only Teardrop itself, but of other invariants of it as well. The patch for the other closed source operating system took a lot longer to be published and successive patches were needed for the other kind of attacks to be resolved (Samoladas & Stamelos).
As evidenced by my studies it is generally consider that open source better enables reliability, security and interoperability. Dodson (2004) agrees with this view but also is quick to point out the evolution time of open source packages and closed source packages and how the comparison of reliability “may be an unfair test as Linux and the X Window System had longer to evolve and arguably suffer less from commitment to compatibility with poor early design decisions and not from deliberate creation of obstacles to interoperability, than those of Microsoft Windows.”
The Free Software Foundation (2002) cites studies showing that free software is more reliable. Regarding security, a theoretical study by Ross Anderson (2002) touches on much of interest and indicates no disadvantage for open source. Given these and other findings, proprietary generic software seems to be a market bubble destined to burst.
The key to the success and reliability of open source software applications is the number of programmers involved and interested in the application. Open Source software has been around for at least 20 years (Cervone, 2003). OSS often provides greater compliance with standards, as commercial vendors may modify those standards to better market other proprietary products that they distribute. In some cases the OSS product can develop faster because there are multiple sites working on various enhancements without the need for a supervisor and associated overhead as in the vendor hierarchy. Local code developers are also closer to the end user and work directly with them to enhance and improve the product. Debugging and troubleshooting is spread across a large number of sites, providing real-world problems that can be tested against, unlike most vendor settings.(Scott P. Muir) All these factors combined results in a very reliable piece of software.
Open Source Software Licensing
When conducting this literary review there were approximately 136,011 software projects listed on SourceForge.net had ‘approved’ open source licenses, of which more than 57,000 are licensed under the General Public License (GPL) or Lesser General Public License (LGPL). The "classic" licenses, GPL, LGPL, BSD, and MIT, were the most commonly used for open-source software before the Mozilla release in early 1998. The Mozilla Public License has since become widely used. Since then many other licenses have been submitted to opensource.org for approval. The list of approved licenses is constantly growing. There are currently approximately 55 OSS licenses, each with its own set of restrictions and requirements based upon the core precepts of the OSD.
Open Source Software (OSS) licensing is built around a common set of requirements know as the Open Source Definition (OSD). Based upon this set of criteria, developers license the source code to their product, granting all recipients broad rights to modify and distribute that code.
Open source licensing makes possible three substantial improvements over traditional proprietary commercial software licensing models.
· The first, and perhaps the greatest, of these benefits is innovation. It is now well demonstrated that programmers are willing to contribute to open source projects for no reward other than that of making a program more useful.
· The second benefit is reliability. Many available programmers mean many people available to debug a given program.
· The third benefit is longevity. When commercially licensed software goes “out of print” and is no longer supported by its publisher, there is generally no way that software can be updated or adapted to new uses. By contrast, open source licensed software can fall into disuse for some period but still be revived, adapted, or rewritten by a subsequent user who finds a use for it—a use that may be completely different from the use originally intended.
While reviewing the research into open source software and all of its many benefits it becomes clear that it is also important to note that even though OSS has arguably the best security and is generally accepted as being very reliable, there are risks associated with going open source. One is that staff developers unfamiliar with the competitive value of various components might accidentally embed strategic business logic or processes into code that is then provided back to the open-source community, neutralizing a competitive advantage (G. Gruman 2006). To combat this risk the company needs to distinguish between weather the project is Application or platform based. Reporting tools and CRM are two examples of platforms that are often marketed as applications.
Platforms typically don't encapsulate specific business processes or logic, making them well-suited for open-source efforts—and less risky for the companies that use them, as companies using such tools will be less tempted to insert their own business logic into the products and unwittingly release it to the world. Gruman also mentions that “Another alternative is to go pseudo open source as in the Avalanche Corporate Technology Cooperative, which openly shares code on a variety of projects, but only among subscribed members.”
Conclusion
The topics covered for review in the body of this report present varied issues within the Open Source Software field of research. There is a lot of qualitative research, much of based upon case studies. As a relatively new area of research, many of the case studies are shared across papers. The examples of Apple, Linux, Firefox and Apache arise time and time again, because they are the highest profile examples of what Open Source Software models can develop. Unfortunately, similar or identical case studies are used by different researchers to justify different opinions on the various topics in the field.Further case studies into the adoption rather than development of open source software, among ordinary companies rather than the reoccurring examples, would benefit the area of knowledge.
It also shows a lack of building upon the existing body of knowledge, that several papers quote the same examples or papers, and often make the same points. All of the papers read began with a goal, researching one of the issues in the field. Along the way, each passed through the industry common knowledge of what open source software is, the “free as in beer, or free as in speech” debate, and examples of open source software. With all the papers coming in such a short space of time, the earliest read being published in 2000, it is not surprising that a “state of the art” common body of knowledge has not been established as a given, but it would much improve the effectiveness of future research if it was unnecessary to justify open source in the first place.
It is clear especially that “The Hybrid Model”, the opening of proprietary software to the OSS community, could benefit greatly from further research. Such a topic is very relevant to the business world and would benefit the industry itself, whereas more discussion of ideals and values of the development community itself serves only to further enforce the image of OSS as a specialist, academic field. As it stands, Apple, IBM and Sun where the only case studies mentioned across many of the 25 papers with regard to this Hybrid model. A contender may be Lego’s robotics, mentioned several times but with less relevance to business and industry.
There is clear disagreement in one area – whether or not open source software is more or less quality assured. Some argue it lacks the standardisation and rigorous testing before release of in-house developments, others argue the speed of development and the dual experiences of users and testers ensures problems are rectified much faster.
A lot of the literature is exceedingly biased toward the merits of open source software development. Some of the papers reviewed include essays by Richard Stallman, “father” of the Free Software Movement, and Leading Edge Forums, a sponsor of various OSS projects. In the interest of proper fairness and relativity, it would be useful to have papers either based upon the dangers of OSS, or giving a more balanced view.
While the popularity of open source software this decade has resulted in a torrent of research papers devoted to it, we have concluded that if future research is to be of any benefit to the field, it must be willing to deviate from defining and justifying open source as a strategy.
References
- Martin Michlmayr, Francis Hunt, David Probert, “Quality Practices and Problems in Free Software Projects,” University of Cambridge 2005
- Jonathan Barnes, “Open Source Software as a computer-specific organisational Technology,” Unversity of Canterbury 2003
- L. Zhao and S. Elbaum, “Quality assurance under the open source development model,” The Journal of Systems and Software, vol. 66, pp. 65-75, 2003.
- Audris Mockus, Roy Fielding, James D Herbsleb, “Two Case Studies of OSS Development: Apache and Mozilla,” ACM Transactions on Software Engineering and Methodology, vol. 11, no. 3, pp. 309-346, 2002.
- Ioannis Stamelos, Ioannis Samoladas, “Assessing Free/Open Source Software Quality,” Aristotle University of Thessaloniki
- David Dodson, “Free Software and Open Source,” London City University 2004
- Bruce Kogut, Anca Metiu, Insead, “Open Source Software Development and Distributed Innovation,” Oxford University 2001
- Tim O’Reilly, “Lessons from Open Source Software Development,” Communications of the ACM 1999
- David M. Nichols, Michael B. Twidale, “Usability and Open Source Software” University of Waikato 2003
- David A. Wheeler, “Why Open Software / Free Software (OSS/FS)? Look at the numbers!,” 2004
- Simon Forge, "the economics of giving away stuff, and software as a political statement" Camford 2000
- Scott P. Muir, "An introduction to the open source software issue", Eastern Michigan University, 2005
- Galen Gruman, "Open Source Moves Up", CIO, 2006
- Frank Hecker, "Setting Up Shop" http://www.hecker.org, 2006
- Thomas Kippenberger, "Giving it away for free" CSBS, 2000
- Leading Edge Forums, “Open Source: Open For Business”, 2004
- Andrea Bonaccorsi, Cristina Rossi, “Why Open Source Software can Succeed”, 2004
- Joel West, “How Open is Open Enough?”, 2002
- Richard Stallman “The GNU Operating System and the Free Software Movement”, from “Open Sources, Voices from the Revolution”, 1999
- Dahlander,L., Mckelvey,M., “Who is not developing open source software? Non-users, users, and developers, Economics of Innovation and New Technology”, 2005
- Fitzgerald, B. Kenny, T., “Developing an information systems infrastructure with open source software”, 2004
- Joseph Feller, Brian Fitzgerald, “A framework analysis of the open source software development paradigm”, 2000
- Everitt, 2004
- J Walker “Identifying and Overcoming Barriers to the Successful Adoption and Use of Wikis” 2006 - etd.ils.unc.edu
- Wusteman, “About XML – Patently Ridiculous”, 2004