fromproprietarytoopensource, acasestudyofcitrixxenserveraiellom/tesi/pieters.pdf ·...
TRANSCRIPT
FROM PROPRIETARY TO OPEN SOURCE,A CASE STUDY OF CITRIX XENSERVER
Harm Roelof Pieterss1537687 - [email protected]
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
• 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