THE TRANSFORMATION OF OPEN SOURCE SOFTWARE

Fitzgerald/Transformation of Open Source Software

MIS Quarterly Vol. 30 No. 3, pp. 587-598/September 2006 587

ISSUES & OPINIONS

THE TRANSFORMATION OF OPEN SOURCE SOFTWARE1

By: Brian FitzgeraldLero—The Irish Software Engineering

Research CentreUniversity of [email protected]

Abstract

A frequent characterization of open source software is thesomewhat outdated, mythical one of a collective of supremelytalented software hackers freely volunteering their services toproduce uniformly high-quality software. I contend that theopen source software phenomenon has metamorphosed intoa more mainstream and commercially viable form, which Ilabel as OSS 2.0. I illustrate this transformation using aframework of process and product factors, and discuss howthe bazaar metaphor, which up to now has been associatedwith the open source development process, has actuallyshifted to become a metaphor better suited to the OSS 2.0product delivery and support process. Overall the OSS 2.0phenomenon is significantly different from its free softwareantecedent. Its emergence accentuates the fundamentalalteration of the basic ground rules in the software landscape,signifying the end of the proprietary-driven model that hasprevailed for the past 20 years or so. Thus, a clear under-standing of the characteristics of the emergent OSS 2.0 phe-nomenon is required to address key challenges for researchand practice.

1Ron Weber was the accepting senior editor for this paper. Giancarlo Succiand Richard Welke served as reviewers. The third reviewer chose to remainanonymous.

Keywords: Open source software, free software, IS develop-ment

Introduction

Just a few years ago, it would have seemed preposterous tosuggest that the might of the proprietary software industry, asexemplified by Microsoft, could be threatened by the largelyvolunteer open source software movement. This movement,however, has altered the basic nature of the software industry.On the supply side, fundamental changes have occurred to thedevelopment process, reward mechanisms, distribution ofdevelopment work, and business models that govern howprofit can be achieved. On the demand side, the alternativestraditionally available to organizations for software acquisi-tion—buy or build—have been supplemented with anothercredible alternative—namely, open source. Indeed, a type ofMoore’s Law effect seems to be taking place as the amount ofopen source software available increases dramatically every12 months or so. A range of issues arises also in relation tothe altered nature of software support, the need for newmodels for total cost of ownership (TCO) of software, andperceptions of exposure to the possibility of intellectualproperty (IP) infringement.

Radical movements often mature to be accommodated into themainstream. French Impressionist art in the 19th century is agood example. I contend that the open source phenomenonhas undergone a significant transformation from its free soft-ware origins to a more mainstream, commercially viableform—OSS 2.0, as I term it.2 This accommodation with the

2Because this article focuses on the evolution and transformation of the opensource phenomenon, terminology is an issue. I use the term FOSS to refer tothe initial era of Free and Open Source Software. I use OSS 2.0 to refer to the


588 MIS Quarterly Vol. 30 No. 3/September 2006

mainstream ensures that the emergent OSS 2.0 phenomenonwill continue to thrive as a significant force in the future soft-ware landscape. Indeed, it is a harbinger of an end to the cur-rent dominance of a proprietary, closed source softwaremodel. I illustrate how the quintessential proprietary softwarecompany, Microsoft, can appear to satisfy the definition of anopen source company, while a quintessential open sourcecompany, Red Hat, can appear to resemble a proprietary soft-ware company. I identify how OSS 2.0 can accommodatethese apparent transformations through achieving a balancebetween a commercial profit value-for-money propositionwhile still adhering to acceptable open source communityvalues.

Compounding the fact that the open source phenomenonrepresents a radical change in the software landscape, it isoften mistakenly and paradoxically characterized as a collec-tive of supremely talented developers who volunteer their ser-vices to develop very high-quality software by means of arevolutionary new approach. This characterization is a mythas almost every aspect of it can be questioned (Fitzgerald2005; Michlmayr et al. 2005; Rusovan et al. 2005; Schach etal. 2002). One effect of this outdated characterization is thatresearch to date has focused inward on the phenomenon,studying the motivations of individual developers to contri-bute to OSS projects, or investigating the characteristics ofspecific OSS products and projects. Such research has beenfacilitated by the availability of a vast amount of data onmailing lists and portals such as Sourceforge. In the case ofthe latter, however, it is important to bear in mind that only asmall percentage of the 100,000 or so projects are stable andmature.

While some disagreement exists between the free and opensource software community as to the definitions of free soft-ware versus open source software (www.fsf.org/philosophy/free-software-for-freedom.html), I will not dwell on that here.I first propose a framework to characterize the initial free andopen source software (FOSS) phenomenon. While the shiftto OSS 2.0 may seem incremental, I use this framework toillustrate the deep nature of the transformation. I also identifykey challenges for research and practice that arise as a resultof the emergence of OSS 2.0.

Characterizing FOSS

Tushman and Andersen (1986) propose a framework for tech-nological transformation based on two sets of technologicalfactors—namely, process and product. I propose a similar

framework to characterize the initial FOSS phenomenon(Table 1, which also presents a characterization of OSS 2.0,discussed in the next section).

FOSS Development Process

In conventional software development, the development lifecycle in its most generic form comprises four broad phases:planning, analysis, design, and implementation. In FOSSdevelopment, these stages tended to be configured differently.The first three phases of planning, analysis, and design areconcatenated and performed typically by a single developeror small core group. The planning phase is probably bestsummarized by Raymond’s (1999) phrase of a single devel-oper perceiving “an itch worth scratching.” This leads toconstruction of an initial prototype. Given the ideal that alarge number of globally distributed developers of differentlevels of ability and domain expertise should be able tocontribute subsequently, the requirements analysis phase waslargely superseded. Requirements were taken as generallyunderstood and not needing interaction among developers andend-users. In this regard, FOSS developers were invariablyusers of the software being developed. This model is perhapsbest suited to infrastructure software in horizontal domains.Design decisions also tended to be made in advance beforethe larger pool of developers starts to contribute. Systems arehighly modularized to allow distribution of work and reducethe learning curve for new developers to participate (they canfocus on particular subsystems without needing to considerthe system in its totality).

