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

Harm Roelof Pieterss1537687 - h.r.pieters@student.rug.nl

March 25, 2014

Master thesis Industrial Engineering and ManagementFaculty of Mathematics and Natural Sciences

University of Groningen

Supervisorsprof. dr. ir. M. Aiello University of Groningendr. ir. I.ten Have, MBA University of GroningenM. McClurg Citrix Research and Development

Executive summaryOpen source is an indispensable part of the software industry, and is growing as an attractive and viable

strategic option for commercial exploitation. Organizations, with an existing proprietary product and the

desire to switch to an open source strategy, are required to undergo a transition profoundly impacting

the organization. The following document presents the study into the initial stages of the transition of

XenServer towards open source, conducted at Citrix Research and Development. In order to provide the

organization with a process on how to proceed with the open sourcing, given the organizational goals.

Research in the field of transitioning to open source is limited, and in order to gain insights existing

literature on open source projects is gathered. Resulting in a segmentation of transition projects in charac-

teristics, providing a segmented structure to the study. The characteristics are legality, community, process,infrastructure, software, community, marketing, business model and motivation. In addition to the literaturecase studies on historical transitions to open source and related work are gathered in order to analyse the

current state of the organization.

The analysis of the organization is conducted through a case study of the current state of the transition,

based on the characteristics and the existing literature and case studies. The result is an overview of im-

provement areas, most notably the community and its activity and growth. Further results suggest a moretransparent organization, providing information and documentation to the public. Maintain activity within

the existing community and implement infrastructure to facilitate bug tracking and documentation. Selec-

tion of an existing target community to act as role model, allowing amongst others the 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 Infrastruc-ture, in addition the adjustment of the internal processes and publicizinginformation is initiated. The secondphase consists of creation and publication ofdocumentation, the remainder of processes and informationand the first part of collaboration initiating between organization and community. Lastly, the final phaseincludes the website and the final section of collaboration. Product improvements and Metrics gatheringspan the three phases of the process, beginning at the first phase. The proposed process is the contribu-

tion 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 engi-neering, FLOSS.

ii

PrefaceThe document presented here is the result of my master thesis research for "Industrial Engineering and

Management - Information Engineering" conducted at Citrix Research and Development. In the preface I

would like to take the opportunity to thank the people who made my research possible. First I would like to

thank my supervisors, prof. dr. Marco Aiello, for taking me on as a student and providing me with support

throughout the research, and dr. ir. Ingrid ten Have for providing me with the opportunity of doing my

master thesis abroad at Citrix and the different insights and feedback.

Second I would like to thank Citrix Research and Development, and Andrew Halley for providing the

opportunity of performing my master thesis and giving initial directions. Special thanks goes out to Mike

McClurg for being my mentor throughout my period in Cambridge. During our weekly meetings you pro-

vided me with different perspective, discussions, interests and kept me sane during the process. Last, but

definitely not least, I would like to thank my parents for their unconditional support during the research

and my entire time as a student.

Harrie Pieters - March 2014

iii

Table of ContentsList of Tables viList of Figures vi1 Introduction 11.1 Citrix Research and Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 42.1 Proprietary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Related work 93.1 OSCOMM framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Open source strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Release Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Problem statement 154.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Goal & research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5 Conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6 Research sub-questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.7 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.8 Research process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Literature 265.1 Open source characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 State of the art on characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Citrix research and Development case study 466.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.4 Future organizational considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

iv

7 Analysis 587.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3 Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.4 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8 Transition 708.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.2 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9 Results 789.1 Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.2 Organizational goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

9.3 Research goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

10 Conclusion 8410.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10.2 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

11 References 86Appendices 90Glossary 91A Organization description 941.1 Citrix Research and Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

1.2 XenServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

1.3 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

1.4 Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

B Release process 101

v

List of Tables2.1 A Software Licensing Taxonomy [17, p. 60]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Release Readiness Rating (R3) Framework [26]. . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Community Watchdog Measurements [26]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Important Measures to Achieve Success [16][p. 55-65] . . . . . . . . . . . . . . . . . . . . . 13

5.1 Technological motivations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Economical motivations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3 Overview of most common used licenses is Open Source (OS). . . . . . . . . . . . . . . . . 31

List of Figures2.1 Continuum of governance in software projects [7, 15, 43, 54, 57]. . . . . . . . . . . . . . . . 4

3.1 Elements of OSS Community Building [52, p. 59]. . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 OSCOMM framework phases [26, p. 1470]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Conceptual Framework for Open Source Engineering [51, p. 4] . . . . . . . . . . . . . . . . 11

4.1 Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Regulatieve cyclus of Van Strien (Van Aken et al., p 13) . . . . . . . . . . . . . . . . . . . . . 23

4.3 Research process illustrated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Community building dimensions [26, p. 1468]. . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 License decision model [33, p. 34]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1 XenServer moving from a proprietary to sponsored OS. . . . . . . . . . . . . . . . . . . . . 47

7.1 Analysis process of the open sourcing at Citrix Research and Development (Citrix R&D). . . . 58

8.1 Transition process divided in phases and actions. . . . . . . . . . . . . . . . . . . . . . . . 71

9.1 Transition process of the organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

vi

1. IntroductionOpen source (OS) is everywhere. It is used to run smart phones (e.g. Android), servers (e.g. Linux, Apache,

MySQL), embedded devices (e.g. Java), browsers (e.g. Mozilla Firefox) and much more. As a result a ma-

jority of the worldwide organisations are now depending on some form of Open Source Software (OSS) for

mission critical processes, an example is the Mars Exploration Rover [40]. The adoption, in combination

with the current economical decline [27] and properties as flexibility, easy integration and security [11], is

pushing the embrace of open source over proprietary products in the market. Resulting in a fundamental

impact on the creation, distribution and use of software [8].

The phenomenon in the market does not appear to be slowing down, OSS is growing and as more OS

project emerge, commercial organisations are starting to increasingly commercialise open source projects.

The historic situation where OSS is exclusively developed by volunteers is no longer accurate. The initial

commercial paradox, how a commercial organisation can earn money when it is offering its products for

free [46], has been disproved by organizations creating viable business strategies such as RedHat, MySQL

and Canonical. Proving the commercial market for OS is maturing and it is becoming a strategic option

for any software business [1] leveraged as mechanism to disrupt an existing market with a strong market

leader, or by the market leader to increase it’s foothold [44].

1.1 Citrix Research and DevelopmentOS 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 artOpen 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

1XenServer 6.2 is open source (13/6/2013) - http://it.slashdot.org/story/13/06/30/0018211/xenserver-62-is-now-fully-open-source

1

found, though there is increasing commercialization, research into firm participation in OSS is low and

“additional research needs to be conducted to investigate how firm-involved FLOSS project differentiate

from non-firm-involved FLOSS projects” [12]. Open source as foundation for new strategy and businesses

have gained low amounts of research interest [26] because the trend to open source proprietary software

is relatively new [34]. Cases such as Java (Sun Microsystems) and Symbian (Nokia) do however demonstrate

the potential of open sourcing.

The amount of research into transitioning from proprietary to open source remains limited. The litera-

ture found so far is based on the single works of Kilamo et al., with the OSCOMMmodel for transitioning to

open source. Unfortunately, as the research is conducted by the same set of researchers, it is not possible

to verify the model as proposed and using it as given is added risk to the validation of the research. Further

research into strategies remains high level and do not include definitive solutions. The different character-

istics are based on the research of Kilamo et al. which are a starting point. The final variable missing in the

model of Kilamo et al. is the assumption the end goal is a vibrant ecosystem. In the case of the research at

Citrix R&D the goal is not a vibrant ecosystem alone but increased market share.

1.3 ProblemThe 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 ContributionThe main contribution of the research is the practical case where Citrix R&D is provided with a transition

process strategy advice. The research contributes toward the existing knowledge of transitioning closed

or proprietary software towards an open source project in the field of FLOSS. The theoretical part of the

research provides a meta-analysis on the state-of-art on open source governance, open source character-

istics, transition to open source and case studies conducted on the transition to open source. Secondly,

based on the OS characteristics found in literature, a case study of Citrix R&D is presented. The case study

is analyzed and evaluated against the existing use cases found in literature. Finally, based on the analysis

of the case study and literature, a model for the remaining open sourcing for Citrix R&D is suggested. The

methodology used in the study can provide inspiration to other commercial organizations contemplating

transiting one or more proprietary products to open source.

2

1.5 Document structureThe first section, chapter two and, contains a background discussion on the differentiation between propri-

etary and OS and related work on open sourcing of closed software. Chapter four discusses the problem

the research aims to address, the methodology used and steps taken in order to arrive at the results in

more detail. Chapter five provides information on the characteristics of open source, the state of are and

