FROM PROPRIETARY TO OPEN SOURCE,
A CASE STUDY OF CITRIX XENSERVER
Harm Roelof Pieters
s1537687 - [email protected]March 25, 2014
Master thesis Industrial Engineering and Management
Faculty of Mathematics and Natural SciencesUniversity of Groningen
Supervisors
prof. dr. ir. M. Aiello University of Groningen dr. ir. I.ten Have, MBA University of Groningen
Executive summary
Open source is an indispensable part of the software industry, and is growing as an attractive and viable strategic option for commercial exploitation. Organizations, with an existing proprietary product and the desire to switch to an open source strategy, are required to undergo a transition profoundly impacting the organization. The following document presents the study into the initial stages of the transition of XenServer towards open source, conducted at Citrix Research and Development. In order to provide the organization with a process on how to proceed with the open sourcing, given the organizational goals.
Research in the field of transitioning to open source is limited, and in order to gain insights existing literature on open source projects is gathered. Resulting in a segmentation of transition projects in charac-teristics, providing a segmented structure to the study. The characteristics arelegality,community,process, infrastructure,software,community,marketing,business modelandmotivation. In addition to the literature case studies on historical transitions to open source and related work are gathered in order to analyse the current state of the organization.
The analysis of the organization is conducted through a case study of the current state of the transition, based on the characteristics and the existing literature and case studies. The result is an overview of im-provement areas, most notably thecommunityand its activity and growth. Further results suggest a more transparent organization, providing information and documentation to the public. Maintain activity within the existing community and implement infrastructure to facilitate bug tracking and documentation. Selec-tion of an existing target community to act as role model, allowing amongst others the implementaSelec-tion of governance structures.
The information is combined to present a transition process for the organization, divided into three phases in accordance to priority. The first phase includes makingdecisionsand implementing Infrastruc-ture, in addition the adjustment of the internalprocessesand publicizinginformationis initiated. The second phase consists of creation and publication ofdocumentation, the remainder ofprocessesandinformation and the first part ofcollaborationinitiating between organization and community. Lastly, the final phase includes thewebsiteand the final section ofcollaboration. Productimprovements andMetricsgathering span the three phases of the process, beginning at the first phase. The proposed process is the contribu-tion of the study to the organizacontribu-tion, whilst the case study and methodological process contribute to the understanding of the opening of proprietary software field in FLOSS research.
Keywords: Open source, Opening proprietary software, Open Source characteristics, Open source engi-neering, FLOSS.
Preface
The document presented here is the result of my master thesis research for "Industrial Engineering and Management - Information Engineering" conducted at Citrix Research and Development. In the preface I would like to take the opportunity to thank the people who made my research possible. First I would like to thank my supervisors, prof. dr. Marco Aiello, for taking me on as a student and providing me with support throughout the research, and dr. ir. Ingrid ten Have for providing me with the opportunity of doing my master thesis abroad at Citrix and the different insights and feedback.
Second I would like to thank Citrix Research and Development, and Andrew Halley for providing the opportunity of performing my master thesis and giving initial directions. Special thanks goes out to Mike McClurg for being my mentor throughout my period in Cambridge. During our weekly meetings you pro-vided me with different perspective, discussions, interests and kept me sane during the process. Last, but definitely not least, I would like to thank my parents for their unconditional support during the research and my entire time as a student.
Table of Contents
List of Tables vi
List of Figures vi
1 Introduction 1
1.1 Citrix Research and Development . . . 1
1.2 State of the art . . . 1
1.3 Problem . . . 2 1.4 Contribution . . . 2 1.5 Document structure . . . 3 2 Background 4 2.1 Proprietary . . . 5 2.2 Open source . . . 5 2.3 Summary . . . 8 3 Related work 9 3.1 OSCOMM framework . . . 9
3.2 Open source strategies . . . 12
3.3 Release Process . . . 13 3.4 Summary . . . 14 4 Problem statement 15 4.1 Problem Definition . . . 15 4.2 Problem Analysis . . . 16 4.3 Stakeholders . . . 17
4.4 Goal & research question . . . 19
4.5 Conceptual model . . . 20
4.6 Research sub-questions . . . 22
4.7 Methodology . . . 23
4.8 Research process . . . 24
5 Literature 26 5.1 Open source characteristics . . . 26
5.2 State of the art on characteristics . . . 26
5.3 Case studies . . . 35
6 Citrix research and Development case study 46 6.1 Organization . . . 46
6.2 Business Model . . . 48
6.3 Characteristics . . . 49
7 Analysis 58 7.1 Introduction . . . 58 7.2 Motivation . . . 58 7.3 Business Model . . . 59 7.4 Characteristics . . . 60 7.5 Summary . . . 67 8 Transition 70 8.1 Introduction . . . 70 8.2 Process . . . 70 8.3 Discussion . . . 76 9 Results 78 9.1 Key Findings . . . 78 9.2 Organizational goals . . . 81 9.3 Research goals . . . 82 9.4 Validation . . . 82 10 Conclusion 84 10.1 Discussion . . . 84 10.2 Further Research . . . 85 11 References 86 Appendices 90 Glossary 91 A Organization description 94 1.1 Citrix Research and Development . . . 94
1.2 XenServer . . . 95
1.3 Strategy . . . 97
1.4 Teams . . . 99
List of Tables
2.1 A Software Licensing Taxonomy [17, p. 60]. . . 7
3.1 Release Readiness Rating (R3) Framework [26]. . . 10
3.2 Community Watchdog Measurements [26]. . . 12
3.3 Important Measures to Achieve Success [16][p. 55-65] . . . 13
5.1 Technological motivations. . . 27
5.2 Economical motivations. . . 28
5.3 Overview of most common used licenses is Open Source (OS). . . 31
List of Figures
2.1 Continuum of governance in software projects [7, 15, 43, 54, 57]. . . 43.1 Elements of OSS Community Building [52, p. 59]. . . 9
3.2 OSCOMM framework phases [26, p. 1470]. . . 10
3.3 Conceptual Framework for Open Source Engineering [51, p. 4] . . . 11
4.1 Conceptual Model . . . 21
4.2 Regulatieve cyclus of Van Strien (Van Aken et al., p 13) . . . 23
4.3 Research process illustrated. . . 24
5.1 Community building dimensions [26, p. 1468]. . . 26
5.2 License decision model [33, p. 34]. . . 31
6.1 XenServer moving from a proprietary to sponsored OS. . . 47
7.1 Analysis process of the open sourcing at Citrix Research and Development (Citrix R&D). . . . 58
8.1 Transition process divided in phases and actions. . . 71
1.
Introduction
Open source (OS) is everywhere. It is used to run smart phones (e.g. Android), servers (e.g. Linux, Apache, MySQL), embedded devices (e.g. Java), browsers (e.g. Mozilla Firefox) and much more. As a result a ma-jority of the worldwide organisations are now depending on some form of Open Source Software (OSS) for mission critical processes, an example is the Mars Exploration Rover [40]. The adoption, in combination with the current economical decline [27] and properties as flexibility, easy integration and security [11], is pushing the embrace of open source over proprietary products in the market. Resulting in a fundamental impact on the creation, distribution and use of software [8].
The phenomenon in the market does not appear to be slowing down, OSS is growing and as more OS project emerge, commercial organisations are starting to increasingly commercialise open source projects. The historic situation where OSS is exclusively developed by volunteers is no longer accurate. The initial commercial paradox, how a commercial organisation can earn money when it is offering its products for free [46], has been disproved by organizations creating viable business strategies such as RedHat, MySQL and Canonical. Proving the commercial market for OS is maturing and it is becoming a strategic option for any software business [1] leveraged as mechanism to disrupt an existing market with a strong market leader, or by the market leader to increase it’s foothold [44].
1.1 Citrix Research and Development
OS offers opportunities, resulting in existing proprietary software to be released under an open source license to seize the opportunities [26]. A commercial organization in the processes of releasing proprietary software is Citrix R&D, a division of Citrix Systems, Inc. (Citrix), with the proprietary product XenServer
1. Motivated by a declining market share of XenServer in order to remain relevant in the market and a
viable product to the parent organization Citrix. The research presented in the remaining chapters focusses around the research, conducted at Citrix R&D, into the process of transitioning. The product XenServer allows for virtualization utilizing the OS project Xen Hypervisor as core and providing enterprise grade and ease of use features on top. A comprehensive summary of the organization can be found in appendix A. The organization is looking to transition successfully, however is currently lacking a clear strategy.
1.2 State of the art
Open sourcing is part of the field of Free Libre Open Source Software (FLOSS) research, providing academic background to OSS. In a recent study by Crowston et al. into the state-of-art of FLOSS development it is
found, though there is increasing commercialization, research into firm participation in OSS is low and “additional research needs to be conducted to investigate how firm-involved FLOSS project differentiate from non-firm-involved FLOSS projects” [12]. Open source as foundation for new strategy and businesses have gained low amounts of research interest [26] because the trend to open source proprietary software is relatively new [34]. Cases such as Java (Sun Microsystems) and Symbian (Nokia) do however demonstrate the potential of open sourcing.
The amount of research into transitioning from proprietary to open source remains limited. The litera-ture found so far is based on the single works of Kilamo et al., with the OSCOMM model for transitioning to open source. Unfortunately, as the research is conducted by the same set of researchers, it is not possible to verify the model as proposed and using it as given is added risk to the validation of the research. Further research into strategies remains high level and do not include definitive solutions. The different character-istics are based on the research of Kilamo et al. which are a starting point. The final variable missing in the model of Kilamo et al. is the assumption the end goal is a vibrant ecosystem. In the case of the research at Citrix R&D the goal is not a vibrant ecosystem alone but increased market share.
1.3 Problem
The initial problem arising from within the organization is how to transition towards an OS project and in particular how it can successfully transition to OS focusing on increased market share and secondary goals of the organization. However there are still a lot of uncertainties on how existing commercial organizations with proprietary software can transition to OS, and the literature regarding transitions is limited. Part of these ambiguities are incorporated into the research, the transitioning, for a commercial company selling proprietary products, to a organization commercializing an open source product in a more general case. The goal of the research, to take the case of Citrix R&D and determine the necessary steps required for the organization to transition to an OS model resulting in achievement of pre-set goals.
1.4 Contribution
The main contribution of the research is the practical case where Citrix R&D is provided with a transition process strategy advice. The research contributes toward the existing knowledge of transitioning closed or proprietary software towards an open source project in the field of FLOSS. The theoretical part of the research provides a meta-analysis on the state-of-art on open source governance, open source character-istics, transition to open source and case studies conducted on the transition to open source. Secondly, based on the OS characteristics found in literature, a case study of Citrix R&D is presented. The case study is analyzed and evaluated against the existing use cases found in literature. Finally, based on the analysis of the case study and literature, a model for the remaining open sourcing for Citrix R&D is suggested. The methodology used in the study can provide inspiration to other commercial organizations contemplating transiting one or more proprietary products to open source.
1.5 Document structure
The first section, chapter two and, contains a background discussion on the differentiation between propri-etary and OS and related work on open sourcing of closed software. Chapter four discusses the problem the research aims to address, the methodology used and steps taken in order to arrive at the results in more detail. Chapter five provides information on the characteristics of open source, the state of are and case studies. The third section includes chapter six, seven and eight. Chapter six is the diagnoses of the case study, looking at Citrix R&D from the perspective of the characteristics found in chapter five. Chapter seven takes the use case and evaluates the case with the literature study in order to define an strategy presented in chapter eight for the organization to achieve their goals. The results of the research are pre-sented in chapter nine, including key findings and validity. Lastly, chapter ten contains the conclusion of the research, including discussion and further research.
2.
Background
The goal of the background section is to provide additional information on the definitions and disparities between the terms: proprietary-, free-, libre- and open source (software). Both proprietary and OS are open systems, if described from systems theory terminology. The systems inputs are people, technology and processes and these three inputs produce again technology, people and products [38]. However pro-prietary and OS can be conceptualized as being on opposing sides of the software development space [2]. Taking the perspective of governance, as done by Capiluppi et al., gives a similar overview of the continuum of governance in software projects. The following figure, figure 2.1, is adapted from Capiluppi et al. and additionally includes work from Dinkelacker et al., Stol et al., Wasserman, Raymond, and provides an state of the art overview of all the different governance structures.
Restricted Governance Proprietary Software
Inner
Source Controlled Source Traditional
Closed Source
Progressive Open Source
Open Governance Sponsored Open Source
Industry-Led Open Source Industry-Involved Open Source Bazaar Style
Community Open Source Traditional Open Source Foundation Open Source Cathedral Style
Figure 2.1:Continuum of governance in software projects [7, 15, 43, 54, 57].
Figure 2.1 illustrates the difference between proprietary and OS governance which contains more than two opposite sides. Project or products can reside on either side of the proprietary or open source spec-trum. Proprietary has more open variants than traditional closed source, including using open source practices internally. OS has many variants divided by sponsored OS, whereby a commercial organization is involved, and community OS where the community makes the decisions. Each category is elaborated upon in the remainder of the chapter, with the goal to provide the reader with enough background knowledge on the differences between proprietary and OS.
2.1 Proprietary
The license of proprietary software prevents the source from being published or reproduced to the public. It remains the property of the organization developing and owning the software, developed by financially compensated developers, including contractors or outsourced teams, and only the binary is provided to the buyer of the product. The main purpose of proprietary systems is technology output, the other two, people and products, are secondary [2]. Well-known examples of proprietary software are Microsoft Windows and Microsoft Office products.
Figure 2.1 illustrates the distinction betweentraditional closed sourceandProgressive Open Source (POS). Wheretraditional closed sourceprocesses and practices are defined internally, are closed and have no inten-tional similarities to processes and practices as found in OS. POS are organizations who use open source processes and practices but only internally. Inner source, also referred to asCorporate Open Sourceis a sub-set of POS whereby OSS development practices and processes are leveraged within the internal corporate environment [54]. Next toInner Source, as described above, POS consists ofControlled Sourcewhere not only internal but also external corporate partners, outside the firewall, are allowed (limited) access. Finally Dinkelacker et al. also mentions OS, products published under a license as approved by the Open Source Initiative (OSI).
2.2 Open source
In general OSS, sometimes referred to as free software, is royalty free redistributed software, its source code is released and available to anyone and any modification to the source are to be redistributed under the same license terms as given in the original [30]. The OS systems purpose is not only technology output, but as much emphases is put on people and products [2]. To get an idea of the size of OS the current number of projects worldwide, as indexed by ohloh.net, exceeds 655.000 projects. Vass estimates, back in 2007, 800,000 programmers contributed to OSaround the world. Creating more than 100 billion lines of code worth 10 million person years of work [41].
Free software is sometimes referred to aslibre softwareto avoid the potential confusion between the intended meaning of free, freedom, and free as in at no cost. Because free software is not the same as zero-cost software. All free software is zero-cost, but zero-cost software is not always free [19]. The reason, in the case of free software, just like OS, is the source code has to be released and open to anyone which is not necessarily a prerequisite of zero-cost software. The differentiation between free or libre and OSS can be controversial, but there are differences. The difference lies in the type of licensing. When modifying and/or incorporate free software the result must also be distributed as free software, and you are restricted from further restricting your software users, giving them exactly the same rights as the rights given to you. In case of OS there are licenses giving users the options to restricts software users and still be considered open-source, but not free source. For the remainder of the research the differentiation between free, libre and open source is out of scope and therefore the umbrella term FLOSS is used to describe the entire field
of free-, libre- and OSS research [13].
OS can be categorized in several ways, [8] and [46] base their categorization on their different con-trol and ownership structures. Boiling down to two different types,Commercial OSorsponsoredOSand community open source. Whereindustry-involvedandindustry-ledprojects are sponsored OSS projects, and industry-involvedandtraditional projectsare both forms ofcommunity open source.
2.2.1 Sponsored open source
OS started as something done by volunteers, but increasingly commercial organizations are getting in-volved [8]. Commercial Open Source Software (COSS), OSS used to develop private software, is a multi-million dollar industry [29]. In asponsored OSSproject commercial stakeholders will contribute more than voluntary programmers [7] such as helping in the testing phase, report bugs, packaging, functional require-ments, documentation, and marketing [21]. Industry-led OSSprojects are led by a commercial firm. It is possible for the community to contribute, but since an organization has control over the project, it defines the evolution strategy.Industry-involved OSSproject have commercial involvement by contributing, but the project governance remains in control of the community. In this scenario organizations have economic benefits from contributing, need a specific feature or want to lead the project [8].
WhenIndustry-led OSSis based around a single organization it is sometimes referred to as single-vendor commercial OS in literature. Organizations have full control over the source, owning full copyright and in-tellectual property, and build their business around it. As a result the organization does not accept outside contributions often, and if they do accept them the contributor gives its code rights to the organization. The organizations differ from tradition proprietary firms as not only the binary of their software but also the code is available for free under a reciprocal license to drive adoption and simultaneously block possible competitors [46].
With the involvement of commercial companies, it is found that OSS projects achieve sustained produc-tivity, increasing amounts of output produced and intake of new developers. It is also found individual and commercial contributions show similar stages: developer intake, learning effect, sustained contributions and, finally, abandonment of the project. This preliminary evidence suggests that a major success factor for OSS is the involvement of a commercial company, or more radically, when project management is in hands of a commercial entity [7].
2.2.2 Community open source
Community OS projects are owned and controlled by a community of stakeholders or a legal entity repre-senting the community [8, 13].Traditional OSprojects are started by individuals, often to "scratch a personal itch" [43] and have no commercial involvement.Foundation-based OScan be compared to traditional con-sortia and when community projects get to a certain growth point the question becomes to create their own foundation or join an existing one. Foundations generally have general predefined governing, infras-tructure, distribution of software and foundation licensing in place. The legal representative of the projects
being the most important aspect of the foundation [47]. Funding for the foundation is often done by cor-porations and other financial supporters. The funding and review process to join a foundation result in the fact foundation-based OS are perceived as solid, credible projects which do not depend on individuals [57, 47]. Popular examples of community OS projects are Linux, Apache web server and PostgreSQL. The license of the project allows anyone to generate revenue from the project without consequences [8]. The community members typically do not derive direct revenues from the software but subsidize it from com-plementary products and services. In the past control is determined by ownership of copyright to the code in the project, but today economically relevant projects see representation of non-profit foundations such as the Apache Software foundation.
2.2.3 The cathedral and the bazaar
In one of the first works on OS Raymond discusses two fundamentally different development styles for software, thecathedraland thebazaar. Thecathedralmethod is based on the proprietary principles where software is build similar to a cathedral, developed by a fixed team in isolation, only releasing and made public when it is complete. Where thebazaarmethod, based on an analysis of the linux operating system and fetchmail OS projects, has almost the opposite approach, release early and often, delegating tasks and transparent about each step of the process.
2.2.4 Software licensing taxonomy
Another perspective on the difference between proprietary and open, based on Feller and Fitzgerald, lists software by its licensing.
Software type/License feature Zer
o price Redistributable Unlimited users and usage Sour ce code available Sour ce code modi fi able Commercial Trial software • • Use-restricted • • Shareware • • Freeware • • • Royality-free binaries • • • Royality-free libraries • • • • Open source • • • • •
In the most elementary and simple explanation of differentiation between proprietary and OS it is only a difference between license type. Table 2.1 illustrates an overview of the different software types, mostly already mentioned in the previous section, on the vertical axes. The horizontal axes illustrates the license features of each software type.
2.3 Summary
Proprietary and OS are not black and white definitions but rather a spectrum of governance exists between both traditional extremes. Proprietary is divided into traditional closed source and POS allowing for more open source, referenced as inner and controller source, influence in a closed source environment. OS is split into sponsored, whereby the commercial interest in projects are high, and community, which is driven by volunteers and community stakeholders. Foundation OS is financed by commercial and non-profit orga-nization and the projects are governed individually under the rules of the foundation. Finally, traditional OS are independent projects under the supervision of volunteers devoting time to develop product. In the final sections the differentiation of development styles, cathedral and bazaar, and licensing taxonomy, software types and their features, are explained.
3.
Related work
In related work research conducted in the field of the open sourcing of proprietary software is discussed. Lundell and Forssten identified, given the recent trend for organizations to open source proprietary soft-ware, the topic of open sourcing has seen little research interest. Kilamo et al. acknowledge the phe-nomenon, and present a framework for building and sustaining an OS ecosystem, the OSCOMM Frame-work. Before discussing the framework Kilamo et al. emphases the importance of the role of stakeholders in the transition process. OS strategies as mentioned by Hecker and Alexy et al. are discussed and the chap-ter finishes with the release process of OS software based on four case studies conducted in the research of Eide.
3.1 OSCOMM framework
Discussion of the OSCOMM Framework is divided into two parts, the first discussing the impact of stake-holders in the transition process and the second discussing the phases of the framework.
3.1.1 Stakeholders
Before starting the OSCOMM process Nakakoji and Yamamoto place emphases on the importance of a consensus between the stakeholders. Coinciding with addressing societal norms and legal matters since failure can result in a failure of the total project. Nakakoji and Yamamoto describe the different layers of stakeholders based on the onion model, illustrated in Figure 3.1, of open source communities.
Figure 3.1:Elements of OSS Community Building [52, p. 59].
The core of the onion, the publishing entity, is the most involved and is most important during and after release. Besides opening the code, skilled developers should form the base of the new community. In the case of industrial partners as stakeholders, Nakakoji and Yamamoto distinguish between enthusiastic and conservative. Enthusiastic partners typically contribute to the open sourcing and are closer to the core
of the onion conservative stakeholders are closer to the edge. Other important stakeholders are existing open source communities, as the new to be released product will join in the ecosystem. Finally the decision has to be made what kind of community the commercial organization is looking for, either industry-led, industry-involved or community based. A specific point of interest is the core of the onion and the decision if this should be open or closed [26].
3.1.2 Framework
The OSCOMM Framework is divided into three phases, illustrated in Figure 3.2 [26]. Each phase is only initiated after the previous phase has been completed. The three phasesrelease readiness rating (R3),open source engineeringandcommunity watchdogare discussed in the remainder of the current section.
Figure 3.2:OSCOMM framework phases [26, p. 1470].
3.1.3 Release readiness rating
In the first phase of the framework, bottlenecks are determined and, based on the results, todo tasks are listed in a plan according to their urgency by evaluation using the release readiness rating framework. The phase is executed before any open sourcing and has the main purpose of measuring the readiness of the project using the framework. The framework, release readiness rating developed by Kilamo et al., has four dimensions with (sub)categories, Table 3.1, each requires weighing by the organization. Determining each individual weight will result in a vector. The model is a guide, and will require adjustment to tailor the unique situation of the organization and situation [26].
Software Community and roles Legalities Releasing authority
Source Code Purpose Copyright and IPR Mindset, culture, and motivation Architecture User community Licensing Process, organization, and support Quality attributes Partners Branding Infrastructure
3.1.3.1 Open source engineering
The output of the previous stage is a priority list for the OS engineering phase, with the goal to eliminate or reduce the items on the list. Although the stage and perspective have shifted the same four dimensions of the R3 model are to be used in the second stage. The priority list should be executed in order of priority. In addition a conceptual model for the second phase is developed by Shah et al. illustrated in Figure 3.3. In the conceptual model the first step is the targeting of a community after which all desired characteristics are retrieved in step two. In step three the source is released to the public. Step four is the beginning of a community, using the core developers mentioned in the stakeholders section, which evolves into a mature community in the final step [51].
3.1.3.2 Community watchdog
In the final phase of the OSCOMM framework, the product is open sourced, and gathering information on the community and analyzing it, both software and social, is a vital activity to drive business decisions [26]. Kilamo et al. present a list of measurement criteria which are listed below in Table 3.2.
Community Software
Number of contributors Number of downloads Number of subscriptions mailing list Number of reported bugs Amount of requests Number of feature requests Amount of feedback Derived projects
Amount of inquiries Number of contributions Number of unique hits website
Number of hits in the media and blogs Social media activity
Geographic distribution
Number of participants to events Number of scientific publications Number of job advertisements
Table 3.2:Community Watchdog Measurements [26].
3.2 Open source strategies
Hecker discusses how to implementing an OS strategy and concludes "You cannot simply release source code, put a few newsgroups up, and expect distributed development to magically self-organize [24]". The strategy is separated into five highlights, focussing on the period before open sourcing.Code Sharing, parts of the code base are shared with other products might require special licensing or modularizing.Third-party technology, dealing with third party technology by removing, replacing or gaining permission and the third party could influence the type of license.Code sanitization, clean the comments. Export control, US based laws dealing with crypto and security code require adjustment before being approved.Product development processes, to achieve the benefits of OS it is vital to change the way the software is produced. Hecker also provides some pointers regarding the development process: form a dedicated team,provide community infrastructureandhave the internal developers use this external infrastructure.
Alexy et al. states organizations wanting to practice Open Source Software Development (OSSD) will have to do more than simply extend their boundaries and claim they are open. Requiring a redesign of R&D processing and convincing of developers and managers bytraining,step-by-step introductionandhiring employees with OSSD experience. Another suggestion is to practice OSSD by starting with progressive OS internally before moving to open source.
3.3 Release Process
Eide conducted four case studies of Norwegian commercial organizations releasing OS and targets the early stages of the release. The research focuses on rationale of commercial organizations open sourcing software, measurements important before releasing to open source, impact of processes on the success of the project and how to interact with open source community. The two main reasons of commercial organizations to open source a product are creating a better product, when revenue cannot directly be derived, and creating revenue [16].
3.3.1 Succes factors
Eide lists a number of project success factors based on the conducted research, listed in Table 3.3, as measurement points before open sourcing to understand the current state.
Project name The name should not infringe trademarks or be similar to other projects.
Working code The product should work properly, install and run easily and provide ba-sic functionality.
Meet a demand Solve a problem for the community, and have a differentiator from other projects.
Potential for succes The project should be active and provide promise to attract external de-velopers to contribute.
Software architecture A modular, clean and structured code base adhering to open standards and protocols and containing no license violations.
Documentation Provide accurate and good documentation.
License The choice of license determines the success of the project.
Table 3.3:Important Measures to Achieve Success [16][p. 55-65]
3.3.2 Impact of processes on success
The impact of processes on the success of the project are divided into technical infrastructure, importance of a website and promotional activities. The technical infrastructure is project specific, but should contain at least a mailinglist, mainly developer orientated, and/or a forum, more user oriented. Although bugs and contributions can be done through both it is advised to use a revision control system and a bug tracker. Eide concludes with the usage of wikis by open source projects and their ability to manage documentation. Eide argues the project website functions as external interface to the community. Therefor it should provide usability, well-functioning layout and design, created in layers and tested properly. During devel-opment special attention should be applied to the search engine optimization. The content should relay the information of the project such as license, description, benefits, road map showing the feature plans, suggested improvements to the project and location of tools and documentation.
Lastly Eide emphasizes the importance of promotional activities for the project. Including promotion during development gatherings, content on related sites, articles in the media, wikipedia articles, actively
engaging with the open source community, newsletters, paid advertisements and external effects.
3.3.3 Community
In the final section of the research Eide investigates the interaction of management between commercial actors and OS communities. First the importance of interaction for attracting and sustaining a OS commu-nity is deemed vital. Further activities should include web site updates as well as source code updates in order to "proof" to the community the project is healthy and for contributors to see their contributions being used. Commercial organizations tend to consider the community in their decision process, and the accommodations and adaptations are divided into leadership, implementation, conflicts and credits [16].
3.4 Summary
The past chapter discusses the existing literature on the open sourcing of commercial proprietary software into a OS community. The field is transforming from mild interest to a mature trans disciplinary research field. The OSCOMM framework, a framework dividing the transition to open source into three different phases, begins with an emphasis on the importance of stakeholders when open sourcing. The framework itself identifies pre-open sourcing problems, analyses implementations of improvements and fixes for the problems and finally provides guidelines for analyzing the community ecosystem post open sourcing. In open source strategies a number of highlights are discussed as well as the importance of starting with open source practices before moving to open source. Lastly Eide discusses the release process of open source software from an commercial organization perspective. Covering a wide variety of topics from an extensive literature study, succes factors of an open source project, impact of processes used within the organization on the success and the interaction with an open source community. The results of the related work reveals, to our knowledge, the limitations in research into the transition from proprietary to open source projects based on the low amount of research. The existing research focuses on the stages before going open source.
4.
Problem statement
The goal of the problem statement is analyzing and clarification of the problem within the problem owning organization Citrix R&D. In the chapter the problem is defined, analyzed, the system of the problem is defined, problem owner and stakeholders are addressed and, lastly, the goal and research question are discussed. In the second section the conceptual model, sub research questions, methodology and research process are described.
4.1 Problem Definition
The open sourcing is the chosen solution, by Citrix, in order to increase market share of XenServer. The consequent problem, arising within Citrix R&D, is the follow up, the execution of the transition to open source. Although the high level end state is defined as an OS project by Citrix, the details and implementa-tion are mostly unknown and finding the soluimplementa-tions is left to Citrix R&D. The organizaimplementa-tion has experienced employees and general ideas about the direction, however the lack of resources prevents the formulation of an evaluated strategy.
The resource constraints originate from the demand of the market to continue developing the product whilst transitioning to a new strategy, without the addition of new resources. The resource constraints result in provisional decision making as decisions are mostly made when the "problem" appears. Causing inability to create a long term strategy for the open sourcing of XenServer. Finally employees each have different attitudes and ideas about the open sourcing, without a general direction people either do to much or do to little resulting in mixed messaging both internally and externally.
In addition to the business perspective there is the academic relevance. Open sourcing is part of the field of FLOSS research, providing academic background to the phenomenon of OSS. In a recent study by Crowston et al. into the state-of-art of FLOSS development it is found, although there is increasing commer-cialization research into firm participation in OSS is low and “additional research needs to be conducted to investigate how firm-involved FLOSS project differentiate from non-firm-involved FLOSS projects” [12]. Open source as foundation for new strategy and businesses have gained low amounts of research interest [26] because the trend to open source proprietary software is relatively new [34]. Cases such as Java (Sun Microsystems) and Symbian (Nokia) do however demonstrate the potential of open sourcing. Recapitula-tory the study will not only provide valuable insights for the organization but also for the academical field.
Limited literature regarding transition from proprietary to open source in combination with a lack of internal resources is preventing Citrix R&D to have the optimal possibility at achieving their pre-set goals.
4.2 Problem Analysis
The first step in the analysis and validation of the problem is to determine if the problem is a reality problem, an actual problem, rather than a perceived problem by the organization. In the case of the problem at Citrix R&D the decrease of market share and increase of competition are facts, as found in market analysis of the past years. In order to remain relevant in the market and be able to remain self supportive financially the succes of the open sourcing is a realistic problem. Consequently successfully moving to open source to regain this market share is a realistic problem for the organization. Failure to succeed will result in the overarching problem to remain or worsen, and therefore succes in open sourcing is required in order to succeed in regaining market share in the current scenario.
Based on a realistic problem the next step is to determine if the problem is an functional or instrumental problem. A functional problem is a problem related to the properties of the output of the system whereas a instrumental problem is a problem related to the properties of the system itself. The research deals with a functional problem, first and foremost the problem of the loss in marketshare is a functional problem as it is an output of the system. Second is the achievement of the success of the open sourcing, directly correlated to the market share, where as the success of the open sourcing is a functional problem of the transition, but simultaneously the characteristics of the open sourcing are instrumental to the system.
Since the problem is defined as a functional problem it is now possible to determine the validity of the problem by the triptych of Haselhoff that defines three requirements to an organizational output: effec-tive (technical-economic system), efficient (open system) and meaningful (social system) [23]. According to Haselhoff a functional problem is only validated once it can be identified and linked to one of the require-ments. In the case of Citrix the problem is the reducing market share and therefor how successful the open sourcing will turn out in relation to market share. Since the metric is the success of open sourcing this prob-lem can be classified as a effective requirement, validating the status as a functional probprob-lem. Furthermore it is also a meaningful problem for Citrix R&D as the successful open sourcing is of importance for the right of existence towards Citrix.
4.2.1 Socio-technical aspects
The interrelatedness of both social and technical aspects of the problem indicate a socio-technical problem. OS is about people, processes, source code and infrastructure, and requires a mindset or culture change throughout the organization. The people involved, from the different departments within Citrix R&D, are affected by the transition to OS as it has a fundamental impact on their daily work routine. From a business perspective the organization is switching business strategy, impacting both internal and external stakehold-ers. Finally the technical aspects of the open sourcing are the hard and software infrastructure changes required to facilitate open source code and foster the growth of a community surrounding XenServer.
4.2.2 System definition
Using the system definition it is possible to define the scope and classification between functional and instrumental problems. It also allows for the separation between internal and external stakeholders, inside and outside of the system respectfully. The system is Citrix R&D and within Citrix R&D theXenServerteams, and not any of the other product teams. Within Citrix R&D there is a separation betweenXenServerproduct and support teams. The product team consists of developers, software architects, product management, product marketing and testing and work directly withXenServer. The support teams include management, documentation, development operations and project management and provide the required infrastructure in order for the product teams to function. The focus is the business and engineering challenges that arise from the transition to OS within Citrix R&D, these are linked to the future state of the solved solution as the changes only effect the system. The marketing and sales departement, both relevant in the process of transition, remain outside of the scope. Both are located in different physical location, and are integrated as single units for all Citrix products.
4.2.3 Problem Owners
The problem is owned by Citrix, however the successful implementation of the open sourcing strategic execution goes to the head ofbuild cloud infrastructurewhich in turn flows down to the vice president of engineering (VP) in Citrix R&D. The VP is tasked with the operational execution of the open sourcing of XenServermaking the VP the problem owner of the successful transition to OS. Included in process are product managementas they are responsible for executing internal change.
Vice president of engineering (VP)- Responsible for the Citrix R&D department and charged with transitioning XenServer to an OS project. The VP has a high interest in the succes, has the power within the organization and is motivated as the failure to do so will have an definitive impact on his future career, even in the scenario the product survives a semi-failed open sourcing the VP remains the responsible.
Product management- Product management is responsible for the execution of the VP strategy and determination of the feature set of the release of each product, where the architects design the feature and the developers implement the features. Product management is in charge of execution and planning of the open sourcing for the Citrix R&D department.
4.3 Stakeholders
In order to justify the problem, find additional criteria and determine the reliability of information the stakeholders of the system are discussed in the following section.
Internal Stakeholders
on adding new features and fixing bugs. The transition to OS will require the developers to transition to a open work style and become an integrated part of the OS ecosystem. The developers therefor have medium power, as unwilling employees can be replaced, and high interest in this transition, and are mostly positively positioned against the open sourcing. The attitude does differ on a team by team basis as some teams and employees have been working extensively with OS even on site where others have never worked with OS before. The latter also see going to a open model as a potential threat of losing their job to unpaid developers of the OS community. Additional threats to the developers are the open nature of OS, everything happens in the open, including mistakes which turns out to impact several developers.
• Software Architects- The software architecture team focuses on the current and future internal architecture of the codebase. In addition they build prototypes of new features to test their ideas. The architects see the open sourcing as an opportunity to remove technical debt from the code base of XenServer, and even hope the community input will allow for beter architectural design.
• Development Operations- The development support department is responsible for maintaining the build system, support infrastructure such as bug tracker and version control systems. There will be small changes to the way this team work, but mostly these will include one time changes to the system. The teams expects impact of the transition will be low, at least this is the perception, and are there for not concerned.
• Testing- The testing department works on testing the product and building test tools. The product is continuously tested to ensure that fixed bugs and new features don’t introduce more new bugs and ensure that the quality of the product remains constant. Most of the testing will remain proprietary to the Citrix XenServer edition, leaving the people of testing relatively unaffected. However future plans include the opening of some of the test tools, as testing hopes the community could help expand and improve testing tools.
• Documentation- Documentation, releases notes, user guides are prepared by the documentation team. Documentation is one of the entry level tasks in OS projects, although mundane, almost anyone can start writing and there for risk of job termination is a bottleneck in moving forward to an OS project from the people in documentation. However Citrix R&D has promised the open sourcing will not cause any lay offs the documentation team continues to progress.
• Project Management- Project management is in charge of managing internal projects. The project managers are not really impacted from the transition as they work mainly for the Citrix XenServer. • Management- Responsible for the management of each individual team within Citrix. The goal is to
translate features from project management into work items for the teams. Impact from open sourc-ing is minimal as the management structure of Citrix R&D has limited interaction with the community and are mainly supportive to the internal corporate structure of Citrix R&D.
External Stakeholders
• Marketing Department- The marketing department is responsible for marketing the product of XenServer. As external stakeholder they have to change the way they marketXenServeras an OS project not only focusing on potential sales but also on selling the community. There is confusion about the precise changes the open sourcing will bring and have limited experience.
• Sales Department- In charge of sellingXenServerlicenses. The sales strategy will have to be revised as the product is available for free and alternative business models will be introduced. It will require a shift from the sales department to understand OS and to explain and convince customers why they should pay for a free product.
• Industry Partners- Industry partner are organizations that already have a relationship with the XenServerproduct and have worked on the code base before. Although the open sourcing allows for easy collaboration, some partners have some trouble with there code contributions being OS under the same license asXenServer.
• Customers- Current customers are affected since the license will change and the product will be-come free. This will have have a different impact on customers as for some nothing will change, some might want to go for the OS and don’t pay, others see it as the abandoning of the product by Citrix. They are however of importance because eventually the customers determine the financial success ofXenServer
• OS Communities- The existing communities consist of people and companies investing in the OS projects. There are a number of communities affected by the open sourcing ofXenServerthe existing Xen Hypervisor and XCP communities and Upstream projects. Although the OS communities are positive regarding the announcement of the open sourcing they do remain skeptical regarding the execution of the open sourcing and the level of implementation.
The stakeholders analysis reveals no mayor conflict between departments or internal teams and the major-ity of stakeholders agree the limited resources constrain the department in the potential to successfully OS XenServer. Additional goals are increasing collaboration between partners and the reduction of technical debt in XenServer.
4.4 Goal & research question
The goal of the research is to provide Citrix R&D with the required information and guidance on how to proceed the process of open sourcing XenServer. Resulting in an overview of OS characteristics based on related work and state-of-art in OS. In order to present the information to the organization a process, containing solutions in different areas of an OS project, is to be presented. In addition to the initial goal of
the organization the second part of the research contains a theory oriented approach in order to provide additional knowledge in the field of FLOSS.
The goal of the research is to provide Citrix R&D with a process to transition XenServer from proprietary to an OS project with the achievement of the pre-set objectives.
Providing a process will allow Citrix R&D to transition towards a successful OS project. Based on the goal the main research question is formulated in the following section.
How will a process for the transition from proprietary to OS be defined, for XenServer, based on the existing state-of-art literature of OS, case studies of transitions to OS and the XenServer case?
4.5 Conceptual model
Recapitulatory to the related work the research will require expanding the knowledge of the characteristics to provide a validated foundation for the research. In order to achieve the need for knowledge the first phase of the research will require a literature study into the characteristics to clarify and further expand the characteristics based on state-of-art literature on OS. The research will not only include a practical case but also provide theoretical knowledge to the research towards transitioning a product from proprietary to OS.
The conceptual model, based on the literature, problem and goal, is a diagram to represent the relation-ship between the different sub-questions of the research. In Figure 4.1 the conceptual model is illustrated, the numbers, within the blue circles, indicate the relationship with the research sub-questions.
Process Infrastructure Software Marketing Legality Community Opensourcing XenServer Process Infrastructure Software Marketing Legality Community Opensource Project
1
3
5
4
2
Literature Citrix R&D
Market Share Product Price Sales Marketing Governance Market Variabels + + +
+/-Figure 4.1:Conceptual Model
Literature- The starting point of the research are the characteristics of a project making the transition to OS. According to Kilamo et al., to our knowledge the only previous research into the transition of OS, the following characteristics can be distinguished: Process, infrastructure, Software, Marketing, Legality and Community [26].
Citrix R&D - After the characteristics of OS projects have been described the characteristics can be used on the practical case of open sourcing XenServer. The open sourcing of XenServer impacts the product, licensing (price) and governance (OS) variables.
Variables - Each of the variables makes an impact on the market share, variables such as sales, marketing campaigns and the market. For example the market could be broken down into competitors but also economic climate and market size.
Market Share - The relation between an OS project and market share is explained by Riehle and argues open sourcing a proprietary product is a mechanism to disrupt an existing market with a strong market leader, or used by the market leader to increase its foothold in the market [44]. The conceptual model tries to convey the relationship between the characteristics of a software project and the output of such a system, in this case Citrix R&D that is focusing mainly on market share.
4.6 Research sub-questions
The research question are decomposed into a number of sub-questions as covered in the following sec-tion. Each sub-question is also represented in the conceptual model, Illustrated as blue circle (Figure: 4.1), through the corresponding number.
1. Based on the state-of-art in OS literature what are the characteristics of open source projects relevant for the XenServer case?
2. For each of the characteristics, found in the previous question, what are implementation which have led to success, achieve similar goals as the goals of Citrix, in existing transitions to open source?
In this first section the goal is to define the characteristics, based on state-of-art literature, resulting in the foundation of the process. It will be based on the existing concepts around open source projects and the el-ements are essentially characteristics of open source projects. Initial research pointed towards the research of Kilamo et al. however it is the only research into transitioning and leaves room for further research into characteristics. The second question is to determine the relation between the different characteristics and the organizational goals.
3. What is the current state of the open sourcing, based on the proposed characteristics in the first question, of XenServer?
4. What characteristics of the process can be improved for XenServer in order to achieve the pre-set goals?
Questions are related to the case-study ofXenServer, and will evaluate, for each of the characteristics of the process, how solutions where constructed, if they are made, and if they have provided Citrix R&D with the desired results. Divided into three questions, the first question is based on the organizational objectives of Citrix R&D in order to perform evaluation in the end. The second question is a case-study at Citrix R&D to determine past and present state of characteristics. Lastly, the third question is an evaluation between the state-of-the-art literature and the case-study founded on the characteristics.
5. How can a process for the transition from commercial to open source, based on the three inputs, be modeled for Citrix R&D?
In the final stage of the research all the inputs are taken and used to construct the final process. The final process will quantify the success of the different building blocks and draw a conclusion for each of the characteristics to provide potential improvements to Citrix R&D.
4.7 Methodology
The research is defined as Practical Oriented Research (POR) at the organization Citrix R&D. Coinciding with the use of empirical data and considering decisions regarding internal structure are required the choice has been made to use the regulative cycle, illustrated in Figure 4.2, as methodological background for the research. Problem Set Problemchoice Diagnoses (analyse) Plan (design) Implementation Evaluation
Figure 4.2:Regulatieve cyclus of Van Strien (Van Aken et al., p 13) .
The initial two phases of the cyclus start with a set of problems from the organizations, Citrix R&D, and end with the definition of the problem as can be found in the previous chapter. The third phase, diagnoses, is the analysis of the problem as conducted in the current chapter, and requires the identification of the causes of the problem. The plan phase is the defined as the shaping of goal and achievement of the goal, in the case of the research at Citrix R&D the development of the process to transition the product to open source. The scope of the research prevent the implementation and evaluation as the implementation and results take multiple years. Results of the design phase will be unique to the case of Citrix R&D, therefor the research is classified as POR. However the meta-study on characteristics and method on how to evaluate the characteristics are universal applicable and the research is thus not only POR but has a limited amount of Theory-Oriented Research (TOR)).
4.8 Research process
Research process entails the phases conducted in order to find answers to the sub-questions, divided into literature, case study, results and conclusion phase. The process is illustrated in Figure 4.3.
Literature Case Study Result
Open Source Characteristics Open Source Projects Case study at Citrix Research and Development
1
2
3
Improvement to achieve pre-set goals Process for transition to open source4
5
Evaluation EvaluationFigure 4.3:Research process illustrated.
The initial literature study is conducted to establish OS characteristics to provide an input for the case study. The case study is segmented into the different characteristics and an evaluation is conducted using both the case study and previous open sourcing projects. Lastly based on the evaluation, case study and the original characteristics a process is proposed to improve the open sourcing of XenServer. Each phase is discusses in more detail in the following sections.
4.8.1 Literature
The first section of the research is the literature study in order to gain knowledge. The goal, to gather state-of-art knowledge on OS projects in the field of FLOSS. In order to retrieve the required literature the internet sources ”Smartcat”1and ”FLOSShub.org”2are consulted. The expected results of the literature
phase are listed below.
• Characteristics of OS projects, • State-of-art on OS characteristics,
• Existing open source projects and their implementation of the characteristics.
4.8.2 Case study
In the case study phase the characteristics, as found in the previous literature phase, are the focus points during the study of XenServer. To uncover information on the current implementations a exploratory case study format is chosen. An exploratory case study is chosen to uncover the current strategies, processes
1http://rug.worldcat.org - The world’s largest library catalog.
and work methods as they occur in Citrix R&D in regards to the transition to an open source project as these facts are currently unknown and are required to provide Citrix R&D with advice. The information will be gathered using semi structured interviews with the stakeholder involved in the transitions. Inter-views will be conducted with: Project Manager, Product Manager, Vice President of Engineering (both past and current), Chief Technology Officer, Developers of different internal teams, Managers of different teams and the Community Manager of Xen Hypervisor. Interviews will be conducted face-to-face and using vir-tual communication such as Microsoft Skype, go-2-meeting and Google Hangout. In addition to interviews, meetings, related to the open sourcing, are also attended in order to take minutes, water cooler conversa-tions, observaconversa-tions, email discussions, documentation, such as internal wiki’s and f.a.q. boards and internal presentations are used as input.
• Expanding on motivations and objectives behind the open sourcing of XenServer, • Current implementation of the characteristics at Citrix R&D,
• Strategy and future implementation of the characteristics at Citrix R&D.
4.8.3 Design
The final step of the research uses the previous steps as input to design the final process. Using an evalua-tion, between state-of-art-literature and the case-study, to gain insights and to enable reflection and assist in the identification of improvements to the transition to an open source project. Lastly, a decision support system will be used to determine which solution is most appropriate for the scenario.
• Evaluation between the current implementation of characteristics at Citrix R&D and state-of-the-art cases from literature.
• Process on the open sourcing transition tailored to the Citrix R&D case,
4.8.4 Conclusion
In the final chapters the results are discussed and the limitations of the research are addressed. The conclusion includes a research summary, key findings, discussion and further research into open sourcing a proprietary product.
5.
Literature
Research in open source has transformed from being an mild interest to a mature multi-disciplinary re-search field [28, 13]. The goal of the following chapter is three fold, first identify the characteristics of an organization transitioning to OS, second describe the state of the art literature of the characteristics and third historical case studies on open sourcing of proprietary products are examined and described based on the characteristics.
5.1 Open source characteristics
To construct the characteristics of an OS project existing work on open source frameworks are identified, gathered and composed. The foundation of the characteristics are based on the research of Crowston et al. in their overview meta-research of FLOSS, Aksulu and Wade and their research into OS research frameworks, Kilamo et al. providing characteristics of the OSCOMM Framework and Fogel, with the book "How to run a successful free open source project". The general concept behind the characteristics for the open sourcing is they are the desired end state when transitioning towards open source. In chapter 3, the characteristics, as defined by Kilamo et al., are discussed and an illustration can be found in Figure 5.1.
Figure 5.1:Community building dimensions [26, p. 1468].
5.2 State of the art on characteristics
5.2.1 Motivation
To enable the definition of success of the transition in retrospect it is necessary to understand the motiva-tions and objectives of an organization at the start of the transition. Feller and Fitzgerald divide motivamotiva-tions into three perspectives: technological motivations, economical motivations and socio-political motivations. According to Alexy et al. firms should realize transitioning to OS has potential benefits, however those might
only surface after an extended period of time.
5.2.1.1 Technological motivations
Technological motivations are motivations related to the attributes of the product. In Table 5.2 the different motivations are listed, including reference to literature, and each motivation is elaborated in the section following the table.
Feller and Fitzger ald [17] Bonaccorsi and Rossi [6] Sirkkala et al. [52] Raymond [43] Robustness • • Development • • • Quality • • • • Reliability • • • Stability • Openness • Features • •
Table 5.1:Technological motivations.
A number of authors discuss technological motivations. Feller and Fitzgerald argue OS allows for more robust code (Robustness), faster development cycle (Development), higher standards of quality (Quality), improved reliability (Reliability), stability (Stability) and for more integration with open standards and plat-forms (Openness). Bonaccorsi and Rossi and Raymond mention "many eyes" will assist in the development, causing increased quality and reliability. More recently Sirkkala et al. writes about the idea of getting the OS community to develop additional features (Features) and help improve the quality of the product. Ray-mond covers the development at Linux and remarks volunteering developers add new features, work on existing defects and write documentation.
5.2.1.2 Economical motivations
Economic motivations are the motivations based on economics. Similar to the previous section Table 5.2 lists the different motivations, including their reference to literature, and each motivation is elaborated in the section below table 5.2.
The motivation or objective of open sourcing, from an economical standpoint, can be to share costs and risk (Cost reduction), try to redefine the software industry (Industry redefinition) or gain market share (Market) [17]. Further motivation are the ability to innovate, especially for smaller firms (Innovation), or the ability to have the community provide outside technical support at no costs. Sirkkala et al. focuses on
Feller and Fitzger ald [17] Bonaccorsi and Rossi [6] Sirkkala et al. [52] Riehle [44] Lerner and Tir ole [30] Agerfalk and Fitzger ald [1] Fogel [19] Cost reduction • • • • • Industry redefinition • • • • Market • • Innovation • Marketing • • Recruiting • • • • Sales •
Table 5.2:Economical motivations.
boosting the industry, the ability to recruit new employees from the community (Recruiting) and argues open sourcing increases product familiarity driving marketing and sales (Marketing). Riehle also mentions the ability to reduce costs by switching to OS, potential to disrupt a market by introducing an OS alternative and the increase in potential employees. Lerner and Tirole also mention the ability for a firm to attract more employees and the ability to influence the industry. Agerfalk and Fitzgerald take a slightly different approach and study the symmetrical and complementary customer and community obligations of open sourcing success from the perspective of outsourcing to a community through open sourcing. Fogel iden-tifies, based on the OS community, costs could be shared, competitors and industry could be opposed, it could be good for marketing and it offers a new motivation in the form of driving sales for hardware products (Sales).
5.2.1.3 Socio-Political motivations
Socio-Political motivations are motivations related to the personal beliefs of humans. According to Crow-ston et al. commercial organizations are not interested in personal motivations. Feller and Fitzgerald men-tion personal motivamen-tions, such as the personal itch, getting mentorship, peer reputamen-tion, the desire to do meaningful work and personal idealism as personal motivations.
5.2.2 Business models
OS business models have been widely discussed in FLOSS literature in the past years. In the early years after the first commercial open sourcing of netscape Hecker lists:Support Sellersby selling complementary services such as support.Loss Leaderfor other commercial products.Widget Frostingwhen an organization sells hardware and the software enables the hardware.Accessorizingphysical items are accessorized with
OS software.Brand Licensingto other companies.Service Enablerwhen a commercial service requires soft-ware to access revenue-generating online services.Sell It,Free It, OS once it’s made its money as commercial product. Lerner and Tirole starts by providing some options for open sourcing:living symbiotically, by pro-viding complementary services and products,release codeopen to create involvement and drive additional product sales and finallyprovide certificationof the product. Riehle identifies three types of commercial opportunities:Consulting and support services,Derivative productsbased on the community project and In-creased revenuein ancillary layers in the software stack. Watson et al. differentiate between five different models for production of software: proprietary, OS community, corporate distribution,sponsored OSand second-generation OS. Three of those can be identified as business models for commercial organizations. Corporate distributionthe firm identifies the best OS product in a category, improves distribution, add com-plementary services and in general make it more accessible to the market. Sponsored OS