In the FOSS development life cycle, the implementationphase consists of several subphases (Feller and Fitzgerald2002):

• Code: writing code and submitting to the FOSS com-munity for review

• Review: a strength of FOSS is the independent, promptpeer review

• Pre-commit test: the negative implications of breakingthe build ensure that contributions are tested carefullybefore being committed

• Development release: code contributions may be in-cluded in the development release within a short time ofhaving been submitted—this rapid implementation beinga significant motivator for developers

• Parallel debugging: the so-called Linus’ Law (“givenenough eyeballs, every bug is shallow”) as the largenumber of potential debuggers on different platforms and

phenomenon which I see emerging now, and I use open source software torefer to the phenomenon in general.


MIS Quarterly Vol. 30 No. 3/September 2006 589

Table 1. Characterizing FOSS and OSS 2.0Process FOSS OSS 2.0

DevelopmentLife Cycle

• Planning—“an itch worth scratching”• Analysis—part of conventional agreed-upon

knowledge in software development• Design—firmly based on principles of modularity to

accomplish separation of concerns• ImplementationN CodeN ReviewN Pre-commit testN Development releaseN Parallel DebuggingN Production Release

(often the planning, analysis, and design phases aredone by one person/core group who serve as “a tail-light to follow” in the bazaar)

• Planning—purposive strategies by majorplayers trying to gain competitive advantage

• Analysis and design—more complex in spreadto vertical domains where business require-ments not universally understood

• Implementation subphases as with FOSS, butthe overall development process becomes lessbazaar-like

• Increasingly, developers being paid to work onopen source

ProductDomains

• Horizontal infrastructure (operating systems,utilities, compilers, DBMS, web and print servers)

• More visible IS applications in vertical domains

PrimaryBusinessStrategies

• Value-added service-enabling• Loss-leader/market-creating

• Value-added service enablingN Bootstrapping

• Market-creatingN Loss-leaderN Dual product/licensingN Cost reductionN Accessorizing

• Leveraging community development• Leveraging the open source brand

ProductSupport

• Fairly haphazard—much reliance on e-maillists/bulletin boards, or on support provided byspecialized software firms

• Customers willing to pay for a professional,whole-product approach

Licensing • GPL, LGPL, Artistic License, BSD, and emergenceof commercially oriented MPL

• Viral term used in relation to licenses

• Plethora of licenses (85 to date validated byOSI or FSF)

• Reciprocal term used in relation to licenses

system configurations ensures bugs are found and fixedquickly.

• Production release: a relatively stable, debugged produc-tion version of the system is released

The management of this process varies a great deal. Differentprojects have varying degrees of formalism as to how deci-sions are made, but the principle of “having a tail-light tofollow” (Bezroukov 1999) captures the spirit well. Often, theinitial project founder or small core group make the keydecisions in accordance with the process outlined in the lifecycle above.

FOSS Product Domains

Due to the globally distributed nature of the developmentcommunity (most members never meet face-to-face), FOSSproducts have tended to be infrastructural systems in hori-zontal domains. Their requirements are part of the generaltaken-for-granted wisdom of the software development com-munity. Thus, the most successful FOSS products—theLinux operating system, the Apache web server, the Mozillabrowser, the GNU C compiler, the Perl scripting language,and MySQL database management system—are all examplesof horizontal infrastructure software.



Primary FOSS Business Strategies

Several FOSS business strategies have been proposed (Hecker2000; Raymond 1999). Two have been most significant—namely, value-added service-enabling and loss-leader/market-creating.

An early example of the value-added service-enabling modelwas Cygnus Solutions, which integrated a suite of GNU toolsand sold support services and other complementary softwareproducts. Red Hat is probably the most well-known pro-ponent of this strategy. Effectively, Red Hat simplifies thetask facing end-users in deploying an overall open sourcesolution, such as Linux, that requires complex configurationof different components.

In the loss-leader/market-creating model, the open sourceproduct is distributed for free, but with the end goal ofenlarging the market for alternative, closed source productsand services. For example, the open source Sendmail productenlarges the subsequent market for Sendmail Pro, a productwith extra functionality that is distributed for a fee.

FOSS Product Support

The nature of product support in FOSS has been haphazardand bazaar-like and is different from the proprietary model.Requests for support and solutions are commonly sent toforums such as bulletin boards and mailing lists. In somecases, support may be purchased from a competent third-partyprovider. For example, Linux support is available from HP orIBM, or a specialized (often local) software firm may offersupport and consultancy services. While many organizationsare reluctant to rely on bulletin boards for support, they maybe equally reluctant to purchase consultancy support to deploya solution effectively (Fitzgerald and Kenny 2003).

FOSS Licensing

Ironically, given the perceptions that FOSS is collectivist andanti-intellectual property, the success of the open sourcemodel is due largely to the use of licensing, albeit in a formthat counters the normal restrictive sense. Property rights arevested in the author through copyright, with liberal rightsgranted to others under license. In the FOSS era, the principallicenses have been the GNU Public License (GPL), the LesserGPL (LGPL), the Artistic License, and the Berkeley SystemDistribution (BSD). This era also saw the emergence of thecommercially oriented Mozilla Public License (MPL), whichhas been quite influential.

The earliest open source license, the GPL, was created in themid 1980s to distribute the GNU project software. Most opensource software to date has been distributed under the GPL,Linux being one high-profile example. The GPL subverts thetraditional concept of restricted access through copyright byensuring complete, unrestricted access to all open source soft-ware and any derivatives. These must also be licensed underthe same terms, referred to as “copyleft—all rights reversed.”This latter guarantee of the same rights to subsequent userscaused such licenses to be termed viral.