case studies. The third section includes chapter six, seven and eight. Chapter six is the diagnoses of the

case study, looking at Citrix R&D from the perspective of the characteristics found in chapter five. Chapter

seven takes the use case and evaluates the case with the literature study in order to define an strategy

presented in chapter eight for the organization to achieve their goals. The results of the research are pre-

sented in chapter nine, including key findings and validity. Lastly, chapter ten contains the conclusion of

the research, including discussion and further research.

3

2. BackgroundThe goal of the background section is to provide additional information on the definitions and disparities

between the terms: proprietary-, free-, libre- and open source (software). Both proprietary and OS are

open systems, if described from systems theory terminology. The systems inputs are people, technology

and processes and these three inputs produce again technology, people and products [38]. However pro-

prietary and OS can be conceptualized as being on opposing sides of the software development space [2].

Taking the perspective of governance, as done by Capiluppi et al., gives a similar overview of the continuum

of governance in software projects. The following figure, figure 2.1, is adapted from Capiluppi et al. and

additionally includes work from Dinkelacker et al., Stol et al., Wasserman, Raymond, and provides an state

of the art overview of all the different governance structures.

Restricted Governance

Proprietary Software

Inner Source

Controlled Source

Traditional Closed Source

Progressive Open Source

Open Governance

Sponsored Open Source

Industry-Led Open

Source

Industry-Involved

Open Source

Bazaar Style

Community Open Source

Traditional Open

Source

FoundationOpen

Source

Cathedral Style

Figure 2.1: Continuum of governance in software projects [7, 15, 43, 54, 57].

Figure 2.1 illustrates the difference between proprietary and OS governance which contains more than

two opposite sides. Project or products can reside on either side of the proprietary or open source spec-

trum. Proprietary has more open variants than traditional closed source, including using open source

practices internally. OS has many variants divided by sponsored OS, whereby a commercial organization is

involved, and community OS where the community makes the decisions. Each category is elaborated upon

in the remainder of the chapter, with the goal to provide the reader with enough background knowledge

on the differences between proprietary and OS.

4

2.1 ProprietaryThe 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 inten-tional similarities to processes and practices as found in OS. POS are organizations who use open source

processes and practices but only internally. Inner source, also referred to as Corporate Open Source is a sub-set 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 notonly 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 sourceIn general OSS, sometimes referred to as free software, is royalty free redistributed software, its source

code is released and available to anyone and any modification to the source are to be redistributed under

the same license terms as given in the original [30]. The OS systems purpose is not only technology output,

but as much emphases is put on people and products [2]. To get an idea of the size of OS the current

number of projects worldwide, as indexed by ohloh.net, exceeds 655.000 projects. Vass estimates, back in

2007, 800,000 programmers contributed to OSaround the world. Creating more than 100 billion lines of

code worth 10 million person years of work [41].

Free software is sometimes referred to as libre software to avoid the potential confusion between theintended 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

of free-, libre- and OSS research [13].

OS can be categorized in several ways, [8] and [46] base their categorization on their different con-

trol and ownership structures. Boiling down to two different types, Commercial OS or sponsoredOS andcommunity open source. Where industry-involved and industry-led projects are sponsored OSS projects, andindustry-involved and traditional projects are both forms of community open source.

2.2.1 Sponsored open sourceOS started as something done by volunteers, but increasingly commercial organizations are getting in-

volved [8]. Commercial Open Source Software (COSS), OSS used to develop private software, is a multi-

million dollar industry [29]. In a sponsored OSS project commercial stakeholders will contribute more thanvoluntary programmers [7] such as helping in the testing phase, report bugs, packaging, functional require-

ments, documentation, and marketing [21]. Industry-led OSS projects are led by a commercial firm. It ispossible 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 theproject 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-vendorcommercial OS in literature. Organizations have full control over the source, owning full copyright and in-

tellectual property, and build their business around it. As a result the organization does not accept outside

contributions often, and if they do accept them the contributor gives its code rights to the organization.

The organizations differ from tradition proprietary firms as not only the binary of their software but also

the code is available for free under a reciprocal license to drive adoption and simultaneously block possible

competitors [46].

With the involvement of commercial companies, it is found that OSS projects achieve sustained produc-

tivity, increasing amounts of output produced and intake of new developers. It is also found individual and

commercial contributions show similar stages: developer intake, learning effect, sustained contributions

and, finally, abandonment of the project. This preliminary evidence suggests that a major success factor

for OSS is the involvement of a commercial company, or more radically, when project management is in

hands of a commercial entity [7].

2.2.2 Community open sourceCommunity OS projects are owned and controlled by a community of stakeholders or a legal entity repre-

senting the community [8, 13]. Traditional OS projects are started by individuals, often to "scratch a personalitch" [43] and have no commercial involvement. Foundation-based OS can be compared to traditional con-sortia and when community projects get to a certain growth point the question becomes to create their

own foundation or join an existing one. Foundations generally have general predefined governing, infras-

tructure, distribution of software and foundation licensing in place. The legal representative of the projects

6

being the most important aspect of the foundation [47]. Funding for the foundation is often done by cor-

porations and other financial supporters. The funding and review process to join a foundation result in

the fact foundation-based OS are perceived as solid, credible projects which do not depend on individuals

[57, 47]. Popular examples of community OS projects are Linux, Apache web server and PostgreSQL. The

license of the project allows anyone to generate revenue from the project without consequences [8]. The

community members typically do not derive direct revenues from the software but subsidize it from com-

plementary products and services. In the past control is determined by ownership of copyright to the code

in the project, but today economically relevant projects see representation of non-profit foundations such

as the Apache Software foundation.

2.2.3 The cathedral and the bazaarIn one of the first works on OS Raymond discusses two fundamentally different development styles for

software, the cathedral and the bazaar. The cathedralmethod is based on the proprietary principles wheresoftware 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 systemand fetchmail OS projects, has almost the opposite approach, release early and often, delegating tasks and

transparent about each step of the process.

2.2.4 Software licensing taxonomyAnother perspective on the difference between proprietary and open, based on Feller and Fitzgerald, lists

software by its licensing.

Software type / License feature Zeroprice

Redistributable

Unlimited

usersa

ndusage

Source

codeavailable

Source

codem

odifiab

le

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

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 SummaryProprietary and OS are not black and white definitions but rather a spectrum of governance exists between

both traditional extremes. Proprietary is divided into traditional closed source and POS allowing for more

open source, referenced as inner and controller source, influence in a closed source environment. OS is

split into sponsored, whereby the commercial interest in projects are high, and community, which is driven

by volunteers and community stakeholders. Foundation OS is financed by commercial and non-profit orga-

nization and the projects are governed individually under the rules of the foundation. Finally, traditional OS

are independent projects under the supervision of volunteers devoting time to develop product. In the final

sections the differentiation of development styles, cathedral and bazaar, and licensing taxonomy, software

types and their features, are explained.

8

3. Related workIn related work research conducted in the field of the open sourcing of proprietary software is discussed.

Lundell and Forssten identified, given the recent trend for organizations to open source proprietary soft-

ware, the topic of open sourcing has seen little research interest. Kilamo et al. acknowledge the phe-

nomenon, and present a framework for building and sustaining an OS ecosystem, the OSCOMM Frame-

work. Before discussing the framework Kilamo et al. emphases the importance of the role of stakeholders

in the transition process. OS strategies as mentioned by Hecker and Alexy et al. are discussed and the chap-

ter finishes with the release process of OS software based on four case studies conducted in the research

of Eide.

3.1 OSCOMM frameworkDiscussion of the OSCOMM Framework is divided into two parts, the first discussing the impact of stake-

holders in the transition process and the second discussing the phases of the framework.

3.1.1 StakeholdersBefore 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

of the onion conservative stakeholders are closer to the edge. Other important stakeholders are existing

open source communities, as the new to be released product will join in the ecosystem. Finally the decision

has to be made what kind of community the commercial organization is looking for, either industry-led,

industry-involved or community based. A specific point of interest is the core of the onion and the decision

if this should be open or closed [26].

3.1.2 FrameworkThe 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), opensource engineering and community watchdog are discussed in the remainder of the current section.

Figure 3.2: OSCOMM framework phases [26, p. 1470].

3.1.3 Release readiness ratingIn 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 authoritySource 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

3.1.3.1 Open source engineeringThe 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

3.1.3.2 Community watchdogIn 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 SoftwareNumber of contributors Number of downloads

Number of subscriptions mailing list Number of reported bugs

Amount of requests Number of feature requests

Amount of feedback Derived projects

Amount of inquiries Number of contributions

Number of unique hits website

Number of hits in the media and blogs

Social media activity

Geographic distribution

Number of participants to events

Number of scientific publications

Number of job advertisements

