FROM PROPRIETARY TO OPEN SOURCE, A CASE STUDY OF CITRIX XENSERVER

Transcription

1 FROM PROPRIETARY TO OPEN SOURCE, A CASE STUDY OF CITRIX XENSERVER Harm Roelof Pieters s [email protected] March 25, 2014 Master thesis Industrial Engineering and Management Faculty of Mathematics and Natural Sciences University of Groningen Supervisors prof. dr. ir. M. Aiello University of Groningen dr. ir. I.ten Have, MBA University of Groningen M. McClurg Citrix Research and Development

2

3 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 characteristics, providing a segmented structure to the study. The characteristics are legality, community, process, infrastructure, software, community, marketing, business model and motivation. 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 improvement areas, most notably the community and 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. Selection of an existing target community to act as role model, allowing amongst others the implementation 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 making decisions and implementing Infrastructure, in addition the adjustment of the internal processes and publicizinginformation is initiated. The second phase consists of creation and publication ofdocumentation, the remainder of processes and information and the first part of collaboration initiating between organization and community. Lastly, the final phase includes the website and the final section of collaboration. Product improvements and Metrics gathering span the three phases of the process, beginning at the first phase. The proposed process is the contribution of the study to the organization, 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 engineering, FLOSS. ii

4 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 provided 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. Harrie Pieters - March 2014 iii

5 Table of Contents List of Tables List of Figures vi vi 1 Introduction Citrix Research and Development State of the art Problem Contribution Document structure Background Proprietary Open source Summary Related work OSCOMM framework Open source strategies Release Process Summary Problem statement Problem Definition Problem Analysis Stakeholders Goal & research question Conceptual model Research sub-questions Methodology Research process Literature Open source characteristics State of the art on characteristics Case studies Citrix research and Development case study Organization Business Model Characteristics Future organizational considerations iv

6 7 Analysis Introduction Motivation Business Model Characteristics Summary Transition Introduction Process Discussion Results Key Findings Organizational goals Research goals Validation Conclusion Discussion Further Research References 86 Appendices 90 Glossary 91 A Organization description Citrix Research and Development XenServer Strategy Teams B Release process 101 v

7 List of Tables 2.1 A Software Licensing Taxonomy [17, p. 60] Release Readiness Rating (R3) Framework [26] Community Watchdog Measurements [26] Important Measures to Achieve Success [16][p ] Technological motivations Economical motivations Overview of most common used licenses is Open Source (OS) List of Figures 2.1 Continuum of governance in software projects [7, 15, 43, 54, 57] Elements of OSS Community Building [52, p. 59] OSCOMM framework phases [26, p. 1470] Conceptual Framework for Open Source Engineering [51, p. 4] Conceptual Model Regulatieve cyclus of Van Strien (Van Aken et al., p 13) Research process illustrated Community building dimensions [26, p. 1468] License decision model [33, p. 34] XenServer moving from a proprietary to sponsored OS Analysis process of the open sourcing at Citrix Research and Development (Citrix R&D) Transition process divided in phases and actions Transition process of the organization vi

8 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 majority 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 1 XenServer 6.2 is open source (13/6/2013) - 1

9 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 literature 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 characteristics 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 characteristics, 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. 2

10 1.5 Document structure The first section, chapter two and, contains a background discussion on the differentiation between proprietary 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 presented in chapter nine, including key findings and validity. Lastly, chapter ten contains the conclusion of the research, including discussion and further research. 3

11 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 proprietary 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. Cathedral Style Bazaar Style Proprietary Software Sponsored Open Source Traditional Closed Source Progressive Open Source Inner Source Controlled Source Industry- Led Open Source Industry- Involved Open Source Foundation Open Source Traditional Open Source Community Open Source Restricted Governance Open Governance 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 spectrum. 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. 4

12 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 between traditional closed source and Progressive Open Source (POS). Where traditional closed source processes and practices are defined internally, are closed and have no intentional 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 as Corporate Open Source is a subset of POS whereby OSS development practices and processes are leveraged within the internal corporate environment [54]. Next to Inner Source, as described above, POS consists of Controlled Source where 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 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 as libre software to 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 5

13 of free-, libre- and OSS research [13]. OS can be categorized in several ways, [8] and [46] base their categorization on their different control and ownership structures. Boiling down to two different types, Commercial OS or sponsoredos and community open source. Where industry-involved and industry-led projects are sponsored OSS projects, and industry-involved and traditional projects are both forms of community open source Sponsored open source OS started as something done by volunteers, but increasingly commercial organizations are getting involved [8]. Commercial Open Source Software (COSS), OSS used to develop private software, is a multimillion dollar industry [29]. In a sponsored OSS project commercial stakeholders will contribute more than voluntary programmers [7] such as helping in the testing phase, report bugs, packaging, functional requirements, documentation, and marketing [21]. Industry-led OSS projects 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 OSS project 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]. When Industry-led OSS is 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 intellectual 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 productivity, 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] Community open source Community OS projects are owned and controlled by a community of stakeholders or a legal entity representing the community [8, 13]. Traditional OS projects are started by individuals, often to "scratch a personal itch" [43] and have no commercial involvement. Foundation-based OS can be compared to traditional consortia 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, infrastructure, distribution of software and foundation licensing in place. The legal representative of the projects 6

14 being the most important aspect of the foundation [47]. Funding for the foundation is often done by corporations 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 complementary 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 The cathedral and the bazaar In one of the first works on OS Raymond discusses two fundamentally different development styles for software, the cathedral and the bazaar. The cathedral method 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 the bazaar method, 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 Software licensing taxonomy Another perspective on the difference between proprietary and open, based on Feller and Fitzgerald, lists software by its licensing. Zero price Redistributable Unlimited users and usage Source code available Source code modifiable Software type / License feature Commercial Trial software Use-restricted Shareware Freeware Royality-free binaries Royality-free libraries Open source Table 2.1: A Software Licensing Taxonomy [17, p. 60]. 7

15 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 organization 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. 8

16 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 software, the topic of open sourcing has seen little research interest. Kilamo et al. acknowledge the phenomenon, and present a framework for building and sustaining an OS ecosystem, the OSCOMM Framework. 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 chapter 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 stakeholders in the transition process and the second discussing the phases of the framework 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 9

17 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] 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 phases release readiness rating (R3), open source engineering and community watchdog are discussed in the remainder of the current section. Figure 3.2: OSCOMM framework phases [26, p. 1470] 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 Table 3.1: Release Readiness Rating (R3) Framework [26]. 10

18 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]. Figure 3.3: Conceptual Framework for Open Source Engineering [51, p. 4] 11

19 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 Number of contributors Number of subscriptions mailing list Amount of requests Amount of feedback Amount of inquiries 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 Software Number of downloads Number of reported bugs Number of feature requests Derived projects Number of contributions 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 infrastructure and have 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 by training, step-by-step introduction and hiring employees with OSSD experience. Another suggestion is to practice OSSD by starting with progressive OS internally before moving to open source. 12

20 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] 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 Working code Meet a demand Potential for succes Software architecture Documentation License The name should not infringe trademarks or be similar to other projects. The product should work properly, install and run easily and provide basic functionality. Solve a problem for the community, and have a differentiator from other projects. The project should be active and provide promise to attract external developers to contribute. A modular, clean and structured code base adhering to open standards and protocols and containing no license violations. Provide accurate and good documentation. The choice of license determines the success of the project. Table 3.3: Important Measures to Achieve Success [16][p ] 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 development 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 13

21 engaging with the open source community, newsletters, paid advertisements and external effects 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 community 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. 14

22 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 implementation are mostly unknown and finding the solutions is left to Citrix R&D. The organization 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 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. Recapitulatory 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. 15

23 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: effective (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 requirements. 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 problem can be classified as a effective requirement, validating the status as a functional problem. 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 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 stakeholders. 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. 16

24 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 the XenServer teams, and not any of the other product teams. Within Citrix R&D there is a separation between XenServer product and support teams. The product team consists of developers, software architects, product management, product marketing and testing and work directly with XenServer. 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 Problem Owners The problem is owned by Citrix, however the successful implementation of the open sourcing strategic execution goes to the head of build cloud infrastructure which 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 XenServer making the VP the problem owner of the successful transition to OS. Included in process are product management as 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 Developers - The development teams are responsible for the codebase of XenServer and mainly work 17

25 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 sourcing 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. 18

26 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 market XenServer as 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 selling XenServer licenses. 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 XenServer product 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 as XenServer. Customers - Current customers are affected since the license will change and the product will become 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 of XenServer 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 of XenServer the 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 majority 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 19

27 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 relationship 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. 20

28 Literature Citrix R&D Variabels 2 Opensource Project 3 Opensourcing XenServer + Product Market Share Process Process + Price Infrastructure Infrastructure + Governance Software Software Market 1 Marketing Marketing 4 Sales Legality Legality +/- Marketing Community Community 5 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. 21

29 4.6 Research sub-questions The research question are decomposed into a number of sub-questions as covered in the following section. 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 elements 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 of XenServer, 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. 22

30 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 Evaluation Problemchoice Implementation Diagnoses (analyse) Plan (design) 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)). 23

31 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 1 2 Case study at Citrix Research and Development 3 Evaluation Evaluation Process for transition to open source Improvement to achieve preset goals 5 4 Figure 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 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 1 and FLOSShub.org 2 are 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 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 The world s largest library catalog FLOSS papers resources. 24

32 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. Interviews 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 virtual 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 conversations, observations, 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 Design The final step of the research uses the previous steps as input to design the final process. Using an evaluation, 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, 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. 25

33 5. Literature Research in open source has transformed from being an mild interest to a mature multi-disciplinary research 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 Motivation To enable the definition of success of the transition in retrospect it is necessary to understand the motivations and objectives of an organization at the start of the transition. Feller and Fitzgerald divide motivations 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 26