The GPL is controversial, because it requires that all applica-tions that contain GPL software are also released under a GPLlicense. A modified version, the Lesser GPL (LGPL) wascreated when this proved impractical. The LGPL differs fromthe GPL in two main ways. First, it is intended for use withsoftware libraries (it was initially known as the Library GPL).Second, the software may be linked with proprietary code,which is precluded by the GPL.

Another early license that achieved fairly widespread use isthe BSD license, which imposes few restrictions. Its mainrequirement is the retention and acknowledgment of previouscontributors’ work.

The FOSS era also saw the creation of the commerciallyoriented Mozilla Public License (MPL) by Netscape. TheMPL was significant because it focused on the conversion ofa commercial software product to open source. This processraised significant challenges. It rendered the GPL problema-tic, because each licensor whose software was incorporatedinto the Netscape browser would have had to use the sameopen source license. Netscape was also concerned that anacademic-style license would not guarantee that developerswould contribute back to the community. It created a newlicense, the MPL, to address these specific concerns.

Characterizing OSS 2.0

The term open source was coined in 1998 to place the phe-nomenon on a more business-friendly footing than that asso-ciated with the ambiguous free software. The latter led to thecommon misperception was that individuals or organizationscould not make money with free software. The open sourceinitiative succeeded spectacularly well, and the emergent OSS2.0 has a very strong commercial orientation. Table 1 sum-marizes how OSS2.0 differs from its FOSS antecedent.

OSS 2.0 Development Process

The largely voluntary nature of FOSS led to a vacuum inrelation to strategic planning (competing with Microsoft on



the desktop being one example of a questionable strategy). Inthe OSS 2.0 development life cycle, in contrast, strategicplanning moves to the fore. The haphazard principle of indi-vidual developers perceiving “an itch worth scratching” issuperseded by corporate firms considering how best to gaincompetitive advantage from open source. For example, RedHat has published an architecture roadmap that details itsplans to move open source up the software stack towardmiddleware and management tools. Other proprietary com-panies have also seen the strategic potential of open source toalter the competitive forces at play in their industry, perhapsto grow market share or undermine competition. Forexample, IBM is a strong supporter of Linux, because iterodes the profitability of the operating system market andadversely affects competitors like Sun and Microsoft.

Analysis and Design

As already discussed, FOSS products were targeted primarilyat horizontal infrastructure where requirements and designissues were largely part of the established wisdom, thus facili-tating a global developer base. Most business software, how-ever, exists in vertical domains where effective requirementsanalysis poses real problems. Students and developers with-out any experience in the application area lack the necessaryknowledge to derive the accurate requirements that are aprecursor to successful development. In OSS 2.0, therefore,the analysis and design phases have become more deliberate.In many cases, based on the earlier phase of strategicplanning, paid developers will be assigned to work on opensource products in vertical domains.

Given the increasingly commercial nature of OSS 2.0, morerigorous project management is required to achieve a profes-sional product. As a consequence, a shift is occurring where-by the management of the development process is becomingless bazaar-like. This outcome is already evident in theformalized meetings for a number of popular open sourceproducts (for example, the Apache conferences in the UnitedStates and Europe, the regular Zope/Plone developmentproject meetings, and the GNOME annual project con-ferences) (German 2003). These meetings bring togetherdevelopers to coordinate and plan further development. Thelegal incorporation of several open source projects ostensiblyreduces the risk of litigation for individual developers(O’Mahony 2005), while allowing these projects to acceptdonations, perhaps to implement requested functionality.

OSS 2.0 Product Domains

Interestingly, in the highly competitive software world,several open source products have nudged out proprietary

alternatives to emerge as “category killers”—that is, productsof sufficiently high quality and popularity that they obviatethe need for development of competitive products. Also, OSS2.0 is moving from deployment as back-office, invisibleinfrastructure to front-office, highly visible deployment of ISapplications in vertical domains. An example is the Beau-mont Hospital case study (Fitzgerald and Kenny 2003), wherea number of in-house developed applications are being madeavailable on an open source basis to other healthcareagencies. In the context of open source, this development issignificant. To date, it has often been assumed that opensource products will not affect many vertical domains,because developers will not perceive an “itch worthscratching” there. If, however, organizations in these areassubscribe to the open source philosophy and contributespecialist expertise to open source projects, the model willspread to more vertical applications.

OSS 2.0 Business Strategies

The FOSS era had two overarching “families” of revenuemodels—value-added service-enabling and loss-leadermarket-creating. These models are still applicable in OSS2.0, but they are further nuanced. Other strategies have alsoemerged, including leveraging community software develop-ment and leveraging the open source brand. Moreover, com-panies may not stick solely to one of these models and mayemploy pragmatic hybrids instead.

Value-Added Service-Enabling in OSS 2.0

Building a lucrative service and support business on top ofopen source was discussed earlier. Companies like Red Hatand Novell have realized large revenues through annualsubscriptions. This bootstrapping model is taken to a higherlevel in OSS 2.0, where open source products are treated as aplatform—somewhat similar to a highway or a telecommuni-cations infrastructure. A company bootstraps its own value-added specialty on top of this infrastructure. Small softwarecompanies can become part of an ecosystem offering con-sultancy, service, and support of open source products. Oneexample would be to purchase a single support license fromMySQL and sell local support to a number of customers.Roughly 90 percent of customer support requests are prob-ably easily dealt with directly, and the 10 percent of com-plicated issues could be passed to MySQL for resolution, andthen the solution passed back to the local customers.

High-profile organizations like Amazon, Google, andSalesforce.com take advantage of the reliability and low costof open source to create a platform on which they can offervalue-added services in their own business domains. For the