Table 3.2: Community Watchdog Measurements [26].

3.2 Open source strategiesHecker 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, partsof the code base are shared with other products might require special licensing or modularizing. Third-partytechnology, dealing with third party technology by removing, replacing or gaining permission and the thirdparty could influence the type of license.Code sanitization, clean the comments. Export control, US basedlaws dealing with crypto and security code require adjustment before being approved. Product developmentprocesses, to achieve the benefits of OS it is vital to change the way the software is produced. Hecker alsoprovides some pointers regarding the development process: form a dedicated team, provide communityinfrastructure 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 hiringemployees with OSSD experience. Another suggestion is to practice OSSD by starting with progressive OSinternally before moving to open source.

12

3.3 Release ProcessEide conducted four case studies of Norwegian commercial organizations releasing OS and targets the

early stages of the release. The research focuses on rationale of commercial organizations open sourcing

software, measurements important before releasing to open source, impact of processes on the success

of the project and how to interact with open source community. The two main reasons of commercial

organizations to open source a product are creating a better product, when revenue cannot directly be

derived, and creating revenue [16].

3.3.1 Succes factorsEide lists a number of project success factors based on the conducted research, listed in Table 3.3, as

measurement points before open sourcing to understand the current state.

Project name The name should not infringe trademarks or be similar to other projects.

Working code The product should work properly, install and run easily and provide ba-

sic functionality.

Meet a demand Solve a problem for the community, and have a differentiator from other

projects.

Potential for succes The project should be active and provide promise to attract external de-

velopers to contribute.

Software architecture A modular, clean and structured code base adhering to open standards

and protocols and containing no license violations.

Documentation Provide accurate and good documentation.

License The choice of license determines the success of the project.

Table 3.3: Important Measures to Achieve Success [16][p. 55-65]

3.3.2 Impact of processes on successThe impact of processes on the success of the project are divided into technical infrastructure, importance

of a website and promotional activities. The technical infrastructure is project specific, but should contain

at least a mailinglist, mainly developer orientated, and/or a forum, more user oriented. Although bugs and

contributions can be done through both it is advised to use a revision control system and a bug tracker.

Eide concludes with the usage of wikis by open source projects and their ability to manage documentation.

Eide argues the project website functions as external interface to the community. Therefor it should

provide usability, well-functioning layout and design, created in layers and tested properly. During devel-

opment special attention should be applied to the search engine optimization. The content should relay

the information of the project such as license, description, benefits, road map showing the feature plans,

suggested improvements to the project and location of tools and documentation.

Lastly Eide emphasizes the importance of promotional activities for the project. Including promotion

during development gatherings, content on related sites, articles in the media, wikipedia articles, actively

13

engaging with the open source community, newsletters, paid advertisements and external effects.

3.3.3 CommunityIn the final section of the research Eide investigates the interaction of management between commercial

actors and OS communities. First the importance of interaction for attracting and sustaining a OS commu-

nity is deemed vital. Further activities should include web site updates as well as source code updates in

order to "proof" to the community the project is healthy and for contributors to see their contributions

being used. Commercial organizations tend to consider the community in their decision process, and the

accommodations and adaptations are divided into leadership, implementation, conflicts and credits [16].

3.4 SummaryThe 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

4. Problem statementThe 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 DefinitionThe open sourcing is the chosen solution, by Citrix, in order to increase market share of XenServer. The

consequent problem, arising within Citrix R&D, is the follow up, the execution of the transition to open

source. Although the high level end state is defined as an OS project by Citrix, the details and implementa-

tion are mostly unknown and finding the 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 tomuch

or do to little resulting in mixed messaging both internally and externally.

In addition to the business perspective there is the academic relevance. Open sourcing is part of the

field of FLOSS research, providing academic background to the phenomenon of OSS. In a recent study by

Crowston et al. into the state-of-art of FLOSS development it is found, although there is increasing commer-

cialization research into firm participation in OSS is low and “additional research needs to be conducted

to investigate how firm-involved FLOSS project differentiate from non-firm-involved FLOSS projects” [12].

Open source as foundation for new strategy and businesses have gained low amounts of research interest

[26] because the trend to open source proprietary software is relatively new [34]. Cases such as Java (Sun

Microsystems) and Symbian (Nokia) do however demonstrate the potential of open sourcing. Recapitula-

tory the study will not only provide valuable insights for the organization but also for the academical field.

Limited literature regarding transition from proprietary to open source in combination with a lack ofinternal resources is preventing Citrix R&D to have the optimal possibility at achieving their pre-set goals.

15

4.2 Problem AnalysisThe first step in the analysis and validation of the problem is to determine if the problem is a reality problem,

an actual problem, rather than a perceived problem by the organization. In the case of the problem at Citrix

R&D the decrease of market share and increase of competition are facts, as found in market analysis of the

past years. In order to remain relevant in the market and be able to remain self supportive financially the

succes of the open sourcing is a realistic problem. Consequently successfully moving to open source to

regain this market share is a realistic problem for the organization. Failure to succeed will result in the

overarching problem to remain or worsen, and therefore succes in open sourcing is required in order to

succeed in regaining market share in the current scenario.

Based on a realistic problem the next step is to determine if the problem is an functional or instrumental

problem. A functional problem is a problem related to the properties of the output of the system whereas

a instrumental problem is a problem related to the properties of the system itself. The research deals with

a functional problem, first and foremost the problem of the loss in marketshare is a functional problem

as it is an output of the system. Second is the achievement of the success of the open sourcing, directly

correlated to the market share, where as the success of the open sourcing is a functional problem of the

transition, but simultaneously the characteristics of the open sourcing are instrumental to the system.

Since the problem is defined as a functional problem it is now possible to determine the validity of the

problem by the triptych of Haselhoff that defines three requirements to an organizational output: effec-

tive (technical-economic system), efficient (open system) and meaningful (social system) [23]. According to

Haselhoff a functional problem is only validated once it can be identified and linked to one of the require-

ments. In the case of Citrix the problem is the reducing market share and therefor how successful the open

sourcing will turn out in relation to market share. Since the metric is the success of open sourcing this prob-

lem can be classified as a effective requirement, validating the status as a functional 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.

4.2.1 Socio-technical aspectsThe interrelatedness of both social and technical aspects of the problem indicate a socio-technical problem.

OS is about people, processes, source code and infrastructure, and requires a mindset or culture change

throughout the organization. The people involved, from the different departments within Citrix R&D, are

affected by the transition to OS as it has a fundamental impact on their daily work routine. From a business

perspective the organization is switching business strategy, impacting both internal and external stakehold-

ers. Finally the technical aspects of the open sourcing are the hard and software infrastructure changes

required to facilitate open source code and foster the growth of a community surrounding XenServer.

16

4.2.2 System definitionUsing 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 productand 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.