34 only surface after an extended period of time 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 Fitzgerald [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 platforms (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. Raymond covers the development at Linux and remarks volunteering developers add new features, work on existing defects and write documentation 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 27

35 Feller and Fitzgerald [17] Bonaccorsi and Rossi [6] Sirkkala et al. [52] Riehle [44] Lerner and Tirole [30] Agerfalk and Fitzgerald [1] Cost reduction Industry redefinition Market Innovation Marketing Recruiting Sales Fogel [19] 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 identifies, 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) Socio-Political motivations Socio-Political motivations are motivations related to the personal beliefs of humans. According to Crowston et al. commercial organizations are not interested in personal motivations. Feller and Fitzgerald mention personal motivations, such as the personal itch, getting mentorship, peer reputation, the desire to do meaningful work and personal idealism as personal motivations 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 Sellers by selling complementary services such as support. Loss Leader for other commercial products. Widget Frosting when an organization sells hardware and the software enables the hardware. Accessorizing physical items are accessorized with 28

36 OS software. Brand Licensing to other companies. Service Enabler when a commercial service requires software 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 providing complementary services and products, release code open to create involvement and drive additional product sales and finally provide certification of the product. Riehle identifies three types of commercial opportunities: Consulting and support services, Derivative products based on the community project and Increased revenue in ancillary layers in the software stack. Watson et al. differentiate between five different models for production of software: proprietary, OS community, corporate distribution, sponsored OS and second-generation OS. Three of those can be identified as business models for commercial organizations. Corporate distribution the firm identifies the best OS product in a category, improves distribution, add complementary services and in general make it more accessible to the market. Sponsored OS is described as the case when a company invests money into foundation OS and does not see direct returns on those investments. Second-generation OS leverages the build up detailed knowledge to provide high level services. A complete overview comes from Wasserman in two article [58] [57] continuing on the works of Riehle. Subscription Model - The basic model involves customers paying for update services such as downloads, updates, errata, source code, solutions, and more. Subscription is not mandatory and the customer can decide if they are willing to pay. Cloud-based hosting services Software - Companies offer Software as a Service (SaaS) or hosted solutions to the customer based on OS software. Offering Commercial and OS Products - Models where there is a OS community version as well as a commercial version of the software. Support and Training Model - Provide support and training for the product to customers. Dual License Model - Allow customers to choose license where an OS license is free and a commercial costs money. Advertising Model - Gaining additional income by provide adds on for example the download site of the product. Packaging Model - Offer customers convenience by bundeling existing OS software into an easy to use environment with little effort on their part. Commercial Enhancement - Providing commercial enhancements such as additional features to (existing) OS projects. Embedding Model - Customers purchase hardware that comes with OS software. Consulting and Integration Strategy - Offering the ability to solve business problem with the use of OS software charging for the labour involved to tailor it to the user. 29

37 Patronage Model - Commercial organizations will invest in projects but won t see direct financial rewards. Rather its done for marketing, branding, improve the knowledge of employees and find potential new employees. Finally Bonaccorsi and Rossi research the strategies of commercial organizations and conclude that the majority of firms use hybrids between OS and commercial business models. The openness of the projects is negatively influenced by switching costs and extern network effects. Experience gained is the positive factor. As final point Bonaccorsi and Rossi note that hybrid business models are not a temporary thing but a new feature of the industry Characteristics Legality Any software product contains a copyright license so do OS projects. Transitioning to OS requires the transition and choice of a OS license for the source code. Licensing is a crucial component of the intellectual property to be accessible and public and at the same time governable [42]. The decision has economical relevancy as the type of license determines elements such as project and community growth [25]. The license type is also identified as influential on FLOSS development, such as motivations, coordination and commercial firm relationship [48]. Lerner and Tirole distinguishes between three license types permissive or unrestrictive, restrictive and highly restrictive. Founded in academics permissive licenses allow the distribution of source code for derivative works, but doing so is not mandatory. Allowing the creation of proprietary software based on top of the OS code, though the license and names of code creators do have to be redistributed. Most known and used license type of this category are Massachusetts Institute of Technology (MIT), Berkeley Software Distribution (BSD), and Apache licenses [33]. Included in the permissive licenses are the Beer an WTFPL license allowing total freedom to the user. The main risk for commercial vendors and OS communities is that competitors start a proprietary competitive product based on their work. Restrictive license prevent proprietary derivatives by forcing any derivative works to have its source code published under the same license. The protection of free software under copyright license is sometimes referred to as copyleft. Restrictive licenses include, but are not limited to, the lesser general public license (LGPL) and Mozilla public license (MPL) [33]. Highly restrictive licenses further restrict the restrictive license by not allowing modified versions of the program to mingle with other software not employing such a license. The result is the question of license compatibility. Licenses with such a clause are sometimes referred to as a reciprocal or a viral provision. The foremost example the general public license (GPL). 30

38 Permissive Hybrid Restrictive Highly restrictive Beer Eclipse LGPL GPL BSD Artistic License CC-BY-SA MIT MPL Apache Public Domain Table 5.3: Overview of most common used licenses is OS. License impact Lerner and Tirole found projects focusing on end users to have restrictive licenses and projects focusing on developers to have less restrictive licenses. Further research into OS licensing looks at the impact of the license on the project. Stewart researched the effects of licensing and organizational sponsorship on success. In the results it is partly supported that non-restrictive project become increasingly popular over time. Sponsored project become more popular than non sponsored projects and the popularity has a good effect on the vitality. Finally the claim in which restrictive projects have higher levels of vitality is not supported. License decision model Lindman et al. researched the factors influencing the choice of a project license and developed a license Figure 5.2: License decision model [33, p. 34]. decision model illustrated in Figure5.2. Four contextual influences are identified: Externalities, Motivation creation, Leadership and Company size. Externalities are constraints based on existing licenses used in the project. Motivation creation is important when community and its growth are going to be the competitive advantage and the license needs to emit trust. Community Leadership occurs when it is important to remain in control and prevent forking. Company Size is the final influence on the context of choosing a license. In the end the business model has the largest weight on the model since the choice of model can greatly influence the type of license Process Kilamo et al. defines the OS development practices as the process. The challenges within the process characteristic are the balance between community and company regarding evolution, maintenance, 31

39 governance and release management. The research, in combination with the meta-studies of Aksulu and Wade and Crowston et al., yields the following subsegments of the process characteristics of OS projects: planning, requirements, coding, testing, releasing and maintenance. Planning - In general FLOSS project don t engage in formal planning [13] and this is a opportunity for commercial organizations to contribute [18]. Requirements - Again not something often found formally in FLOSS projects, it is often confined to discussions held on mailing lists and feature requests of users. Besides to planning requirements are deemed an area where commercial organizations can add contributions [13]. Coding - The process of coding in FLOSS is "release early, release often" [43] contrary to proprietary development. Although perhaps a characteristic of OSSD Fuggetta mentions that anyone opposing the waterfall development method feels these characteristics are good and therefor not specific to OS. Secondly FLOSS focuses on code reuse, modularity and extendability [5]. Testing - Testing code is a final quality check. Testing can include peer review, individual code testing, automated testing (e.g. unit tests) and continues integration testing. Testing process and formalities varies greatly between projects and although there might not be formal testing or review available the code is open and anyone can do quality control [13]. Releasing - OS code is always accessible and therefor continuously available to the public. However releases are preferred by users since they give certain guarantees about the quality of the software. Defining a distinguished FLOSS approach to release is hard and research shows that it ranges from very formal release cycles to highly irregular ad hoc systems [13]. Maintenance - Maintenance in FLOSS include problem-solving processes, user support practices, bugs and new features, software quality maintenance work, continues improvement, bug fixing processes, problem resolution interval, patches, shallow bugs, and incident management [13]. It is found that smaller project rely on community support where as bigger projects often have commercial parties offering payed support. Alexy et al. look at the problems and challenges that arise for the developers of proprietary organizations that move to OSS practices. This is directed at both software development and the governance of the software and a typical case of continuous participation with OS is taken from literature as reference. For each of the possible roles of an employee Alexy et al. lists the found benefits and drawbacks as indicated by his interviewees. Regarding development jobs that interact daily are highly affected by the transition by spending less time on actual developing and more by working on support for the OSS community. The governance is influencing managers since there is the potential of losing intellectual property or control 32

40 over the product. In the end the impact on daily work varies greatly between job role Infrastructure Kilamo et al. define the infrastructure as the tools and technologies allow for communication between the community, project coordination and management of project repositories. At the core of the communication infrastructure, especially in past projects, is the mailing list as the hub for the community [22]. Most projects have multiple mailing lists for different topics, such as user support, technical development issues, etc of the project [56]. Other means are almost always digital communication such as , instant messaging or forums where the conversation is in the public and stored for reference [22]. Fogel emphasizes the importance of the infrastructure for the success of the project. The most important communication tools can be found in the list below. Mailing lists Real-time chat (IRC) Forums Project website Wikis Face-to-Face Next to communicate a OS project will require technical infrastructure to support the development of a project. Compared to proprietary firms OS projects require infrastructure to facilitate the distributed nature of contributors working remotely and the open nature means that anyone should be able to access information regardless of date. Version Control System Build infrastructure Documentation infrastructure Issue/bug tracking Testing infrastructure Feature requests Archivation of communication 33

41 Software Kilamo et al. defines software as the approachability of the software and its quality as this may have an impact on the success of the community building. The software characteristic in literature encompasses mainly the modularity and software architecture [13]. Conley and Sproull states that one of the most important parts of the software is the degree of modularity. For Scacchi the extendability of the software is very important so that addition functionality can easily be added. MacCormack et al. in his study of the modularity of pre and post open sourcing Mozilla and Linux. It is found that Mozilla pre open sourcing is far less modular than Linux and that after the open sourcing considerable effort was put into the modularity of the code to improve performance [35]. Conley and Sproull finds that there is a negative relationship between the modularity and software complexity. Second the relation between modularity and static bugs is not positive, against theoretical suggesting the number of bugs is not reduced. Finally increased modularity in a release closes more bugs in most cases and no relation between modularity and number of bugs is found [10] Community Kilamo et al. interpret the community as the change the entire team will have to go through when moving to OS as well as the whole interaction with the outside world. A large portion of community research focusses on intrinsic and extrinsic motivation for individuals to join communities [30], the structure and membership between members and teams [39] and trust, social accountability cooperation, coordination and control [50]. Aksulu and Wade further lists the research fields of communities in their meta-study of literature: team formation, governance, team leadership, individual and team learning, role of the volunteer, user and developer motivations and the role of commercial organizations in the community Marketing Transitioning towards OS is equally a marketing challenge [26]. Marketing is needed to attract both new users and developers. Fogel mentions the importance of using marketing to create a "buzz" around the product and stresses the importance of being careful with the message, as everything is in the open and part of the public domain. 34

42 5.3 Case studies In the final section of the literature study case studies on open sourcing of proprietary products are examined and divided based on the characteristics discussed and explained in the previous sections. In order to provide background to the organizations covered in the case study characteristics each case study is introduced and described individually in the introduction. In the subsequent sections each characteristic is examined from the viewpoint of the different case studies Introduction Mozilla Mockus et al. investigate the displacement of traditional commercial development for OS style software development. Using the apache web server and the Mozilla browser as case studies the development aspects are quantified and hypotheses are developed by comparing apache to commercial projects. In the case of Mozilla both scenarios of before open sourcing as proprietary product and as OS are used for the hypotheses. In addition the work of Raymond includes an epilog in his paper "the cathedral and the bazaar" describing the development process at Mozilla. MacCormack et al. analyses the code modularity of Mozilla in comparison to Linux, both shortly after the release to OS Trolltech, Bekk Consulting, Linpro and ez Systems Eide retrieves data from four case studies of Norwegian organizations commercially exploiting OS. The four organizations are Bekk Consulting, Linpro, Trolltech and ez Systems. Bekk Consulting is a consulting firm, developing OS software to ensure and provide effective consultancy services. Linpro is another consulting firm providing services, training, support and solutions with existing OS software. Both Trolltech and ez Systems develop their own OS products, Qt Systems and ez Publish respectfully. Eide conducted a single interview with each of the organizations head of development or OS evangelist, and describes both current situation as well as retrospectively on the transition to OS Gurux Gurux is a platform providing communication products independent of used protocol, device or connection type (e.g. control a SMS-enabled device). The platform is divided into layers, each with their own group of developers. Recent succes in other software ecosystems inspired the organization to transition to OS in an attempt to expand internationally and reduce development costs. The business model evolved from proprietary licensing to SaaS, dual licensing and addition service offering (e.g. consulting). Eventually the organization expects the community to take over development from Gurux employees. The decision was not easy to make, requiring considerable time and resources. Although initially the organization lost a small 35

43 portion of existing customers due to the transition more and more new customers are being obtained as a result of the transition today [26] Wringer Wringer, developed by Sesca Mobile Oy, is a platform binding javascript for GNOME/GTK+, and the case study into the organization and product is conducted by Shah et al.. The goal of the open sourcing is to build an OS community for Wringer which can ultimately take over development from Sesca Mobile Oy. The case study provides advice to the organization, and the author warns the implementation is not a guaranteed success for community building as well as the advice itself might be ignored by the organization Symbian In 2010 Nokia hoped to revive Symbian, a mobile operating system, by transitioning it to OS. Motivated by the rise of other OS linux based mobile operating systems such as Android [4]. In a retrospective article on the open sourcing of Symbian it becomes apparent the transition timing was critical as well as the execution. The lessons learned from the Symbian case includes the fact OS is a powerful method to initiate and accelerate product momentum, but a poor choice to reverse product decline. Open sourcing should not be seen as single event in which the open sourcing is announced and the code is publicized. It turns out it is the opposite and open sourcing requires ongoing work in the areas of evangelism, programming and customer success stories in order for the contributors to feel their work is being valued [4] Legality During the open sourcing of Mozilla Netscape developed the Netscape/Mozilla Public License for the product instead of choosing an existing licenses. Iterations of the license followed, initially open developed code could theoretically become proprietary code, however the OS community opposed the license and the license changed to include copyleft features in order to safeguard OS contributions [60]. The license choice reflects the goal of Netscape to increase market share and compete agains other browsers. [35]. The license of Wringer should be based on the parent organization, GNOME and GTK+, license, LGPL 2.1, according to Shah et al. in order to be compatible. Gurux is licensed under the GPLv2 license 1, resulting in any derivations to be OS as well. Commercial organizations can prevent the open sourcing obligation by purchasing a commercial license as Gurux is dual licensing its product to gain additional income besides selling support [26]. In the research of Eide licensing is not specifically addressed in the case studies, the only information is concerning Trolltech and ez Systems which both use dual licensing as there business model and therefor have the strict non-proprietary license GNU GPL. In addition it is argued most successful projects use BSD style licenses, and using an acclaimed license, known by the community, further increases chances on success. Trolltech experienced a clash with the community regarding the license of the product because,

44 although the source code has always been available, it was not available under GPL. Trolltech did not feel the need to change, however the community felt the software was not truly OS and free, and argued for a change in license. In order to put pressure on Trolltech the community decided to start forking the project and start a competing project, resulting in Trolltech adopted the GPL license [16] Process Planning Within Mozilla roadmaps specify the features of future releases including release dates. Although Mozilla ultimately determines content and date it is important for them to incorporate the community in the process and the community is able to comment and participate as a result [36]. Bekk consulting drafts a public todo list of features and bugs the project should complete at the end of next month. Linpro advocates road maps and are using iterative development, Scrum, internally and this encompasses a road map and todo list, known as the backlog in Scrum development. EZ Systems work on a six month planning schedule for the public, longer running projects are kept internally, however planning has only been introduced recently as before development was ad hoc and highly unpredictable Coding Code at Mozilla is written on an ad hoc basis with the focus on areas where contributors have expertise or on upcoming prioritized features for the next milestone. The bug tracker, known as "Bugzilla", is used as a repository of potential work items for contributors to work on. Fixes are attached as reports to the bug reports. Contributors can flag items if they are not able to fix the problem due to lack of expertise or resources. News groups are used for discussion and idea generation. Finally the web site is used to indicate areas where new contributors could help out [36]. Shah et al. recommend the use of Linux kernel coding in order to comply with the parent library Testing Mozilla has dedicated teams for testing the software, running daily builds of the product and a minimal set of tests on all platforms to maintain sufficient stability. Results are posted on a daily basis and failures are passed to the responsible contributor. The test teams, half-dozen of them, are mainly occupied with Netscape personnel. Since the code base of Mozilla has a high dependency between its modules both the module owner reviews contributed patches as well as by the "super reviewers", a group of highly accomplished technical people, to review module interaction [36]. Linpro advocates unit testing provide quality control and each patch or contribution should include a test and pass all previous tests. Additionally to release the product automatic building should be provided as automatic builds greatly increases development speed before releasing [16]. 37

45 Releasing Before releasing a new version of the product Mozilla runs continues builds to determine issues including changes and contributors who made them. The process produces binaries nightly and produces "Milestones" on a monthly basis. Management decision are made in order to code freeze a few days before releasing, a designated group is responsible for input from the community [36]. Shah et al. argue OS development is subjected to continuous maintenance, and advice the same pattern as the parent projects GNOME/GTK+ for release management. The method includes bug fixes and new features in each release. Eide finds all interviewees agree the need for constant development releases, containing new code commits, providing motivation for the developers. Linpro and Bekk consulting both have daily builds in order for contributors to see there work in action, provide feedback, are conscious of current developments and display the notion there are commits going into the product. Mayor releases, according to Linpro, should occur within a six month timeframe, he gives the example of KDE where contributors and users left for the more active alternative GNOME and argues the need for smaller projects to release even more frequent, providing updates each month [16] Documentation Mozilla s initial releases did not have a lot of documentation, in the time after open sourcing tutorials where added, documentation improved and tools and processes refined. After these steps collaboration of external people started to increase. Further documentation include architecture and technology use, building and testing, cross-reference and change presentation systems [36]. Shah et al. argues documentation is not a necessity with development revolving around code, but feels documentation on Application Program Interface (API)s and introduction tutorials can add value. Wringer leans on the GTK+ community which provides large set of documentation and the author feels Wringer should provide an example application together with tutorial to further increase the usefulness of the product. Linpro is attentive to documentation quality, accuracy and coverage in order to attract contributors. Further writings includes a readme, installation scripts and providing the same information on the web site. EZ Systems initially had limited documentation, as the project was small, however it did include installation tutorials. Technical and how-to-use documentation was lacking and the documentation could not be found on the website. Trolltech feels its documentation is among the best out there for developers and is considered a unique selling point [16] Deployment The process of building Wringer is effortless on Ubuntu, however it is advised to increase the documentation on installation (e.g. by adding a readme) [51]. Bekk consulting argues for the first impression of users and potential contributors, each step should go smoothly without leaving the user frustrated [16]. 38

46 Timing The timing and addressing of international community of when to OS the project was of importance to ez Systems as the organization feels it would not have the same succes if it had transitioned its software later [16]. The same is true for the decision to OS Symbian, where some argue the open sourcing came to late [4] Infrastructure The Mozilla project uses "Bugzilla" for bug tracking and patch submissions as one of the main community hubs. In addition there are mailing list for discussions, IRC channels and a website to provide documentation and roadmaps. In the case of Wringer there is no infrastructure at the time of the case study, as such Shah et al. provide suggestions for the project based on parent projects. As the GNOME project uses CVS as version control and software configuration management with module maintainers as reviewers of patches. Wringer is advised to follow the same pattern but due to the small size the number of module maintainers can remain relatively small. Regarding communication the same advice is given, adding mailing lists, IRC, a committee organizing conferences and a biweekly activity summary however other similar communities could also be used as role model. Bug tracking is advised to be made available in Bugzilla, again following the parent project, in order to pilot community contributors [51]. Gurux has a bug tracker, forum, documentation (including sample code), animated tutorials and quick starts. In retrospect the migration to an open infrastructure required large amounts of resources and it is important to take the requirements into account when deciding to transition to OS according to Kilamo et al.. Linpro explaines the forum is the primary infrastructure for communication, however developers tend to use mailing lists and wikis more. Mailing lists are also recommended as being more effective for the task of development coordination. The forum is a tool useful for the beginning users, where as the wiki should contain documentation, suggestions, and more. In addition the use of IRC is common among the developers. Although Linpro notices the preference of users for forums and developers mailing lists there is no distinction introduced at the governance level. Bekk consulting has no preference for mailing list or forum and advices one should be available. Linpro starting infrastructure consisted of a mailing list and static web site, but since includes bug tracker, wiki, forum and additional mailing lists. EZ Systems provides only mailing lists, and although initially a forum was provided low activity caused it to be shut down. It did extend the mailing lists to add additional lists and separate topic between them and no longer uses IRC switching to instant messaging, mostly Skype, and for most of instant communication. Trolltech uses CVS and a bug tracker [16] Mailing lists Linpro argues the mailing list is their most effective communication tool, since all important notifications are broadcasted creating awareness and transparency within the community [16]. 39

47 Forum Bekk consulting argues for a forum as opposed to mailing lists as forums are less intimidating for users and it is easier to filter its contents, automatically archives and include search ability out of the box [16] Wikis EZ Systems initially had a wiki system, but the solution was only used internally. After the decision to abandon the wiki the community started a technically directed wiki which is now interlinked with the organization own documentation forming a single repository of knowledge for the project. Linpro feels a wiki is ideal for documentation but needs to be constructively structured [16] Website Linpro explains providing a good website is a necessity, however the costs of a professional version have withheld the organization to follow their own advice. EZ Systems tries to update its website regularly but keeping the documentation up to date with the software is proving a challenge. The organization believes design and layout are factors influencing interest, and now competitive projects invest in the area of design it is becoming a more important consideration since its a marketing tool. Trolltech explains the website is the primary sales channel, so hugely important, and the organization is continuously improving. A recent overhaul of the website greatly increased sales [16] Software Linpro argues the most important aspect of the software is to meet a need of users considering contributing and meeting a need is more important than the state of the code base such as level of optimization. Bekk consulting is arguing for the importance of quality, and the ability of the software to perform a specific task well. Linpro has a similar view and when starting the code should work in a basic form providing a minimum viable product installing and running with no hick ups where potential contributors feel they just need to add some specific features on top of it and they have what they need [16]. Gurux reported the refactoring and cleanup of the code base required more resources than expected, especially the adjustment of processes to manage an OS community. In hindsight more resources should have been made available for the refactoring. Double the time was required for writing documentation, rewriting code and building an example. Additionally maintaining distinct versions of the product proved to be a resource burden [26] Architecture In the early days, after releasing Mozilla to the public, the architecture of Mozilla was cumbersome, as stated by a leaving project leader [36], and the code was significantly less modular compared to Linux [35]. Understanding the code was to rigidly coupled, making it harder for potential contributors to join 40

48 the project, a redesign to increase modularity was proposed and executed by a small team of Netscape developers. In order to promote contributions an "architecture of participation" is needed [35] and in the case of Mozilla the redesign was followed by and increase in contributions [36]. In order to improve understanding of the code base of Wringer documentation of the high level architecture (e.g. component diagram) is designed and verified with the original developers [51]. Shah et al. argue the documentation makes Wringer accessible and appealing to contributors. The architecture of an OS project is an important aspect as, according to Eide, it determines the success of the project and should be suitable for attraction. New project emerge with similar features of older projects but provide a better and more modern architecture. Therefor a modular architecture is important for a project, making each module a separate section almost as if being a project on their own. The modularity creates flexibility and comprehensibility for potential contributors reducing the learning curve and allows extensibility without requiring modifications to other modules [16] Code Cleanness After open sourcing an edition of Wringer, "SpiderMonkey", dead code was removed from the source to prevent confusion and promote clean code [51]. Eide finds code cleanliness is not necessarily needed for the success of a project as long as the functionality and need for the project is evident. In the scenario where functionality and need are evident contributors will clean up, create structure, come up with ideas and really polish the project. Arguably getting the right combination of people will results in project success, not only in OS [16] Code Comments Shah et al. considers comments, pre-conditions, post-condition and statements, a recommended tool to make the code base accessible. Although the latest release of Wringer is adequately commented, more comments could advance the product even further. However code comments is also known to be an ideal starting point for new contributors joining the community[51] Bugs, Debugging and Standards Wringer had a number of bugs and the organization felt it was important to make the bugs evident to the community as repairing the bugs is a great introduction into the project for new contributors [51]. The product does not have a debugger and according to Shah et al. lacking such a tool is preventing the development of complex applications on top of the Wringer platform. Finally the use of standards in the OS project are important for the innovation, by adhering to open standards and protocols projects get endorsement from other communities and collaboration becomes easy [16]. 41

49 5.3.6 Community Wringer is advised to use a similar approach to contributions as the parent project GNOME, having module maintainers make decisions on accepting code contributions [51]. Gurux decided to split the project up into an ecosystem of sub communities dedicated to sections of the platform with contributors both internal, from Gurux and partners, as external volunteers. Gurux implemented a transparent system in which users are able to gain points for activities an as such get more user rights. The results after six months are promising, the number of contributors exceeded 200, often from abroad, as well as a steady rise of the number of downloads of the product [26]. In order to monitor the evolution and healthiness of the community metrics such as downloads, web page visitors, volume and feedback on google alerts as continues data are gathered. The data is analyzed and action is taken accordingly. At Trolltech the community is al about innovation, the synergy between volunteers and professionals identifies problems and creates solutions and sparks for improvements of new features [16] Contributions After the open sourcing the growth of outside contributions where lower than expected [36, 43]. Raymond argues the reason for the lack of contribution is one of the basic bazaar rules was broken by Netscape, namely potential contributors where unable to run and see the product working until a year later when a proprietary license for the proprietary library Motif was no longer required. Other reasons where large size, cumbersome architecture and lack of support from Netscape [36]. Code contributions have gradually increased over time but outside contributions are lower than internal, presumably due to the part time nature of participants. However 53% of the problems reported by 95% of the people are external participants [36]. Because of the metrics Mockus et al. hypothesizes that in the case of successful OS development a significantly larger portion of contributors in comparison with development of new features will repair defects and an even larger group reports defects. Eide notes the right to contribute remains largely in control of the starting organizations. For instance Trolltech only allows employees to push code into the project, code contributions from the community are quality controlled and tested for the full product not the specific situation, for ownership considerations. Bekk consulting and ez System are more lenient and allow outside contributions based on a meritocratic structure, active participation and high quality contributions. Trolltech has gained a lot from it s community especially in the case of bug reports, allowing the product to become better at a faster rate than the competition. A second benefit are community members who use the product for recreational activities but introduce them in a commercial environment when they start to appreciate the product. EZ Systems receives large number of development contributions such as modules and plug-ins [16] Roles and responsibilities The Mozilla project has its own staff, responsible for coordinating and guidance, process and work on the product. The internal people are responsible for quality assurance, milestone releases, website tools and 42

50 maintenance and infrastructure such as Bugzilla. In the years following the open sourcing external people from other organizations also started working full-time on the project. Decision making is based on module owners and left to people who know particular code [36] Ownership In the case of Mozilla code ownership is imposed and code owners are responsible for the activities within the modules. Activities include: bug reporting, feature requests, patches, facilitate good development defined by the community and review code commits. Because of the code imposing Mockus et al. argues OS development has a core group responsible of 80% of the new functionality, in the case of informal ad hoc coordination the group is not larger then 15 developers. In the case of more than ten to fifteen people code ownership is the only viable option to successfully develop. The hypothesis further suggests, in the case of OS development, developers need to be consumers of the product at the same time (dogfooding) [36]. The organization and the community often have disagreement on the direction of OS project as both have different motives. Bekk Consulting acknowledges the initiator of a project commonly remains in control of the project. Eide finds in literature OS projects often have meritocratic structuring and all interviewees feel they where the people making the final decision. Bekk consulting describes the process of the direction of the product by internally going through suggestions, from customers, the community and ourselves. EZ Systems has a similar approach and describes the difficulties associated with juggling of both community, customer and internal features. In the end customers requests are the most highly valued as they provide the revenue needed for the organization to sustain. Eide concludes the organizations have the final word, but try to incorporate the community and its wishes as much as possible Governance Governance between organization and community should result in a symbiotic relationship where both parties gain benefit. Linpro feels open sourcing a project is a favor to the community and non-contributing users cannot demand features. To counter the behavior monetary rewards could be granted as features are implemented by others. Balancing interests of the commercial organization and the community is crucial, and organizations wanting to remain in control should actively allocate resources to the project [16] Activity Activity of a OS project, such as bug reports, code changes, forum and mailing list items, is important to the success of a project as contributors don t waste time on projects soon to be terminated as they are often looking to work on their career by contribution to projects. Bekk consulting advocates an active forum and mailing lists in order for the project to appeal to external users [16]. 43

51 Communication Although Linpro employees work and communicate internally, solutions and related issues are debated in the open on the communication infrastructure (e.g. the mailing list) and documentation is provided in order to attract contributors. However ez Systems is more conservative and feels not all discussions need and should be publicly available. Bekk consulting and ez Systems both feel the important aspect of active communication and in particular answering of questions of the community in a quick fashion. In the current state answering all questions is no longer possible as the quantity exceeds the resources within ez Systems and today the community is mostly responsible. Bekk consulting recommends prioritization in larger projects where knowledgable people answer the difficult questions and leave the rest. For ez Systems the business model also provides issues with communication as they sell support. Each question quickly gets a reply, but only if a question is quick to fix a solution is provided, otherwise pointers and references are made. When people want direct support they are directed to the payed support section [16] Credit Linpro provides credit to all contributions in a single alphabetical list, and argues distinction of the list according to role is a bad idea. EZ Systems acknowledges providing credits to contributors should be actively pursued by the project owners, and until implementing a system for automatic contributions it actually regrettably did not always provide credit [16] Marketing In order to promote the Wringer project an effective marketing campaign should attract both individual contributors as well as other organizations [51]. Gurux initially contacted existing communities with related projects as part of the marketing strategy to gain early contributors. In a retrospective of the open sourcing of Gurux the organization feels marketing is important and should be tackled aggressively and extensively. The organization plans to continue and increase its marketing efforts in order to attract additional community members to attain self sufficiency. Ultimately more users of the software should result in more Gurux customers [26]. Based on the cases Eide notes the general principle behind marketing remains the same for proprietary and OS, spending resources on announcements, interviews, conferences and sponsoring. In hindsight the marketing strategy of Varnish, mainly publishing to the press without a clear strategy, did not get the desired results. The organization states in case where to redo the open sourcing the project would require additional marketing, investing in web pages (as a web page is seen as a success criteria), good documentation, active wiki, active mailing lists, thanking contributors and release code often. Some suggestions provided by the interviewees for marketing include present at conferences, proper website, index on mayor OS and download portals, regular press releases, accurate wikipedia, news letter, engaging (potential) users and customers, partner with other projects and traditional marketing i.e. paid advertisement 44

52 [16]. Bekk consulting sees the first step to an active community is getting users to download and use the software. Providing interaction with the community and maintaining an active core developers group are key ingredients for an active community [16]. 45

53 6. Citrix research and Development case study The following chapter contains the information gathered during the case study at Citrix R&D, further indicated as the organization. The goal of the chapter is to provide an overview of the strategy, organizational objectives and the current state of each of the characteristics based on current, historical and expected future implementation. 6.1 Organization Product XenServer, in the remainder of the chapter described as the product, as a product consists of Xen Hypervisor and additional features. Xen Hypervisor consists of a number of packages that can transform any linux distribution into a Hypervisor. The product is similar, as it is an extension of Xen Hypervisor, but includes more technical fidelity. In order to support a multitude of industry standard hardware products a single linux distribution, Linux CentOS 1, is chosen in order to provide a stable foundation for the product. With only a single distribution to consider the product modifies the linux kernel in order to support all vendor requirements. Additional features are often built on community OS projects, but modifications are not returned to Upstream. To provide the ability to manage the product an API layer is used between the product instance and the administration application XenCenter. The different development teams work on the different facets that require modification or addition. Developing the product is in many ways similar to maintaining a custom linux distribution, involving large amounts of work. More information about the organizations, the products and the teams can be found in appendix A Strategy At the end of 2012 the general strategy for Citrix R&D converged to fully OS XenServer and simultaneously focus on technical integration with cloud distribution. Previous strategies focused on enterprise software integration, but the strategy has shifted towards cloud distribution customers as the market for enterprise software integration is highly competitive and in a feature race. The move towards cloud computing also includes the adaptation from large scale enterprise customers to also include smaller businesses. Citrix R&D is not expecting the transition to OS to develop a vibrant OS community as the general idea is few organizations will be interested CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. 46

54 Proprietary Sponsored Open Source Citrix Research and Development Community Citrix Research and Development XenServer OS XenServer Citrix XenServer Figure 6.1: XenServer moving from a proprietary to sponsored OS. For Citrix R&D the transition to OS is a separation between the commercial organization Citrix R&D and the Community organization. In the early stages the separation will be a distinction visible internally in the organization as the community consists of employees of the organization. Although the partition will not be a clear cut line, the vision of the organization is to have the commercial side develop, test, certify the product as Citrix XenServer including support and internal processes. On the other side is the public community project around the product. The community project has overlap with the commercial side regarding bug tracking, communication and documentation exchange and produces a community product version Open sourcing projects In order to prepare the initial transition to OS the organization planned two projects. The first project was designed to provide the bare minimal required to be an OS project. The core was the release of a new iteration of the product (XenServer 6.2), under public licenses and provide the code base on public repositories. Included in the transition to public repositories was the sanitation of the source code to remove any proprietary or otherwise internal documentation. Lastly the first project goal was the introduction of mailing lists for the different components. The goal of the second project, and follow up projects, was to determine and execute further open sourcing of the product without having a clear scope at the time of discussion. During the initial development stages of the second project the idea of using projects was dropped in favor of continues improvements on the open sourcing. The definition of a project to have a deliverable in a certain time frame seemed unfit with the permanent changes the transition to OS was and is having on the organization Internal development process Before the start of the research and the transition to OS the organization switched development method. From the inception of the organization development was based on the waterfall approach for developing software. The waterfall approach was replaced by an agile work method. Although the implementation 47

55 of internal processes do not affect the open sourcing, the agile development method is regarded a much better fit for OS projects. 6.2 Business Model The organization believes, although business might get lost whilst transiting to OS, the majority of commercials organizations will continue to invest in licenses. The mayor reason, organizations want to have the guarantee of full time support for products. The product is used to support mission critical business processes, and paying for support allows shifting responsibility outside the organization (e.g. not a core business), easy updating, certification and a third party to attribute. In most scenarios an company requires and demands working tools and is willing to pay for the service provided by the organization to reduces the risk involved and the ability to contact another organization to solve their problem. Additionally customers can request features or fixes, reducing costs for themselves as they do not have to invest in the development of the requested features Historical Before transitioning to OS the organization offered five versions of the product. Following a freemium model by offering XenServer free, a full product but excluding a majority of the premium product features, for free under Citrix End-User License Agreement (EULA). Alongside XenServer Free an OS version, Xen Cloud Platform (XCP), was offered under the OS LGPL, GPL and Q Public License including a variety of features also found in the premium versions. The final three premium versions of the product consisted of three tiers: Advanced, Enterprise and Platinum each offering additional features in respect to the version before it Current Transitioning to OS has reduced the product offering to a single version. Both the OS project as the paid product are identical, making features no longer a unique selling point for the product. In order to keep monetary gains from the product customers are offered the option to pay for a license offering full time support, tested and certified product, automatic patches and updates in XenCenter and acces to Citrix knowledge base. Thus the organization is following the Support and Training model. Two paid versions exists, either an annual license or a "lifetime" perpetual license, both only offer a single year of support but the perpetual license gives a "lifetime" of access to the other three features Future Currently the organization is exploring possibilities to increase its earnings by including its product with support in other vendors product. Examples include paid linux operating system licenses including the product 48

56 as virtualization platform allowing it to drive profits and market share simultaneously. The organization is diversifying its product channels, moving from a single traditional sales funnel of sales people generating leads to a more diversified funnel by including their product in other products and allowing people to order a license using the internet. The goal is to appeal to smaller businesses and lower the barrier to entry Challenges Some challenges remain in the business model, for instance the goal of being able to have package integration with all mayor distribution contradicts with the unique selling point of easy upgradability. Additional problems surface as processes get opened to the public, e.g. the development mailinglist has all developers of XenServer on the list making it tempting for a user to ask support questions instead of development questions and circumventing paying for support. 6.3 Characteristics In compliance with the characteristics found in the literature study the subsequent sections of the case study are divided based on the before mentioned characteristics Legality Historical The Xen Hypervisor project has always been OS from the beginning. The project is licensed under LGPL as most of the code used to create Xen Hypervisor came directly from the upstream linux kernel. The Xen API project OSd in 2009, as part of an earlier attempt to OS the product, and became GNU LGPLv2. A GPL type license was preferred and the choice for LGPL allowed for the linking between other libraries, required for the project, without the obligation of including the source of these libraries as the product project was still proprietary licensed. The proprietary product was using an custom EULA typical in proprietary software sales Current In the process of open sourcing the first step for the product is the choice of license, as the license differentiates between open and closed source. The different teams or component owners, and subsequently different modules of the product, where tasked with choosing the license. A member of the open sourcing projects explains "Most chose BSD, does not require redistribution of source code if you use the code. We did not care because we want people to use the code, if people would contribute because it is advantageous to them and because its just part of good OS citizenship". Alternatives to the license choice of LGPL and BSD where hard as another member explains "The para virtualized drivers in windows where interesting, windows update service makes it impossible to distribute source code but would be required if it where GPL code". Even though 49

57 the majority of the project is OS (96%) some third party components and libraries are still proprietary, for instance the para virtualized drivers in windows, and require linkage as binary as they are still essential to the product. On the question if the organization considered dual licensing: "We haven t looked at dual licensing since it was advantageous to us not to have a restrictive version anyway. Doing that may seem the project to be less open, again this might have appeared to the public as open washing the project and this is not what we want. And also we didn t think people would flock to come and buy code license, so it only brings bad association and not a lot of good." Process Planning The initial planning method within the organization was based on the waterfall method for general development planning. Before the transition to OS the organization moved its development towards agile working practices, resulting in ongoing working practices during the open sourcing. In the agile working method a number of key concepts have changed including the method of planning. The organization uses release trains to determine the features and resource allocation of the next release of the product. Most of the contents of the release trains are not made public, but a roadmap for future releases on the wiki shows mayor features to expect in different time frames. Currently detail information, such as current work in progress and smaller to be done work items, are not communicated to the outside world. Some effort has been made to work with a changelog to communicate to the community the fixes and added features of each version release, but it is maintained sporadic. A number of teams change logs have remained the same since the release to OS Requirements The requirements of the product are based on internal decisions and none of these are published to the external community Coding Currently code is being published in the public repositories of the product. The development of each of the different components is updated on a daily basis, however each team has their own workflow regarding committing code.code reviewing is done different in each team, but includes at least one review by pears before being added to the development branch of the product. Subsequently the code will be put through testing, if it fails returned to the developer if not the code will be merged into the main branch of the team. Finally a last round of testing ensures compatibility with the entire product and will mean a merge with the master repository of the product. 50

58 Project related to the product project include a dedicated file explaining potential contributors how to proceed when they want to contribute.each team is allowed to control their own coding styles and per team different programming languages such as OCAML, Python and Windows C# allow for different coding conventions.current coding processes within agile include a backlog of tasks, a task is chosen by any of the team members, code is written or the problem is analyzed and handed over to another member, team member reviews code, code is merged into development code base followed by two rounds of testing for team master branch and product master branch any faults result in moving a few steps back Testing The organization is using continues testing to maintain a degree of quality within the product. Code entering the development branches is automatically tested before moving towards the stable branch in nightly builds. In order to continuously test a dedicated team within the organization is actively developing a test tool called Xen Regression Tests (XenRT). Following the initial open sourcing XenRT is also open sourced to the community two months after. The results of the tests running internally are currently not available to the community. The individual teams have no standards regarding unit testing and the level of implementation varies Releasing The organization is in full control of the release schedule of the product and it is impossible for a member of the community to build the product. "Citrix is advantageous to have a non public build system, so then Citrix holds the key to integrating all the different components and integrate this into a nice polished tested package. That would differentiate what Citrix could provide against something somebody else could provide on their own. It is not saying that somebody could not get XEN API and get a spin-off Debian system but the system would still be different to Citrix". The build system requires a high amount of resources and highly customized setup and is specifically geared to creating the Citrix XenServer ISO. Given the future plans there are no intentions to invest resources to open source the build system. In order to deliver feedback on development to the community the organization is building developer snapshot ISOs on a weekly basis. An overview of the entire build and release schematics can be found in Appendix Maintenance Current support to the community is based on the mailing list, forums, IRC and wikis related to the XCP project. There is no single point for external people to report bugs and they can be found on the mailing list, forums and IRC. For support non-paying customers are reliant on the community and occasional help from developers in the mailing lists, forums and IRC. The support is a though issue since providing technical help to further improve the product and community is needed, but its proven hard to distinguish support questions and the profit of the organization now rests on the delivery of support. 51

59 The problem-solving processes within the organization are internal, bugs come from either automatic testing, development, performance tests or customer feedback. Bugs and problems are listed in an internal bug tracker or a semi-external bug tracker accessible to customers only, in order to follow progress. In most cases the first step is to determine the cause of the bug and its origin using triaging. After the cause is determined planning determines when a developer is able to work on a bug and the regular code interaction as described in coding is continued. Fixes to critical bugs are bundled in hot fixed which are available to the customers, where paying customers can automatically update and non-paying have to apply the patches manually Deployment Although there is no possibility for developers to build the product themselves there is always the ability to download the ISO from the web site. As the product is provided in a ISO it is simple as running the installer on an machine and install the product, operating the product is possible using the graphical client allowing ease of use to the user. Regarding the robustness of the product one of the developers notes "most of components of the product expect a perfect environment giving an often cryptic message when the component fails.". The perfect environment is provided with the ISO but not when external developers develop on the product Documentation Extensive documentation on the features and the API of the product exist from before the transition to OS. The documentation are user manuals and the ability for third parties to communicate with the application. For the development the only source are the archives of the mailing lists, IRC and wikis. The wikis are out-of-date and written for the depreciated XCP version Infrastructure Historical The open sourcing of 2009 of mainly the component XenAPI included the creation of mailing lists, an IRC channel and documentation on the wikis of the Xen Hypervisor project. Additionally the internal XenAPI team opted for a workflow including the online code hosting solution Github to store and maintain the code base. On the Citrix forums there is a part for XenServer for user questions on the product and Citrix provides official documentation Current The current public infrastructure at the organization include forums, mailing lists, IRC, questions and answers on the website, documentation, web site, version control system and wikis (at the Xen Hypervisor 52

60 project). Internally the infrastructure includes bug trackers, agile boards, backlogs, wikis, podio 2, intranet and build and test infrastructure. The forum existed before the transition to OS and is not integrated into the routines of developers as one of them mentions the following: "There is a forum, but it is problematic because, who is looking at that? Nobody at the moment as it is not yet part of the culture.". Moreover the forum is tightly integrated with the citrix.com infrastructure and not on the new community portal web site. Mailing lists exists for the users and developers of the component XenAPI and main product, however as one of the internal developers explains "Developers are not used to proposing development specifications over lists. Some seeds have been tried but nothing happened. The probable cause are the good internal tools so its not really convenient to use external mailing lists. Since the internal tools are so good people don t really feel like moving to a mailing list to do there discussions.". Multiple IRC channels exist for both community and internal processes. The transition to OS included the development of a community web site, xenserver.org, designated to become the central place of communication. The website includes media and blog posts related to the product, upcoming product events, product information, high level project roadmap, downloads of the software, references to the source code, mailing lists and forums and a questions and answers section. Documentation currently available exists on the support infrastructure of Citrix and is provided in pdf format. Additional information can be found on the wikis of the Xen Hypervisor project infrastructure however is stil labeled under the previous open sourcing project name XCP. The code of the project is hosted on an online code hosting service Github. "Everyone was forced to Git and GitHub, It is possible for people to continue working on their own way as they please but our XenServer manager felt that constancy was better if there was a single central hosted entity for code.". Before the transition to OS the teams used mercurial as code repositories and some teams still use internal mercurial workflow replicating the code on Github as a mirror Software Architecture The architecture of XenServer is highly interwolven and although the organization is split up into teams the code is not as easily separated. Although the code itself is clearly split between modules the implementation of features is not clearly held within the boundary and it is sometimes hard to figure out which module does what in a specific task Code cleanliness No modification where made to the source code in preparation for the open sourcing. The codebase found in the Github repositories remains the same code base as can be found internally in the organization. 2 Podio - A web-based platform for managing team communication, business processes, data and content in project management workspaces. 53

61 Code comments Before the open sourcing the comments had to be cleaned of inappropriate language, confidential and sensitive information and inaccuracy. There are no internal guidelines regarding commenting on code and the level of comments is limited Bugs, features, debugging and standards Currently the process of handeling bugs and features are completely internal, with the exception of a high level roadmap on the website. The process for potential contributors to add new features is to contact the mailing list and propose the feature to the maintainers of the project. When there is no internal work in process or planned for the future the contributor could start working on adding the feature. Externally it is not possible to debug the code in any way, as even building the software is not available outside the organization firewall. No standards apart from generally accepted code guidelines, as one of the developers notes "There are no document coding conventions yet." Community Contributions Contributing to the project is possible for external developers by following the guide in the contribution or maintainer document in each code repository. "Ring3 will accept pull requests from external contributes by review.". After the code is reviewed it is resumed into the normal internal processes. Although Github makes it possible for a almost automated process the mailing lists can be used as well, even if it requires additional effort for the maintainers. The idea from the organization is in the scenario a external contributor takes the effort of developing a high quality patch he or she will go through the effort of finding out how to get the patch into the main branch of the software Roles and Responsibilities The internal developers of the organization are the maintainers of their own code base they maintain as team. As the number of outside contributions have been less than ten there are no real opportunities for external contributors to get any official role or responsibility. The roles and responsibilities of the developers are unchanged apart from the allocation of resources to actively participate in the community Ownership The ownership of the code base remains in full control of the organization. Although attempts have been made to have public discussions on directions of the project the lack of responds in combination with the internal infrastructure has left current decision making fully in the organizations hands. 54

62 Governance The organization does not have any implementation of governance, and is operating in an ad hoc basis regarding decision making. As the only contributions, with a few exceptions, have been made by employees of the organization the same structure and processes from before the open sourcing remain. Some employees within the organization feel the strategy should be to join a existing OS foundation and inherit the governance Communication Communication with the users of the community is conducted utilizing the forums and IRC of the organization. Development communication is achieved through the mailing lists and IRC. News about the project is spread using the community and corporate website including blog posts on experimental projects conducted internally in the organization to preview upcoming changes in the product. The questions and answers tool on the community website allows interaction between the users and maintainers Credit The only project to provide credit to the community is the XenAPI component using the code version system commits to filter out all different authors. Other projects feature a manually created maintainers list featuring employees of the organization or no list at all Marketing Consequently with the open sourcing of the product the marketing strategy for the product changed from enterprise to cloud computing not limited to large corporations but including smaller businesses. The launch of the OS release of the product included several previews, blog post and press releases. The decision was made to not include the news in the yearly conference of the overal organization but rather make a specific event purely at promoting the transition to OS with the new release. 6.4 Future organizational considerations The following section describes the proposed and desired changes for the future within the organization based on characteristic. The items discussed below are not guaranteed to be implemented and function as a consideration list from the organization and its employees at the time of the case study Legality As the organization mentions themselves, "Currently there are no plans to introduce further OS license changes into the product", the current license arrangements will remain unchanged for the foreseeable future. 55

63 6.4.2 Process Releasing The developers snapshot with a light builds of the product delivered each day demoing the latest features and publish the build to the community. Further adjustments to releasing include the ability to build individual components to test modifications Testing The organizations wants to integrate testing throughout the product components (e.g. unit-tests), however only for development after the open sourcing as a new coding practice. To help facilitate the code practice work has begon on a general test skeleton easily reusable to create tests. In the end the process for contributors when writing code will include running tests before submitting for a code review from the maintainers. To extend on the tests a system wide quick test would allow end-to-end tests Documentation As one of the OS evangelist mentions when discussing documentation: "Definitely not there yet!". The organization is planning on providing a wiki to include a lot of the internal documentation already available and provide documentation on the architecture, designs, component interfaces and architecture road maps. The software behind the wikis will be used to allow discussion on features and roadmaps from both internal and external contributors. The architects within the organization are working on writing al documentation in markdown format, stored in a repository and provide trigger hooks to people in the mailinglist when adjustments are made to the documentation Infrastructure There have always been plans to implement a public bug tracker and wikis dedicated to the project. According to the community manager on the community website both should be available soon "The big process improvements will hopefully be unveiled in late December or early January when we get our long needed wiki and defect trackers online". As reasons for the delayed introduction of tools the community manager states "Unfortunately, there is no magic wand to remove customer sensitive information, ensure that designs linked to closed source development on other Citrix products, or information provided to Citrix by partners under NDA isn t accidentally made public". Another important aspect of the publication is the ability for search engines to crawl the contents so it can easily be found by those who are looking for it using search engines Software Resources within the organization have been assigned to a project to decouple the products different functional areas, making separated modules. The work includes designing component interfaces, which are 56

64 also documented by the software architects. The project furthermore re-evaluates the build-in defaults and is aimed at switching to more commonly used solutions found in other OS project. Introduce configuration on a modular level and allow developing on a single component automatically discovering its dependancies. The developers and architects agree that in the period before the open sourcing the goal was to provide the ISO and solutions chosen are not the best for individual component development. With the transition to OS the idea is to move to a system where each component becomes a module on its own regarding development and get the individual modules in the different linux distributions. In order to achieve the independence it is discussed to provide versioning to each library. Ultimately the build system, currently only used internally, is destined to be replaced by a more standardized process to create a shrink-wrapped product. A intermediate step is the ability to build individual components, and sequentially replace the component in an installed product. Rebuilding components allows developers to test code changes without having to wait for the development release to come out. 57

65 7. Analysis The following chapter analyses and assess the information derived of the case study by comparing and evaluated the information against the information found in the literature study findings. The goal is to identify improvements areas for Citrix R&D, the organization, to serve as an input for the next stage of the research, the process of transition. In the chapter the analyses is explained, motivation, business model and characteristics are analyzed and the results are presented. 7.1 Introduction The goal of the analysis is to provide a systematic and as objective as possible assessment between the ongoing activities within the organization and the information in the state-of-art literature and case study findings. In the first two sections of the chapter the motivation and business model of the organization as discussed and analyzed. The second part assess the open sourcing based on the characteristics of open sourcing, the process is illustrated in Figure 7.1. Literature Characteristic Open source Literature Case studies Citrix case study Characteristic Improvement Assessment Figure 7.1: Analysis process of the open sourcing at Citrix R&D. 7.2 Motivation The motivation and goal of the organization is increasing the market share, ultimately converting users into paying support customers. Community growth is not a priority for the organization, as the organization believes little growth can be expected given the specific niche of the product. Further general assessments conclude the organization initial momentum has halted after the open sourcing, mainly caused by alternative resource occupations regarding the product itself. Officially the product is OS, the code is published under a public license, however it still has a long way to get to the benefits of OS as mentioned in OS literature. A large number of the benefits of open sourcing can be attributed to the community, as the community provides bug reports, feature request, extension 58

66 development, third party development, marketing and more. Gaining market share is in the same way is linked to the community. A product can attract more attention and market share because of qualities such as product quality, security, stability, documentation, activeness and more. All of these qualities greatly increase once an active community is formed around the product. An argument can be made for the scenario where market share is already driven by the act of open sourcing alone, however open sourcing the product for marketing purposes only, openwashing, rarely has positive consequences. A project appearing inactive from an external perception looses popularity and thus market share as potential users and contributors refuse to invest in a "dead" or inactive project. Further risks of an inactive project are the possibilities of commercial organizations or groups of users forking the code base to start developing a new community and product directly competing agains original organization. The open sourcing received press attention both from the organization and its partner organization itself as the general press. However the response is mixed and some have stated the organization is dropping the product as it no longer holds value, something the organization is fighting hard to disprove. It is therefor important to create trust between the commercial organization and the OS community by being as transparent in the intentions and goals as possible so a thrust can exists between the both.. Given the information presented above the general advice to the organization is the creation of an active community to be the intermediate goal of the organization as it will ultimately provide the organization with the opportunity to expand its market share. Further improvements should include transparency, providing openness of the project to the community as a whole to create thrust and confidence. 7.3 Business Model The business model implemented by the organization is a natural consequence given the available infrastructure before the open sourcing. There is no need for change as the support infrastructure, employees and procedures require no adjustments. Alternate options such as adopting a dual licensing business model is not possible given the license.the choice for a less limiting license was an active one from the organization as the nature and functionality of the software prevents any business model to be justified and it is believed the less limiting license leads to additional sales. Other options mentioned in literature such as providing training, consulting and implementation of software has traditionally been an activity of third party partners of the organization. Third party partners are able to get certification, generating income to the organization, on the level of partnership they have with the parent organization. The structure has historically led to the organization being able focus on the product rather than implementation. The structure with partners will remain and therefor resorting to training, consulting and other tasks is not a viable option. Additionally the organization has no experience and would need to invest. Options such as providing hardware are also left to third party partners, as the market for server hardware is mature, highly competitive and saturated. Finalizing the business model there is limited room for 59

67 improvement, and it is advised to continue the current model. Possible extensions can be found in expanding the market and bundle deals. 7.4 Characteristics Legality The license types of the project are determined by the organization, changing the license at the stage of the open sourcing would be damaging to the relationship between organization and community fueling mistrust. The remaining 4% of proprietary software is advised to be either clearly documented, replaced or left out when installing (opt out) in case a user feel strongly about using products containing proprietary components in a product. From the case studies it is noted the license type BSD has an further increased chance on successfully attracting contributions confirming the choice of license of the organization. Document the proprietary software parts remaining in the product. Provide users the ability to opt-out of the proprietary components at installation Process Planning The organization and community are separated entities and the organization is in control of the product. However it is advised to provide the bare minimum of planning as public information, mainly including feature releases. Although some information is provided, more details about the following six months and current status of feature release could be made public. Other information includes current bugs under consideration of repair and when features will be shipping in development and release builds of the product, but are dependent of other sections of the organization for example a bug tracker. The control remains within the organization, but incorporation of the community is advised as it can further increase the thrust and activity within the community. Providing information regarding future plans will allow potential users to make decisions to use the product or not, by not informing customers about certain features customers might opt for the competition rather then the product as there is uncertainty. The transition to the agile working method allows the organization to publish parts of its backlog, todo lists, sprint and train planning. Provide planning details to the community. Create a platform where the community and organization can discuss releases and its content Requirements The requirements of the product are analogous to the planning proposed in the previous section and although some level of transparency will be required by adapting processes to include discussion on the 60

68 mailing list. Most of the requirements planning will remain internal to the organization, since the organization determining the direction of the project. No further actions are advised on the point of requirements Coding The current structure for coding allows external contributors to contribute to the product. Components or sections to contribute to, starting point as a new contributor, how the code base is divided and starting jobs for contributors could provide the incentive for first time developers to join the project. The information to notion to people how to become maintainers and provide transparent information on the governance structure, including the current fact no external developers are allowed to have commit rights until further notice. Implementing a bug or defect tracker would provide a backlog for potential contributors and allow users to contribute their defects or confirm defects available at present. The basic information is in place but it is advised to be extended, catering to the community by providing starting guides, beginner projects and insight into the governance of the project. Provide first time developers with information on where and how to start contributing to the project. Publish governance structure to the public Testing Testing improves quality and as a result makes the product more appealing to contributors and users by increasing confidence and thrust in the product. The open sourcing of XenRT provides the community with the opportunity to test the product itself. It is advised to make a testing framework and documentation on how the organization is planning to test available. Testing is difficult outside of the organization and the testing software applies to the product as a whole. Future plans should be discussed and made available to the public regarding the process behind testing. Results of internal testing could be made public in order to keep the community aware and provide feedback. Implementing a process and standard for testing sections of code. Explain the testing process by providing documentation and information. Implement at testing framework foundation developers can reuse. Feedback to the community about the test results, on a individual basis Releasing Similar to planning, it is again advised in the releasing section to provide the community with releasing information. The inability to build the product can provide a hurdle for external contributors as there is no way to check if features or fixes are implemented correctly until the next development build is released. Releasing the product is an additional motivator for contributors, and shows the project is active. A release schedule should be established with set deadlines for future releases, preferred within a six month time frame between each release. 61

69 Provide planning details to the community, especially for the next release or six month period. For instance by publishing sprint and train plans. Switch to a six month community release schedule, separate from the commercial version. Start releasing a development version of the product on a daily basis Documentation Documentation proved a valuable step in the case study of Mozilla to attract more collaborators. Given the lack of development documentation it is key for the organization to start formulating guidelines on documentation, provide the community with the information available today and allow contributions on documentation. Development documentation includes but is not limited to code documentation, architecture and technology usage, building and testing documentation, cross-referencing documentation and change presentation systems. In the case of Wringer the importance of API and introduction tutorials are emphasized. Lastly documentation provided should be high quality, accurate and cover all aspects. Formulate guidelines regarding documentation. Provide a documentation development platform for both the organization and the community to commonly contribute to documentation. Increase documentation of code, architecture and technology usage. Provide how to s and tutorials for users, focusing on both product usage and API Maintenance Problem solving processes include the triaging of bugs, where systematic steps are followed to track down defects once they are able to reproduce the defect. Making the process publicly available is advised as external developers are able to investigate and resolve there own defects. The organization offers hot fix patches for mayor defects to the product including but not limited to compromised security and reliability. The distinction between developer and user support is left to judgement of individual employees of the organization. The goal is to provide developers with all the information to develop, but user questions regarding problems in the operations of the product need to be diverted to the support division. Lastly it is advised to provide the community with a tool to be able to provide support to each other. A decision will have to be made between the forums, currently acting as a support mechanics, a dedicated user mailing list or a new solution. Publicize internal bug triaging process. Provide a clear guidelines and documentation for both developers and users, and explicit explanation of non-support and support questions. Decide on the support infrastructure for both users and developers. 62

70 7.4.3 Deployment The goal of the product is to provide an easy to use, out of the box experience of the Xen Hypervisor product. Deployment for users is straight forward and requires little knowledge of the product itself, and thus the deployment is no concern. As the product is designed to be a single binary file, the deployment and robustness of components and libraries used within the product are harder to deploy and less user friendly. In the scenario where the product is separated into modules the deployment of modules will become the deployment method for (external) developers to test their work. It is advised to take the reliability and deployment of the modules into consideration when moving forward with the seperation. Improved component and library reliability and deployment in the same process as the separation of the product in modules Infrastructure Bug Tracker The organization intends to introduce a bug tracker, however at the time of writing there is none available. It is advised to move forward with the implementation of the bug tracker as it provides a gateway for potential contributors and users to contribute to the project. Simultaneously with the implementation a workflow is needed to ensure external people can submit bugs and internal people will need to verify and ensure the bug is a general bug and not to the specific use case of the user. Additional workflow is needed to ensure bug reports are not mis-used by external users to get free support. Implement a bug tracker, preferably the same software as used internally. Implement workflows for external bug tracking submissions Mailing lists The mailing lists are available, used and are the main communication between organization and community. The process of adopting the mailing list are not integrated internally by the organization, partly as the internal tools are familiar and considered to work convenient. The solution would include mirrored discussions where internal tools are used in combination with the mailing lists. Integrate the mailing lists in current work flows Forums The current forum solution, targeted at the users of the product, is not intended for development questions and focuses on users of the product. Development questions are to be redirected to the mailing lists. 63

71 The forum is provided by the commercial organization rather then the community website, and the separate accounts might slow down community support growth. Additionally the support questions provide a difficult situation for employees as selling commercial support is the main income. Providing support to developers is currently not integrated in the process of employees, resulting in inactivity, un-answered posts and frustrated users. Integrate forum into the work flow of employees of the organization and the community. Decide to include or exclude forums from the community. Inform the community about the proposed workflows regarding the forums Website The website is considered an important part of the infrastructure of an OS project. The current community website provides a portal for the community and is one of the important sales channels of the organization. Advised improvement are the execution of delivery and content. Improvements to the website include a redesign of the front page to encompass an information overview of the entire project. Additionally the website should see continues improvements based on monitoring usage, A/B testing, eye tracking and more metrics. Improve delivery and content of the website. Redesign of the front-page to provide an overview of all the available information of the project. Integrate all available knowledge on the product on the website providing a community hub Documentation Infrastructure As user documentation is offered to the public through the parent organization website, a remainder of the proprietary version, no feedback or additions are possible. Setting up wikis for the products project will remove confusing around the XCP and other past projects and allow users to contribute back to the community. Provide infrastructure for the community to contribute to the existing and new documentation. Remove confusion surrounding information of the product on other wikis Version Control System The source code is available to the public though a version controlled website, Github, allowing anyone to view the code base of the project. Although differences exist between the teams internally, externally a single choice is made regarding version control removing the need for direct improvements. Some of the teams within the organization are not using the Github workflow, but remain with the internal workflow. The current mirroring of the repositories does not show up as activity in those repositories appear inactive. A goal would be to slowly transition the teams towards a transparent development model, however the 64

72 model does not have to be the flow of Github. The transition to a modular code base sections all sub projects allowing each team to remain independent regarding work flows. Show progress and activity of all the teams independent of workflow Build infrastructure The build infrastructure is internal only due to the composition of the product. The organization is transitioning to an alternative strategy to allow external contributors to directly build and test modified products. Publicize documentation and information regarding the build process and daily development builds Software Architecture Literature favors modularity in product architecture when the code base allows it, as modularity allows for distinct separation between components or modules. In the scenario of OS a distinct separation can allow the modules to become sub communities, making it easier to attract outside contributions as the barrier to entry is lower due to less and more specific source code. The benefits also facilitate to internal developers by easier maintainable code and more accessible for new employees. It is advised to modularize the product, the organization is working on implementing a modular architecture as the code base foundation for the product. Another factor brought up in literature is the extendability of the software by means of plugins. Currently the product can be extend by using the product API, however extending the product has been deemed difficult by external developers as the documentation is limited and almost no code examples exist. A way to start attracting external contributors, create value for the product and promote the product would be to increase the amount of documentation, how to s and code examples so the community can extend upon the product driving traffic, attention and activity. Providing documentation of the architecture, e.g. high level component diagrams, is advised to be implemented to increase accessibility and appeal to contributors. In combination with the architecture documentation the upcoming changes planned for the project could be included, e.g. including upstream versions of libraries and replacing custom solutions by other OS projects. Modularize the architecture to form separate projects. Provide documentation on the architecture and the future proposed plans. Include the community in the architectural decisions. Provide documentation, how to s and code examples on how to extend upon the product. 65

73 Code Removal of unused code and replacement of existing custom libraries for upstream libraries will increase accessibility for potential contributors as well as reduce the maintenance burden on the developers of the project. The code base of the project does lack documentation, the organization should provide the code base with high level comments and encourage beginning external contributors or internal developers to start commenting the lower level functions with pre-conditions, post-conditions and statements as a learning exercise benefiting both the community and organization. Adhering to OS standards by the project should help to increase innovation, credibility and contributions. Provide initial comment standards and high level comments. Include adding documentation as one of the entry level work items for potential contributors and newly started employees. Examine the possibilities of including OS standards in the project Community Contributions The contributions by external developers are dependent on a large amount of factors mentioned in the previous sections, such as code magnitude, architecture and organization support to the community. The organization will remain in control and contributions are processed by an internal developer before being integrated in the product Roles, responsibilities and Ownership Roles and responsibilities are covered by the internal employees, and until a community starts to develop there is no need to extend upon the idea. A system of seniority based on contributions should be implemented once external developers start contributing, and more important documentation on the process of increasing their own role and responsibility should be available to the public. Adopt a governance structure. Provide information to the the public regarding the governance structure Governance Similar to the roles, responsibilities and ownership the control and governance remains with the organization. The organization should adopt a governance structure best suited to the needs of the organization and communicate the governance model to the community. 66

74 7.4.7 Marketing Marketing is focusing on the generation of leads for sales, similar to before the transition to OS with the change of some minor details. A shift towards attracting contributors once other infrastructure such as documentation are in place would be a positive addition as literature stresses the importance of promotion. Not only should marketing target contributors but also target other organizations as involvement could generate highly valuable payed employee contributors. A large chunk of marketing is actually the state of the community and resources available such as documentation mentioned in the previous sections. Marketing focus on the community and attracting contributors and organizations. 7.5 Summary The results found in the previous characteristics sections are summarized into different areas in the following. The areas identified are categorized into information, documentation, software, infrastructure, processes, decisions, website and integration. The main areas focus on transparency, documentation, project activity, community nurturing and growth and metrics Information Transparency can create thrust, commitment and understanding from the community for the organization. Publicize architecture and short term release planning, the publications allows external developers and users to see the direction of the product and make decisions based on official planning and engage in conversation about the planning. Publicizing processes include bug triaging, forum process, testing process and the support process in order for external parties to participate with and understand the organization. Additional processes include the build process, strategy and daily development builds and governance structure. The developers will need guidelines regarding code conventions and documentation and feedback regarding the internal testing in the organization. The product offering legacy requires attention in the form of formulating of the current scenario and updating external sources with the information. A dedicated section for first time community members should be constructed on how to start, what to start on, guidelines to read, etc. Finally the support process of the organization will require explanation in order to prevent discontent, as well as the proprietary components of the product Documentation The documentation currently available is limited and requires extending. Documentation is a collaborate effort between both the organization and the community, however the organization is advised to implement a platform to make collaboration possible. Once a platform is implemented documentation of code, 67

75 architecture, technology and external libraries should be added. The existing user documentation should also be added to the new platform, including how to s and tutorials on how to use the product. Development documentation surrounding the API, including code examples, are needed to allow external parties to build extensions on top op the product Software Software encompasses the changes advised to the code base and to be developed code. The first modification is the installation process, which should include an opt-out feature for the proprietary components, allowing users to operate a complete OS software. The advantages of a modularized product are discussed and the product should move to a modularized product to form sub communities. In the process of the modularization individual components will need to become separate projects usable outside of the main product, reliable, testable, resilient to different environments and maintainable. Not directed linked to the code of the product but related the development the development of a general purpose testing framework and/or guidelines on how to implement testing Infrastructure In order to enable the organization and community to interact and work infrastructure is needed to facilitate. The infrastructure will require a platform for the community and organization to discuss releases and architectural planning or alternatively develop a workflow to integrate both in existing infrastructure. To accommodate the documentation it is advised to setup the wikis. Similar to support the ability to submit and view bugs it is advised to setup a bug tracker. Finally it is important all the different components of the project remain active and the project remains alive Processes Processes include the implementation of new process, standards and guidelines or the adjustment of existing. The results include the implementation of processes and guidelines for testing, documentation and bug tracking submissions. Integrate the mailing lists and forum in the current workflows. Choose and introduce a governance structure. Provide a clear release process for planning and releasing (community) versions of the product. Make a daily build available to the public and include it in the current workflow. Lastly the introduction of standards for coding and commenting. The marketing process will need to adapt to incorporate and embrace the community by targeting community growth by attracting external people and organization to the project Decisions The organization will have to make a decision regarding the forums, keep them in the current form, change the location to the community website, stop the support for the forums or remove them and for all options 68

76 inform the community accordingly. As well as the support infrastructure and possibility of using open standards in the project Website The website is an important hub for the community and sales. It is advised to redesign the front-page to encompass an overview of the project, improve the content, integrate all available knowledge and improve the delivery Integration Integration between the organization and the community allows the formation of thrust and commitment from external parties. Allowing external users and contributors to have input on the planning, requirements, architectural decisions and community decisions might lead to new insights for the organization and provides an insight into the wishes of, a subgroup of, the users of the product. The organization will ultimately remain in control of the organization and can make the final decision Metrics In order to understand the status of the community it is advised to keep metrics of the status of the community. By tracking metrics on different aspects of the project, as listed in 3.2, the active areas of the community become visible for the community and organization. The metrics are important in order to verify the succes of open sourcing and be able to communicate quantitative data to the external community and internal organization. 69

77 8. Transition In the previous two chapters the situation at the organization was examined, defined (Chapter 6) and assessed (Chapter 7) resulting in an overview of improvement areas for the organization. The proposed solutions, advices, suggestions and remarks are combined to provide the organization with advice and suggestions regarding the implementation steps in the transition to an OS project. The proposed solution is then discussed on feasibility, considerations and possible alternative solutions. 8.1 Introduction In order for the organization to succeed in achieving its goal, the following chapter proposes a process for the implementation of the improvement areas as suggested in the previous chapters. The focus area is the community aspect of the open sourcing, as its argued the characteristics benefiting of an OS project are founded on its community. Analyzing the organization on the OS characteristics revealed the areas of improvement are the community, infrastructure, process and software. Considering the current stage of the organization, regarding the transition to OS, it is at the inception. The focus, considering the stage, is on the development of a healthy active community ecosystem. Derived improvements focus on quality, extendability and usability of the product. Practically resulting in focusing on the key aspects Transparency, Documentation, Software, Infrastructure, Processes, Decisions, Website, Integration and Metrics. Decisions made during the development of the process are based on the priority of the suggestions, which are weighted in accordance to the formation of an OS project. Growth will generally start by attracting users which grow in the project by contributing bug reports, bug fixes, process enhancements, documentation, how to s and tutorials, feature requests, feature contributions and ultimately maintainers of specific components. Alternatively users can contribute by developing third party applications as extension of the product or writing on their experiences with the product. 8.2 Process The process for further transitioning towards an OS project is segmented into three phases. The phases are segmented into three as dependencies require sequential execution of the actions required in the phases. An illustration of the process is represented in Figure 8.1, followed by an explanation. The sections following the current section explain each action in more detail. 70

78 Phase I Phase II Phase III Decisions Documentation Website Infrastructure Processes Information Collaboration Product Metrics Figure 8.1: Transition process divided in phases and actions. The first phase includes decisions, infrastructure, product and metrics. The objective of the first step is making decisions regarding the target project, governance structure and infrastructure before continuation is possible. Second is the implementation of the infrastructure to support the community and allow documentation and information to be shared. Simultaneously product enhancements can start as the implementation timeframe is long, furthermore the metrics gathering of the community is suggested to be implemented as the more historical data is available the more accurate the community status can be tracked. Between the first and second phase implementation of processes and information can initiate. Decisions and gathering can start without the completion of phase one, and initial information is publishable on the website. Once the first phase is complete the outcome decisions can be translated in publications and updating of the internal processes. The second phase entails providing the first batch of documentation to the community, placed on the implemented infrastructure. It allows for collaboration to begin between organization and users and potential community members. Ideally the collaboration phase can begin earlier however it requires the joining of external users and contributors. The final phase concludes with modifications to the website in order to represent the new status the project has achieved by performing the previous stages and to further foster growth of the community. 71

79 8.2.1 Decisions During the analysis phase a number of decions are identified. For the implementation of some of the proposed changes it is necessary to decide on the implementation before execution is possible. An overview of the most important decisions is listed below. Priority is given to the selection of a target project which allows consequential questions to be answered based on the target project and parent project. Target project - In order to resolve decisions it is suggested to search and select another OS project with characteristics matching the values and goals of the organization. Decisions for the project can be based on the implementation and choices made by the target project. Xen API - The Xen API component of the product is different from other components as it is part of the organization, but due to previous open sourcing efforts is also part of another OS project (Xen Hypervisor). The organization will need to decide if the information and documentation of the component is either provided by the organization and its project or the Xen Hypervisor project. The decision will clarify the role of the component and the team within the project and organization and could provide a role model for other teams on how to become an independent OS project. Discussion Platform - A discussion platform allows interaction between the community and organization regarding releases and planning. Existing infrastructure, e.g. the mailing lists or IRC, could be used to reduce the resources required for implementation. Forums - Forums provide interaction for both users and developers amongst each other and with the organization. Supporting the forum requires resources and therefor the decision to support the forums is needed. Additionally the forums are currently hosted at the parent organization and not on the community hub, the question remains if the organization should move the forums under the community website. It is advised to start actively supporting the forum and move the forum to the community website. Standards - Standards allow interoperability between the project and other OS project. Standards implemented are suggested to follow the standards available on the target project and the parent Xen Hypervisor project. Governance structure The governance structure entails the different roles within the community, how to community operates, who can contribute, how contributions are evaluated, who decided when they are integrated in an release. Suggested is to look at both the target project and the parent project to evaluate the governance structure the organization wants to implement. 72

80 8.2.2 Documentation Documentation provides information on the product, and is a collaborative effort between the organization and the community Publish Documentation required includes, but is not limited to, providing tutorials and guides for users and developers of both product and the API, architectural and technology usage, documentation of the extendibility of the product and provide a list of items of starting projects for potential contributors and new employees Implementation The first step is to create a list of all documentation items available and unavailable. Assess the priority of different documentation to determine priority as providing documentation is a continues effort. Second is gathering the existing documentation available. The third step is to transform the documentation into the format of the wiki platform. If there is no documentation available internally new documentation will need to be written in the format of the wiki. Finally the documentation will need to be published. Alternatively the documentation list itself can be made an starting point for users considering contributing to the project and allowing them to request documentation. The documentation of code will require a different approach, after determining the target community a comment guideline can be established. From the newly established guidelines developers are to be encouraged to start adding documentation to the code as they work on it and the guidelines should be published for external contributions. Tutorials, how to and guides on different sections of the product are advised to be deployed on the wiki. Depending on the decision about the API documentation will need to be integrated or shared between both Xen Hypervisor and the project. Code comments are to placed directly in the code itself in repositories of the organization Information Information is internal available knowledge which is suggested to be shared with the community to create thrust, understanding, transparency and integration Publish Information to be published are the planning and releasing schedules and contents, explanation of the build process in combination with the daily development build explanation, the governance structure of the project, the architecture of the project and future plans, the testing process, bug triaging process, the distinction between paid support and support, the proprietary components of the product, processes regarding the forum and product information regarding historic product offering. 73

81 Implementation The majority of the information is available internally, but decisions prevent information from being published. It is advised to use the wiki platform for the majority of the information. In addition to the wiki the web site is advised to provide a mirror, or short explanation including a link to the wiki, containing the latest version of the information. The architecture documentation should contain visual high level representation for improved understanding of components and interoperability, including the external libraries Product Product entails modifications related to the product software. In order to become an attractive project for contributors modifications to the software are required. Product recommendation includes the modifications listed beneath. Provide users the ability to opt-out of the proprietary components during the installation process of the product. Provide a testing framework starters-kit to aid developers and contributors. Modularize the architecture of the product into separate independent modules. Improve independent module reliability and deployment. The installation process code base requires modification to include an opt-out feature during the installation process. Each team is suggested to develop a testing framework and provide the documentation and an implementation examples internally and to the community. The final implementation is a complete redesign of the product, starting from the architects who will need to design the new architecture. The integration with other OS libraries during the design phase is recommended. The design can be discussed with the community, and the changes required will need to be scheduled for execution by the different teams. Finally each component of the design should be a self reliant module, capable of forming its own sub-community with domain experts Infrastructure Supporting the development and processes of the community and organization is the infrastructure consisting of third party software. Infrastructure enables the integration between the community and organization by providing mutual platforms for communication and collaboration. In need of attention are the followin. The infrastructure requires the implementation of documentation platform and a bug tracker. Public code repositories are advised to be mirrored continuously with internal repositories. Choice of bug tracker and documentation platform software is advised to be identical to the internal software at the organization. After the choice of software has been made deployment on a hosting solution is 74

82 required, with the ability to access the infrastructure outside the organization. Update the content of the infrastructure to be up to date with the known content within the organization. Mirroring of the different repositories will require development of automation between internal and external tools Processes Integration and transition towards an OS project requires changes to the processes in use in the organization. A itemized list of suggested changes to the processes can be found below. Developing and implementation of testing procedures for sections of project code. Develop procedures regarding documentation and comments of the product. Develop, integrate and publish external bug report submissions procedures. Develop daily development builds of a unsupported development version of the product. Release cycle of a community version of the product to a minimum of one per six months. Integrate the usage of mailing lists and forums in the internal workflows. Integrate the chosen governance structure within the organization. Develop and integrate tools to gather metrics regarding the community. Implementation of the process requires a different approach for each individual modification, and execution lies within the organization. For guidance on the choice of procedures for testing, documentation, comments and bug reporting the chosen governance, target project and parent project are suggested. Updating to a daily nightly release and general release cycle of the product requires modifications to the infrastructure and internal procedures. Integrating the mailing lists and governance structure will require informing the employees, allow feedback and conversation to construct an accepted governance and work on merging the new processes with the existing Website The central information hub of the OS project is the community web site. Allowing users, contributors, developers, organizations to find the means to interact. Required modifications to the website are listed below. Redesign of the front-page to provide an overview of all the available information of the project. Improve content and delivery of the web site. Integrate all available knowledge on the product on the web site, acting a community hub. Contract an external organization to develop a redesign of the community website. Together with the external organization and the community it is advised to set up requirements and gather all information the website will need to contain. It is recommend to look at OS solutions for the content management system. Starting with the existing web site today it is advised to integrate all available information and 75

83 documentation. Moreover the integration with the wikis to direct people to information subjects under continuous change Collaboration Collaboration between organization and community enables thrust and commitment from external contributors. Integrate community and organizational procedures with regards to planning procedures. Integrate community with architectural decisions procedures. Although similar to the processes it is important to integrate the community and the organization to start becoming an collaboration. Planning and architectural planning are suggested to start discussing the contents on the mailing list and wiki, depending on the preferences and current procedures in planning and architectural Metrics Metrics allow the organization and community to monitor the health and status of the community over time. Suggested is the implementation metric software similar to the software found at the target project and parent project. It is suggested to keep at least the metrics as presented in the community watchdog phase of the OSCOMM framework in table Discussion In the proposed proces a number of implementation decisions are made, without further explanation. In the follow section the decision are explained and elaborated in more detail. The decision to advice wikis is based on the collaboration offered between organization and the community. Additionally using similar software as the existing internal wikis will make the transition easier for the content and its users. Wikis enable the exchange of information and access rights are a core component. The usage of wikis also allows historical versions to be revisited, providing archive functionality. Lastly, the wikis provide a single source of information reducing the amount of infrastructure types required. Implementation of the product modifications including architecting and refactoring of the code base, which will require large resource commitments. However the restructuring is not only beneficial for community growth and the creation of separate sub-communities, the restructuring allows for depreciation of technical debt, improve readability and stability, reduction of the learning curve for new employees and easier identification of bugs. Integration with other libraries will provide the potential for additional features as they are implemented by contributors of the third party libraries. Project infrastructure is the gateway for the community to interact with the project, and is of vital importance to the health of the community. Without infrastructure there is no possibility for a community to 76

84 form and no interaction is possible. The decision to implement a bug tracker, rather then using for instance mailing lists for bug reports, is based around the information of the case study where the internal tools are found to be effective, blocking integration with the mailing lists. The advice to use the same software as used internally is based on the same reasoning, and will allow easy migration. Mirroring of internal and external code repositories is important to attract users and developers and keeping the project active. Hiring an external organization to help develop the community website will require significant investments from the organization. However the project has competition of other OS projects and needs to present the project professionally, convincing potential users and convert users into paying customers. 77

85 9. Results As the commercial organization Citrix R&D transitions towards an OS project guidance, redirections and resource investments are continuously required. In the study performed the current situation at the organization is assessed, reviewed and analyzed against existing literature on OS projects, open sourcing closed source software and case studies of other organizations. Resulting in a recommendation and a implementation process the organization can follow in order to ultimately achieve its goals and become a successful OS project. Transitioning a product from proprietary to OS is a process unique to the organization executing the transition. Variables influencing transition include organizational motivation, product market, product need, employees, organization culture and current workflows, etcetera and the results are unique to the case of Citrix R&D. A illustration of the historical, current and presented future state of the organization in the light of the governance can be found below in Image 9.1. Cathedral Style Bazaar Style Start Current Target Proprietary Software Sponsored Open Source Traditional Closed Source Progressive Open Source Inner Source Controlled Source Industry- Led Open Source Industry- Involved Open Source Foundation Open Source Traditional Open Source Community Open Source Restricted Governance Open Governance Figure 9.1: Transition process of the organization. The following chapter discussed the key findings of the study, coverage of pre-set goals of the organization and finally, validation of sections of the research. 9.1 Key Findings In order to understand the key finding the starting point is the goal of the study. The goal of the study is divided in sub-questions, each treated in the key findings section. The goal of the research is to provide Citrix R&D with a process advice to transition XenServer from proprietary to an OS project, from its current state, with the achievement of the pre-set objectives. 78

86 In order to explain the findings of the goal, the findings are divided in accordance to the sub questions. The sub questions, presented in chapter 4.6, are each provided with a summary of the key findings and reference to the chapters going in more detail. Based on the state of the art in OS literature what are the characteristics of OS projects relevant for the XenServer case? The characteristics, based on the state-of-art literature, are discussed in chapter 5.1. The characteristics are legality, process, infrastructure, software, community and marketing. Two additions are presented and discussed, the motivation of an organization determines the success factors, and the business models has implications on interaction between organization and community as well as the legality. The characteristics reoccur as guidance throughout the document. Characteristics are applied in the state of the art literature, chapter, the case studies of historical transitions to OS, chapter 5.3, the Citrix case study, chapter 6.3, and lastly during the analysis phase, chapter 7.4. It is found the characteristics as presented by Aksulu and Wade reoccur in other literature studies and present a usable foundation for the segmentation of key areas of OS projects. However the characteristics as used in the study of Aksulu and Wade are limited by the predefined scope of attaining a healthy ecosystem. A healthy ecosystem is not all encompassing as motivations for the transition to OS, as the research presented here proves. It is therefor found the inclusion of motivation to the model allows for other goals than a healthy ecosystem. In addition it is argued the use of business model as another key characteristic if considering a commercial organization. The business model has an impact on the implementation of the remaining characteristics and in the case of a commercial organization is considered the most important variable as it is the source of income and revenue. 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 R&D, in historical transitions to OS? In order to understand the implementations leading to succes both a state-of-art literature review on OS projects, chapter 5, and case studies of historical OS transitions, chapter 5.3. The case studies from Mozilla, Trolltech, Bekk Consulting, Linpro, ez Systems, Gurux, Wringer and Symbian are examined on the characteristics found in the previous question. Both positive and negative lessons learned are extracted and used in the analysis in chapter 7. Key findings include the limited amount of case studies available, making the search for identical organizations impossible, but enough transitional studies where found to continue the research. It is found success is derived from the synergy between organization and community. Most factors influencing succes within OS projects are based purely on the state of the community. Consequently transparency from the organization towards the community, collaboration and activity in the project are important to 79

87 have a sustaining vibrant community. What is the current state of the open sourcing, based on the proposed characteristics in the first question, of Citrix R&D? By performing a case study in the organization through semi structured interviews, meetings, water cooler conversations, observations, discussions and lists, internal documentation and presentations the current state of the different characteristics. The results of the case study can be found in chapter 6. In addition to the characteristics of the current state the future, businessmodel and strategy are discussed resulting in an complete overview of the organization. Currently the organization is still in the initial phases of the transition and although the business model and license are defined the other characteristics still need to be addressed. The decision of the timing of the organization to OS is considered early and in retrospect some more preparation and resource allocation would have helped the initial growth of the community. It is important for the organization to continuously work on the open sourcing of its product and start focusing on the community growth as an important metric for the success of the project. What characteristics of the framework need to be improved for Citrix R&D in order to achieve the pre-set goals? Analyzing the case study found in chapter 6 against the chapters 5 and 5.3 to determine the areas in need of improvement. Resulting in an list of improvements per characteristic and sub characteristic of the current state of the project at the organization. Improvement areas are itemized in a list. Transparency - Share, publicize and integrate with the OS community. Information - Provide information to the community. Documentation - Documentation to support the community and internal developers. Software - Modifications to the product. Infrastructure - Support software and infrastructure for the organization and community. Processes - Integrate the transition changes in existing processes. Decisions - Make decisions about the kind of community the organization wants. Web site - The central hub between organization and community. Integration - Integration between the organization and the community. Metrics - Continuously gather and monitor the state of the community. The findings for the improvements focus on the integration of the organization with the OS community. How does the process of transition from commercial to OS, based on the previous three inputs, be 80

88 executed at Citrix R&D? In the final phase of the study the analysis of the organization is used to construct a process for the organization in chapter 8. The process are the steps found in chapter 7 applied to the organization. An overview of the process can be found in Figure 8.1. The key findings include the increase of transparency of information, providing documentation, improve product, infrastructure and website and update internal procedures. Finally the collaboration between organization and community needs to be improved and metrics are required to judge the success of the organization. To recap from the main goal to provide a process for the transition to OS it is clear the organization still requires to invest large amounts of resources to sustain the community. The resource demand will remain for the coming years as the growth of the community is a continues process. Currently the organization has done nothing more then publish the code to OS repositories, started granting collaboration from external parties, updated their business model and change the technical licenses. The results from the research indicate more effort is needed in the growth and creation of an OS community, as the community is the key to the ultimate goal, larger market share. Going forward from the current advice the idea is the community should be something of high importance to the organization and not something which might or might not happen. 9.2 Organizational goals The goals of the organization extend beyond the question surrounding the market share. In order to evaluate the study conducted has solved, or at least covered, each individual goal of the organization, each of the goals is covered separately in the following overview. Market share - The process presented in the previous section is specifically targeted at an increase in market share. It is argued benefits of OS are linked to the community, in order to then become a successful OS project the community is highly important. The process proposed is engineered to provide the optimal growth for the community in order to indirectly grow the market share of the organization. Collaboration and marketing - Focusing on the community by the organization, adopting OS standards and governance will allow other OS project to easily collaborate with the project. In addition showing the OS ecosystem the organization is actively working on the open sourcing of the project allows for more easy integration with other libraries. Creating an content community will promote itself with positive marketing. Product offering - The product offering is solved by the open sourcing itself, however it suggested to inform the external world about the product offering and remove any existing confusion by increasing transparancy. 81

89 Monitization - Analyzing the business model of the organization it is not advised to change the strategy. The growth of users can hopefully be converted into paying customers. The conversion has been left out of the scope of the study. Technical debt - Modularizing and replacing existing libraries as suggested in the results will greatly reduce the technical debt of the project. 9.3 Research goals In the problem statement chapter of the research the limited research into the field of commercial products transitioning to OS is addressed. The goal of the research next to providing the organization with a process to transition to OS is to contribute to the field of FLOSS. From the research it becomes clear more research is required in the areas of open sourcing, especially in the area of case studies. Additionally it became apparent the transition to OS is a unique process different for each organization. Organizations considering the transition to OS should be aware of the high resource requirements needed to transition an entire organization into a new strategy. Simply making the code base publicly available under an OS license and leave it can have disastrous results for the product and organization. 9.4 Validation The case study, conducted only at the organization, might have compromised the validity of the view of the organization. Although the data of the case study is validated by the organization itself, the data is gathered from a single source. It is not impossible the data suffers from tunnel vision or a shared perception only available in the organization and not outside of the organization. Additionally the opinions of stakeholders is subjective to time, resulting in data only found at the specific time of interview. However, even if considering the compromised validity, the results and advised process are based on multiple sources from literature. Similar to the single source case study are the characteristics found in the state of the art literature. The amount of literature available is limited and the characteristics might have limited the analysis of the organization leaving some parts of the open sourcing uncovered. Although the current analysis already uncovered areas of improvements for the organization it could be possible some are overlooked. However the current advice is based on the knowledge available at the time of writing, and does not account for all the changes required in the future. The results are heavily based on literature both OS projects and in particular the practical case studies. The case studies used are all historical information describing open sourcing of a product. However each open sourcing is unique, target different markets, different in complexity, different organizational culture, etcetera and the data might not always contain the best advice for the organization. 82

90 The validation of the research itself might be biased by the researcher as the analysis, case study and result are all designed and conducted by the same single person. Although supervisors validate the research there is no validation of domain experts in OS validating the research. 83

91 10. Conclusion In the study a process suggestion of transition from proprietary to OS is provided for the commercial organization Citrix R&D. The study entails the definition of OS project characteristics based on related work on transition to OS and meta-studies into OS. The characteristics are segmented in sub characteristics based on existing OS literature. A meta-study is conducted based on OS research and case studies of products transitioning to OS to analyze the Citrix R&D case study. The main contribution is the case study as conducted at Citrix R&D of the product XenServer based off the OS characteristics. Including an assessment of the current state of the project providing the data retrieved from literature. Finally a process is proposed to the organization to further increase transparency and build a community to drive the objective, market share. In the study change management and strategic change although present are not covered as the research field is outside the scope and domain of the study. It has become clear the organization will need to focus on the collaboration and growth of the community surrounding their product. In addition the research indicates transitioning to OS requires continues investments of resources and heavily impact the organizational structure. The research presented allowed the process which took place at the organization to become transparant and accessible for each organization considering to transition their product to OS. In the research it has become evident the community is the most important aspect of any OS project. Even for the organization looking to increase market share the community is very important to achieve the goal. Resulting in the fact, although each case of an organization transitioning to OS is unique, the main focus point for organizations needs to be the community. Additionally transitioning to OS impacts the very core of the organization requiring cultural changes and new or update processes for almost any employee Discussion The initial draw back of the analysis of the case study is the length associated with the case study. The case study is conducted during a six month period of three months before and three months after the open sourcing. Results of the study are based on the data gathered, and result therefor do not represent the process entirely. The analysis conducted is based and therefor limited by the data provided from the literature study. Although five case studies are used to extract data, it is still a limited sub set of information. In the meta study of Crowston et al. a reason for the lack of data is adhered to the desire for commercial organization to keep information internal. The general results of the study are based on a single study at the organization Citrix R&D, the data, although gathered using multiple methods and from multiple source are still derived from a single source. The results reflect the vision of the source and are there for hard to generalize. 84

92 Elaborating upon the singularity of the case study is the uniqueness of any product going from proprietary to OS. Commercial organizations and their products are unique and there for the result of the analysis and assessment of the characteristics will be different for every organization. For a organization looking to transition a product from proprietary to OS the study is input but the process should be done similar to the research of the unique case to result in a useful guide for the organization. The OS characteristics chosen have determined the study, however the characteristics are limited by the limited related works. In the study it is shown the characteristics can be a guide, but as the characteristics do not have a clearly defined scope the results are depended on the execution of the study Further Research Continuing from the study it is clear further research is needed, and the first proposed study is the revisitation of the organization after a time period of a year. The limited timeframe to execute the case study, results might take years to materialize as wel as execute. In short it is to soon to tell if the proposed results have the desired effects. Secondly, the transition to OS is as much a problem with people as it is on the technical side. The study conducted has taken the perspective of an engineer. However the field of change management might have a solution for the internal processes changes requires as the organization pivots towards an entirely different strategy. Thirdly the provided solution is unique to the case of Citrix R&D and although the method and case study can be useful for other organization preparing for open sourcing it is still limited. A more general proposed process, conducted before the open sourcing, and not during as in the case of the study, would provide great improvements to the field. Finally, availability of case studies and literature on open sourcing is both limited and could require extension by performing additional studies on the open sourcing of closed / proprietary products. 85

93 11. References [1] Agerfalk, P. and Fitzgerald, B. (2008). Outsourcing to an unknown workforce: exploring opensourcing as a global sourcing strategy. MIS quarterly, 32(2): [2] Aksulu, A. and Wade, M. (2010). A Comprehensive Review and Synthesis of Open Source Research. Journal of the Association for Information Systems, 11(11): [3] Alexy, O., Henkel, J., and Wallin, M. W. (2013). From closed to open: Job role changes, individual predispositions, and the adoption of commercial open source software development. Research Policy, 42(8): [4] Asay, M. (2010). Symbian : A Lesson on the Wrong Way to Use Open Source. [5] Baldwin, C. Y. and Clark, K. B. (2006). The Architecture of Participation: Does Code Architecture Mitigate Free Riding in the Open Source Development Model? Management Science, 52(7): [6] Bonaccorsi, A. and Rossi, C. (2006). Entry Strategies Under Competing Standards : Hybrid Business Models in the Open Source Software Industry. 52(7): [7] Capiluppi, A., Stol, K., and Boldyreff, C. (2012). Exploring the role of commercial stakeholders in open source software evolution. In Open Source Systems: Long-Term Sustainability, pages [8] Capra, E. and Wasserman, A. (2008). A framework for evaluating managerial styles in open source projects. In Open Source Development, Communities and Quality., chapter A framewor, pages I edition. [9] Citrix (2013). Citrix Systems Inc, Annual report, FORM 10-K, volume 15. [10] Conley, C. and Sproull, L. (2009). Easier said than done: an empirical investigation of software design and quality in open source software development. ystem Sciences, HICSS nd Hawaii International Conference on, pages [11] Craig-Wood, K. (2013). Open source as the secure alternative: a case study. Computer Fraud & Security, (May 2011): [12] Crowston, K., Howison, J., and Annabi, H. (2006). Information systems success in free and open source software development: theory and measures. Software Process: Improvement and Practice, 11(2): [13] Crowston, K., Wei, K., Howison, J., and Wiggins, A. (2012). Free/Libre open-source software development. ACM Computing Surveys, 44(2):1 35. [14] DiBona, Chris Ockman, S. (1999). Voices from the Open Source Revolution. [15] Dinkelacker, J., Garg, P., Miller, R., and Nelson, D. (2002). Progressive open source. Proceedings of the 24th International Conference on Software Engineering, 94303(650): [16] Eide, T. E. (2007). Study of the Release Process of Open Source Software. PhD thesis. [17] Feller, J. and Fitzgerald, B. (2000). A framework analysis of the open source software development paradigm. In ICIS 00 Proceedings of the twenty first international conference on Information systems, pages 86

94 [18] Fitzgerald, B. (2006). The Transformation of Open Source Software. Mis Quarterly, 30(3): [19] Fogel, K. (2005). Producing open source software: How to run a successful free software project. [20] Fuggetta, A. (2003). Open source software an evaluation. Journal of Systems and Software, 66(1): [21] Goldman, R. and Gabriel, R. (2005). Innovation happens elsewhere open source as business strategy. Morgan Kaufmann, Amsterdam; Boston. [22] Guzzi, A., Bacchelli, A., Lanza, M., Pinzger, M., and van Deursen, A. (2013). Communication in open source software development mailing lists. In The 10th Working Conference on Mining Software Repositories, pages [23] Haselhoff, F. (1977). A new paradigm for the study of organizational goals. From Strategic Planning to Strategic Management, pages [24] Hecker, F. (1999). Setting up shop: the business of Open-Source software. Software, IEEE, (February 1999): [25] Hofmann, G. and Riehle, D. (2013). A Dual Model of Open Source License Growth. In Proceedings of the 9th International Conference on Open Source Systems (OSS 2013), pages [26] Kilamo, T., Hammouda, I., Mikkonen, T., and Aaltonen, T. (2012). From proprietary to open sourceâăť- Growing an open source ecosystem. Journal of Systems and Software, 85(7): [27] King, R. (2008). Cost Conscious Companies Turn to Open Source Software. [28] Krogh, G. V. and Hippel, E. V. (2006). The promise of research on open source software. Management Science, 52(7): [29] Kumar, V., Gordon, B. R., and Srinivasan, K. (2011). Competitive Strategy for Open Source Software. Marketing Science, 30(6): [30] Lerner, J. and Tirole, J. (2001). The open source movement: Key research questions. European Economic Review, 45(4-6): [31] Lerner, J. and Tirole, J. (2003). Some Simple Economics of Open Source. The Journal of Industrial Economics, 50(2): [32] Lerner, J. and Tirole, J. (2005). The Scope of Open Source Licensing. Journal of Law, Economics, and Organization, 21(1): [33] Lindman, J., Rossi, M., and Puustell, A. (2011). Matching Open Source Software Licenses with Corresponding Business Models. IEEE Software, 28(4): [34] Lundell, B. and Forssten, B. (2009). Exploring health within OSS ecosystems. In Proceedings of the First International Workshop on Building Sustainable Open Source Communities, number 2006, pages 1 5. [35] MacCormack, A., Rusnak, J., and Baldwin, C. Y. (2006). Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. Management Science, 52(7): [36] Mockus, A., Fielding, R. T., and Herbsleb, J. D. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology, 11(3): [37] Nakakoji, K. and Yamamoto, Y. (2002). Evolution patterns of open-source software systems and com- 87

95 munities. In IWPSE 02 Proceedings of the International Workshop on Principles of Software Evolution, number January 2001, pages [38] Nambisan, S. and Wilemon, D. (2000). Software development and new product development: potentials for cross-domain knowledge sharing. IEEE Transactions on Engineering Management, 47(2): [39] Niederman, F. and Davis, A. (2006). A research agenda for studying open source I: a multi-level framework. Communications of the Association for Information Systems, 18(7):2 39. [40] Norris, J. (2004). Mission-critical development with open source software: Lessons learned. Software, IEEE. [41] NorthBridge (2012). The Future Of Open Source. [42] O Mahony, S. (2003). Guarding the commons: how community managed software projects protect their work. Research Policy, 32(7): [43] Raymond, E. (1999). The cathedral and the bazaar. Knowledge, Technology & Policy, pages [44] Riehle, D. (2007). The Economic Motivation of Open Source Software Stakeholder. IEEE Computer Society, (April): [45] Riehle, D. (2009). The Commercial Open Source Business Model. In Proceedings of the Fifteenth Americas Conference on Information Systems (AMCIS 2009). [46] Riehle, D. (2010). The single-vendor commercial open course business model. Information Systems and e-business Management, 10(1):5 17. [47] Riehle, D. and Berschneider, S. (2012). A Model of Open Source Developer Foundations. In Open Source Systems: Long-Term Sustainability, chapter A Model of, pages [48] Rossi, M. (2004). Decoding the" free/open Source (F/OSS) Software Puzzle", a Survey of Theoretical and Empirical Contributions. [49] Scacchi, W. (2004). Free and open source development practices in the game community. Software, IEEE, 21(1): [50] Scacchi, W., Feller, J., Fitzgerald, B., Hissam, S., and Lakhani, K. (2006). Understanding Free/Open Source Software Development Processes. Software Process: Improvement and Practice, 11(2): [51] Shah, F., Hammouda, I., and Aaltonen, T. (2009). Open source engineering of proprietary software: the role of community practices. In Proceedings of the OSCOMM 2009 First International Workshop on Building Sustainable Open Source Communities. [52] Sirkkala, P., Aaltonen, T., and Hammouda, I. (2009). Opening industrial software: planting an onion. In Open Source Ecosystems: Diverse Communities Interacting, chapter Opening In, pages [53] Stewart, K. (2005). A preliminary analysis of the influences of licensing and organizational sponsorship on success in open source projects. In System Sciences, HICSS 05. Proceedings of the 38th Annual Hawaii International Conference on Jan. 2005, volume 00, pages [54] Stol, K.-J., Babar, M. A., Avgeriou, P., and Fitzgerald, B. (2011). A comparative study of challenges in integrating Open Source Software and Inner Source Software. Information and Software Technology, 53(12): [55] Vass, B. (2007). Migrating to open source: Have no fear. In Proceedings of the 3rd DoD Open Conference: 88

96 Deployment of Open Technologies and Architectures within Military Systems. [56] von Krogh, G. and Spaeth, S. (2007). The open source software phenomenon: Characteristics that promote research. The Journal of Strategic Information Systems, 16(3): [57] Wasserman, A. I. (2013). Community and Commercial Strategies in Open Source Software. (January). [58] Wasserman, T. (2009). Building a business on open source software. [59] Watson, R. T., Boudreau, M.-C., York, P. T., Greiner, M. E., and Wynn, D. (2008). The business of open source. Communications of the ACM, 51(4): [60] Wilson, R. (2012). The Mozilla Public License V An Overview. 89

97 Appendices 90

98 Glossary API An application programming interface (API) specifies how software components should interact with each other. The API allows programmers to use predefined functions to interact with a system instead of writing them from scratch.. 38, 62, 68, 73, 96, 99 binary A computer file containing machine-readable information that must be read by an application and is unreadable for humans. 5, 6 changelog A document, often found in software projects, containing the changes of the project given a release.. 50 Citrix Citrix Systems, Inc.. 1, 15 17, 22, 53, 94, Citrix R&D Citrix Research and Development. vi, 1 3, 15 23, 25, 46, 47, 58, 78 81, 84, 85, Cloud Cloud computing is a general term for anything that involves delivering hosted services over the Internet. In science, cloud computing is a synonym for distributed computing over a network and means the ability to run a program on many connected computers at the same time. More commonly it is used to refer to network based services which appear to be provided by real server hardware, but which in fact are served up by virtual hardware, simulated by software running on one or more real machines.. 95 copyleft "Copyleft uses copyright law, but flips it over to serve the opposite of its usual purpose: instead of a means of privatizing software, it becomes a means of keeping software free" DiBona, Chris Ockman. Copyleft allows the same activities as copyright, but is intended to restrict proprietary appropriation. Works derived from software licensed under copyleft cannot be made proprietary, dissimilar to software in the public domain. [42].. 30 COSS Commercial Open Source Software. 6 derivative works Derivative work is work based upon one or more preexisting works.. 30 dogfooding Dogfooding, or eating your own dog food, is a term used within software developing organizations to indicate the organization is using its own product internally.. 43 EULA A contract between the licensor and purchaser, establishing the purchaser s right to use the software.. 48, 49 91

99 FLOSS Free Libre Open Source Software. 1, 2, 5, 15, 20, 24, 28, 32 forking To fork a project or forking is to copy or clone the entire code base of a project and apply your own changes on top of it.. 37, 59 freemium A business model whereby a, often digital, product version is offered for free and a payed version offeres additional features. The name freemium is a combination between free and premium describing the two product versions.. 48 Github GitHub is a web-based hosting service for software development projects that use the Git revision control system , 54, 64, 65 Hypervisor A Hypervisor, in computer science terms, is a piece of computer software, firmware or hardware that creates and runs virtual machines.. 95 IaaS Infrastructure as a Service. 95 ISO An ISO image is a computer file that is an exact replica of an existing file system. In the context of the research the ISO is used to describe the CD-ROM buyers of the product received after purchase of the product.. 57 license compatibility License compatibility entails the ability of different licensed software to be combined into a new piece of software only if the requirements of such licenses allow it.. 30 Loss Leader A product sold below its market costs to drive sales of other products. Examples are inkjet printers, that drive cartridge sales, and game consoles, that drive videogame sales.. 28 NDA Non-disclosure agreement. 98 openwashing Having an appearance of open-source and open-licensing for marketing purposes, while continuing proprietary practices.. 59, 98 OS Open Source. vi, 1 9, 11 16, 19, 20, 22, 24, 26, 32, 35 44, 47, 58, 70, 72, 74, 75, 77 84, 96 OSS Open Source Software. 1, 2, 5, 6, 15, 32 OSSD Open Source Software Development. 12, 32 personal itch A common reason for a developer to join or start an open source project is to satisfy a need of his/her own need.. 6, 28 POR Practical Oriented Research. 23 POS Progressive Open Source. 5, 8 92

100 readme A readme file is commonly distributed with computer software and contains information about other files in a directory. The typical content includes but is not limited to: configuration instructions, installation instructions, operating instructions, list of files, copyright and licensing, contact information, known bugs, troubleshooting, credits, change log and news.. 38 SaaS Software as a Service. 29, 35 Scrum Scrum is an iterative, incremental framework for project management often seen in agile software development, a type of software engineering. Its focus is on a strategy based on flexibility, comprehensiveness and unity as opposed to traditional sequential approach. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication among all team members and disciplines in the project.. 37 TOR Theory-Oriented Research. 23 Type 1 Hypervisor Type 1 (or native, bare metal) hypervisors run directly on the host s hardware to control the hardware and to manage guest operating systems.. 95 Upstream Upstream are software projects, or packages, that feed into a larger collection.. 19, 46, 98 VM Virtual Machine. 95 XenRT Xen Regression Tests. 51, 61 XenServer XenServer. 1, 15 17, 19 21, 24, 25, 46 48, 52, 53, 78, 84, 94, 95, 97 99,

101 A. Organization description The following section gives an introduction into Citrix, its subdivision Citrix Research and Development Cambridge (Citrix R&D) and the products Xen Hypervisor and XenServer. The goal is to provide contextual information about the organization, the products developed by the organization and historical and strategic decisions made by the organization. 1.1 Citrix Research and Development Citrix R&D is a department of Citrix, a global supplier in cloud computing that enables mobile work styles 1. Citrix was founded in 1989, went public on the Nasdaq in 1995 and in it s current form a company with 8,212 employees, and a turnover of 2,586 billion dollar over the fiscal year of 2012 [9]. It s global goal is: Empowering people to work and collaborate from anywhere, accessing apps and data on any of the latest devices, as easily as they would in their own office - simply and secure. To accomplish it s goal Citrix offers a large range of products, divided into six categories 2. The Build cloud infrastructure category includes XenServer the product in development by Citrix R&D a sub department of Citrix. Citrix R&D emerged from the acquisition of XenSource Inc (XS) by Citrix in XS was founded in 2003 and commercialized the open source project Xen Hypervisor under development by the organization. The business model consisted of offering commercial products developed on the foundation of Xen Hypervisor. The first product to be sold was Xen Enterprise 3, based of Xen Hypervisor 3.0, and XenServer is the modern day itteration. Citrix R&D is located in Cambridge, UK and consists of roughly 100 employees. Citrix R&D currently develops XenDesktop and XenServer, still based on the open source project of Xen Hypervisor. Xen Hypervisor, an open source linux foundation project as of recent, is partly being developed by members of the Xen Platform Team within Citrix R&D. The Citrix R&D location is focused on development of their products and does not include marketing, sales or accounting departments. Citrix R&D consists of management, engineering and supportive teams. Management consisting of Product Management, includes both product development and product marketing and team managers for each engineering team. The management teams develop long term road maps for the product and manages the execution. Specific projects, falling outside the scope of management, are handled by the Project Management team. The seven engineering teams: Ring3, Ring0, Storage, Performance, Windows Drivers, Testing and XenCenter develop features, fix bugs and continuously test the additions to the XenServer product. In addition to the engineering teams XenServer consists of support and managing teams to help the engineering teams achieve their goals: Development Operations, Documentation and Human Resources. 1 Based on - accessed on The complete offering can be found at - accessed on

102 1.2 XenServer XenServer is the product developed by Citrix R&D, and is the product transitioning from proprietary to open source. To provide a contextual background on the product the following section describes both the Xen Hypervisor as well as the XenServer product. Xen Hypervisor is the foundation of XenServer, and in essence XenServer is a proprietary extension of Xen Hypervisor Xen Hypervisor Product Xen Hypervisor or any Hypervisor enables the hardware resources of a computer to be virtualized and dynamically partitioned to allow multiple different guest machines to be run simultaneously. Each of the machines can run any operating system images almost completely independent of one and another. As example Xen Hypervisor allows a servers resources to be divided into multiple smaller containers each container or Virtual Machine (VM) running a operating systems such as Windows or Linux. Xen Hypervisor is the only Type 1 Hypervisor that is available as open source 3. To manage the different containers or domains a control domain is used, called dom0 (domain 0). The applications of Xen Hypervisor can be found in different commercial and open source applications, such as: Server virtualization, Infrastructure as a Service (IaaS), Desktop virtualization, Security applications, embedded and hardware appliances. Virtualized (Hypervisor) Non- virtualized Dom0 DomU DomU (Control) (OS) (OS) XEN Hypervisor Operating System (OS) Hardware Hardware Figure A.1: Graphical depiction of a Hypervisor Strategy Although Xen Hypervisor wasn t the first virtualization platform from the start, it was the first open source virtualization platform. Today it is in active development for more than 10 year and is running as the main backend of the Cloud, powering providers such as Amazon AWS and Rackspace Public Cloud. At the moment of writing Xen Hypervisor has been accepted into the Linux Foundation, allowing it to gain back it s 3 accessed on

103 vendor neutral status, away from Citrix. Organizations joining the Advisory Board, pledging support in the form of financial or time investments, are among the top of the industry in areas of hardware and silicon (AMD, Cisco, Intel, Samsung), products (Oracle, Citrix) or are large scale consumers (Amazon, Google, Verizon Terremark). With the transition to the linux foundation all the governance and tooling implemented are compliant to linux foundation requirements. Xen Hypervisor is becoming a community based foundation OS project coming from Sponsored Industry-Led OS. The main reason for moving the project to a foundation is to increase the popularity and implementation of the project and getting the right governance and structure in place to grow the product XenServer Product Based on Xen Hypervisor, XenServer is an extension with the goal to provide managing layer to its users. Making it convenient to manage the virtual machines running on top of Xen Hypervisor, allowing customers to easily integrate, manage and automate a virtual datacenter. In order to support a multitude of industry standard hardware products a single linux distribution, Linux CentOS 4, is used to provide a stable foundation for the product, Xen Hypervisor can be used on any linux distribution. Further enhancements include an API to provide easy access to functionality, enterprise storage and network solution integration, orchestration application (XenCenter - Allowing the end user to control their virtual machines from a single windows application), Microsoft Windows Drivers (To allow Microsoft Windows to run as a virtual operating system) and a multitude of additional features. XenServer, before transitioning to open source, is a commercial product with four different tiers: Free, Advanced, Enterprise and Platinum. Where each version offers more features than the version before and all had support divided in tiers. In addition to the Free version a open source version called Xen Cloud Platform (XCP) with a mixture of features from both free and some of the payed options was released in Interrelated The product of Citrix R&D, XenServer, is not only a stand alone product, but also used within Citrix as a foundation for other Citrix products. The Citrix products including XenServer account for the majority of turnover of XenServer. Citrix places strategic value in the ownership of XenServer because of the interrelation in current and future products. Given the relationship, the importance of control by ownership is a strategic advantage for Citrix and a switch to third party replacement is highly unfavorable. Additionally, since XenServer is also a stand alone product, it is, in theory, financially self sustaining as opposed to a single cost factor CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. 96

104 Market XenServer is primarily focused on enterprise customers interested in virtualizing their data centers without having to deal with the hypervisor itself and the maintenance and overhead associated. In addition XenServer is used by Citrix internally as foundation for products as XenDesktop and NetScaler. XenDesktop runs virtualized Microsoft Windows (or Linux) instances in similar way of the old main frame. Another product is Netscaler, which is a cloud network platform. Next to internal customers other typical enterprise customers can be found in the cloud hosting platforms but also large telecom vendors, supermarkets, etc. Competitors include VMWare, Microsoft (Hyper-V), KVM, Red Hat and Oracle. Based on the report of 2011 XenServer has 8% marketshare making it the third largest commercial virtualization product behind Windows Hyper-V (25,7%) and market leader VMWare (55,6%) Strategy Historical In recent years the market share of XenServer is under pressure due to increasing competition and perception of the product from the market. The initial responds, in 2009, of Citrix R&D to the introduction of the open source hypervisor (KVM), was a first attempt at open sourcing XenServer. The execution resulted in parts of XenServer becoming open source projects as well as providing customers with an open source edition with similar features to the free version of XenServer. However the limited amount of resources allocated meant that the endeavor did not have the intended effect and added additional workloads on the teams within Citrix R&D. In conclusion the market share remains a problem for the organization Open sourcing The main overarching problem of Citrix is defined as the loss of market share. The previous attempt at open sourcing did not have the desired effect and Citrix R&D is still looking to increase its relevance in the market. The strategy has shifted to transitioning the entire XenServer product from a proprietary to an open source project. Open sourcing as strategy can increase market share by increasing the accessibility of the project and remove barriers of usage due to the zero price tag. Coincidently, if a community is formed around the product, quality improves, new features will be introduces and niche solutions get build on top of XenServer. Although market share can be increased in a variety of methods, open sourcing is, given the historical background, the additional goals, such as integration with upstream open source projects and increasing collaboration with partners, a strategical choice with high potential. In addition the public announcement of the open sourcing implies the strategy, at this moment in time, is irreversible, as failure to execute will 5 Based on IDC study of virtualization market share i d = 39 - accessed on

105 lead to a damaged reputation of XenServer most likely resulting in a negative impact on the market share. The subsequent challenge is a successful open sourcing of thexenserver product and prevent the open sourcing to turn in to openwashing Goals In order to regain market share the strategic decions is made at end of 2012, to move XenServer to open source. The primary goal to regain traction on the market, however market share is not the singular objective of Citrix R&D and an overview of the goals of Citrix R&D are listed below. Market share - The main goal of Citrix is to expand the market share of Citrix R&D. In the past years competitors have managed to either regain or expand market share where XenServer has seen it s market share drop. Collaboration - Citrix R&D has a number of partnerships with other industry organizations in order to improve compatibility or offer unique solutions. Conventionally jointly working on the XenServer code base required the partner organization to sign a Non-disclosure agreement (NDA), consuming time and resource for both parties to set-up, evaluate and finally sign documents. By moving to open source the code base is open to anyone and working on the XenServer code base no longer requires NDA procedures. Product offering - Before moving to open source Citrix R&D offered a tiered product range. Starting from a free version of the product, a open source version (XCP), and three payed tiers: advanced, enterprise and platinum. Product offering confused customers and internal departments outside the direct circle of development of XenServer. Moving to open source could allow product offering simplification. Monitization - Xen Hypervisor is used more extensively then XenServer in the market. In a scenario where XenServer is also open source, organizations should more easily choose for the XenServer product as opposed to the more bare Xen Hypervisor product. Upgrading to XenServer now becomes less expensive as there are no longer licensing fees. Resulting, at least that is the prognoses, in a large user base of open source XenServer, opening the door to a paid support license from Citrix R&D. Marketing - With the transition to open source Citrix is also creating a more open image to the market. Goals are the improvement in the relation with Upstream projects and code inclusions. As open source project it is more easy to collaborate with other open source projects than an proprietary project with an open source project. Technical debt - Internally XenServer uses a large number of packages originating from other open source projects. These packages where taken from their repository at the time of integration, but the changes where never upstreamed back to the projects. Resulting in a maintenance burden on 98

106 software also under development by a dedicated open source community. The transition is hoped to allow for easy reintegration with these existing open source projects and after the technical debt is cleared remain in sync with the open source projects. 1.4 Teams Citrix R&D is the development department of XenServer and consists of seven engineering and five support teams. The seven engineering teams are: ring3, ring0, storage, performance, windows drivers, testing and XenCenter. In addition to the engineering teams XenServer consists of support and managing teams: product management (includes both product development and product marketing), project management, development operations, management and documentation. Each of the team is discusses briefly in the following list. Ring3 - Responsible for the API layer of XenServer. The API is a combination of binding to lower level features and offering additional functionality by implementing logic on top of lower level features. The API layer is also used for the command line tool used to manage XenServer from the terminal. Ring0 - Responsible for the linux kernel used in XenServer. Responsible for the lower levels of Xen Hypervisor as used in XenServer. Storage - The storage team works on support for enterprise grade storage solutions, additional specific storage features, etc. Performance - Work on the entire product to increase the performance of the product (e.g. increase number of virtual cpu s that can be supported). Windows Drivers - Work on enabling Microsoft Windows products by providing driver support for XenServer in Microsoft Windows solutions. XenCenter - The XenCenter developers work on the graphical interface for administering XenServer. Testing - The Testing engineers work on the tools used to test and debug the XenServer product. Product Management - Includes both product development and product marketing departments and concern themselves with product lifecycle. Determine which features will be included into next release, planning and execution of planning. Project Management - Manage specific projects that are assigned to team members of different engineering teams. Development Operations - Provide the infrastructure for the organization. The infrastructure contains maintaining the version control, build system, test infrastructure, bug trackers, wikis, intranet. 99

107 Management - Prioritize allocation of resources, communicate with other departments and higher up management, making sure each team member can function properly and focus on developing or fixing code, report and give feedback on team performance. Documentation - Document new features, release documentation, user guides, how to s, bug reports. 100

108 B. Release process Figure B.1 illustrates the different components of the XenServer product resulting in the ISO. Included is the process of the source code to final product given the build process. Distro s! Windows Update! External! Source! Binary! Binary! XenServer! Linux.git! xen.git! LF( LF( CentOS 6.4! Linux.rpm! *( Tech.(Preview( Bug support from Citrix! WHQL Test! Citrix! *.sys! xen PQ! xen-api.git! windows-driver.git! XenServer.git! XenCenter.git! Xen.rpm! Xapi.rpm! Glue/Tools! XenCenter! Release(Candidates( Main.iso( Free! Requires(non. free(rpms( qemu.git! PQ! qemu.rpm! On the web! xenserver.org! User focused! Closed!!! XCP XAPI (legacy)! *( LF( LF*( rpm( *( HA.hg! HA.rpm! Citrix build + published rpm! ^ hbad.rpm! ^ nvidiadriver! ^ No source! Binary from vendor! *( ) Citrix designed release schedule! Figure B.1: Release process given the source and binary components within the organization. 101