most part, the use of open source is invisible to their cus-tomers. These companies also customize open source pro-ducts to suit their internal needs. Moreover, because they arenot redistributing software, they are not faced with anyproblems of noncompliance with the GPL.

Market Creation Strategies in OSS 2.0

The other FOSS era business strategy discussed above is theloss-leader market-creating strategy. In OSS 2.0, the empha-sis is firmly focused on market creation through a loss-leaderapproach and involves products with dual licensing, costreduction, and accessorizing.

Integrated development environments (IDEs) have illustratedthis approach. Traditionally, IDEs were expensive proprie-tary applications, which were especially lucrative if theyattracted a large license-paying user base. When IBM choseto move its Eclipse IDE to open source, the decision seemedsurprising because the source code was valued at $40 million.IBM has had massive compensations, however. It substan-tially increased its popularity as a development platform andexpanded the market for its complementary products. Severalother companies have now also moved their proprietary IDEsto open source, including Sun with NetBeans and BEA withBeehive.

Several examples of dual product/licensing exist. MySQLprovides a high-profile example of such a strategy. Millionsof free copies of MySQL have been downloaded. Of these,about one customer in every thousand has purchased a com-mercial license from MySQL. This proportion seems small,but it amounts to thousands of fee-paying customers. Otherdual-product strategies include Red Hat with Fedora andEnterprise Linux, Sun with StarOffice and OpenOffice, andIona Technology with Celtix and Artix.

Companies can also leverage the commodification effect thathas occurred with open source. They take advantage of opensource in terms of its low cost, reliability, and portabilityacross platforms. For example, Oracle can reduce the overallcost of database implementation for its customers, and IBMcan reduce the overall cost of servers. In the area ofembedded systems, open source is fast becoming dominant.Here, companies are concerned with open standards, stability,high performance, small footprint, and the ability to run ongeneric hardware. A vibrant, responsive development com-munity exists and is willing to port to other platforms andwrite extra utilities.

Several companies leverage open source as a base upon whichthey offer products other than software. For example, HPpromotes open source in areas that facilitate the deploymentof its hardware, while the O’Reilly publishing house hasearned significant revenue from books related to the opensource concept.

Leveraging Community Software Development

Leveraging the talents of the open source community allowscompanies to increase development productivity, with theadded benefit that much work may be done for free. Thus,hundreds of Eclipse plug-ins have been developed. Also,Apple’s initiative in starting the Darwin open source projectto develop part of its operating system facilitates extradevelopment contributions that for the most part are free. Inaddition, Apple’s reputation in the open source communityhas improved. The phenomenon becomes circular, as theextra functionality increases the software’s attractiveness toother developers. These, in turn, contribute additionalfunctionality.

Leveraging the Open Source Brand

While patents and copyrights are key issues with respect tofree software, another IP mechanism, the trademark or brand,could become significant with OSS 2.0. For example, Oraclepromotes the “unbreakable Linux” slogan. Also, an in-creasing number of government agencies and public adminis-trations (traditionally the largest consumers of software) aremandating that open source be a priority option, even to theextent of requiring formal justification for not choosing anopen source solution if one is available. This will ensure theopen source brand becomes even more important in thefuture.

OSS 2.0 Product Support

In the past, developers have referred to the “exhilaratingsuccession of problem-solving challenges” in installing opensource products (Sanders 1998). As the OSS 2.0 modelbecomes more mainstream, however, time-impoverishedprofessionals are unlikely to seek exhilaration in this manner.Further, many organizations have difficulty relying onbulletin boards for their support. As OSS 2.0 evolves,customers will want professional service—support, training,and certification—and will be prepared to pay for it.



Table 2. A Typology of OSS 2.0 Licenses

Reciprocal GPL, LGPL, Open Source License (OSL)

Academic Style Academic Free License, Apache License, BSD, MIT

Corporate Type MPL, Qt Public License, Sun Public License, IBM Public License, Apple PublicLicense, Eclipse Public License

Non-Approved (e.g., SharedSource family)

Microsoft Shared Source Initiative Licenses: (Microsoft Community License, MicrosoftPermissive License), Sun Community Source License (SCSL)

The Whole-Product Approach: From BazaarProcess to Bazaar Product

The particular characteristics of OSS 2.0 position it as a goodexemplar of the “whole-product” concept of a market-drivenbusiness approach that seeks to deliver a complete solution tothe customer in terms of products and services (Moore 1999).The open source phenomenon is market-driven and, as dis-cussed above, places a great deal of emphasis on services. Itadopts a professional approach to achieving value by estab-lishing a profitable business venture for which customers arewilling to pay the going rate. In this scenario, developers dothe coding. Others complete the business model by addingsales and marketing services—necessary activities but ones inwhich developers may not be interested. The OSS 2.0 whole-product approach is also larger than a single company or soft-ware product or service. Indeed, the network benefits of opensource arise as a result of the size of the overall communityand ecosystem. Thus, a network of interested parties withcomplementary capabilities can form an ecosystem to offer aprofessional product and service in an agile, bazaar-friendlymanner. Customer service requests can be routed to the mostappropriate expert partner in the network, perhaps even to thedeveloper who wrote the actual code. In this manner, theOSS 2.0 brand increases trustworthiness to achieve market-leader status. Such convenience networks exist already inconventional business circles. The LVMH (Louis VuittonMoet Hennessy) brand is an international network of almost50 luxury brand leaders in fashion, wines and spirits, watches,jewelry, and cosmetics (www.lvmh.com). From a businessperspective, this network of well-known brands creates theultimate luxury brand status, LVMH. Nonetheless, individualbusinesses can still pursue their own interests independently.

In OSS 2.0, the bazaar metaphor therefore shifts from justbeing associated with the development process (Raymond,1999), which becomes less bazaar-like, to product deliveryand support, which becomes more bazaar-like. Many com-panies will find profitable opportunities in customer support.