4.2.3 Problem OwnersThe 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 ofengineering (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 areproduct 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 anddetermination 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 StakeholdersIn 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 andmainly work

17

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 internalarchitecture 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 maintainingthe 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 iscontinuously 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 documentationteam. 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 projectmanagers 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 totranslate features from project management into work items for the teams. Impact from open sourc-

ing is minimal as themanagement 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

External Stakeholders• Marketing Department - The marketing department is responsible for marketing the product ofXenServer. As external stakeholder they have to change the way they market XenServer as an OSproject 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 revisedas 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 theXenServer product and have worked on the code base before. Although the open sourcing allows foreasy 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 be-come free. This will have have a different impact on customers as for some nothing will change,

some might want to go for the OS and don’t pay, others see it as the abandoning of the product by

Citrix. They are however of importance because eventually the customers determine the financial

success of XenServer• OS Communities - The existing communities consist of people and companies investing in the OSprojects. There are a number of communities affected by the open sourcing of XenServer the existingXen Hypervisor and XCP communities and Upstream projects. Although the OS communities arepositive regarding the announcement of the open sourcing they do remain skeptical regarding the

execution of the open sourcing and the level of implementation.

The stakeholders analysis reveals no mayor conflict between departments or internal teams and the major-

ity of stakeholders agree the limited resources constrain the department in the potential to successfully OS

XenServer. Additional goals are increasing collaboration between partners and the reduction of technical

debt in XenServer.

4.4 Goal & research questionThe 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

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 proprietaryto 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 theexisting state-of-art literature of OS, case studies of transitions to OS and the XenServer case?

4.5 Conceptual modelRecapitulatory to the related work the research will require expanding the knowledge of the characteristics

to provide a validated foundation for the research. In order to achieve the need for knowledge the first

phase of the research will require a literature study into the characteristics to clarify and further expand

the characteristics based on state-of-art literature on OS. The research will not only include a practical case

but also provide theoretical knowledge to the research towards transitioning a product from proprietary to

OS.

The conceptual model, based on the literature, problem and goal, is a diagram to represent the relation-

ship between the different sub-questions of the research. In Figure 4.1 the conceptual model is illustrated,

the numbers, within the blue circles, indicate the relationship with the research sub-questions.

20

Process

Infrastructure

Software

Marketing

Legality

Community

Opensourcing XenServer

Process

Infrastructure

Software

Marketing

Legality

Community

OpensourceProject

1

3

5

4

2

Literature Citrix R&D

Market ShareProduct

Price

Sales

Marketing

Governance

Market

Variabels

+

+

+

+/-

Figure 4.1: Conceptual Model

Literature - The starting point of the research are the characteristics of a project making the transition toOS. 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 beused 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 andargues 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

4.6 Research sub-questionsThe research question are decomposed into a number of sub-questions as covered in the following sec-

tion. Each sub-question is also represented in the conceptual model, Illustrated as blue circle (Figure: 4.1),

through the corresponding number.

1. Based on the state-of-art in OS literature what are the characteristics of open source projects relevant forthe XenServer case?

2. For each of the characteristics, found in the previous question, what are implementation which have led tosuccess, achieve similar goals as the goals of Citrix, in existing transitions to open source?

In this first section the goal is to define the characteristics, based on state-of-art literature, resulting in the

foundation of the process. It will be based on the existing concepts around open source projects and the el-

ements are essentially characteristics of open source projects. Initial research pointed towards the research

of Kilamo et al. however it is the only research into transitioning and leaves room for further research into

characteristics. The second question is to determine the relation between the different characteristics and

the organizational goals.

3. What is the current state of the open sourcing, based on the proposed characteristics in the first question,of XenServer?

4. What characteristics of the process can be improved for XenServer in order to achieve the pre-set goals?Questions are related to the case-study of XenServer, and will evaluate, for each of the characteristics of theprocess, 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, bemodeled 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

4.7 MethodologyThe research is defined as Practical Oriented Research (POR) at the organization Citrix R&D. Coinciding with

the use of empirical data and considering decisions regarding internal structure are required the choice

has been made to use the regulative cycle, illustrated in Figure 4.2, as methodological background for the

research.

Problem Set

Problemchoice

Diagnoses(analyse)

Plan(design)

Implementation

Evaluation

Figure 4.2: Regulatieve cyclus of Van Strien (Van Aken et al., p 13) .

The initial two phases of the cyclus start with a set of problems from the organizations, Citrix R&D, and end

with the definition of the problem as can be found in the previous chapter. The third phase, diagnoses,

is the analysis of the problem as conducted in the current chapter, and requires the identification of the

causes of the problem. The plan phase is the defined as the shaping of goal and achievement of the goal,

in the case of the research at Citrix R&D the development of the process to transition the product to open

source. The scope of the research prevent the implementation and evaluation as the implementation and

results take multiple years. Results of the design phase will be unique to the case of Citrix R&D, therefor the

research is classified as POR. However the meta-study on characteristics and method on how to evaluate

the characteristics are universal applicable and the research is thus not only POR but has a limited amount

of Theory-Oriented Research (TOR)).

23

4.8 Research processResearch process entails the phases conducted in order to find answers to the sub-questions, divided into

literature, case study, results and conclusion phase. The process is illustrated in Figure 4.3.

Literature Case Study Result

Open Source Characteristics

Open Source Projects

Case study at Citrix

Research and Development

1

2

3

Improvement to achieve pre-

set goals

Process for transition to open source

4

5

Evaluation

Evaluation

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.

4.8.1 LiteratureThe first section of the research is the literature study in order to gain knowledge. The goal, to gather

state-of-art knowledge on OS projects in the field of FLOSS. In order to retrieve the required literature the

internet sources ”Smartcat”1and ”FLOSShub.org”

2are consulted. The expected results of the literature

phase are listed below.

• Characteristics of OS projects,• State-of-art on OS characteristics,• Existing open source projects and their implementation of the characteristics.

4.8.2 Case studyIn the case study phase the characteristics, as found in the previous literature phase, are the focus points

during the study of XenServer. To uncover information on the current implementations a exploratory case

study format is chosen. An exploratory case study is chosen to uncover the current strategies, processes

1http://rug.worldcat.org - The world’s largest library catalog.

2http://flosshub.org/biblio - FLOSS papers resources.

24

and work methods as they occur in Citrix R&D in regards to the transition to an open source project as

these facts are currently unknown and are required to provide Citrix R&D with advice. The information

will be gathered using semi structured interviews with the stakeholder involved in the transitions. Inter-

views will be conducted with: Project Manager, Product Manager, Vice President of Engineering (both past

and current), Chief Technology Officer, Developers of different internal teams, Managers of different teams

and the Community Manager of Xen Hypervisor. Interviews will be conducted face-to-face and using vir-

tual communication such as Microsoft Skype, go-2-meeting and Google Hangout. In addition to interviews,

meetings, related to the open sourcing, are also attended in order to take minutes, water cooler conversa-

tions, observations, email discussions, documentation, such as internal wiki’s and f.a.q. boards and internal

presentations are used as input.

• Expanding on motivations and objectives behind the open sourcing of XenServer,• Current implementation of the characteristics at Citrix R&D,• Strategy and future implementation of the characteristics at Citrix R&D.

4.8.3 DesignThe final step of the research uses the previous steps as input to design the final process. Using an evalua-

tion, between state-of-art-literature and the case-study, to gain insights and to enable reflection and assist

in the identification of improvements to the transition to an open source project. Lastly, a decision support

system will be used to determine which solution is most appropriate for the scenario.

• Evaluation between the current implementation of characteristics at Citrix R&D and state-of-the-art casesfrom literature.

• Process on the open sourcing transition tailored to the Citrix R&D case,

4.8.4 ConclusionIn 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

5. LiteratureResearch in open source has transformed from being an mild interest to a mature multi-disciplinary re-

search field [28, 13]. The goal of the following chapter is three fold, first identify the characteristics of an

organization transitioning to OS, second describe the state of the art literature of the characteristics and

third historical case studies on open sourcing of proprietary products are examined and described based

on the characteristics.

5.1 Open source characteristicsTo 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 characteristics5.2.1 MotivationTo enable the definition of success of the transition in retrospect it is necessary to understand the motiva-

tions and objectives of an organization at the start of the transition. Feller and Fitzgerald divide 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 thosemight

26

only surface after an extended period of time.

5.2.1.1 Technological motivationsTechnological 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.

FellerandFitzgerald[17]

BonaccorsiandRossi[6]

Sirkkalaetal.[52]

Raymond[43]

Robustness • •

Development • • •

Quality • • • •

Reliability • • •

Stability •

Openness •

Features • •

Table 5.1: Technological motivations.

A number of authors discuss technological motivations. Feller and Fitzgerald argue OS allows for more

robust code (Robustness), faster development cycle (Development), higher standards of quality (Quality),

improved reliability (Reliability), stability (Stability) and for more integration with open standards and plat-

forms (Openness). Bonaccorsi and Rossi and Raymondmention "many eyes" will assist in the development,

causing increased quality and reliability. More recently Sirkkala et al. writes about the idea of getting the

OS community to develop additional features (Features) and help improve the quality of the product. Ray-

mond covers the development at Linux and remarks volunteering developers add new features, work on

existing defects and write documentation.

5.2.1.2 Economical motivationsEconomic 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

FellerandFitzgerald[17]

BonaccorsiandRossi[6]

Sirkkalaetal.[52]

Riehle[44]

LernerandTirole[30]

AgerfalkandFitzgerald[1]

Fogel[19]

Cost reduction • • • • •

Industry redefinition • • • •

Market • •

Innovation •

Marketing • •

Recruiting • • • •

Sales •

Table 5.2: Economical motivations.

boosting the industry, the ability to recruit new employees from the community (Recruiting) and argues

open sourcing increases product familiarity driving marketing and sales (Marketing). Riehle also mentions

the ability to reduce costs by switching to OS, potential to disrupt a market by introducing an OS alternative

and the increase in potential employees. Lerner and Tirole also mention the ability for a firm to attract

more employees and the ability to influence the industry. Agerfalk and Fitzgerald take a slightly different

approach and study the symmetrical and complementary customer and community obligations of open

sourcing success from the perspective of outsourcing to a community through open sourcing. Fogel iden-

tifies, based on the OS community, costs could be shared, competitors and industry could be opposed,

it could be good for marketing and it offers a new motivation in the form of driving sales for hardware

products (Sales).

5.2.1.3 Socio-Political motivationsSocio-Political motivations are motivations related to the personal beliefs of humans. According to Crow-

ston et al. commercial organizations are not interested in personal motivations. Feller and Fitzgerald men-

