Lessons Learned From Applying Social Network Analysis On An Industrial Free/Libre/Open Source Software Ecosystem
Lessons Learned From Applying Social Network Analysis On An Industrial Free/Libre/Open Source Software Ecosystem
Abstract
Many software projects are no longer done in-house by a single organization. Instead, we are in a new age where
software is developed by a networked community of individuals and organizations, which base their relations to each
other on mutual interest. Paradoxically, recent research suggests that software development can actually be
jointly-developed by rival firms. For instance, it is known that the mobile-device makers Apple and Samsung kept
collaborating in open source projects while running expensive patent wars in the court. Taking a case study approach,
we explore how rival firms collaborate in the open source arena by employing a multi-method approach that
combines qualitative analysis of archival data (QA) with mining software repositories (MSR) and Social Network Analysis
(SNA). While exploring collaborative processes within the OpenStack ecosystem, our research contributes to Software
Engineering research by exploring the role of groups, sub-communities and business models within a high-networked
open source ecosystem. Surprising results point out that competition for the same revenue model (i.e., operating
conflicting business models) does not necessary affect collaboration within the ecosystem. Moreover, while detecting
the different sub-communities of the OpenStack community, we found out that the expected social tendency of
developers to work with developers from same firm (i.e., homophily) did not hold within the OpenStack ecosystem.
Furthermore, while addressing a novel, complex and unexplored open source case, this research also contributes to
the management literature in coopetition strategy and high-tech entrepreneurship with a rich description on how
heterogeneous actors within a high-networked ecosystem (involving individuals, startups, established firms and
public organizations) joint-develop a complex infrastructure for big-data in the open source arena.
Keywords: Social network analysis; Open source; Open-coopetition; Software ecosystems; Business models;
Homophily; Cloud computing; OpenStack
© 2015 Teixeira et al. Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0
International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and
reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the
Creative Commons license, and indicate if changes were made.
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 2 of 27
Samsung continued their collaboration in WebKit while organizations) joint-develop a complex infrastructure for
running expensive patent-wars in the court worldwide [3]. big-data in the open source arena.
This hybrid behavior comprising competition and coop-
eration has been named coopetition. A number of man- 2 Coopetition and Free/Libre/Open Source
agement scholars have emphasized the increasing impor- software ecosystems
tance of coopetition both for today’s networked business A number of management scholars [4–7] have empha-
and networked scientific investigation [4–7]. Neverthe- sized the increasing importance of coopetition both
less, it remains undetermined whether such knowledge for today’s networked business and networked scientific
can contribute to Software Engineering research, which investigation. According to Dagnino and Padula [1], the
more recently embraced the ecosystem thinking [8]. term “coopetition” was coined by Nadar, former CEO of
In this research, we study coopetition in the open Novell, and introduced into research by Brandenburger,
source arena by investigating the OpenStack ecosystem first in an academic journal [15] and then in a more
that jointly develops, promotes and exploits a complex practice-oriented book [7].
cloud computing infrastructure. We take software ecosys- The current coopetition body of knowledge argues that
tems as they were early defined by Jansen et al. as “a set competitors can be involved in both cooperative and
of businesses functioning as a unit and interacting with a competitive relationships with each other simultaneously
shared market for software and services, together with the while benefiting from both in a symbiotic way. Coopeti-
relationships among them” [9]. tive relationships are complex and hard to manage, as they
Within an exploratory case study [10], we employ a consist of two diametrically opposed logics of interaction
mixed methods approach which bridges qualitative analy- [16]. According to Bengtsson and Kock [2], firms tend to
sis of archival data (QA) with mining software repositories cooperate more frequently in activities carried out at a
(MSR) and Social Network Analysis (SNA) to assess how greater distance from buyers, and to compete in activi-
competition and collaboration among firms evolve over ties closer to buyers. From a strategic point of view, this
time. This blended methodological approach allowed us means that R&D activities, such as software development,
to exploit synergies among methods while minimizing are best suited to be developed in cooperation with a com-
single-source and single-method biases [11–13]. petitor, but when it comes to marketing a new product,
Taking a longitudinal design covering more than 4 years competitors choose to distinguish the products from each
of the OpenStack development, we address a call from other. A core driving force behind this behavior is the het-
Basole [14] for the use of methods which take into con- erogeneity of resources, as each competitor holds unique
sideration the time, pace and sequence in the study of an resources that are best utilized in combination with other
ecosystem. We are also addressing the novel and more competitors’ resources. Other driving forces are shorter
specific term of “open-coopetition”, coined by Teixeira product life cycles, convergence of multiple technologies
and Lin as “a portmanteau of cooperative competition in and increasing R&D and capital expenditures [5]; rapidly
the open source arena, where R&D is jointly performed changing consumer preferences; and the speed and mag-
by competing firms in a open source way, giving-up nitude of technological changes [17]; additionally, firms
authorship-granted intellectual property rights for maxi- need to speed-up their innovation efforts [18] and to aim
mizing both the blueprints transparency and collaborative at setting up standards and platforms [19, 20].
benefits” [3]. Even though the existing literature addressing coope-
We assess how revenue models affect collaboration in tition in the technological sector is still scarce, there
OpenStack: contrary to expectations, firms competing for is a growing stream of research addressing coopeti-
the same revenue model (i.e., where rivalry is expected) tion grounded on empirical material from the techno-
tend to collaborate more than firms which do not com- logical sector. For instance, Osarenkhoe described how
pete for the same revenue model; being the exception only Nokia, Ericsson, and Motorola cooperated to improve the
those firms that provide public cloud services (in the case Chinese telecom infrastructure while competing on the
of OpenStack, these are HP, Rackspace and Canonical). same market with different mobile devices [21]. On the
Our findings indicate that by combining QA methods LCD TV markets, Sony and Samsung cooperated strongly
with SNA visualizations, we can produce rich longitudi- in R&D and manufacturing while commercializing inno-
nal descriptions and interpretations which enable a better vative flat screen TVs. Addressing collaboration among
understanding of competitive and collaborative issues in high-tech giants, Gnyawali and Park [5] found that both
large and complex software ecosystems. Sony and Samsung were able to reap major benefits from
Finally, we also contribute to management and innova- applying coopetitive elements in their strategy. By exam-
tion studies with a rich description of how heterogeneous ining data from Taiwanese firms in the information and
actors within a high-networked ecosystem (involv- communication technology industry, Huang and Yu [22]
ing individuals, startups, established firms and public suggested that coopetition in R&D boosts innovation in
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 3 of 27
a firm. Addressing the manufacturing of telecommunica- similar attributes (e.g., age, gender, class, organizational
tion satellites, one of the most competitive segments of the role or company affiliation) [34, 35]. The same applies
space aircraft industry, Lopez-Fernandez et al. [23] pin- to the natural ecosystems where animal species tend
pointed that coopetition is filled with tension due to inher- to mate with similar ones [38]. Prior research dealing
ent contradictory and opposing forces. They contributed with inter-organizational networks, strongly suggests that
with a conceptual framework that increases the under- homophily drives the formation of corporate strategic
standing of tension in coopetition, and key approaches alliances [39, 40], the formation of entrepreneurial teams
to cope with it. Using empirical data from the semicon- [41] or the selection of human resources [42, 43].
ductor industry Park et al. [24] examined coopetition The concept of homophily was already addressed in
and its effects on innovation performance. The authors technology related contexts. The concept was integrated
conclude that competition and cooperation intensities in the ’diffusion of innovation’ theory [44], as acknowl-
have a non-monotonic positive relationship with firms’ edged previously by Software Engineering scholars
coopetition-based innovation performance. [45, 46], “one of the most distinctive problems in the dif-
Since coopetition applies to inter-firm relationships, the fusion of innovations is that the participants are usually
phenomenon is to be observed in inter-organizational net- quite heterophilous” [44]. Existing studies in Information
works, which many scholars more recently refer to by Systems also suggest that homophily plays a very impor-
using the ecosystems metaphor [14, 25–27]. Following a tant role in the assimilation of technology [47]. However,
trend from industry, there is an emergence of Software the concept remains largely unexplored in studies tak-
Engineering research with an interest in software ecosys- ing into account both the social and the technological
tems [28–30]. It is recognized that “ecosystem thinking” perspectives.
brought a radical shift in how Software Engineering is
being carried out, influencing fundamental aspects such 3 Research questions
as control, collaboration, business models, and innovation Our research questions focus on understanding the hybrid
[8, 31, 32]. behaviors of collaboration and competition within the
Knowledge of business ecosystems, or even of natural development of the OpenStack Nova open source project,
ecosystems, can also be useful for understanding software an example of a high-tech industrial Free/Libre/Open
ecosystems [28–30]. However, as pointed out by Hanssen Source software ecosystem involving competing firms
and Dybå, the software business has radically different that market similar products and services.
characteristics (e.g., short distance from design to use,
the intangibility of software, the high innovation veloc- RQ1 – What is the software development process used
ity) [30]. Hence, it is not clear to what extent theories to develop the OpenStack high-networked open
drawn from business and natural ecosystems apply in the source cloud computing infrastructure?
Software Engineering world. RQ2 – Are developers affiliated with different firms
Even if coopetition is a phenomenon that has an impact collaborating with each other in the project? How
on how R&D operations are conducted in an ecosystem does the collaboration evolve over time? How is
setting, there are very few empirical studies addressing collaboration affected by exogenous events in the
how rival software development teams simultaneously market?
collaborate and compete [33]. In Software Engineering, RQ3 – Is there a tendency towards sub-grouping in the
empirical research exploring the inherent notions of com- project? Are there different sub-communities within
petition and collaboration in software development teams the OpenStack ecosystem-community? Which ones?
is as well very scarce. Such scarcity is a principal raison How do developers cluster into different groups? Do
d’être for this research. developer clusters correspond to firms?
There are several known cases of open-coopetition (i.e., RQ4 – Do firms that compete in the same revenue
coopetition in the open source arena) as captured in model collaborate less in the ecosystem?
Table 1. The phenomenon where competing firms jointly
develop open source ecosystems has reached different 4 Case Study: OpenStack
R&D intensive sectors, following the development of the OpenStack is an open source software cloud computing
Internet, cloud computing, mobile-devices and automo- platform that is primarily deployed as an “Infrastruc-
tive technologies among others. ture as a Service” (IaaS) solution. It started as a joint
A key concept which emerged in this research was project of Rackspace, an established IT web hosting com-
the sociological concept of homophily - the tendency pany, and NASA, the well-known USA governmental
of individuals to associate and bond with similar oth- agency responsible for the civilian space program, aero-
ers [34–37]. A vast array of network studies pointed nautics and aerospace research. Today more than 200
out that humans tend to connect with humans sharing firms and many individual contributors contribute to a
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 4 of 27
set of different open source projects governed by the In order to provide evidences of competitive issues, we
OpenStack Foundation. exemplify in Table 2 and Fig. 1 how OpenStack firms
Both hardware and software developers affiliated with directly compete with each other for the same revenue
companies such as AT&T, AMD, Canonical, Cisco, Dell, streams. The network nodes in Fig. 1 represent the top
EMC, Ericsson, HP, IBM, Intel, NEC, NASA and many firms contributing to the OpenStack ecosystem while the
others, work together with independent, non-affiliated edges connect firms that compete for the same revenue
developers in a scenario of pooled R&D in an open source stream.
fashion. We decided to address the OpenStack case due to
its perceived novelty, its high inter-networked nature (i.e., 5 Methodology
an ecosystem involving many firms and individual con- We have combined qualitative analysis of archival
tributors), its heterogeneity (i.e., an ecosystem involving data (QA), mining software repositories (MSR) and
both startups and high-tech corporate giants), its market- Social Network Analysis (SNA) on publicly-available and
size ($1.7bn by 2016 as claimed by Al Sadowski 451 naturally-occurring data from the OpenStack Nova repos-
Research analyst in August of 2014 [48]), its complexity itory in order to re-construct and visualize the evolu-
(i.e., involving different programming languages, differ- tion of collaborations in a sequence of networks. Table 3
ent operating systems, different hardware configurations) presents a set of multidisciplinary methodological notes
and its size (17,020 community members, 100,000 code that guided our mixed methods research design.
reviews and 1,766,546 lines of code as recently reported We started in a qualitative way, by screening publicly
by Jason Baker from Red Hat in June 2014 [49]). available data such as company announcements, finan-
The OpenStack Nova project, our unit of analysis, is cial reports and specialized press reports, which allowed
a cloud computing fabric controller, the main part of an us to review an immense amount of on-line information
IaaS system. It is the largest and the most “core” project pertaining to the competitive cloud computing industry.
governed by the OpenStack Foundation. While taking into consideration established methodolog-
Even if OpenStack emphasizes the joint develop- ical notes that legitimate the use of archival data when
ment of a large and complex open source ecosystem, studying a case [10, 11, 50–52, 138], we gained valu-
there are competing firms within its community. For able insights from the industrial context surrounding the
instance, by October 2014, third-party software devel- OpenStack community. After attaining a better under-
opers could choose from three different firms offering standing of the industrial collaborative and competitive
OpenStack-based cloud computing public cloud services: dynamics, we extracted and analyzed the social net-
HP, Canonical and Rackspace. All those three firms were work of the OpenStack Nova project by leveraging SNA
fighting for revenues from OpenStack-based cloud com- [53–55]. By mining digital traces of code collaboration,
puting services marketed under different brands: HP and by uncovering the social structure of the OpenStack
Helion Public Cloud, Ubuntu Cloud, Ubuntu BootStack, Nova project, the computerized SNA revealed key pre-
Rackspace Cloud Servers and Rackspace Public Cloud. In liminary understandings of coopetition in the OpenStack
other words, besides contributing to the same project, ecosystem that were later re-investigated with comple-
all the three mentioned firms competed for revenues mentary qualitative data. The combination of methods
from third-party actors “renting” public cloud services. was not only fundamental for the retrieval of social struc-
Within the hardware business, many contributors to tures, but also for explaining them.
OpenStack such as IBM, HP and Nebula also compete We first explored social networks data with Gephi
in sales of specialized hardware for cloud-computing (v0.8.2) [56] and the sna (v2.3-2) and statnet (v2014.2.0)
installations. statistical modules [57, 58] for R (v3.0.2) [59], based
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 5 of 27
on the OpenStack Nova project changelog. As in prior are consistent with more focal and discipline-oriented
multi-disciplinary studies [60, 146–148], our analysis guidelines established in Software Engineering [11, 69],
emphasizes the visualization of the collaboration network, Information Systems [50, 51], Operations Research [52]
which evolves over time, to reveal dynamics among the and Management [70, 71].
OpenStack software developers. We then attempted to More especially, we have reviewed the most relevant
understand the visualized networks with our acquired public announcements of companies, publicly avail-
understanding from the competitive cloud computing able financial reports, publicly available documenta-
industry in general and OpenStack in particular. The tion supporting software development, news from both
visualization, together with a deeper understanding of specialized and generalist press, discussions in forums,
the phenomenon under investigation, corresponds to the white-papers and blogs. The selection of sources took in
notion of figuration [61] as pointed out in several stud- consideration key guidelines on how to conduct quali-
ies [62, 63, 147]. Studies which take a SNA perspective for tative empirical research online [72, 73]. The Kozinets’
building social network visualizations are already becom- four criteria for selecting from on-line data sources [72]
ing established in Software Engineering studies in general, set the departure points from where we started collecting
and in FLOSS research in particular [64–67, 141]. Even relevant empirical material.
so, very few Software Engineering studies exploit the We also took into consideration specific notes on how
potential of social network visualizations for exploratory to account archival data within a case study, we counter-
research as suggested by [68]. act possible biases by including many and diverse media
sources [10, p. 12,13]; we exploited peer debriefing by con-
5.1 Data collection ducing the analysis as a group instead of one working
Our screening of public and naturally-occurring data alone [69, p. 12,13]; and organized the collected quanti-
available on the Internet followed established method- tative textual data within an digital content management
ological guidelines on case study research [10, 138] which system for meticulous record-keeping [50, p. 374].
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 6 of 27
In Table 4 we point out our selected departure points for scripts that validated and corrected repository commit
collecting relevant on-line archival data. From the initially data, for instance to deal with small mistakes performed
selected sources, we followed many ‘links’ and end up by developers that submitted code with Unrecognized
visiting many other sites (e.g., corporate sites from com- author (no email address), Unrecognized author (with
panies involved in the development and commercializa- email address) or with an invalid email. Second, we had
tion of OpenStack technologies or blogs from individual to deal with the fact that some developers do not commit
OpenStack contributors). their changes with their corporate account (e.g., a devel-
After the retrieval and qualitative analysis of the selected oper commits code using [email protected] instead
archival data, we also conducted SNA which allows us of [email protected], while actually affiliated with HP).
to depict overall pictures of the coopetitive dynamics This problem was tackled by manually triangulating our
among different developers in the project. Knowledge automatically-retrieved affiliation results with data from
gained from earlier phases of this study (more qualitative) the Foundation affiliation database using two external
on OpenStack’s actors, events, processes and technology data sources [74, 75].
informed the subsequent SNA design.
The input data of SNA is based on different source 5.2 Data analysis
code release versions of the OpenStack project. The lat- Our empirical materials span the time period from
est source code snapshot from the repository of the October 21st 2010 to April 17th 2014. After the
OpenStack Nova project was performed on 16 June of Cactus release (April 15th 2011), OpenStack aban-
2014, using git (v1.8.5.1). From the repository changelog doned the 3-month time-based release cycle for a coor-
documentation, we extracted basic information, includ- dinated 6-month release cycle with frequent development
ing developer email addresses and the time stamp when milestones [76–78]. Thus, we opted to take a longitudinal
changes to a specific file had been made (see Fig. 2). approach and to construct SNA visualizations that depict
We then connect the developers who work on the same collaborative behaviors release after release. Table 5 lists
file, and construct a network of collaboration activities the 9 releases of OpenStack addressed by this study.
among the developers. With the visualization of the col- The design choice was inferred by characteristics of
laboration network over time, we aim to understand the the OpenStack project: 1) The cyclical nature of Open-
evolution of the code-based collaborations with a lens of Stack development where each release cycle encom-
social structure. passes planning, discussion, implementation and fixing
The process of associating the developer email address release-critical bugs in a sequential way [78]; and 2) The
with code commits is one of the most challenging steps OpenStack scheduling policy, where developers are dis-
in this research. First, we developed a set of Python couraged from implementing new features during the
last development milestone and concentrate efforts on During the planning phase of each release, the commu-
bug-fixing for the coming release candidates [78–80]. nity gathers for a Design Summit to facilitate live devel-
As illustrated in Fig. 3, we narrow code-collaboration as oper working sessions and to assemble the OpenStack
a synchronous behavior happening within a release. It roadmap. Documentation regarding the development sta-
is important to remark that due to this design choice tus of the current release and decisions made at each
our research does not capture collaboration between two Design Summit are publicly available [81].
developers who contributed to the same file but in a From publicly available data [74, 75] and reports sup-
different release cycle. porting decision-making in the OpenStack ecosystem
In line with existing guidelines on how to combine [82], we observed an onion model, as addressed in the
digital trace data with SNA [145], we constructed the open source research literature [64, 83, 84], with a rela-
collaboration network of developers for each partitioned tively dense core [82]. This indicates that a small set of
time-slice (i.e., by software release date). In this way, we developers (mostly affiliated to a company) account for
are able to assess how the collaboration network has most of the development activity. Therefore, in order to
evolved over time in response to the exogenous events in better understand collaboration in such a complex collab-
the industry. orative network and to minimize the impact of outliers, we
decided to focus our research on the developers affiliated
Table 5 Releases of the OpenStack community with the top 10 contributing firms to the OpenStack Nova
Release date Release name project during the complete period under study. These
firms were selected using classical code metrics provided
Oct 21st, 2010 Austin
by Bitergia and Mirantis (i.e., number of commits, lines of
Feb 3rd, 2011 Bexar
code and number of completed blueprints).
Apr 15th, 2011 Cactus The selected top 10 firms contributing to OpenStack
Sep 22nd, 2011 Diablo Nova, briefly introduced in Table 6, can be formally
Apr 5th, 2012 Essex defined as:
Sep 27th, 2012 Folsom
Apr 4th, 2013 Grizzly
TOPTEN ={Canonical, Citrix, Cloudscaling, HP, IBM,
Oct 17th, 2013 Havana
Mirantis, Nebula, Rackspace, VMware, Red Hat}
Apr 17th, 2014 Icehouse
(1)
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 9 of 27
The collaborative network during a certain time slice can same software source code file. An edge will exist iff
be formally defined as: two developers have modified the same file during
the release under study. Edges are both unweighted
Gt = (V , Av, E)
and undirected.
where:
Various numeric network measures have been estab-
• V is the set of nodes representing the developers lished in SNA: for example, eigenvector-centrality [85,
∈ TOPTEN contributing to the OpenStack Nova 86], degree-centrality and betweenness-centrality [53]; all
open source software project. All other developers revealing the importance of a node in a network. Other
not affiliated with the top 10 contributing firms are aspects of a network can also be manifested with impor-
not considered in this study. tant measures such as network-density [54], cluster coef-
• Av is the set of nodes-attributes, capturing the ficients [87], strength of ties [88], etc.
company affiliation of a developer. However, as our SNA goes hand-in-hand with
• E is the set of edges, identifying the connections qualitative analysis of a very competitive and dynamic
between two developers if they have worked on the environment, we concentrated our efforts in visualizing
the network graphs, which was sufficient to uncover mode (as reported in other open source projects
some history line and to reveal the dynamics of coopeti- [95, 96]).
tion in an observational way. Although the visualization The ‘planning stage’ is at the start of a cycle, just after
of social networks has been widely utilized by scholars the previous release. This phase usually lasts 4 weeks and
[60, 64, 141, 147, 148], few studies have explored the time runs in parallel with the OpenStack Design Summit on
dimension in order to observe how networks evolve lon- the third week (in a mixture of virtual and face-to-face
gitudinally [3, 89]. At a later stage, we also used another collaboration). The community discusses among peers
specialized software tool, Visone(v2.7.3) [90], to visualize gathering feedback and comments. In most cases, specifi-
a sequence of networks according to the established cation documents are proposed via a support system [97]
release cycle, and to interpret the network evolution that should precisely describe what should be done. Con-
with understanding generated from the collection of rich tributors may propose new specs at any moment in the
qualitative material capturing the network dynamics. cycle, not just during the planning stage. However doing
Given the high density of the collaborative networks so during the planning stage is preferred, so that con-
during the last releases, and in order to better address tributors can benefit from the Design Summit discussion
RQ3 (who tends to collaborate with whom in the project), and the elected Project Team Leads (PTLs) can include
we also explored sub-community detection methods. those features into their cycle roadmap. Once a specifica-
Among a number of possible methods from Graph Theory tion is approved by the corresponding project leadership,
[91, 92, 153, 154], we opted for a novel technique based implementation is tracked in a blueprint [98], where a
on the extraction of Simmelian backbones [155], due to its priority is set and a target milestone is defined, com-
efficiency to analyze complex networks with unweighted municating when in the cycle the feature is likely to go
edges. live.
The obtained social network visualizations (key part of The ’implementation stage’ is when contributors actu-
our data analysis) added rigor and comparative logic to ally write the code (or produce documentation, test
the qualitative description (via triangulation of research cases among other software related artifacts) mapping the
methods) as suggested by Eisenhardt [93, 138]. However, defined blueprints. This phase encompasses a number
it also added ‘pictures’ of the social structure, which per of milestone iterations (a characteristic of agile software
se increased the richness of the qualitative description as development methods). Once developers perceive their
rejoindered by Dyer [94]. work as ready to be proposed for merging into the master
branch, it is pushed to OpenStack’s Gerrit review system
for public review [99]. It is important to remark that in
6 Results order to be reviewed in time for a milestone, the change
6.1 A overview of the software development process should be proposed in the weeks before the targeted
Directly addressing RQ1, we constructed a brief qualita- milestone publication date. An open source software col-
tive description of collaborative software development of laboration platform [100] is used to track blueprints in the
OpenStack, as can be found in the software engineering ’implementation stage’. In an open source way, it is worth
literature for other projects [83, 139]. Such description remarking that not all “features” have to go through the
directly derives from many sources of archival data which blueprints tracking: contributors are free to submit any
have been preserved throughout the history of Open- ad hoc patch. Both specifications and blueprints are tools
Stack [76–80]. The process data is naturally occurring supporting the discussion, design and progress-tracking
(i.e., not provoked by the researchers), not created for of the major features in a release. Even if the big corporate
research purposes but to guide and steers real software contributors are naturally more influential in the election
developers contributing to OpenStack. As our analysis of PTLs steering the tracking process, it should not pre-
covered more than 4 years of the OpenStack project lifes- vent other contributors from pushing code and fixes into
pan, and as the process kept evolving, the description is OpenStack. Development milestones are tagged directly
based on the most recent releases of OpenStack (i.e. years on the master branch during a two-day window (typically
2014–2015). between the Tuesday and the Thursday of a milestone
OpenStack operates a time-based cyclical software week).
development process where each release cycle encom- At the last development milestone OpenStack applies
passes planning, discussion, implementation and fixing three feature freezes (i.e., FeatureFreeze, DepFreeze and
release-critical bugs (all in a sequential way). During our StringFreeze). At this point, the project stops accept-
investigation we notice that during the earlier release ing new features and disruptive changes, and concen-
phase, the ‘coding’ efforts are discussion and specification trates on stabilization, packaging and translation. The
oriented, while in a later release phase (i.e., stabilization of project turns then into a ‘pre-release stage’ (termed
release candidates) the development turns into bug-fixing as ‘release candidates dance’ [78]). Contributors are
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 11 of 27
encouraged to turn most of their attention to testing “What is OpenStack? Well, our mission statement says
the result of the development effort and fix release- this:
critical bugs. Critical missing features, dubious features
and bugs are documented, filed and prioritized. Contrib- To produce the ubiquitous Open Source Cloud
utors are advised to turn their heads to the quality of Computing platform that will meet the needs of public
the software and its documentation. The development and private clouds regardless of size, by being simple to
becomes mainly bug-fixing oriented and a set of norms implement and massively scalable.
and tools guide this last product-stabilization phase [101,
102]. Any change proposed for the master branch should That is a big ambition. The good news is that
at least reference one bug on the bug-tracking sys- OpenStack is starting with code contributions from
tem. Once all the release-critical bugs are fixed, Open- two organizations that know how to build and run
Stack produces the first release candidate for that project massively scalable clouds - Rackspace and NASA.
(named RC1). Rackspace has been in the cloud business for 4 years
The OpenStack release team is empowered during this and now serves tens of thousands of customers on its
last phase. It creates a stable/* branch from the current cloud platform. Likewise, NASA began building their
state of the master branch and introduces any new release- Nebula cloud platform 2 years ago to meet the needs of
critical fix discovered until the release day. Between the their scientific community” — Jim Curry, OpenStack
RC1 and the final release, OpenStack looks for regres- Lead, 19 July 2010 [103]
sion and integration issues. RC1 may be used as is for
the final release, unless new release-critical issues are Visualizations in Figs. 4, 5, 6, 7, 8, 9, 10 and 11 provide
found that warrant a RC respinning. If this happens, a an understanding of how key players in the cloud com-
new milestone will be open (RC2), with bugs attached puting industry collaborate in a Free/Libre/Open Source
to it. Those RC bug fixes need to be merged in the software ecosystem. SNA visualizations are not just ‘pretty
master branch before they are allowed to land in the pictures’ as network studies are periodically criticized
stable/* branch. Once all release-critical bugs are (counter-arguments to this criticism can be found in
fixed, the new RC is published. This process is repeated as [104]), but exploit combinations of text, signs, color, size,
many times as necessary before the final release. As it gets location and shape to communicate several pieces of
closer to the final release date, to avoid introducing last- numerical information simultaneously [105]. Each net-
minute regressions, the release team limits the number work visualization aggregates both numbers, mathemati-
of changes and their impact: only extremely-critical and cal formulae, and written text which have to be otherwise
non-invasive bug fixes can get merged. All the other bugs communicated sequentially [106].
are documented as known issues in the Release Notes In our visualizations, the size of a node is dependent
instead. on its degree-centrality; i.e., the larger the node, the more
On the release day, the last published Release Candi- social connections the developer has. The value of degree-
date of each integrated project is collected and the result centrality depends on the number of adjacent nodes with
is published collectively as the OpenStack release for this which a node is connected. Therefore, the higher a devel-
cycle. OpenStack should by then be stable enough for real oper’s degree-centrality, the more likely he/she is collabo-
industrial deployments. But once the version is released, rating with others.
a new cycle will commence within OpenStack; the master Figure 4 captures collaboration in the OpenStack Nova
branch switches to the next development cycle, new fea- project from the Austin to the Bexar release, from
tures can be freely merged again, and the process starts October 21st 2010 to February 3rd 2011. From it, we can
again. derive the collaboration between software developers
affiliated with companies; so, Citrix had three developers
6.2 Longitudinal description of collaborative and working on the project together with Rackspace.
competitive issues “OpenStack provides a solid foundation for promoting
To answer RQ2 we will take a chronological approach. the emergence of cloud standards and interoperability.”
We will proceed by quoting the words of Jim Curry in .... “As a longtime technology partner with Rackspace,
one of the first announcements of the OpenStack project. Citrix will collaborate closely with the community to
The founding leader of the OpenStack community starts provide full support for the XenServer platform and
by advocating the freedom of open source software before our other cloud-enabling products.” — Peter Levine,
stating the mission of the the OpenStack project. It is SVP and GM, Citrix, 19 July 2010 [107]
important to notice that Jim Curry emphasized the roles
of NASA and Rackspace as initial contributors to the Citrix who have been working before with Rackspace,
project; project did not start from zero. wanted to make sure that their XenServer platforms
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 12 of 27
would be conveniently integrated with Rackspace plans 2011). From this visualization we can observe a new node,
for OpenStack. a developer affiliated with Cloudscaling. Cloudscaling
was founded in 2006 by the cloud architect and open
“The project is exhibiting the key benefits that the source software advocate Randy Bias, and the co-founder
industry derives from successful open source Adam Waters. It started as a professional services com-
collaboration: rapid development, faster testing, pany selling custom cloud infrastructure for large service
feedback and project turn around, broader industry providers, chiefly telecom service providers. They had
adoption and learning through implementation and KT (formerly Korea Telecom) as an early customer, for
de-facto standardization whilst avoiding the prospect which the company in 2010 designed and deployed the
of commoditization. first OpenStack-based storage cloud outside Rackspace.
It has been rewarding to work with the OpenStack
crew, and to have experienced first hand the dedication
to an open, code-rules, community-first approach “Earlier this week, one of our clients, a Tier 1 ISP,
taken by the project leaders. OpenStack has shown launched an object storage cloud based on OpenStack,
that it is possible to rally the community around the an open source compute and storage framework
development of “management” software - as opposed created by Rackspace and NASA. The new storage
to the Linux kernel or Xen - and it is definitely the case cloud is the first commercial OpenStack-based storage
that OpenStack is breaking new ground for the industry offering in the market after Rackspace itself, which is
at large. With the release behind us, our team will head based on the same technology.
in force to San Antonio for the next Design Summit.” Cloudscaling assisted in developing
— Simon Crosby, CTO, Citrix 21 October 2010 [108] this solution for the new product, including
hardware, networking, configuration, systems
Our second visualization with degree-centrality, integration, monitoring and management.” – Joe
in Fig. 5, captures collaboration from the Bexar to the Arnold, Director of engineering, Cloudscaling, 31 of
Cactus release (from February 3rd 2011 to April 15th January 2011 [109]
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 13 of 27
Our visualization in Fig. 6 captures collaboration from “Our internal infrastructure is running on Fedora,
the Cactus to the Diablo release (from April 15th 2011 instead of migrating the full infrastructure to Ubuntu,
to September 22nd 2011). HP (a well-known IT multi- we decided to make OpenStack Fedora-friendly.” –
national company), Mirantis (an OpenStack startup), and Maxim Lvov, Senior deployment engineer, Mirantis,
Red Hat (the company behind the Red Hat Enterprise 18 of May 2011 [110]
Linux and sponsor of the Fedora Linux distributions)
joined the coopetitive software development efforts. “Are you aware of the upstream effort to create
Mirantis was founded in January 2011 by Boris Renski packages for Fedora?” ... “would you be willing to
Jr. and Alex Freedland. Also born in Northern California, contribute your specs if you really build your rpms
this startup marketed itself as a “pure-play” OpenStack from the sources?” – Fabian Deutsch, Contributor to
company and started working early with Red Hat. Dur- the Fedora project, 20 of May 2011 [110]
ing our qualitative analysis of on-line data on the Inter-
net, we came across a conversation between engineers “I’ve had a conversation with David Nalley about
from Mirantis and an open source enthusiast contribut- contributing to Fedora. Sure, we are willing to
ing occasionally to the Fedora project. Such conversation contribute. We are under refactoring, and we’ll show
provided qualitative digital trace data evidencing collabo- them soon.” – Mike Scherbakov, OpenStack architect,
ration between Mirantis and Red Hat [110]. 20 of May 2011 [110]
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 16 of 27
Meanwhile, HP started marketing their cloud comput- initiatives such as in the Apache and Eclipse projects, and
ing services based on OpenStack. HP markets itself as has been able to sell complementary solutions (i.e., hard-
the leading corporation behind the project, emphasiz- ware, software and services) from open source projects.
ing that OpenStack is the only cloud computing solution It expects the same business model to work well with
without a single-vendor lock-in, but with an extensive OpenStack.
ecosystem behind it [111]. Another key startup to Open-
Stack was born in those days, Nebula. Nebula was founded “Our goal is to accelerate the rate and pace of both
also in Northern California in Spring 2011 by Chris C. functional and non-functional (performance,
Kemp, a former NASA Chief Technology Officer, his long- scalability, reliability, etc.) enhancements to the
time colleague Devin Carlen, and the entrepreneur Steve OpenStack code base. In that vein, IBM will be a very
O’Hara. The company absorbed much of the original active participant in the next OpenStack Design
NASA team which coded the first bits of OpenStack [112]. Summit scheduled for October 15–19 in San Diego.
Figure 7 depicts collaborations from the Diablo to the The time has come to establish a de-facto base
Essex release (from September 22nd 2011 to April 5th implementation for IaaS and related open interfaces.
2012). Although the graph becomes more dense, we can Without this, the industry risks fragmentation and
visualize new nodes representing early contributions of complexity that will only serve to slow down the
Intel (interested in making OpenStack deployments work adoption of cloud technology and innovation. Support
well on Intel micro-processors) and IBM. IBM has a long for OpenStack and the OpenStack Foundation is an
history of working with open standards and open source effective way to achieve this goal. In a Wired.com blog
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 17 of 27
I wrote back in April, I highlighted three initial focus 2011. This turn of strategy from Citrix is related with the
areas for IBM: 1) Establish the OpenStack Foundation, OpenStack lack of integration with the Amazon’s APIs
2) Support and expand the OpenStack Ecosystem and (Application Programming Interfaces). Amazon is cur-
3) Contribute to the OpenStack Development.” – rently the leader of cloud services, and the migration costs
Angel Diaz, Vice President of Open Standards, IBM, to another cloud computing infrastructure are very high,
19 of September 2012 [113] specially if the APIs do not resemble each other.
investing increasingly in the development of OpenStack, Figure 11 captures collaborations in the latest period
interested in keeping its Linux Distribution Ubuntu as the studied, from the Havana to the Icehouse release (from
leading Linux distribution for OpenStack clouds [115]. October 17th 2013 to April 17th 2014). In this visualiza-
VMware, a Northern Californian firm with exper- tion, the number of network nodes (i.e., software devel-
tise in virtualization technologies, made substantial opers affiliated with TOPTEN firms in the OpenStack
contributions (evidenced by the number of commits) Nova) decreased, while retaining a similar density. This
during this between-releases period [116]. The acqui- fact must be interpreted carefully, as it does not mean
sition of the networking virtualization startup Nicira that the number of software developers contributing to
in July 2012 reshaped the VMware cloud comput- the OpenStack Nova is now lower. There were currently
ing strategy. As a sign of commitment to OpenStack, 313 developers contributing with code, and 483 develop-
VMware and Canonical issued a joint statement on their ers reviewing code during this period. The community
intentions to work together to improve the integra- contributing to the OpenStack Nova project increased sig-
tion VMware technologies with Canonical’s OpenStack nificantly, while the role of the TOPTEN firms decreased.
distribution. As of this release, Intel, NEC, Huawei and the rest of the
non-affiliated developers grouped together would belong
to the TOP 10 contributors of the Icehouse release
“(OpenStack Summit) Canonical and VMware, Inc.
– although considering the whole lifespan of OpenStack
(NYSE: VMW), the global leader in virtualization and
the project, we have considered them to be out of the
cloud infrastructure, today announced a collaboration
TOP 10.
that will enable organizations to deploy VMware
By this time the role of NASA on OpenStack had dimin-
technologies, including VMware vSphere and Nicira
ished. The first developments of OpenStack were in the
NVP, with Canonical’s OpenStack distribution.
service of science, supporting NASA’s research activi-
Canonical’s Ubuntu Cloud Infrastructure, the most
ties. NASA’s prestige and participation has been a selling
widely used OpenStack distribution, will now include
point for advocates of OpenStack technologies. NASA
the plugins required to use OpenStack with vSphere
lost much of its IT staff working on its Nebula cloud
and NVP. Canonical will provide commercial support
computing project. Software developers and IT architects
for OpenStack and will collaborate with VMware on
headed to startups and high-tech giants within the Open-
issues related to vSphere or NVP running with
Stack ecosystem. Moreover, a cost-driven IT reform led to
OpenStack. In addition, VMware reaffirms its support
disinvestment in OpenStack by NASA. Today, scientists
of Ubuntu as a fully supported guest operating system
at NASA depend on Amazon EC2 and Microsoft Azure
(OS) on vSphere. This agreement will enable
cloud computing infrastructures [119]. While much of
customers the flexibility to deploy and reliably run
the scientific data Meanwhile, on the other side of the
OpenStack clouds with Ubuntu Cloud Infrastructure
Atlantic, the European Organization for Nuclear Research
on VMware vSphere while receiving commercial
(CERN) decided on an OpenStack based strategy in
support.” – Joint press release from VMware and
2012. In January 2014, OpenStack was already running
Canonical, Acquire Media, 16 of April 2013 [116]
collision reconstructions at the Large Hadron Collider
(LHC) [120].
Figure 10 captures collaboration in the project in a
more recent phase, from the Grizzly to the Havana 6.3 Ecosystem and its sub-communities
release (from April 4th 2013 to October 17th 2013). We In order to carefully address RQ3 we employed
can see that VMware took its commitment to OpenStack sub-community detection methods to discover sub-
seriously, as six new developers engaged in developing communities in the ecosystem. Particularly for the last
with other OpenStack developers affiliated with TOPTEN releases, with very dense networks, the direct inter-
firms. Mirantis, in yellow on the right of Fig. 10, invested pretation of the visualizations is extremely difficult.
heavily in collaborative activities with IBM, Rackspace We opted to use data from the last OpenStack releases
and Red Hat. Mirantis counted on financial support from (Grizzly, Havana and Icehouse) because of higher
Dell Ventures and Intel Capital (representing the interests project maturity and a steady diminution of group
of hardware manufacturers betting on OpenStack) [117] cohesion (i.e., tendency for subgrouping) as “plotted” in
and additional investment by Ericsson, Red Hat, and SAP Fig. 12. The figure includes three basic social network
Ventures [118], turning it into one of the biggest code con- metrics that capture the evolution of the collaborative
tributors to the OpenStack software ecosystem in just a network over time/release: number of nodes, number
few months as reported by Bitergia [82]; the number of of edges and network density, all correspondent mea-
developers from Mirantis increased from 1 to 17 in this sures of community-size, collaborative behavior and
time period. community cohesion.
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 19 of 27
Fig. 12 Evolution of the size of the community, collaborative relationships and cohesion of the community over time
As a result of the extraction of Simmelian backbones (i.e., sub-communities): a larger one involving IBM, HP,
from the collaborative network of the last OpenStack Rackspace, Red Hat and Mirantis (see top-left Fig. 13b);
releases, the emergent sub-communities in Fig. 13 reveal, and two smaller ecosystem-groups including 1) VMware,
contrary to what the authors expected, a low degree of Red Hat, IBM and HP (bottom of Fig. 13b); and 2) IBM,
homophily in code collaboration, meaning that develop- HP and Rackspace and Red Hat (top-right of fig. 13b).
ers do not tend to work with developers from their own There were overlapping communities (e.g., Red Hat is
company. present in all the detected groups). It is also important
Instead of visualizing the complex “raw” collaborative to notice that among the top 10 firms contributing to the
network (see Fig. 13a), by using the sub-community detec- OpenStack project, no firm had their developers working
tion technique, we can depict three ecosystem-groups with each other in an isolated sub-community.
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 20 of 27
(a) (b)
Fig. 13 Sub-community structure extraction
6.4 Exploring the relationship between revenue-models Either by the calculated network densities or by the
and collaboration visualizations, we can conclude the following:
For addressing RQ4, we can also exploit network analysis
to explore how competition for a revenue stream affects
collaboration in the OpenStack Nova case. This can be • Companies providing complementary software
done (as displayed in Table 7) by calculating the density collaborate more than companies not providing
of the two collaborative networks: collaboration among complementary software.
firms competing for a specific revenue stream vs. collab- • Companies providing complementary hardware
oration among firms that do not compete for a specific collaborate more than companies not providing
revenue stream. It should be noted that density is a mea- complementary hardware.
sure of cohesion, collaboration and learning. Alternatively, • Companies providing distribution and support
but less precisely, it can be also be done by zooming and collaborate more than companies not providing
visualizing side by side collaboration among firms com- complementary distribution and support.
peting vs. collaboration among firms that do not compete • Companies providing public clouds collaborate less
(see Fig. 14). than companies not providing public clouds.
Table 7 Community cohesion across firms competing for the same revenue stream
DO DO NOT
n(αi ) n(βi )
Competing revenue stream Revenue stream description Competing firms den(αi ) den(βi )
136 0
Firms providing specialized support, ALL TOPTEN 1 UND
Complementary services maintenance, integration,
customization, testing, consulting, etc.
76 65
Firms providing software embedding IBM, VMware, Nebula, 0.472 0.362
Complementary software OpenStack or complementary drivers Cloudscaling, Red Hat,
and plug-ins. Citrix, Canonical
69 67
Firms providing hardware targeting IBM, HP, Nebula 0.459 0.434
Complementary hardware OpenStack installations.
91 45
Firms distributing OpenStack with Red Hat, IBM, HP, 0.460 0.425
Distribution and support enterprise support (for a fee). VMware, Canonical
41 95
Firms providing OpenStack based HP, Rackspace, Canonical 0.3200 0.458
Public cloud services public cloud services such as hosting.
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 21 of 27
(a) (b)
(c) (d)
(e) (f)
(g) (h)
Fig. 14 Visualizing the impact of competition for the same revenue revenue model
These results suggest that the open competition strategy occurred when Cloudscaling deployed OpenStack to KT
is working well for the firms involved in the development (formerly Korea Telecom); it also happened when Miran-
of the OpenStack Nova. Even if they are competitors for tis helped in deploying OpenStack to AT&T, suggesting
the same revenue stream they do not collaborate less, with that HP, Rackspace and Canonical are forced to collabo-
the exception of HP, Rackspace and Canonical, who are rate more with others since they are deploying OpenStack
providers of public cloud computing services. internally. Those OpenStack installations must be run-
During our investigation we observed that collabora- ning smoothly, with high guaranteed up-time, enabling
tion increased when a firm from the OpenStack ecosystem revenues from selling computing services to the public as
was deploying (i.e., installing or delivering) OpenStack. It Amazon, Microsoft and Google do.
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 22 of 27
7 Discussion, including further research or other arrangements where access is granted only to
7.1 Homophily a few selected partners [1, 4]. In the OpenStack case,
The visualizations of degree-centrality Figs. 4, 5, 6, 7, 8, everyone is welcome to contribute to the project, and
9, 10 and 11 ascertained the hyper-collaborative nature everyone is allowed to copy, sell and distribute outcomes
of the OpenStack as its developers often collaborate with from the project. Prior coopetition research, derived
developers affiliated with competing firms. In a more pos- from the Nordic milk industry, proposed that coopetition
itivist way, the sub-community detection process revealed activities take place far from the customer – “competi-
a small degree of homophily in code collaboration. As tors cooperate with activities far from the customer and
visible from Fig. 13, sub-communities within the Open- compete in activities close to the customer” [2]. How-
Stack Nova project are highly heterogeneous as they tend ever, as we observed code-contributions from many dif-
to include developers from many different firms. These ferent end users (such as AT&T, NASA and CERN),
results contradict with prior sociological studies report- we illustrate that in the open source arena, coopeti-
ing the tendency of individuals to associate and bond with tion can also occur very close to the market and the
similar others [34–37]. customers.
Surprisingly, the low level of homophily in code collab- We have assessed how revenue models affect collabora-
oration contradicts an expected social behavior. Why do tion in OpenStack: Contrary to expectations, and visible
not developers tend to collaborate with colleagues that in Fig. 14 and Table 7, and with the exception of a few
should represent the same business interests within the firms providing public cloud services (HP, Rackspace and
ecosystem? What drives homophily? Is this because of the Canonical), firms competing for the same revenue model
openness of FLOSS projects? Is it due to the increasing (i.e., where rivalry is expected) tend to collaborate more
virtualization of work practices as developers collaborate than firms that do not compete for the same revenue
with reduced face-to-face interactions? Future research model.
should assert if the observed low level of homophily is
a characteristic only of OpenStack, or more generally of 7.3 Understanding the dynamics of industrial FLOSS
FLOSS and/or other coopetitive projects. projects
We believe that the Software Engineering discipline can
7.2 Coopetition theories and business models benefit from developing code-collaboration metrics and
Our case study integrates with the established literature visualizations based on developers attributes (e.g., affil-
on coopetition. We confirm that the need for external iation) as a valuable complement to established soft-
resources is a main driving force behind the establishment ware development metrics emphasizing code size, code
of long-term cooperative relationships [121]. Additionally, quality and productivity. The information that can be
through cooperation, two companies can gain access to obtained by this means can lead to better decision mak-
each other’s unique resources or share the cost of develop- ing by stakeholders and investors, as well as to point
ing new unique resources [2, 122]. Within an open source out possible technical and organizational problems in the
scenario, it is an open to and networked community that project [123].
fulfills the need for external resources. Moreover, accord- In the case of projects with an ample number of indus-
ing to Bengtsson and Kock, individuals within a firm can trial corporations, having the possibility of a transparent
only act in accordance with one of the two logics of inter- development process is of key importance. Nonethe-
action at a time, i.e., either compete or collaborate [2]. less, companies are reluctant to invest significant capital
Hence, the two logics either have to be divided between and/or resources on a coopetitive project in perceived
individuals within the firm or need to be controlled and disadvantage to its competitors (i.e., fear of exploitation
regulated by an intermediate organization such as a col- or other non-cooperative behaviors). Thus, this type of
lective association. Again, within an open source scenario, analysis facilitates the generation of trust and confidence
it is the project community that plays the role of such among stakeholders, resulting in a win-win cooperative
an intermediate organization. Developers must identify relationship.
themselves with the project community in order to be Related to the above is the fact that collaborative soft-
able to collaborate with rivals in the same community. ware development processes should be fair. No matter
In our case, developers must identify themselves with how advanced the technology being developed or how
the open source community, the OpenStack Foundation involved a stakeholder might be, if some of the involved
or the OpenStack community to engage in coopetitive companies or individuals perceive that the project is not
behaviors. neutral to all stakeholders, this can arise mistrust and
Our research however finds discrepancies with prior lit- neglection which may end in abandonment or forking of
erature on R&D coopetitive networks, which addresses the project. Given the proliferation of industrial FLOSS
alliances in a form of either joint-ventures, consortia projects in recent times, future research should undertake
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 23 of 27
what a fair development process is, incorporating process project. Thanks to complementary ethnographic knowl-
metrics that conveniently address this issue. edge we know that Mirantis has been in contractual sup-
Also, an analysis like the one carried out enables super- ply relationships with AT&T, Cisco, Red Hat and NASA.
visor agents, as is the case with the OpenStack Foundation Moreover, other companies contributing to the project
in our case study, to identify possible malfunctions in the (e. g., Intel, Ericsson, Red Hat and SAP) have equity par-
community. This can be the case of companies that do ticipation within Mirantis. Hence, pure repository-driven
not want to be integrated into the community or to coop- quantitative judgments about the centrality, importance
erate with other companies. Our idea hence expands the or influence of actors within a software ecosystem setting
notion of community metrics [124, 125] from the indi- must be interpreted very carefully.
vidual developer to organizations by including affiliation
information. 8 Threats to validity
Practitioners from the high-tech sector can further 8.1 Threats to construct validity
explore the potential of using our socio-structural visual- These threats consider the relationship between theory
izations for better communicating the importance of their and observation, in case the measured variables do not
contributions to particular open source software projects. provide a good measure of the actual factors. A main
High-tech firms are already active in claiming their contri- simplification in our modeling of reality has been how
butions to the open source community [126–128]; the use we identify collaboration in our case study. So, collabo-
of the implemented visual approach can be used for com- ration was narrowed to working on the same code files;
municating the social importance of a firm in a project. other software development activities (testing, bug-fixing,
The same socio-structural visualizations are more valu- translation, code-review, specification, testing, design)
able when complemented with rich textual descriptions should be included. In addition, only modifications to the
of what was contributed [126] or in combination with same file during a software release have accounted for
measurable quantities of contributed source code [129]. collaboration, artificially limiting its scope and dimension.
Future research efforts from a software engineering Some choices regarding the SNA can also be improved.
point of view could be focused on obtaining better com- So far, we only used density as a community cohesion
munity cohesion metrics and the development of code metric, other network-based measures for the same con-
collaboration metrics. They might not make sense in a struct (e.g., transitivity, compactness, connectedness and
small development team, but they are definitely relevant distance-weighted fragmentation among others) should
in a high-networked ecosystem where ‘who works with be considered for enhancing the rigor of this research.
who’ is not obvious. Other ways of measuring collabora- In addition, our method is still supported mainly by
tion (i.e., at the function level instead of at the file level) visualizing the resulting SNA graph and its attributes,
or other types of collaboration (i.e., reviews, bug fixing, although other means might be more suitable (i.e., a
etc.) would help understanding these type of communities matrix based solution). Efforts should be also invested
better. The inclusion of weighted edges would add more in exploring regressions of SNA topological properties
tangible information on the frequency and importance of with other measures such as activity or quality, that for
the collaboration among stakeholders. the sake of parsimony have not been included in this
manuscript.
7.4 Mixed method approach
Our findings suggest that by methodologically combining 8.2 Threats to external validity
more ethnographic qualitative methods with social net- These type of threats consider the problematic of gener-
work visualizations, we can produce longitudinal and rich alizing our findings. In our research, we show evidence
descriptions that enable a better understanding of com- based on a single case study; our understanding is that it
petitive and collaborative issues simultaneously present is representative of other industrial FLOSS projects, with
and interconnected in large and complex software ecosys- volunteer and affiliated developers developing together
tems. As a methodological note, and as in prior research a software. However, further research should replicate
employing similar research designs [33], we also warn that our method on other projects to explore other open-
repository-driven social network measures (i.e., central- coopetition scenarios and to find out if our findings hold
ity, eigenvector centrality) or related visualizations must there too.
be interpreted carefully. As Shihab et al. point out [130], a “frequent miscon-
For instance from the Grizzly to the Havana release, ception is that empirical research within one company
either by summing the centrality measures of the devel- or one project is not good enough, provides little value
opers affiliated to Mirantis or by interpreting Fig. 10, we for the academic community, and does not contribute
could easily make wrong judgments about the impor- to scientific development”. The authors note that histori-
tance or influence of Mirantis within the OpenStack Nova cal evidence shows otherwise; Flyvbjerg presents several
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 24 of 27
examples from the fields of physics, economics, and the happening under the ubiquitous pressure to innovate
social sciences [131]. Basili et al. argue that the study of from collaborators, competitors and power-users.
large samples or populations and of single case studies are Our results are of interest to the body of knowledge
both essential [132]. in Software Engineering, where FLOSS studies are on
the research agenda. Additionally, we also integrate our
research findings with management literature in business
9 Conclusions ecosystems and coopetition strategy. In order to facili-
By employing a longitudinal design covering more than tate future testing of our inductive findings from a single
4 years of a FLOSS ecosystem, we combined an exten- case, and as it was recurrently pointed that Software
sive qualitative investigation, the mining of a software Engineering research also needs to engage in theory-
repository and Social Network Analysis. We addressed the building [134–137]. Furthermore, we advocate the need
question of how rival firms collaborate in OpenStack in to take into account affiliation information of the devel-
an open source way, by analyzing the roles of firm affil- opers to determine issues as the health of a software
iation and revenue stream. We found that management ecosystem or the fairness of its development process.
research in business ecosystems and coopetition provided Failing to identify inefficient or unfair development pro-
powerful lenses for understanding the competitive and cesses may lead to the abandonment or forking of the
collaborative issues embedded in the OpenStack software project by some stakeholders, may they be corporations or
evolution. individuals.
We learned that a qualitative analysis of archival data, Further steps are required for strength our results and
combined with social network visualizations derived from consequently increase the validity of the proposed the-
source code repositories, provide a rich medium that oretical contributions. Also plenty of future research is
enables a better understanding of software ecosystems. needed for gaining further lessons from this complex case.
By addressing the initial research questions, new ques- Finally, there are also many other open-coopetition cases
tions emerged regarding homophily, coopetition, user- that remain unexplored, calling for additional research
innovation and deployment within a FLOSS ecosystems on how knowledge from business ecosystems applies to
setting. By pure serendipity, we also provided a longi- software development.
tudinal description of how heterogeneous actors within
Competing interests
a high-networked ecosystem (involving individuals, star-
The authors declare that they have no competing interests. JGB works for
tups, established firms and public organizations) joint- Bitergia who has as customer the OpenStack Foundation. GR is co-owner of
develop an complex infrastructure for big-data in the Bitergia. In order to avoid conflicts of interest, as there are professional
relationships between Bitergia (2nd and 3rd author) and the OpenStack
open-source arena.
Foundation, all data collection and analysis process was executed by the first
We shed some light on the potential of visualizing author.
collaboration for supporting strategic alliance decisions
Authors’ contributions
in R&D projects, especially within large-scale and high-
JT carried out data-collection and analysis. All authors contributed to the
networked production scenarios. We argue that our SNA writing, discussion and revising of this manuscript. All authors read and
visualizations, retrieved from natural occurring source- approved the final manuscript.
code repositories can help stakeholders in assessing
Acknowledgments
their inter-firm network positions for better decision- We are grateful to Daniel Izquierdo Cortázar, from Bitergia, for explaining the
making regarding strategic alliances. Our methodological data of developer affiliations for the OpenStack Nova project, and keeping it
approach provides visualizations that support awareness up-to-date, well documented and in a research-friendly way.
Acknowledgements also for Tingting Lin, who initially motivated the mining
of human activities in software development [133], poten- of open-source repositories with social network analysis, Salman Mian who
tially supporting decisions on how to balance coop- carefully reviewed our network visualizations. Also for Jukka Ruohonen and
eration and competition in a particular product or Marko Niemimaa with whom we had joyful discussions on how the important
social concept of homophily applies to Software Engineering and Information
market area. Systems. A word also for the Professors Reima Suomi and Hannu Salmela, who
The practical importance of open-coopetition, as supported fund-seeking initiatives that made this research possible.
explored by this research, should be taken into account. The work of Jose Teixeira was partially supported by the Fundação para a
Ciência e a Tecnologia (grant SFRHBD615612009), Liikesivistysrahasto (grant
Stakeholders in R&D projects have many reasons to con- 3-1815) and Marcus Wallenberg Säätiö (grant open-coopetition R&D
sider coopetition in an open source fashion: The costs management strategy). The work of Gregorio Robles and Jesús M. González
and risks of developing new products are divided among Barahona has been funded in part by the Spanish Government under project
SobreSale (TIN2011- 28110) and by the Region of Madrid under project
the cooperating companies; the time-to-market can be “eMadrid - Investigación y Desarrollo de tecnologías para el e-learning en la
shorter as each company can contribute with its core Comunidad de Madrid” (S2013/ICE-2715).
competence; and ‘extra’ contributions can be more eas- The last word is for the OpenStack community for developing a cool, open
and research-friendly cloud computing infrastructure for big-data. More
ily captured from third-party open source contributors methodological details, data, high-resolution visualizations, and source-code
(e.g., altruistic volunteers or user-contributors). All this are publicly available at http://users.utu.fi/joante/OpenStackSNA/.
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 25 of 27
Author details 25. Iansiti M, Levien R (2004) Strategy as ecology. Harv Bus Rev 82(3):68–81
1 School of Economics (TSE), University of Turku, Turku, Finland. 2 Universidad 26. Iansiti M, Levien R (2004) The keystone advantage: what the new
Rey Juan Carlos, Camino del Molino s/n, 28943 Fuenlabrada, Madrid, Spain. dynamics of business ecosystems mean for strategy, innovation, and
3 Bitergia S.L., Avenida Gregorio Peces Barba, 28918 Leganés, Madrid, Spain. sustainability. Harvard Business Press, Boston
27. Jansen S, Finkelstein A, Brinkkemper S (2009) A sense of community: a
Received: 15 October 2014 Accepted: 3 June 2015 research agenda for software ecosystems. In: Software
Engineering-Companion Volume, 2009. ICSE-Companion 2009. 31st
International Conference On. IEEE. pp 187–190
References 28. Bosch J (2009) From software product lines to software ecosystems. In:
1. Dagnino GB, Padula G (2002) Coopetition strategy: a new kind of Proceedings of the 13th international software product line conference.
interfirm dynamics for value creation. In: Innovative research in Carnegie Mellon University. pp 111–119
management, European Academy of Management (EURAM), second 29. Yilmaz M, O’Connor RV (2011) A software process engineering approach
annual conference, Stockholm, May Vol. 9 to improving software team productivity using socioeconomic
2. Bengtsson M, Kock S (2000) “Coopetition” in business networks—to mechanism design. ACM SIGSOFT Softw Eng Notes 36(5):1–5
cooperate and compete simultaneously. Ind Mark Manag 29(5):411–426 30. Hanssen GK, Dybå T (2012) Theoretical foundations of software
3. Teixeira J, Lin T (2014) Collaboration in the open-source arena: the ecosystems. In: IWSECO@ ICSOB. Citeseer. pp 6–17
webkit case. In: Proceedings of the 52nd ACM conference on computers 31. Von Hippel E (2005) Democratizing innovation. MIT press, Massachusetts
and people research. ACM. pp 121–129 32. Scacchi W, Feller J, Fitzgerald B, Hissam S, Lakhani K (2006)
4. Gnyawali DR, Madhavan R (2001) Cooperative networks and competitive Understanding free/open source software development processes.
dynamics: a structural embeddedness perspective. Acad Manag Rev Softw Process Improv Pract 11(2):95–105
26(3):431–445 33. Teixeira J, Lin T (2014) Collaboration in the open-source arena: The
5. Gnyawali DR, Park B-JR (2009) Coopetition and technological innovation WebKit case. In: Proceedings of the 52th ACM SIGMIS conference on
in small and medium sized enterprises: a multilevel conceptual model. computers and people research, Singapore
J Small Bus Manag 47(3):308–330 34. McPherson M, Smith-Lovin L, Cook JM (2001) Birds of a feather:
6. Lado AA, Boyd NG, Hanlon SC (1997) Competition, cooperation, and the homophily in social networks. Annu Rev Sociol:415–444
search for economic rents: a syncretic model. Acad Manag Rev 35. Monge PR, Contractor NS (2001) Emergence of communication
22(1):110–141 networks. The new handbook of organizational communication:
7. Nalebuff BJ, Brandenburger A (1996) Co-opetition. HarperCollinsBusiness, Advances in theory, research, and methods. Sage, Thousand Oaks, CA
NYC, USA 36. Nohria N (1994) Networks and organizations: structure, form and action.
8. Messerschmitt DG, Szyperski C (1979) Software ecosystems: Harvard Business School Press, Boston, MA
understanding an indispensable technology and industry. 2003. The MIT 37. Brass DJ (1995) A social network perspective on human resources
Press, Cambridge management. Res Pers Hum Resour Manag 13(1):39–79
9. Jansen S, Finkelstein A, Brinkkemper S (2009) A sense of community: a
38. Jiang Y, Bolnick DI, Kirkpatrick M (2013) Assortative mating in animals.
research agenda for software ecosystems. In: Proceedings of 31st
Am Nat 181(6):125–138
International Conference on Software Engineering (ICSE’09). IEEE
39. Gulati R, Gargiulo M (1999) Where do interorganizational networks come
Computer Society, Vancouver, Canada. pp 187–190
from? Am J Soc 104(5):1439–1493
10. Yin RK (2011) Applications of case study research. Sage, London, UK
11. Runeson P, Höst M (2008) Guidelines for conducting and reporting case 40. Madhavan R, Gnyawali DR, He J (2004) Two’s company, three’s a crowd?
study research in software engineering. Empir Softw Eng 14(2):131–164 Triads in cooperative-competitive networks. Acad Manag J
12. Jick TD Mixing qualitative and quantitative methods: triangulation in 47(6):918–927
action. Adm Sci Q:602–611 41. Aldrich HE, Kim PH (2007) Small worlds, infinite possibilities? how social
13. Johnson RB, Onwuegbuzie AJ, Turner LA (2007) Toward a definition of networks affect entrepreneurial team formation and search. Strateg
mixed methods research. J Mixed Methods Res 1(2):112–133 Entrep J 1(1–2):147–165
14. Basole RC (2009) Visualization of interfirm relations in a converging 42. Acker J (2006) Inequality regimes gender, class, and race in
mobile ecosystem. J Inf Technol 24(2):144–159 organizations. Gend Soc 20(4):441–464
15. Brandenburger AM, Stuart HW (1996) Value based business strategy. 43. Etzkowitz H, Kemelgor C, Uzzi B (2000) Athena unbound: the
J Econ Manag Strateg 5(1):5–24 advancement of women in science and technology. Cambridge
16. Tidström A (2009) Causes of conflict in intercompetitor cooperation. J University Press
Bus Ind Mark 24(7):506–518 44. Rogers EM (2010) Diffusion of innovations. Simon and Schuster, NYC
17. Deeds DL, Hill CW (1996) Strategic alliances and the rate of new product 45. Dyba T (2000) An instrument for measuring the key factors of success in
development: an empirical study of entrepreneurial biotechnology software process improvement. Empir Softw Eng 5(4):357–390
firms. J Bus Ventur 11(1):41–55 46. Sjoberg DI, Anda B, Arisholm E, Dyba T, Jorgensen M, Karahasanovic A,
18. Lynn GS, Akgün AE (1998) Innovation strategies under uncertainty: a Koren EF, Vokác M (2002) Conducting realistic experiments in software
contingency approach for new product development. Eng Manag J engineering. In: Empirical Software Engineering, 2002. Proceedings.
10:11–18 2002 International Symposium N. IEEE. pp 17–26
19. Garud R (1994) Cooperative and competitive behaviors during the 47. Hovorka DS, Larsen KR (2006) Enabling agile adoption practices through
process of creative destruction. Res Policy 23(4):385–394 network organizations. Eur J Inf Syst 15(2):159–168
20. Gomes-Casseres B (1994) Group vs. group: How alliance networks 48. 451Research (2014) 451 Research’s new OpenStack Market Monitor
compete. Harv Bus Rev 72(4):62–76 service predicts a $1.7bn+ market by 2016. https://451research.com/
21. Osarenkhoe A (2010) A coopetition strategy–a study of inter-firm report-short?entityId=82593
dynamics between competition and cooperation. Bus Strateg Ser 49. Baker J (2014) OpenStack by the numbers | Opensource.com. http://
11(6):343–362 opensource.com/business/14/6/openstack-numbers.
22. Huang KF, Yu C-MJ (2011) The effect of competitive and non-competitive Accessed 15 Oct 2014
r&d collaboration on firm innovation. J Technol Transf 36(4):383–403 50. Benbasat I, Goldstein DK, Mead M (1987) The case research strategy in
23. Fernandez AS, Le Roy F, Gnyawali DR (2014) Sources and management studies of information systems. MIS Q:369–386
of tension in co-opetition case evidence from telecommunications 51. Lee AS (1989) A scientific methodology for mis case studies. MIS Q:33–50
satellites manufacturing in europe. Ind Mark Manag 43(2):222–235 52. Flynn BB, Sakakibara S, Schroeder RG, Bates KA, Flynn EJ (1990) Empirical
24. Park B-JR, Srivastava MK, Gnyawali DR (2014) Walking the tight rope of research methods in operations management. J Oper Manag
coopetition: Impact of competition and cooperation intensities and 9(2):250–284
balance on firm innovation performance. Ind Mark Manag 53. Wasserman S, Faust K (1994) Social network analysis: methods and
43(2):210–221 applications vol. 8. Cambridge University Press, Cambridge
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 26 of 27
54. Scott J (2012) Social network analysis. SAGE Publications Limited, London 84. Masmoudi H, den Besten M, De Loupy C, Dalle JM (2009) Peeling the
55. Brandes U, Robins G, McCranie A, Wasserman S (2013) What is network onion. In: Open source ecosystems: diverse communities interacting.
science? Network Sci 1(01):1–15 Springer, NYC. pp 284–297
56. Bastian M, Heymann S, Jacomy M, et al (2009) Gephi: an open source 85. Ruhnau B (2000) Eigenvector-centrality—a node-centrality? Soc
software for exploring and manipulating networks. ICWSM 8:361–362 Networks 22(4):357–365
57. Handcock MS, Hunter DR, Butts CT, Goodreau SM, Morris M (2003) 86. Bonacich P (2007) Some unique properties of eigenvector centrality.
Statnet: Software Tools for the Statistical Modeling of Network Data, Soc Networks 29(4):555–564
Seattle, WA. http://statnetproject.org 87. Albert R, Barabási AL (2002) Statistical mechanics of complex networks.
58. Butts CT (2010) Tools for social network analysis. R package version 2 Rev Mod Phys 74(1):47
59. R Core Team (2014) R: A Language and Environment for Statistical 88. Granovetter MS (1973) The strength of weak ties. Am J Sociol:1360–1380
Computing. R Foundation for Statistical Computing, Vienna, Austria. R 89. Bhattacharya D, Ram S (2012) Sharing news articles using 140 characters:
Foundation for Statistical Computing. http://www.R-project.org a diffusion analysis on twitter. In: Proceedings of the 2012 international
60. Porter K, Whittington KB, Powell WW (2005) The institutional conference on Advances in Social Networks Analysis and Mining
embeddedness of high-tech regions: relational foundations of the (ASONAM 2012). IEEE Computer Society. pp 966–971
Boston biotechnology community. Clusters Netw innov 261:296 90. Brandes U, Wagner D (2004) Analysis and visualization of social
61. Elias N (1978) What is sociology?. Columbia University Press, NYC networks. In: Graph drawing software. Springer, NYC. pp 321–340
62. Newton T (2001) Organization: the relevance and the limitations of elias. 91. Girvan M, Newman ME (2002) Community structure in social and
Organization 8(3):467–495 biological networks. Proc Natl Acad Sci 99(12):7821–7826
63. Gfaller GR (1993) Figuration’: the contribution of norbert elias to group 92. Blondel VD, Guillaume JL, Lambiotte R, Lefebvre E (2008) Fast unfolding
analysis and the contribution of group analysis to the social sciences. of communities in large networks. J Stat Mech Theory Experiment
Group Anal 26(3):341–356 2008(10):10008
64. Crowston K, Howison J (2005) First Monday 10:2–7. http://firstmonday. 93. Eisenhardt KM (1991) Better stories and better constructs: the case for
org/ojs/index.php/fm/article/view/1207 rigor and comparative logic. Acad Manag Rev 16(3):620–627
65. Bird C, Pattison D, D’Souza R, Filkov V, Devanbu P (2008) Latent social 94. Dyer WG, Wilkins AL (1991) Better stories, not better constructs, to
structure in open source projects. In: Proceedings of the 16th ACM generate better theory: a rejoinder to eisenhardt. Acad Manag Rev
SIGSOFT international symposium on foundations of software 16(3):613–619
engineering. ACM. pp 24–35 95. Rossi B, Russo B, Succi G (2009) Analysis of open source software
66. Geipel MM, Schweitzer F (2012) The link between dependency and development iterations by means of burst detection techniques. In:
cochange: Empirical evidence. IEEE Trans Softw Eng 38(6):1432–1444 Open source ecosystems: diverse communities interacting. Springer.
67. Zanetti MS, Scholtes I, Tessone CJ, Schweitzer F (2013) Categorizing pp 83–93
bugs with social networks: a case study on four open source software 96. Michlmayr M, Fitzgerald B, Stol KJ (2015) Why and how should open
communities. In: Software Engineering (ICSE), 2013 35th international source projects adopt time-based releases? IEEE Softw 32(2):55–63
conference on. pp 1032–1041 97. OpenStack (2015) OpenStack Specifications. http://specs.openstack.
68. Freeman LC (2005) Graphic techniques for exploring social network org/. Accessed 24 Apr 2015
data. Models and methods in social network analysis:248–269 98. OpenStack (2014) Blueprints - OpenStack - OpenStack Wiki. https://wiki.
69. Runeson P, Host M, Rainer A, Regnell B (2012) Case study research in openstack.org/wiki/Blueprints. Accessed 24 Apr 2015
software engineering: guidelines and examples. Wiley, Hoboken, NJ 99. OpenStack (2015) OpenStack Developer’s Guide. http://docs.openstack.
70. Piekkari R, Welch C, Paavilainen E (2008) The case study as disciplinary org/infra/manual/developers.html. Accessed 24 Apr 2015
convention: evidence from international business journals. SAGE 100. Ltd CG (2014) Launchpad. https://launchpad.net/. Accessed 18 Jun 2014
Publications, London, UK 101. OpenStack (2015) BugTriage - OpenStack - OpenStack Wiki. https://wiki.
71. Gibbert M, Ruigrok W, Wicki B (2008) What passes as a rigorous case openstack.org/wiki/BugTriage. Accessed 24 Apr 2015
102. OpenStack (2015) Bugs - OpenStack - OpenStack Wiki. https://wiki.
study? Strat Manag J 29(13):1465–1474
openstack.org/wiki/Bugs. Accessed 24 Apr 2015
72. Kozinets RV (2002) The field behind the screen: using netnography for
103. Curry J (2010) Introducing OpenStack | The OpenStack Blog. http://
marketing research in online communities. J Mark Res:61–72
www.openstack.org/blog/2010/07/introducing-openstack/.
73. Kozinets RV (2009) Netnography: doing ethnographic research online.
Accessed 19 Jul 2010
Sage Publications Limited, London 104. Scott J (2012) What is social network analysis? What Is... ? Series.
74. Bitergia Oa (2014) Dash of Development Activity | data-sources. http:// Bloomsbury Academic. https://books.google.fi/books?id=
activity.openstack.org/dash/browser/data_sources.html. rWBMAQAAQBAJ
Accessed 7 Oct 2014 105. Krempel L (2009) Network visualization. Handbook of Social Network
75. Mirantis Oa (2014) Members of OpenStack Foundation. http:// Analysis. Sage, London, UK
stackalytics.com/report/members?release=all&metric= 106. Bertin J, Berg WJ (2011) Semiology of Graphics: Diagrams, Networks,
members&project_type=all&company=&days=93. Accessed 7 Oct 2014 Maps ESRI Press. ISBN=9781589482616, LCCN=2010031657
76. OpenStack (2015) Releases - OpenStack Wiki. https://wiki.openstack.org/ 107. Rackspace (2010) Rackspace Open Sources Cloud Platform; Announces
wiki/Releases. Accessed 12 Feb 2015 Plans to Collaborate with NASA and Other Industry Leaders on
77. OpenStack (2015) Developers training guide - OpenStack Docs. http:// OpenStack Project. http://www.rackspace.com/blog/newsarticles/
docs.openstack.org/training-guides/content/developer-getting-started. rackspace-open-sources-cloud-platform-announces-plans-to-
html. Accessed 12 Feb 2015 collaborate-with-nasa-and-other-industry-leaders-on-openstack-
78. OpenStack (2015) Release Cycle - OpenStack Wiki. https://wiki. project/. Accessed 19 Jul 2010
openstack.org/wiki/Release_Cycle. Accessed 24 Apr 2015 108. Crosby S (2014) If you’ve seen one redwood, you’ve seen them all... |
79. OpenStack (2015) Branch Model - OpenStack - OpenStack Wiki. https:// Citrix Blogs. http://blogs.citrix.com/2010/10/21/if-youve-seen-one-
wiki.openstack.org/wiki/Branch_Model. Accessed 24 Apr 2015 redwood-youve-seen-them-all/. Accessed 21 Oct 2010
80. OpenStack (2015) FeatureFreeze - OpenStack - OpenStack Wiki. https:// 109. Arnold J (2011) OpenStack Object Storage Moves Beyond Rackspace |
wiki.openstack.org/wiki/FeatureFreeze. Accessed 24 Apr 2015 Cloudscaling. https://cloudscaling.com/blog/cloud-computing/
81. OpenStack (2014) Roadmap OpenStack Open Source Cloud Computing openstack-object-storage-moves-beyond-rackspace/.
Software. https://www.openstack.org/software/roadmap/. Accessed 31 Jan 2011
Accessed 7 Oct 2014 110. Lvov M (2011) OpenStack Deployment on Fedora using Kickstart - Pure
82. Bitergia (2014) OpenStack releases reports. http://bitergia.com/ Play OpenStack. https://www.mirantis.com/blog/openstack-
openstack-releases-reports/. Accessed 7 Oct 2014 deployment-on-fedora-using-kickstart/. Accessed 18 May 2011
83. Mockus A, Fielding RT, Herbsleb JD (2002) Two case studies of open 111. HP (2011) HP Video Gallery OpenStack Technology. http://www8.hp.
source software development: apache and mozilla. ACM Trans Softw com/h20621/video-gallery/us/en/events/enterprise/hp-discover-2011/
Eng Methodol 11(3):309–346 2793799141001/OpenStack%20Technology/video/. Accessed Jun 2011
Teixeira et al. Journal of Internet Services and Applications (2015) 6:14 Page 27 of 27
112. Darrow B (2012) OpenStack developers leave Rackspace for Nebula — 135. Sjøberg DI, Dybå T, Anda BC, Hannay JE (2008) Building theories in
Tech News and Analysis. https://gigaom.com/2012/07/23/openstack- software engineering. In: Guide to advanced empirical software
developers-leave-rackspace-for-nebula/. Accessed 15 Oct 2014 engineering. Springer, NYC. pp 312–336
113. Diaz A (2012) OpenStack: Poised to lead the way to open cloud 136. Johnson P, Ekstedt M, Jacobson I (2012) Where’s the theory for software
computing - Thoughts on Cloud. http://thoughtsoncloud.com/2012/ engineering? IEEE Softw 29(5):96
09/openstack-poised-to-lead-the-way-to-open-cloud-computing/. 137. Stol KJ, Fitzgerald B (2015) Theory-oriented software engineering. Sci
Accessed 19 Sept 2012 Comput Program 101:79–98. http://www.sciencedirect.com/science/
114. Fratto M (2012) Amazon APIs Are Fine ... For Amazon - Network article/pii/S0167642314005425
Computing. http://www.networkcomputing.com/cloud-infrastructure/ 138. Eisenhardt KM (1989) Building theories from case study research. Acad
amazon-apis-are-fine--for-amazon/a/d-id/1233527?. Manag Rev 14(4):532–550
Accessed 4 Mar 2012 139. Mockus A, Fielding RT, Herbsleb J (2000) A case study of open source
115. Shuttleworth M (2014) Ubuntu is the leading OpenStack distribution. software development: the apache server. In: Proceedings of the 22nd
http://www.markshuttleworth.com/archives/1373 international conference on software engineering. ACM. pp 263–272
116. VMware (2013) Canonical and VMware Collaborate to Enable OpenStack 140. Madey G, Freeh V, Tynan R (2002) The open source development
Clouds With VMware Technologies (NYSE:VMW). http://ir.vmware.com/ phenomenon: An analysis based on social network theory. In: Americas
releasedetail.cfm?ReleaseID=756729. Accessed 16 Apr 2013 Conference on Information Systems (AMCIS2002), Dallas, Texas, USA.
117. Mirantis (2013) Mirantis receives $10 million from Intel, WestSummit, pp 1806–1813. http://www.nd.edu/~oss/Papers/amcis_oss.pdf
and Dell. https://www.mirantis.com/company/press-center/company- 141. López L, González-Barahona JM, Robles G (2004) Applying social
news/mirantis-receives-10-million-from-intel-capital-westsummit- network analysis to the information in CVS repositories. In: Proceedings
capital-and-dell-ventures-to-accelerate-its-openstack-game/. of the international workshop on mining software repositories,
Accessed 10 Jan 2013 Edinburg, UK. pp 101–105
118. Mirantis (2013) Ericsson, Red Hat, and SAP Ventures Back Mirantis with 142. Kagdi H, Collard ML, Maletic JI (2007) A survey and taxonomy of
Investment - Pure Play OpenStack. https://www.mirantis.com/ approaches for mining software repositories in the context of software
company/press-center/company-news/ericsson-red-hat-and-sap- evolution. J Softw Maint Evol Res Pract 19(2):77–131
ventures-back-mirantis-with-investment/. Accessed 6 Jun 2013 143. Robles G, Gonzalez-Barahona JM, Michlmayr M, Amor JJ (2006) Mining
119. Cureton L (2012) IT Reform at the National Aeronautics and Space large software compilations over time: another perspective of software
Administration | NASA CIO Blog. http://blogs.nasa.gov/NASA-CIO-Blog/ evolution. ACM. ISBN = 1595933972
2012/06/09/post_1339205656611/. Accessed 15 OCt 2012 144. Hahn J, Moon JY, Zhang C (2008) Emergence of new project teams from
120. O’Luanaigh C (2014) The importance of OpenStack for CERN | CERN. open source software developer Emergence of new project teams from
http://home.web.cern.ch/about/updates/2014/01/importance- open source software developer. Inform Syst Res 19(3):369–391
openstack-cern. Accessed 5 Mar 2014 145. Howison J, Wiggins A, Crowston K (2012) Validity issues in the use of
121. Kock S (1991) A Strategic process for gaining external resources through social network analysis with digital trace data. J Assoc Inf Syst
long-lasting relationships: examples from two Finnish and two Swedish 44(2):767–797
industrial firms. Swedish School of Economics and Business 146. Lundvall BA (1922) User-producer relationships, national systems of
Administration, Umeå innovation and internationalisation. National systems of innovation:
122. Bengtsson M, Kock S (2014) Coopetition—quo vadis? past Towards a theory of innovation and interactive learning:45–67
accomplishments and future challenges. Ind Mark Manag 43(2):180–188 147. Cambrosio A, Keating P, Mogoutov A (2004) Mapping collaborative work
123. Jansen S (2014) Measuring the health of open source software and innovation in biomedicine: A computer-assisted analysis of
ecosystems: beyond the scope of project health. Inf Softw Technol antibody reagent workshops. Social Studies of Science:325–364
56(11):1508–1519 148. Glänzel W, Schubert A (2005) Analysing scientific networks through
124. Izquierdo-Cortazar D, González-Barahona JM, Robles G, Deprez JC, co-authorship. In: Handbook of quantitative science and technology
Auvray V (2010) Floss communities: analyzing evolvability and research. Springer, NYC. pp 257–276
robustness from an industrial perspective. In: Open Source Software: 149. Zachary W (1977) An Information Flow Model for Conflict and Fission in
New Horizons. Springer. pp 336–341 Small Groups. J Anthropological Res 33(4):452–473
125. Vasilescu B, Serebrenik A, Goeminne M, Mens T (2014) On the variation 150. Kleinberg J (2002) An impossibility theorem for clustering. vol
and specialisation of workload — a case study of the Gnome ecosystem 15:463–470. NIPS
community. Empir Softw Eng 19(4):955–1008 151. Newman MEJ, Girvan M (2004) Finding and evaluating community
126. HP (2013) White paper | HP and the Open Cloud. http://www.hpcloud. structure in networks. Phys Rev E 69(2):026113
com/sites/default/files/Whitepaper%20-%20HP%20%20OpenStack 152. Adamcsek B, Palla G, Farkas IJ, Derényi I, Vicsek T (2006) CFinder: locating
%201_25_2013.pdf Accessed 18 Jun 2014 cliques and overlapping modules in biological networks. Bioinformatics
127. Apple (2014) Apple - Open Source. https://www.apple.com/ 22(8):1021–1023
opensource/. Accessed 31 Oct 2014 153. Brohee S, van Helden J (2006) Evaluation of clustering algorithms for
128. Ericsson (2014) Open source - Ericsson. http://www.ericsson.com/ protein-protein interaction networks. BMC bioinformatics 7(1):488
article/open_source_1714451213_c. Accessed 18 Jun 2014 154. Fortunato S (2010) Community detection in graphs. Phys Rep
129. OpenStack, Mirantis (2014) Stackalytics | OpenStack community 486(3):75–174
contribution in Juno release. http://www.stackalytics.com/. 155. Nick B, Lee C, Cunningham P, Brandes U (2013) Simmelian backbones:
Accessed 18 Jun 2014 amplifying hidden homophily in facebook networks. In: Advances in
130. Shihab E, Bird C, Zimmermann T (2012) The effect of branching Social Networks Analysis and Mining (ASONAM), 2013 IEEE/ACM
strategies on software quality. In: Empirical Software Engineering and International Conference On. IEEE. pp 525–532
Measurement (ESEM), 2012 ACM-IEEE International Symposium On. IEEE.
pp 301–310
131. Flyvbjerg B (2006) Five misunderstandings about case-study research.
Qual Inq 12(2):219–245
132. Basili VR, Shull F, Lanubile F (1999) Building knowledge through families
of experiments. IEEE Trans Softw Eng 25(4):456–473
133. Storey M-AD, Čubranić D, German DM (2005) On the use of visualization
to support awareness of human activities in software development: a
survey and a framework. In: Proceedings of the 2005 ACM Symposium
on Software Visualization. ACM. pp 193–202
134. Hannay JE, Sjoberg DI, Dyba T (2007) A systematic review of theory use
in software engineering experiments. IEEE Trans Softw Eng 33(2):87–107