The claim by large proprietary software companies that opensource would stifle local software industries is provingunfounded. A more-likely scenario is that small service-centric software companies will thrive by providing training,technical support, and consultancy for local organizations thatdeploy open source products.

OSS 2.0 Licensing

In OSS 2.0, a plethora of license types has emerged. TheOpen Source Initiative (OSI) and the Free Software Founda-tion (FSF) has approved almost 100 distinct licenses overallto date between them (but with little general agreement asonly about one-third of these licenses are approved by both)(Lyddy-Collins 2005). The licenses can be grouped into fourbroad categories: reciprocal licenses (as per the FOSS era),academic-style licenses, corporate licenses, and non-approved(by FSF or OSI) licenses such as Microsoft’s Shared Sourcefamily of licenses (Table 2).

In OSS 2.0, the term viral has been adjudged to have negativeconnotations. The preferred term is reciprocal. Reciprocallicenses such as the GPL and LGPL have already been dis-cussed above in relation to FOSS licensing. Another varia-tion, the Open Software License (OSL), was created in 2002as an alternative to the GPL that would be more acceptable tocorporate users and developers. Again, this emphasizes thecontinued progression toward corporate and commercialcompatibility, which is at the heart of OSS 2.0. Interestingly,while the FSF has issued warnings against this license, LinusTorvalds has adopted it for open source development otherthan the Linux kernel.

Corporate-style licenses are central to OSS 2.0. They reveala potential friction point in OSS 2.0, because they seek tobenefit corporate interests rather than the open source devel-opment community. As mentioned already, these are gener-ally based on the Mozilla Public License (MPL). Typically,



they seek to allow open source code to be mixed withproprietary code and to ensure that corporate sponsors retaincontrol of derivative works.

The non-approved category of licenses for OSS 2.0 is perhapsthe most interesting. It pushes the boundaries of proprietarysoftware as this sector seeks to accommodate the open sourcemodel. Two significant exemplars are the Sun CommunitySource License (SCSL) and the Microsoft Shared SourceInitiative family of licenses.

The realization that “transparency increases trust” (Matusow2005) has led to Microsoft’s Shared Source Initiative.Microsoft has recently converged on three core shared sourcelicenses:

• Microsoft Reference License allows licensees to merelyview source code. This practice is regarded with deepsuspicion by the open source community, which foreseespotential transgressions of patents by developers whocopy the code.

• Microsoft Community License is based on the MozillaPublic License and is intended for collaborative projects.

• Microsoft Permissive License is similar to the BSDlicense and effectively allows “licensees to review,modify, redistribute, and sell works with no royaltiespaid to Microsoft” (Matusow 2005).

Both the FSF and OSI originally agreed that the SharedSource Initiative was neither free nor open. Nonetheless, itwill be increasingly difficult to exclude licenses, such as theMicrosoft Permissive License, that comply with the hybridmodel of OSS 2.0.

Microsoft is, therefore, likely to be a major player in OSS 2.0.It has already distributed an open source product for sometime—Windows Services for Unix—and has publiclyacknowledged that Windows 2000 and Windows XP use opensource BSD code. Also, it has a number of high-profile opensource projects on SourceForge. Microsoft has abstractedsome of the key ideas from open source. Recognizing thepower of the social and community identification aspects ofopen source, it has introduced the Most Valued Professionals(MVP) initiative. It has extended access to source code tothis select group. The Open Value policy permits salesrepresentatives to offer extreme discounts and zero percentfinancing to small businesses that might switch to zero-costopen source (Roy 2003).

Summary

The above discussion illustrates how the OSS 2.0 phenom-enon is significantly different from its FOSS antecedent. Thedevelopment process becomes less bazaar-like as strategicplanning becomes paramount. Analysis and design are moredeliberate as the model spreads to vertical product domains.Developers are increasingly being paid to work on opensource. More sophisticated business models are emerging andemployed in a hybrid fashion. Customers are willing to paythe going rate for the whole product in terms of support,which in turn can be delivered by a bazaar network ofinterested parties that provide varied but complementaryservices. Licensing also moves to the fore as proprietarycompanies produce licenses that comply with the open sourcedefinition, while open source companies seek to raise moneythrough licensing. Given this complex melting pot, a numberof significant implications and challenges for research andpractice emerge.

Implications and Challengesfor Research and Practice

The discussion above indicates several issues that provide keychallenges for research and practice (Table 3). As is appro-priate in an applied discipline, these are not completelydistinct. Challenges for practice have a research angle andvice versa. Some research initiatives that appear relevant toaddressing these challenges are also identified.

Implications and Challenges for Research

Transferring Lessons from Open Sourceto Conventional Development

While open source may not represent a real paradigm shift insoftware development (Fitzgerald 2005), the model is anextremely successful exemplar of globally distributeddevelopment. It is attracting considerable attention in thecurrent climate of outsourcing and off-shoring. Organizationsare seeking to emulate open source success on traditionaldevelopment projects, through initiatives variously labeled asinner source, corporate source, or community source(Dinkelacker and Garg 2001; Gurbani et al. 2005).

Other open source principles—such as open sharing of sourcecode, large-scale independent peer review, the community



Table 3. Key Issues for Research and Practice

Research• Transferring lessons from open source development to conventional development (inner source)

N Offshoring—globally distributed software developmentN Open code-sharing, large-scale peer-review, community development model

• Expanded role of users and altered user-developer relationship• Elaboration of business models • Derivation of appropriate TCO models

Practice• Achieving balance between value-for-money versus acceptable community values • Implementing the whole-product approach• Stimulating development in vertical domains• Safeguarding against IPR infringement