tion personal motivations, such as the personal itch, getting mentorship, peer reputation, the desire to do

meaningful work and personal idealism as personal motivations.

5.2.2 Business modelsOS 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 complementaryservices such as support. Loss Leader for other commercial products. Widget Frosting when an organizationsells hardware and the software enables the hardware. Accessorizing physical items are accessorized with

28

OS software. Brand Licensing to other companies. Service Enabler when a commercial service requires soft-ware to access revenue-generating online services. Sell It,Free It, OS once it’s made its money as commercialproduct. Lerner and Tirole starts by providing some options for open sourcing: living symbiotically, by pro-viding complementary services and products, release code open to create involvement and drive additionalproduct sales and finally provide certification of the product. Riehle identifies three types of commercialopportunities: Consulting and support services, Derivative products based on the community project and In-creased revenue in ancillary layers in the software stack. Watson et al. differentiate between five differentmodels for production of software: proprietary, OS community, corporate distribution, sponsored OS andsecond-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 com-plementary services and in general make it more accessible to the market. Sponsored OS is described asthe case when a company invests money into foundation OS and does not see direct returns on those in-

vestments. 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 down-loads, 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 hostedsolutions to the customer based on OS software.

• Offering Commercial and OS Products - Models where there is a OS community version as well asa 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 commer-cial costs money.

• Advertising Model - Gaining additional income by provide adds on for example the download siteof the product.

• Packaging Model - Offer customers convenience by bundeling existing OS software into an easy touse 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 useof OS software charging for the labour involved to tailor it to the user.

29

• Patronage Model - Commercial organizations will invest in projects but won’t see direct financialrewards. 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.

5.2.3 Characteristics5.2.3.1 LegalityAny 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 andhighly restrictive. Founded in academics permissive licenses allow the distribution of source code for deriva-tive 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 Dis-

tribution (BSD), and Apache licenses [33]. Included in the permissive licenses are the Beer an WTFPL licenseallowing total freedom to the user.

The main risk for commercial vendors and OS communities is that competitors start a proprietary com-

petitive product based on their work. Restrictive license prevent proprietary derivatives by forcing any deriva-tive 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 theprogram 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

Permissive Hybrid Restrictive Highly restrictiveBeer 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 impactLerner 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 modelLindman 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 theproject. Motivation creation is important when community and its growth are going to be the competitiveadvantage and the license needs to emit trust. Community Leadership occurs when it is important to remainin control and prevent forking. Company Size is the final influence on the context of choosing a license. Inthe end the business model has the largest weight on the model since the choice of model can greatlyinfluence the type of license.

5.2.3.2 ProcessKilamo 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

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 andmaintenance.

Planning - In general FLOSS project don’t engage in formal planning [13] and this is a opportunity forcommercial organizations to contribute [18].

Requirements - Again not something often found formally in FLOSS projects, it is often confined todiscussions 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 proprietarydevelopment. 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. Howeverreleases 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 andnew 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

over the product. In the end the impact on daily work varies greatly between job role.

5.2.3.3 InfrastructureKilamo 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 communica-

tion 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 email, instant mes-

saging 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

• E-mail

• 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 na-

ture 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

5.2.3.4 SoftwareKilamo 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 themodularity and software architecture [13]. Conley and Sproull states that one of themost impor-

tant 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 modu-

larity 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 betweenmodularity and number of bugs is found

[10].

5.2.3.5 CommunityKilamo et al. interpret the community as the change the entire teamwill have to go through whenmoving 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 andmembership

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.

5.2.3.6 MarketingTransitioning 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

5.3 Case studiesIn the final section of the literature study case studies on open sourcing of proprietary products are exam-

ined 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.

5.3.1 Introduction5.3.1.1 MozillaMockus 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.

5.3.1.2 Trolltech, Bekk Consulting, Linpro and eZ SystemsEide 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.

5.3.1.3 GuruxGurux 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 tomake, requiring considerable time and resources. Although initially the organization lost a small

35

portion of existing customers due to the transition more and more new customers are being obtained as a

result of the transition today [26].

5.3.1.4 WringerWringer, 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.

5.3.1.5 SymbianIn 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].

5.3.2 LegalityDuring the open sourcing of Mozilla Netscape developed the Netscape/Mozilla Public License for the prod-

uct 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 license1, 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,

1http://www.gurux.fi/index.php?q=OpenSource

36

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].

5.3.3 Process5.3.3.1 PlanningWithin Mozilla roadmaps specify the features of future releases including release dates. AlthoughMozilla ul-

timately 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.

5.3.3.2 CodingCode 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.

5.3.3.3 TestingMozilla 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 accom-

plished 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

5.3.3.4 ReleasingBefore 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 "Mile-

stones" 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 continuousmaintenance, 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].

5.3.3.5 DocumentationMozilla’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 installa-

tion 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].

5.3.3.6 DeploymentThe process of building Wringer is effortless on Ubuntu, however it is advised to increase the documenta-

tion 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

5.3.3.7 TimingThe 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].

5.3.4 InfrastructureThe 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 documenta-

tion 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 ini-

tially 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 email for most of instant communication. Trolltech uses CVS and a bug tracker [16].

5.3.4.1 Mailing listsLinpro 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

5.3.4.2 ForumBekk 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].

5.3.4.3 WikisEZ 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 orga-

nization 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].

5.3.4.4 WebsiteLinpro 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].

5.3.5 SoftwareLinpro argues themost important aspect of the software is tomeet 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].

5.3.5.1 ArchitectureIn 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

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 archi-

tecture (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 suc-

cess 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 mod-

ularity creates flexibility and comprehensibility for potential contributors reducing the learning curve and

allows extensibility without requiring modifications to other modules [16].

5.3.5.2 Code CleannessAfter 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].

5.3.5.3 Code CommentsShah 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].

5.3.5.4 Bugs, Debugging and StandardsWringer 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

5.3.6 CommunityWringer 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 inter-

nal, 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, email volume and feedback on google alerts as

continues data are gathered. The data is analyzed and action is taken accordingly. At Trolltech the com-

munity is al about innovation, the synergy between volunteers and professionals identifies problems and

creates solutions and sparks for improvements of new features [16].

5.3.6.1 ContributionsAfter 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 na-

ture 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 commu-

nity 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].

5.3.6.2 Roles and responsibilitiesThe 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

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. Decisionmaking is based onmodule

owners and left to people who know particular code [36].

5.3.6.3 OwnershipIn 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 con-

trol of the project. Eide finds in literature OS projects often have meritocratic structuring and all intervie-

wees 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 our-

selves. 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.

5.3.6.4 GovernanceGovernance 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].

5.3.6.5 ActivityActivity 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

5.3.6.6 CommunicationAlthough 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].

5.3.6.7 CreditLinpro 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].

5.3.7 MarketingIn 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 re-

lated 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 addi-

tional 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 propri-

etary and OS, spending resources on announcements, interviews, conferences and sponsoring. In hind-

sight 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 sug-

gestions 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 (po-

tential) users and customers, partner with other projects and traditional marketing i.e. paid advertisement

44