development model, and the expanded role of users—alsohave important implications. In the traditional model of soft-ware development, users and developers are often located inseparate departments. They sometimes have little mutualrespect or voluntary interaction. The user–developer relation-ship in open source has typically been different. Early opensource developers were often users of the products. As OSS2.0 has emerged, this situation has changed. In the absence ofa traditional vendor, users need to become involved moreintimately in the development process, as technical staffcannot simply send a checklist of requirements to the vendorto ascertain if needs will be met. Deploying open source canlead to a sense of shared adventure that is not common in theproprietary software arena. Furthermore, users may be morewilling to sacrifice certain desired functionality if open sourceproducts could not easily provide it (Norris 2004).

Elaboration of Business Models

Much research is already being undertaken to refine andelaborate the business strategies discussed earlier (e.g., Felleret al. 2006; Koenig 2004; Krishnamurthy 2005; Onetti andCapobianco 2005). Nonetheless, a more-careful definition ofthe concept is needed. For example, the term business modelis frequently used loosely in the context of open source. Auseful definition of business model suggests it comprisesthree components: value, revenue, and logistics (Mahadevan2000). The value component represents the value propositionfor customers and vendors, the revenue component focuses onhow organizations can earn revenue, and the logistics com-ponent focuses on supply chain issues. Revenue generationhas been the primary focus for most of the research on open

source business models. As the earlier discussion of OSS 2.0business strategies illustrates, however, the value propositionand the logistics of the whole product across the overallsupply chain are paramount in OSS 2.0. More analysis isneeded in these areas.

Deriving Appropriate Total Cost of Ownership(TCO) Measures for OSS 2.0

Calculating the total cost of ownership (TCO) of software isa complex, multifaceted issue. It requires consideration ofmany factors, including software purchase, maintenance andupgrade costs, hardware purchase and maintenance costs,personnel training, and legal and administrative costs (Russoet al. 2005). Given this complexity, proprietary and opensource advocates predictably have each claimed a lower TCO(Wheeler 2005). Nonetheless, conventional TCO measuresmay not be suited to the open source phenomenon. Less-obvious benefits accrue due to network externality effects anda more cooperative developer-user relationship.

A promising strand of research that could suit the dynamicsof open source is based on the theory of real options invest-ment analysis (Fichman 2004). Real options analysis isappropriate where high levels of flexibility and uncertaintyexist (characteristics of open source environments). In termsof flexibility, considerable scope surrounds which products orfunctions may be implemented and how the software might becustomized. Also, the zero-cost aspect offers considerableflexibility in terms of choosing when implementation occurs.Uncertainty arises because no “royal road” to fail-safe opensource implementation exists.



Implications and Challenges for Practice

Value for Money Versus Adhering toAcceptable Community Values

The ambiguous term free may have been the key word forFOSS, where both its meanings (i.e., free as in zero cost, andfree as in unrestricted access) were significant. Value, aneven more ambiguous term, will be the key word for OSS 2.0.Two of the term’s connotations are especially significant:value for money and acceptable community values. Theintegration of open source into the commercial arena and theassociated desire to create profit represents a critical source oftension, given the concomitant need to achieve a balance withcollectivist, public-good community values—an inevitablelegacy from the more ideologically driven Free Softwarecommunity. Both connotations of value are discussed here.

Value for Money

OSS 2.0 can dramatically alter the economic dynamics of amarketplace. Despite the vast sums of money involved andthe enormous economic potential of OSS 2.0, it erodes certainhitherto profitable markets, for example, the multibilliondollar operating system market. Such a market destructionstrategy is captured in the mantra, “If you can’t be the numberone product in a sector, then open source it.” As OSS 2.0emerges, those involved are neither driven primarily byideology nor seeking to make vast fortunes. They simplywish to earn a reasonable livelihood from their efforts (Everitt2004). Both customers and developers need to perceive valuefor money in OSS 2.0. Free as in zero cost is replaced by avalue-for-money concern, and OSS 2.0 customers areprepared to pay for a professional service. For instance, manycompanies are prepared to pay a fee for StarOffice withassociated support and warranty, in preference to adopting thezero-cost, OpenOffice alternative.

Acceptable Community Values

OSS 2.0 blurs the distinction between open source andproprietary software. Key open source players such as RedHat and Novell's SUSE Linux business unit position theirLinux distributions to be more similar to a proprietary model.Traditional proprietary companies, such as HP, IBM, andMicrosoft, move more toward open source. Nevertheless, inthe OSS 2.0 model, these companies must still satisfy certaincriteria in relation to acceptable community values (asignificant challenge for OSS 2.0). Large commercial organi-zations are not always well perceived within the open sourcecommunity. Companies such as IBM, Sun, and HP support

open source initiatives, but their support for patents is clearlyat odds with the open source philosophy. Also, the quin-tessential patron of open source, Red Hat, could struggle infuture as its policies increasingly conflict with communityspirit and values. Use of subscription agreements and effec-tive customer lock-ins through confidential service bulletinsare close to the boundary of acceptable community values.Also, MySQL’s decision to port to SCO’s OpenServer plat-form, although a profitable venture, has met with strong criti-cism because of the negative feelings toward the SCO groupwithin the open source community. The power of communityshould not be underestimated. A telling example was theattempt by Caldera to sell its Linux distribution, which faileddue to the extremely negative reaction of the open sourcecommunity.

Within the overall community, the spirit of OSS 2.0 can leadto positive network externalities. In the Beaumont Hospitalcase (Fitzgerald and Kenny 2003), users of the same opensource products in Finland traveled to Ireland to volunteersupport and offer extra functionality that they had developed.The expectation was that Beaumont would reciprocate bymaking available any extra functionality they developed.Cooperation of this nature is rare in the proprietary market-place, but it is symptomatic of the strong community valueorientation of open source.

Implementing the Whole-Product Approach

I have already discussed how a bazaar network of companiescan collaborate to offer a whole-product approach to cus-tomers. In addition to providing a customized professionalsupport service, the whole-product bazaar network can satisfyother emerging business needs. For instance, the plethora ofopen source products currently available and the lack ofvendors to provide marketing information cause a largeknowledge gap. An up-to-date catalog of high-quality opensource products is needed which could provide details on thefunctionality offered by various products, the types of supportavailable, training needs, reference sites of deployment, andcompanies offering support.