[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

6. Citrix research and Development case studyThe following chapter contains the information gathered during the case study at Citrix R&D, further indi-

cated 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 Organization6.1.1 ProductXenServer, in the remainder of the chapter described as the product, as a product consists of Xen Hyper-

visor 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 CentOS1, is chosen in order to provide a stable foundation for the prod-

uct. 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.

6.1.2 StrategyAt 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.

1http://www.centos.org - CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a

prominent North American Enterprise Linux vendor.

46

Community Citrix Research and Development

Citrix Research and Development

XenServer OS XenServer Citrix XenServer

Proprietary Sponsored Open Source

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.

6.1.3 Open sourcing projectsIn 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 repos-

itories. 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 develop-

ment stages of the second project the idea of using projects was dropped in favor of continues improve-

ments 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.

6.1.4 Internal development processBefore 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

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 ModelThe organization believes, although business might get lost whilst transiting to OS, the majority of com-

mercials 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 re-

quires 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. Addition-

ally customers can request features or fixes, reducing costs for themselves as they do not have to invest in

the development of the requested features.

6.2.1 HistoricalBefore 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.

6.2.2 CurrentTransitioning 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.

6.2.3 FutureCurrently the organization is exploring possibilities to increase its earnings by including its product with sup-

port in other vendors product. Examples include paid linux operating system licenses including the product

48

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.

6.2.4 ChallengesSome challenges remain in the business model, for instance the goal of being able to have package integra-

tion 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 develop-

ers 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 CharacteristicsIn compliance with the characteristics found in the literature study the subsequent sections of the case

study are divided based on the before mentioned characteristics.

6.3.1 Legality6.3.1.1 HistoricalThe 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.

6.3.1.2 CurrentIn the process of open sourcing the first step for the product is the choice of license, as the license differ-

entiates 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 didnot care because we want people to use the code, if people would contribute because it is advantageous to themand because its just part of good OS citizenship". Alternatives to the license choice of LGPL and BSD wherehard as another member explains "The para virtualized drivers in windows where interesting, windows updateservice makes it impossible to distribute source code but would be required if it where GPL code". Even though

49

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 sinceit was advantageous to us not to have a restrictive version anyway. Doing that may seem the project to be lessopen, 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 andnot a lot of good."

6.3.2 Process6.3.2.1 PlanningThe initial planningmethod within the organization was based on the waterfall method for general develop-

ment 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 re-

lease 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 infor-

mation, 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.

6.3.2.2 RequirementsThe requirements of the product are based on internal decisions and none of these are published to the

external community.

6.3.2.3 CodingCurrently 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

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 teammembers, 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.

6.3.2.4 TestingThe organization is using continues testing to maintain a degree of quality within the product. Code enter-

ing 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 implemen-

tation varies.

6.3.2.5 ReleasingThe 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 Citrixholds 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 stillbe different to Citrix". The build system requires a high amount of resources and highly customized setupand 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 .

6.3.2.6 MaintenanceCurrent 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 themailing 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

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 inter-

nal 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 interac-

tion 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.

6.3.2.7 DeploymentAlthough 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 ofcomponents of the product expect a perfect environment giving an often cryptic message when the componentfails.". The perfect environment is provided with the ISO but not when external developers develop on theproduct.

6.3.2.8 DocumentationExtensive 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.

6.3.3 Infrastructure6.3.3.1 HistoricalThe 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.

6.3.3.2 CurrentThe current public infrastructure at the organization include forums, mailing lists, IRC, questions and an-

swers on the website, documentation, web site, version control system and wikis (at the Xen Hypervisor

52

project). Internally the infrastructure includes bug trackers, agile boards, backlogs, wikis, podio2, 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 thecitrix.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 email lists. Some seeds havebeen tried but nothing happened. The probable cause are the good internal tools so its not really convenient touse external mailing lists. Since the internal tools are so good people dont really feel like moving to a mailing listto 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 for-

mat. 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 toGit and GitHub, It is possible for people to continue working on their own way as they please but our XenServermanager felt that constancy was better if there was a single central hosted entity for code.". Before the transitionto OS the teams used mercurial as code repositories and some teams still use internal mercurial workflow

replicating the code on Github as a mirror.

6.3.4 Software6.3.4.1 ArchitectureThe 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 implementa-

tion 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.

6.3.4.2 Code cleanlinessNomodification 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.

2Podio - A web-based platform for managing team communication, business processes, data and content in project management

workspaces.

53

6.3.4.3 Code commentsBefore 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.

6.3.4.4 Bugs, features, debugging and standardsCurrently 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.".

6.3.5 Community6.3.5.1 ContributionsContributing 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 byreview.". After the code is reviewed it is resumed into the normal internal processes. Although Githubmakesit possible for a almost automated process themailing 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.

6.3.5.2 Roles and ResponsibilitiesThe 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 develop-

ers are unchanged apart from the allocation of resources to actively participate in the community.

6.3.5.3 OwnershipThe 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

6.3.5.4 GovernanceThe 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 employ-

ees 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.

6.3.5.5 CommunicationCommunication with the users of the community is conducted utilizing the forums and IRC of the organi-

zation. 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 con-

ducted 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.

6.3.5.6 CreditThe only project to provide credit to the community is the XenAPI component using the code version sys-

tem 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.

6.3.6 MarketingConsequently 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 considerationsThe 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.

6.4.1 LegalityAs the organizationmentions themselves, "Currently there are no plans to introduce further OS license changesinto the product", the current license arrangements will remain unchanged for the foreseeable future.

55

6.4.2 Process6.4.2.1 ReleasingThe 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 indi-

vidual components to test modifications.

6.4.2.2 TestingThe 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.

6.4.2.3 DocumentationAs one of the OS evangelist mentions when discussing documentation: "Definitely not there yet!". The orga-nization 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 email people in the mailinglist

when adjustments are made to the documentation.

6.4.3 InfrastructureThere have always been plans to implement a public bug tracker and wikis dedicated to the project. Accord-

ing to the community manager on the community website both should be available soon "The big processimprovements will hopefully be unveiled in late December or early January when we get our long needed wikiand 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 toclosed source development on other Citrix products, or information provided to Citrix by partners under NDA isn’taccidentally made public". Another important aspect of the publication is the ability for search engines tocrawl the contents so it can easily be found by those who are looking for it using search engines.

6.4.4 SoftwareResources within the organization have been assigned to a project to decouple the products different func-

tional areas, making separated modules. The work includes designing component interfaces, which are

56

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 con-

figuration 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 stan-

dardized 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

7. AnalysisThe 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 IntroductionThe 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.

Open source Literature

Literature

Case studies

Citrix case study

Assessment

CharacteristicCharacteristicImprovement

Figure 7.1: Analysis process of the open sourcing at Citrix R&D.

7.2 MotivationThe 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 be-

lieves 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 alterna-

tive 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

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. Fur-

ther 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 organi-

zation.

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 drop-

ping 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 organiza-

tion 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 ModelThe business model implemented by the organization is a natural consequence given the available infras-

tructure 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 hard-

ware is mature, highly competitive and saturated. Finalizing the business model there is limited room for

59

improvement, and it is advised to continue the current model. Possible extensions can be found in expand-

ing the market and bundle deals.

7.4 Characteristics7.4.1 LegalityThe 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.

7.4.2 Process7.4.2.1 PlanningThe 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 bemade public. Other information includes current bugs under con-

sideration 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.

7.4.2.2 RequirementsThe requirements of the product are analogous to the planning proposed in the previous section and al-

though some level of transparency will be required by adapting processes to include discussion on the

60

mailing list. Most of the requirements planning will remain internal to the organization, since the organiza-

tion determining the direction of the project. No further actions are advised on the point of requirements.

7.4.2.3 CodingThe 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.

7.4.2.4 TestingTesting 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.

7.4.2.5 ReleasingSimilar 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

• Provide planning details to the community, especially for the next release or six month period. For instanceby 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.

7.4.2.6 DocumentationDocumentation 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, archi-

tecture 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 com-monly 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.

7.4.2.7 MaintenanceProblem 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 ofnon-support and support questions.

• Decide on the support infrastructure for both users and developers.

62

7.4.3 DeploymentThe 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 theproduct in modules.

7.4.4 Infrastructure7.4.4.1 Bug TrackerThe 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.

7.4.4.2 Mailing listsThe mailing lists are available, used and are the main communication between organization and commu-

nity. 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.

7.4.4.3 ForumsThe current forum solution, targeted at the users of the product, is not intended for development ques-

tions and focuses on users of the product. Development questions are to be redirected to the mailing lists.

63

The forum is provided by the commercial organization rather then the community website, and the sep-

arate 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.

7.4.4.4 WebsiteThe 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.

7.4.4.5 Documentation InfrastructureAs 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.

7.4.4.6 Version Control SystemThe 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

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.

7.4.4.7 Build infrastructureThe build infrastructure is internal only due to the composition of the product. The organization is transi-

tioning 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.

7.4.5 Software7.4.5.1 ArchitectureLiterature 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 develop-

ers 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. Cur-

rently 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

7.4.5.2 CodeRemoval 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 newlystarted employees.

• Examine the possibilities of including OS standards in the project.

7.4.6 Community7.4.6.1 ContributionsThe 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.

7.4.6.2 Roles, responsibilities and OwnershipRoles 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 imple-

mented 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.

7.4.6.3 GovernanceSimilar to the roles, responsibilities and ownership the control and governance remains with the organiza-

tion. The organization should adopt a governance structure best suited to the needs of the organization

and communicate the governance model to the community.

66

7.4.7 MarketingMarketing 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 SummaryThe results found in the previous characteristics sections are summarized into different areas in the follow-

ing. The areas identified are categorized into information, documentation, software, infrastructure, pro-

cesses, decisions, website and integration. The main areas focus on transparency, documentation, project

activity, community nurturing and growth and metrics.

7.5.1 InformationTransparency 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 pro-

cess of the organization will require explanation in order to prevent discontent, as well as the proprietary

components of the product.

7.5.2 DocumentationThe 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 imple-

ment a platform to make collaboration possible. Once a platform is implemented documentation of code,

67

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. Develop-

ment documentation surrounding the API, including code examples, are needed to allow external parties

to build extensions on top op the product.

7.5.3 SoftwareSoftware encompasses the changes advised to the code base and to be developed code. The first modifi-

cation 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.

7.5.4 InfrastructureIn order to enable the organization and community to interact and work infrastructure is needed to facili-

tate. 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.

7.5.5 ProcessesProcesses include the implementation of new process, standards and guidelines or the adjustment of ex-

isting. 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 in-

troduce 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.

7.5.6 DecisionsThe 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

inform the community accordingly. As well as the support infrastructure and possibility of using open

standards in the project.

7.5.7 WebsiteThe 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.

7.5.8 IntegrationIntegration 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, require-

ments, 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.

7.5.9 MetricsIn order to understand the status of the community it is advised to keep metrics of the status of the com-

munity. 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 ver-

ify the succes of open sourcing and be able to communicate quantitative data to the external community

and internal organization.

69

8. TransitionIn the previous two chapters the situation at the organization was examined, defined (Chapter 6) and as-

sessed (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 sug-

gestions 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 IntroductionIn 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 focus-

ing 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 attract-

ing users which grow in the project by contributing bug reports, bug fixes, process enhancements, doc-

umentation, 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 ProcessThe 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

Phase I Phase II Phase III

Decisions

Infrastructure

Documentation

Metrics

Website

Information

Collaboration

Product

Processes

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 mak-ing 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. Decisionsand 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 theimplemented infrastructure. It allows for collaboration to begin between organization and users and poten-tial 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 theproject has achieved by performing the previous stages and to further foster growth of the community.

71

8.2.1 DecisionsDuring 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 withcharacteristics 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 theorganization, 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 organizationregarding 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 theorganization. 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 tocommunity 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

8.2.2 DocumentationDocumentation provides information on the product, and is a collaborative effort between the organization

and the community.

8.2.2.1 PublishDocumentation required includes, but is not limited to, providing tutorials and guides for users and devel-

opers 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.

8.2.2.2 ImplementationThe 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 bemade 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.

8.2.3 InformationInformation is internal available knowledge which is suggested to be shared with the community to create

thrust, understanding, transparency and integration.

8.2.3.1 PublishInformation 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 re-

garding the forum and product information regarding historic product offering.

73

8.2.3.2 ImplementationThe majority of the information is available internally, but decisions prevent information from being pub-

lished. 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.

8.2.4 ProductProduct 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 modifica-

tions 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 instal-

lation 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.

8.2.5 InfrastructureSupporting the development and processes of the community and organization is the infrastructure con-

sisting of third party software. Infrastructure enables the integration between the community and organi-

zation 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 soft-

ware at the organization. After the choice of software has been made deployment on a hosting solution is

74

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.

8.2.6 ProcessesIntegration and transition towards an OS project requires changes to the processes in use in the organiza-

tion. 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 execu-

tion 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. Up-

dating 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.

8.2.7 WebsiteThe 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

documentation. Moreover the integration with the wikis to direct people to information subjects under

continuous change.

8.2.8 CollaborationCollaboration between organization and community enables thrust and commitment from external con-

tributors.

• 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 con-

tents on the mailing list and wiki, depending on the preferences and current procedures in planning and

architectural.

8.2.9 MetricsMetrics 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 3.2.

8.3 DiscussionIn 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 com-

munity 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 eas-

ier 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 im-

portance to the health of the community. Without infrastructure there is no possibility for a community to

76

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 invest-

ments 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

9. ResultsAs 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 orga-

nization 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 implemen-

tation 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.

Restricted Governance

Proprietary Software

Inner Source

Controlled Source

Traditional Closed Source

Progressive Open Source

Open Governance

Sponsored Open Source

Industry-Led Open

Source

Industry-Involved

Open Source

Bazaar Style

Community Open Source

Traditional Open

Source

FoundationOpen

Source

Cathedral Style

Start Current Target

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 FindingsIn 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 fromproprietary to an OS project, from its current state, with the achievement of the pre-set objectives.

78

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 theXenServer 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 anddiscussed, the motivation of an organization determines the success factors, and the business models hasimplications 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 ecosys-

tem. 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 goalsthan a healthy ecosystem. In addition it is argued the use of business model as another key characteristic ifconsidering 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 ledto 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 fromMozilla,

Trolltech, Bekk Consulting, Linpro, ez Systems, Gurux, Wringer and Symbian are examined on the charac-

teristics 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

have a sustaining vibrant community.

What is the current state of the open sourcing, based on the proposed characteristics in the firstquestion, of Citrix R&D?

By performing a case study in the organization through semi structured interviews, meetings, water cooler

conversations, observations, email 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-setgoals?

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

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 or-

ganization 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 inter-

nal 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 goalsThe 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 increasein 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 pro-

vide 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 standardsand 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 toinform the external world about the product offering and remove any existing confusion by increasing

transparancy.

81

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 reducethe technical debt of the project.

9.3 Research goalsIn 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 ValidationThe 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 gath-

ered 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 stake-

holders 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

The validation of the research itself might be biased by the researcher as the analysis, case study and re-

sult 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

10. ConclusionIn the study a process suggestion of transition from proprietary to OS is provided for the commercial orga-

nization 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 con-

ducted 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 commu-

nity 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 organiza-

tion 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.

10.1 DiscussionThe 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

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.

10.2 Further ResearchContinuing from the study it is clear further research is needed, and the first proposed study is the revis-

itation 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

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):385–409.[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):576–656.[3] Alexy, O., Henkel, J., andWallin, M. W. (2013). From closed to open: Job role changes, individual predispo-

sitions, and the adoption of commercial open source software development. Research Policy, 42(8):1325–1340.

[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):1116–1127.[6] Bonaccorsi, A. and Rossi, C. (2006). Entry Strategies Under Competing Standards : Hybrid Business

Models in the Open Source Software Industry. 52(7):1085–1098.

[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 178–200.[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 1–15. I edi-tion.

[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, 2009. HICSS ’09. 42nd Hawaii Interna-tional Conference on, pages 1–10.

[11] Craig-Wood, K. (2013). Open source as the secure alternative: a case study. Computer Fraud & Security,(May 2011):15–20.

[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):123–148.[13] Crowston, K., Wei, K., Howison, J., and Wiggins, A. (2012). Free/Libre open-source software develop-

ment. 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 the24th International Conference on Software Engineering, 94303(650):177–184.

[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

58–69.

[18] Fitzgerald, B. (2006). The Transformation of Open Source Software. Mis Quarterly, 30(3):587–598.[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):77–90.[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 developmentmailing lists. In The 10th Working Conference onMining Software Repositories,pages 277–286.

[23] Haselhoff, F. (1977). A new paradigm for the study of organizational goals. From Strategic Planning toStrategic Management, pages 15–27.

[24] Hecker, F. (1999). Setting up shop: the business of Open-Source software. Software, IEEE, (February1999):45–51.

[25] Hofmann, G. and Riehle, D. (2013). A Dual Model of Open Source License Growth. In Proceedings of the9th International Conference on Open Source Systems (OSS 2013), pages 245–256.

[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):1467–1478.[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. ManagementScience, 52(7):975–983.

[29] Kumar, V., Gordon, B. R., and Srinivasan, K. (2011). Competitive Strategy for Open Source Software.

Marketing Science, 30(6):1066–1078.[30] Lerner, J. and Tirole, J. (2001). The open sourcemovement: Key research questions. European EconomicReview, 45(4-6):819–826.

[31] Lerner, J. and Tirole, J. (2003). Some Simple Economics of Open Source. The Journal of IndustrialEconomics, 50(2):197–234.

[32] Lerner, J. and Tirole, J. (2005). The Scope of Open Source Licensing. Journal of Law, Economics, andOrganization, 21(1):20–56.

[33] Lindman, J., Rossi, M., and Puustell, A. (2011). Matching Open Source Software Licenses with Corre-

sponding Business Models. IEEE Software, 28(4):31–35.[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):1015–1030.

[36] Mockus, A., Fielding, R. T., and Herbsleb, J. D. (2002). Two case studies of open source software devel-

opment: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology, 11(3):309–346.[37] Nakakoji, K. and Yamamoto, Y. (2002). Evolution patterns of open-source software systems and com-

87

munities. In IWPSE ’02 Proceedings of the International Workshop on Principles of Software Evolution, numberJanuary 2001, pages 76–85.

[38] Nambisan, S. and Wilemon, D. (2000). Software development and new product development: poten-

tials for cross-domain knowledge sharing. IEEE Transactions on Engineering Management, 47(2):211–220.[39] Niederman, F. and Davis, A. (2006). A research agenda for studying open source I: a multi-level frame-

work. 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):1179–1198.[43] Raymond, E. (1999). The cathedral and the bazaar. Knowledge, Technology & Policy, pages 1–40.[44] Riehle, D. (2007). The Economic Motivation of Open Source Software Stakeholder. IEEE ComputerSociety, (April):25–32.

[45] Riehle, D. (2009). The Commercial Open Source BusinessModel. In Proceedings of the Fifteenth AmericasConference on Information Systems (AMCIS 2009).

[46] Riehle, D. (2010). The single-vendor commercial open course business model. Information Systems ande-Business Management, 10(1):5–17.

[47] Riehle, D. and Berschneider, S. (2012). A Model of Open Source Developer Foundations. InOpen SourceSystems: Long-Term Sustainability, chapter A Model of, pages 15–28.

[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):59–66.

[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):95–105.[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 BuildingSustainable 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 57–69.[53] Stewart, K. (2005). A preliminary analysis of the influences of licensing and organizational sponsorship

on success in open source projects. In System Sciences, 2005. HICSS ’05. Proceedings of the 38th AnnualHawaii International Conference on 03-06 Jan. 2005, volume 00, pages 1–10.

[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):1319–1336.

[55] Vass, B. (2007). Migrating to open source: Have no fear. In Proceedings of the 3rd DoD Open Conference:

88

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):236–253.[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):41–46.[60] Wilson, R. (2012). The Mozilla Public License V 1.1 - An Overview.

89

Appendices

90

GlossaryAPI 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 in-

stead 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 andis unreadable for humans. 5, 6

changelog A document, often found in software projects, containing the changes of the project given arelease. . 50

Citrix Citrix Systems, Inc.. 1, 15–17, 22, 53, 94, 96–98Citrix R&D Citrix Research and Development. vi, 1–3, 15–23, 25, 46, 47, 58, 78–81, 84, 85, 94–99Cloud 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 programonmany 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: insteadof 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. 6derivative works Derivative work is work based upon one or more preexisting works.. 30dogfooding Dogfooding, or eating your own dog food, is a term used within software developing organi-

zations 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 soft-ware.. 48, 49

91

FLOSS Free Libre Open Source Software. 1, 2, 5, 15, 20, 24, 28, 32forking 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 revisioncontrol system. - http://en.wikipedia.org/wiki/GitHub. 53, 54, 64, 65

Hypervisor A Hypervisor, in computer science terms, is a piece of computer software, firmware or hard-ware 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 com-bined 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 inkjetprinters, that drive cartridge sales, and game consoles, that drive videogame sales.. 28

NDA Non-disclosure agreement. 98openwashing 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, 96OSS Open Source Software. 1, 2, 5, 6, 15, 32OSSD Open Source Software Development. 12, 32personal 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. 23POS Progressive Open Source. 5, 8

92

readme A readme file is commonly distributed with computer software and contains information aboutother 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 informa-

tion, known bugs, troubleshooting, credits, change log and news.. 38

SaaS Software as a Service. 29, 35Scrum 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, compre-

hensiveness 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. 23Type 1 Hypervisor Type 1 (or native, baremetal) 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, 61XenServer XenServer. 1, 15–17, 19–21, 24, 25, 46–48, 52, 53, 78, 84, 94, 95, 97–99, 101

93

A. Organization descriptionThe 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 DevelopmentCitrix 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 categories2. 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 2007. 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 modernday 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. XenHypervisor, an open source linux foundation project as of recent, is partly being developed by membersof 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 teammanagers for

each engineering team. The management teams develop long term road maps for the product and man-

ages 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 prod-

uct. 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.

1Based on http://www.citrix.com/ - accessed on 06-04-2013

2The complete offering can be found at http://www.citrix.com/products.html - accessed on 02-10-2013

94

1.2 XenServerXenServer 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 XenHypervisor as well as the XenServer product. Xen Hypervisor is the foundation of XenServer, and in essenceXenServer is a proprietary extension of Xen Hypervisor.

1.2.1 Xen Hypervisor1.2.1.1 ProductXen Hypervisor or any Hypervisor enables the hardware resources of a computer to be virtualized anddynamically 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 eachcontainer or Virtual Machine (VM) running a operating systems such as Windows or Linux. Xen Hypervisoris 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.

Hardware

XEN  Hypervisor

Dom0 DomU DomU

Virtualized  (Hypervisor)

(OS) (OS)

Hardware

Operating  System  (OS)

Non-­‐virtualized

(Control)

Figure A.1: Graphical depiction of a Hypervisor

1.2.1.2 StrategyAlthough 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 mo-

ment of writing Xen Hypervisor has been accepted into the Linux Foundation, allowing it to gain back it’s3http://wiki.xenproject.org/wiki/Xen_Overview#What_is_Xen accessed on 02-07-2013

95

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, Veri-

zon 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 foundationOS project coming from Sponsored Industry-Led OS. The main reason for moving the project to a founda-tion is to increase the popularity and implementation of the project and getting the right governance and

structure in place to grow the product.

1.2.2 XenServer1.2.2.1 ProductBased 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 customersto easily integrate, manage and automate a virtual datacenter. In order to support a multitude of industry

standard hardware products a single linux distribution, Linux CentOS4, is used to provide a stable founda-

tion for the product, Xen Hypervisor can be used on any linux distribution. Further enhancements include anAPI to provide easy access to functionality, enterprise storage and network solution integration, orchestra-

tion 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 CloudPlatform (XCP) with a mixture of features from both free and some of the payed options was released in2009.

1.2.2.2 InterrelatedThe product of Citrix R&D, XenServer, is not only a stand alone product, but also used within Citrix as afoundation for other Citrix products. The Citrix products including XenServer account for the majority ofturnover of XenServer. Citrix places strategic value in the ownership of XenServer because of the interrela-tion 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 singlecost factor.

4http://www.centos.org - CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a

prominent North American Enterprise Linux vendor.

96

1.2.2.3 MarketXenServer is primarily focused on enterprise customers interested in virtualizing their data centers with-out 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. XenDesktopruns virtualized Microsoft Windows (or Linux) instances in similar way of the old main frame. Another prod-

uct 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%)5.

1.3 Strategy1.3.1 HistoricalIn recent years the market share of XenServer is under pressure due to increasing competition and per-ception 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 resultedin parts of XenServer becoming open source projects as well as providing customers with an open sourceedition with similar features to the free version of XenServer. However the limited amount of resourcesallocated 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.

1.3.2 Open sourcingThe 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 opensource 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

5Based on IDC study of virtualization market share 2011 - http://www.idc.com/tracker/showproductinfo.jsp?prodid = 39 - accessedon 02-10-2013

97

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 opensourcing to turn in to openwashing.

1.3.3 GoalsIn 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 objec-

tive 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 yearscompetitors 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 orderto 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. Startingfrom 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 scenariowhere XenServer is also open source, organizations should more easily choose for the XenServer

product as opposed to themore 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 mar-ket. 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 opensource 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

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 TeamsCitrix 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 levelfeatures 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 XenHypervisor as used in XenServer.

• Storage - The storage team works on support for enterprise grade storage solutions, additionalspecific storage features, etc.

• Performance - Work on the entire product to increase the performance of the product (e.g. increasenumber of virtual cpu’s that can be supported).

• Windows Drivers - Work on enabling Microsoft Windows products by providing driver support forXenServer 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 departmentsand 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 differentengineering teams.

• Development Operations - Provide the infrastructure for the organization. The infrastructure con-tains maintaining the version control, build system, test infrastructure, bug trackers, wikis, intranet.

99

• Management - Prioritize allocation of resources, communicate with other departments and higherup management, making sure each teammember 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 re-ports.

100

B. Release processFigure 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.

Win

dows

Up

date!

External!

Binary!

Binary!

Main.iso

(

XenServer!

xens

erve

r.org!

! !

Free!

User

focu

sed!

Bug

supp

ort f

rom

Ci

trix! Re

quire

s(non

.free(RPM

s(

Source!

Tech.(Preview

(

Cent

OS

6.4!

Linu

x.rp

m!

Xen.

rpm!

Xapi

.rpm!

Glu

e/To

ols!

XenC

ente

r!

qem

u.rp

m!

Release(Cand

idates(

Closed!

xen.

git!

xen

PQ!

xen-

api.g

it!

wind

ows-

drive

r.git!

XenS

erve

r.git!

XenC

ente

r.git!

qem

u.gi

t!PQ

!

Dist

ro’s!

*.sys!

WHQ

L Te

st!

Citri

x!XCP

XAPI

(le

gacy

)!

Linu

x.gi

t!

rpm(

HA.h

g!HA

.rpm!

^ hb

ad.rp

m!

^ nv

idia

drive

r!

^ No

sou

rce!

Bina

ry fr

om v

endo

r!

Citri

x bu

ild +

pub

lishe

d rp

m!

LF(

LF(

LF(

LF*(

On

the

web!

) Ci

trix

desig

ned

rele

ase

sche

dule!

*(*(

*(

*(

Figure B.1: Release process given the source and binary components within the organization.

101