Stimulating Open Source in Vertical Domains

Early open source products tended to involve horizontal infra-structure where requirements are part of conventionalwisdom. Developers with different backgrounds, or evenstudents, could contribute. In vertical domains, however,business requirements are more complex and demand more-specialized knowledge. A significant challenge is to stimulateopen source development in these domains. An example in



the healthcare sector is the Beaumont Hospital case men-tioned earlier. As more purposeful strategic planning takesplace in OSS 2.0, complementary development strategies willbe enacted to provide a complete portfolio of open sourceproducts. Likewise, in the education sector, some cooperativeinitiatives have emerged to promote use of open source (e.g.,www.osef.org; www.ossite.org; www.schoolforge.net).

Safeguarding Against IPR Infringement

While open source was a fringe phenomenon, its relativeobscurity offered some safety from litigation. Once it enteredthe mainstream, the threat of litigation arising from IPRinfringements became real—for example, the SCO Group’slawsuit against IBM over alleged patent infringement inLinux. The ultimate goal of IP protection mechanisms suchas patents could be summarized as the publication of non-trivial ideas, with an explicit guarantee of continued avail-ability, which seeks to protect the interest of the smallplayers, for the overall betterment of society, as others learnfrom and improve on the original ideas. Interestingly, thisdefinition also captures the open source phenomenon well.However, the stimulation of innovation and creativity, whichshould be the fundamental rationale behind IP protection, hasfailed abjectly in the software area (Bessen and Hunt 2004).Ironically, even though open source has often been aboutreplicating proprietary products, the ingenuity of the globaldevelopment community has allowed innovative newfunctionality to emerge—for example, the OpenOffice suiteand the Mozilla Firefox browser.

Warranties and indemnification against IP infringements arekey issues for OSS 2.0. A number of initiatives exist, but allare limited in scope. For example, Red Hat offers a warrantyagainst any infringement in its Red Hat Enterprise Linuxdistribution (although this warranty just promises that RedHat will replace any infringing code). Similarly, Novell hasoffered customers of its SUSE Linux an indemnificationagainst copyright (but not patent) infringements. HP alsooffers its customers an indemnification, but only for claimsmade by SCO. JBoss offers indemnification to its customers,but limited to the value of the customer’s contract. Mean-while, some third parties, such as Open Source Risk Manage-ment, are selling indemnification protection.

Concluding Remarks

The open source field today and the decision support systems(DSS) field in the past have interesting similarities. Bothhave drawn together a wide range of researchers from dis-

parate disciplines. For DSS, however, the consequence hasnot been benign. For instance, Keen lamented DSS researchhaving been “co-opted and trivialized…by lab-experiment-academics,” and concluded that “identity is easily blurred anderoded when the purposive focus of the research is lost andthe topic area then dominates” (Keen 1991, pp. 37-38). Ibelieve a similar situation could occur in open sourceresearch—indeed, the problems could be exacerbated asresearchers take advantage of the ready availability of largeonline data repositories (where much of the data may be oflittle real value), and continue to focus their research effortsinward on the phenomenon to repeatedly study projectcharacteristics and developer motivation, for example. Suchresearch has been valuable, but a more purposive agenda isneeded—one that also looks outward at the open source phe-nomenon in general and at the emergent OSS 2.0 phenom-enon in particular.

Acknowledgments

I would like to record my gratitude to Joe Feller, Rishab AiyerGhosh, Carlo Daffara, Franco Gasperoni, and Maha Shaikh forfeedback on this topic, and also the MIS Quarterly reviewers. Thework was supported by EU project grants, CALIBRE and COSPA,and by a Science Foundation Ireland Principal Investigator Grant,02/IN.1/I108.

References

Bessen, J., and Hunt, R. “An Empirical Look at Software Patents,”Working Paper No. 03-17/R, Research on Innovation, Boston,2004 (available online at http://www.researchoninnovation.org/swpat.pdf).

Bezroukov, N. “Open Source Software Development as a SpecialType of Academic Research (Critique of Vulgar Raymondism),”FirstMonday (4:10), October 1999 (available online at http://www.firstmonday.org/issues/issue4_10/bezroukov/).

Dinkelacker, J., and Garg, P. “Applying Open Source Concepts toa Corporate Environment,” in Proceedings of 1st Workshop onOpen Source Software Engineering, Toronto, May 15, 2001(available online at http://opensource.ucc.ie/icse2001).

Everitt, P. “Zope: Open Source, Revisited,” First CALIBRE Inter-national Conference, Hague, November 19, 2004 (availableonline at http://www.calibre.ie/hague/docs/3_PEveritt_Zope.pdf).

Feller, J., Finnegan, P., and Hayes, J. “Open Source Networks: AnExploration of Business Model and Agility Issues,” Proceedingsof the 14th European Conference on Information Systems,Göteborg, Sweden, June 12-14, 2006.

Feller, J., and Fitzgerald, B. Understanding Open Source SoftwareDevelopment, Addison-Wesley; London, 2002.

Fichman, R. “Real Options and IT Platform Adoption: Implicationsfor Theory and Practice,” Information Systems Research (15:3),2004, pp. 132-154.



Fitzgerald, B. “Has Open Source a Future?,” in Perspectives onFree and Open Source Software, J. Feller, B. Fitzgerald, S.Hissam, and K. Lakhani (eds.), MIT Press, Cambridge, MA,2005, pp. 121-140.

Fitzgerald, B., and Kenny, T. “Open Source Software in theTrenches: Lessons from a Large Scale Implementation,” inProceedings of 24th International Conference on InformationSystems, S. T. March, A. Massey, and J. I. DeGross (eds.),Seattle, December 2003, pp. 316-326.

German, D. M. “GNOME: A Case of Open Source Global Soft-ware Development,” in Proceedings of the InternationalWorkshop on Global Software Development, Portland, OR, May9, 2003, pp. 39-43, gsd2003.cs.uvic.ca/gsd2003proceedings.pdf).

Gurbani, V. K., Garvert, A., and Herbsleb, J. D. “A Case Study ofOpen Source Tools and Practices in a Commercial Setting,” inProceedings of the 5th Workshop on Open Source SoftwareEngineering, St. Louis, MO, May 17, 2005, pp. 24-29.

Hecker, F. “Setting Up Shop: The Business of Open-SourceSoftware,” June 2000 (available online at http://www.hecker.org/writings/setting-up-shop).

Keen, P. “Keynote Address: Relevance and Rigor in InformationSystems Research,” in Information Systems Research: Contem-porary Approaches and Emergent Traditions, H. Nissen, H.Klein, and R. Hirschheim (eds.), Elsevier Publishers, Amsterdam,1991, pp. 27-49.

Koenig, J. “Seven Open Source Business Strategies for CompetitiveAdvantage,” IT Manager’s Journal, May 14, 2004 (availableonline at http://management.itmanagersjournal.com/article.pl?sid=04/05/10/2052216&tid=85&tid=4).

Krishnamurthy, S. “An Analysis of Open Source Business Models,”in Perspectives on Free and Open Source Software, J. Feller, B.Fitzgerald, S. Hissam, and K. Lakhani (eds.), MIT Press,Cambridge, MA, 2005, pp. 279-296.

Lyddy-Collins, N. Perspectives on Open-Source Software LicensingPolicy in a Commercial Software Development Environment,npublished Master’s Thesis, University of Limerick, 2005.

Mahadevan, B. “Business Models for Internet-Based Ecommerce:An Anatomy,” California Management Review (42:4), 2000, pp.55-69.

Matusow, J. “Shared Source: The Microsoft Perspective,” inPerspectives on Free and Open Source Software, J. Feller, B.Fitzgerald, S. Hissam, and K. Lakhani (eds.), MIT Press,Cambridge, MA, 2005, pp. 329-346.

Michlmayr, M., Hunt, F., and Probert, D. “Quality Practices andProblems in Free Software,” in Proceedings of First InternationalConference on Open Source (OSS2005), M. Scotto and G. Succi(eds.), Genoa, Italy, July 11-15, 2005, pp. 24-28.

Moore, G. Crossing the Chasm, Harper, New York, 1999.Norris, J. “Mission-Critical Development with Open Source Soft-

ware: Lessons Learned,” IEEE Software (21:1), 2004, pp.42-49.

O’Mahony, S. “Non-Profit Foundations and their Role in Com-munity-Firm Software Collaboration,” in Perspectives on Free

and Open Source Software, J. Feller, B. Fitzgerald, S. Hissam,and K. Lakhani (eds.), MIT Press, Cambridge, 2005, pp.393-414.

Onetti, A., and Capobianco, F. “Open Source and Business ModelInnovation: The Funambol Case,” in Proceedings of FirstInternational Conference on Open Source (OSS2005), M. Scottoand G. Succi (eds.), Genoa, Italy, July 11-15, 2005, pp. 224-227.

Raymond, E. The Cathedral and the Bazaar: Musings on Linuxand Open Source by an Accidental Revolutionary, O’Reilly,Sebastapol, CA, 1999.

Roy, A. “Microsoft vs. Linux: Gaining Traction,” CharteredFinancial Analyst (9:5), 2003, pp. 36-39.

Rusovan, S., Lawford, M., and Parnas, D. “Open Source SoftwareDevelopment: Future or Fad?,” in Perspectives on Free andOpen Source Software, J. Feller, B. Fitzgerald, S. Hissam, and K.Lakhani (eds.), MIT Press, Cambridge, MA, 2005, pp. 107-122.

Russo, B., Braghin, B., Gasperi, P., Sillitti, A., and Succi, G.“Defining TCO for the Transition to Open Source Systems,” inProceedings of First International Conference on Open Source(OSS2005), M. Scotto and G. Succi (eds.), Genoa, Italy, July 11-15, 2005, pp. 108-112.

Sanders, J. “Linux, Open Source, and Software’s Future,” IEEESoftware, September/October 1998, pp. 88-91

Schach, S., Jin, B., and Wright, D. “Maintainability of the LinuxKernel,” in Proceedings of 2nd Workshop on Open SourceSoftware Engineering, J. Feller, B. Fitzgerald, S. Hissam, and K.Lakhani (eds.), Orlando, FL, 2002 (available at http://opensource.ucc.ie/icse2002).

Torvalds, L., and Diamond, D. Just for Fun: The Story of anAccidental Revolutionary, Harper Collins, New York, 2001.

Tushman, M., and Anderson, P. “Technological Discontinuities andOrganizational Environments,” Administrative Science Quarterly(31), 1986, pp. 439-465.

Wheeler, D. “Why Open Source Software/Free Software (OSS/FS,FLOSS, or FOSS)? Look at the Numbers!,” November 2005(available online at http://www.dwheeler.com/oss_fs_why.html).

About the Author

Brian Fitzgerald holds the Frederick A Krehbiel II Chair inInnovation in Global Business and Technology at the University ofLimerick, Ireland, where he is Research Fellow and ScienceFoundation Ireland Principal Investigator. He has a Ph.D. from theUniversity of London and has held visiting positions in Sweden, theUnited Kingdom, and the United States. His publications include 8books and more than 100 papers, published in leading internationalconferences and journals in both the Information Systems andSoftware Engineering fields. Having worked in industry prior totaking up an academic position, he has more than 20 yearsexperience in the software field.

Documents

THE TRANSFORMATION OF OPEN SOURCE SOFTWARE