Poo-Caamaño et al.

Journal of Internet Services and Applications (2017) 8:12

DOI 10.1186/s13174-017-0063-2
Journal of Internet Services
and Applications

RESEARCH Open Access

Herding cats in a FOSS ecosystem: a tale

of communication and coordination for
release management
Germán Poo-Caamaño1* , Eric Knauss2 , Leif Singer1 and Daniel M. German1

Abstract
Release management in large-scale software development projects requires significant communication and
coordination. It is particularly challenging in Free and Open Source Software (FOSS) ecosystems, in which hundreds of
loosely connected developers and their projects are coordinated to release software to a schedule. To better
understand this process and its challenges, we analyzed over two and half years of communication in the GNOME
ecosystem and studied developers’ interactions. Through a case study, we cataloged communication channels,
determined the main channel from which we categorized high level communication and coordination activities
spanning five releases, and triangulated our results by interviewing ten key developers. We found that a release
schedule, influence (instead of direct control), and diversity are the main factors that positively impact the release
process in the GNOME ecosystem. We report a set of lessons learned that encapsulates our understanding of how the
Release Management process function in a FOSS ecosystem, we learned that: (1) ensure that the release team follows
the main communication channels used by developers, (2) provide a common place for coordination for an
ecosystem, (3) consider including both good technical and social skills in a release team, (4) aim for a diverse release
team, (5) based on lack of power, lobbying and consensus based management must be followed, (6) help the release
team in the coordination process with a well defined schedule, and (7) release team work is different from regular
software work. Our results can help organizations build better large-scale teams and show that research focused on
individual projects might miss important parts of the picture.
Keywords: Release management, Software ecosystem, Empirical study

“We need to communicate to make sure ... we have a developed autonomously, with distributed teams of devel-
product altogether that works. That components are opers, different motivations, many of them working as
well integrated with each other ... we don’t consider volunteers. And yet, most of the time, the complex prod-
GNOME a random set of tools that are totally separated uct with all its individual pieces is released on time and
from each other, we want [them] to work well [together].” in high quality. The developers of each of these pieces
—A GNOME release team member must communicate and coordinate effectively throughout
an ecosystem of interrelated software products to achieve
1 Introduction the goal of releasing a cohesive product.
Releasing a single software product is already challenging, Release management in such an ecosystem relates to
but consider the challenges of releasing a complex prod- both technical and social aspects of software engineering
uct that consists of a multitude of independent software [15, 59] in a highly distributed setting [27, 30] and better
products. Each of these individual software products is understanding of this phenomenon is important both for
closed and open source development.
*Correspondence: [email protected] Software development is more than writing code, it
1
Department of Computer Science, University of Victoria, 3800 Finnerty Road, involves a set of technical and social aspects that must be
Victoria, British Columbia, Canada taken in consideration [15, 59].
Full list of author information is available at the end of the article

© The Author(s). 2017 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.
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 2 of 24

Especially in distributed settings, the software develop- In this study, we empirically investigate in the complex
ment process requires additional work to overcome dif- phenomenon of the GNOME FOSS ecosystem by employ-
ferent strategic and cultural views to design, implement, ing three theories that provide a lens for our inquiry: the
and test software [27, 30]. Empirical studies in industrial media richness theory [14], the channel expansion the-
settings report that “cross-site communication and coordi- ory [10], and the shared understanding theory [1]. We rely
nation issues are critical to achieving speed in multi-site on these three theories to obtain a holistic and complete
development” [30]. account of communication and coordination for release
Yet, communication and coordination is challenging in management.
distributed teams, and since such distributed teams is the In their media richness theory, Daft and Lengel [14]
nature of many FOSS projects [53] they offer a unique argue that organizations process information to reduce
opportunity to further our understanding of release man- uncertainty and ambiguity, for which the communication
agement in ecosystems. channels and organizational structure play an important
FOSS projects can encompass a variety of methods or role. The communication channels vary in their capacity
process es for developing software, which can vary accord- for providing richer or leaner information.
ing to the type of governance model they have [5]. The Rich communication channels, such as face-to-face and
purpose of FOSS governance is three fold: to solve collec- video interactions, enable immediate feedback, cross-
tive action dilemmas, to solve development coordination check of information, and provide additional cues, such as
problems, and to create a climate for contributors [48]. body language, tone, and message content in natural lan-
Projects with a strong leadership may not require to reach guage. In contrast, leaner communication channels, such
consensus in the decision making process. as email or instant messaging, lack the ability of con-
In solo projects as well as projects lead by a benev- veying nonverbal cues, and the feedback is limited [41].
olent dictator (for example, Linux, and Perl) or by a In addition, a second source of uncertainty is produced
corporation (for example, MySQL and BerkeleyDB) the by the need of integration between multiple teams or
direction and decision making process are clear; whereas projects within an ecosystem: “people come to a problem
in community and Foundation-based projects, the deci- with different experience, cognitive elements, goals, val-
sions are usually reached via consensus [4]. GNOME ues, and priorities” [14]. FOSS ecosystems may be limited
is a project governed by a Foundation, and it needs to to use certain communication channels, and the diversity
find different ways to align all projects and developers. of projects and developers’ background may increase the
Furthermore, GNOME is a FOSS ecosystem, where the difficulties to reach consensus, motivating our first two
developers and leaders of multiple independent projects research questions:
must reach consensus to decide what features to deliver
in a common integrated product, when to deliver it, RQ1 What are the communication channels used for
and how to reach the minimum acceptable quality to release management?
deliver it. RQ2 How do developers communicate and coordinate for
A FOSS ecosystem is a set of independent, interrelated release management?
FOSS applications that operate together to deliver a com-
mon user experience. Besides GNOME, other examples The channel expansion theory, proposed by Carlson
of FOSS ecosystems include Linux distributions (such as and Zmud [10], presumes that as individuals gain expe-
Debian), or the R ecosystem (R language, libraries and rience in the use of a channel, they are able to use the
tools). Because in a FOSS ecosystem a release comprises media channel more effectively; such experience involves
many different independent applications, the release man- the use of the channel itself, the organizational context,
agement of the ecosystem can be significantly more diffi- the message topic, and the understanding of how their
cult than any of its applications alone. Release managers co-participants communicate. Furthermore, according to
need to coordinate the goals and schedules of multiple Dennis and Valacich [16], the development of standards
teams to deliver, from the point of view of the user, one and norms increases with the experience that a group
single release. gains, and as a result such a group may also experience
Previous research on communication and coordination an improvement in the interplay and the tasks they per-
in software ecosystems has focused in a temporal analysis form over time. This theory may or may not apply on how
of information flows [37], and then obtained a structural a successful FOSS ecosystem releases software on time
map about flows between actors [38]. To our knowl- and indicates a need to further understand the usage of
edge, the requirements and challenges that release man- channels for release management.
agers face in software ecosystems have not been explored, Finally, the theory of shared understanding proposed by
and little is known about how FOSS ecosystems conduct Aranda [1], argues that the formalization of a process in
release management. a software project helps reduce the overall complexity,
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 3 of 24

because once a process is formalized, it facilitates that the similar FOSS ecosystems and facilitate future research in
stakeholders familiarize with the process itself rather than this area.
the details of each part of the organization. As a conse- (ii) A set of lessons learned: Based on the empirical stud-
quence, the stakeholders can make assumptions on parts ies, we report a set of lessons learned that encapsulates our
of the organizations that are unfamiliar to them, and the understanding of how the Release Management process
organizational complexity is reduced. function in FOSS ecosystems. We learned that: (1) ensure
Motivated by the channel expansion and shared under- that the release team follows the main communication
standing theories, we aim to understand the key actors channels used by developers, (2) provide a common place
that help to align a distributed team of mostly volunteers, for coordination for an ecosystem, (3) consider including
and to understand what kind of tasks they have that enable both good technical and social skills in a release team,
the coordination across the ecosystem. (4) aim for a diverse release team, (5) based on lack of
power, lobbying and consensus based management must
RQ3 Who are the key actors in the release management be followed, (6) help the release team in the coordination
process? process with a well defined schedule, and (7) release team
RQ4 What are the release management tasks in a FOSS work is different from regular software work.
ecosystem? (iii) An exception to the richness media theory in a FOSS
ecosystem: In a FOSS ecosystem, with the variety of cul-
Finally, motivated by all three theories, and to under-
tural and technical backgrounds of its members, the main
stand what could be missing in any or all of them when
communication channel for coordination is asynchronous
we study a FOSS ecosystem, we investigate research
(usually mailing). Email is egalitarian because it allows
question five:
contributors with different levels of English skills to par-
RQ5 What are the challenges that release managers face ticipate in equal terms (something that it is hard to achieve
in a FOSS ecosystem? in synchronous channels, where contributors with better
language skills can dominate a discussion). In an overview
To answer these research questions, we studied how the of the research literature, we did not find references to lan-
release management is done in the GNOME project. guage barriers in the use of communication channels in
We chose GNOME because it is a large and mature software development, perhaps because they did not study
software ecosystem [49], it has been studied before teams with the same level of variability of national origins
[22, 36, 39, 46, 47, 67, 79], its official release is a single as the FOSS ecosystem we studied.
product comprised of many independent and distributed
projects, and more important, it has a successful and sta- 2 Background
ble release schedule: a new GNOME release is issued every A software ecosystem is a set of software projects that
six months. We studied the high level communication of evolve together, share infrastructure, and are themselves
the release management process across five releases. part of a larger software project [45, 46].
This research will improve the way of working in In previous work [38] we identified the existence of
GNOME and similar FOSS ecosystems. three major streams in software ecosystems in research:
While other software development efforts might be able (1) software platforms and architecture, which includes
to profit from our insights as well, our research does not modelling and architecture such as software evolution,
allow generalization of results beyond the specific scope of software architecture, and software development as prod-
our study, i.e. the release management within the GNOME uct lines [8] (2) business and managerial perspectives
FOSS ecosystem. [34, 35], and (3) FOSS ecosystems [45, 68]. In addition, an
The contribution of this paper is threefold: ecosystem can be studied in-the-large or in-the-small [49].
(i) An empirical study of Release Management in That is, the interactions with external actors, or the inner
a FOSS ecosystem: This empirical study deepens our ones, respectively. Our research complements these works
understanding of the release management practices in and is focused in the inner parts of a FOSS ecosystem, that
a FOSS ecosystem. Empirical studies aim to investi- is, an ecosystem “in-the-small”.
gate complex real life issues where analytical research Goeminne and Mens first explored potential research
might not be enough [66]. In particular, empirical soft- questions to assess the quality of FOSS projects and that
ware engineering aims to understand the software engi- could lead to an improvement of the software develop-
neering discipline by treating software engineering as ment process [24]. A further study focused on the social
an empirical science [60]. In this sense, our study is aspects in FOSS ecosystems; in particular, the intersection
contributing empirical data to the body of knowledge of roles among developers and their activities. Devel-
about release management in FOSS ecosystems, which in opers might play multiple roles in a FOSS ecosystem,
turn will improve the way of working in GNOME and each role involves a set of activities and interactions with
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 4 of 24

other developers that are needed to articulate the tasks in channels induce a higher motivation, but the receiver
software development [49]. requires more abilities to process such information
This paper aims to further the understanding of com- because there is more information to process; and
munication and coordination in a software ecosystem richer communication channels are also synchronous,
with respect to release management. We studied the giving the receiver less time to process the message.
enabling factors to deliver a product in a FOSS ecosystem The opposite happens with leaner communication chan-
with many individual projects. To this end, we considered nels: they decrease the motivation but increase the abil-
the organizational structure, its communication chan- ity to process a message. This is what Robert and
nels, and the interaction between developers of different Dennis [63] call “richness media paradox” because the
projects towards a common goal. rich media can simultaneously improve and impair the
communication.
2.1 Social aspects and communication channels
FOSS development teams use multiple communication 2.2 Release management
channels. There is a prevalence of certain channels over We studied the factors that allow a distributed FOSS
others, depending on the projects and the resources avail- ecosystem to deliver a product that involves coordina-
able to them, and because usually FOSS projects are devel- tion among many individual projects. To this end, we
oped by groups of people distributed across the globe. considered the organizational structure of the ecosystem,
FOSS projects might use different communications chan- its communication channels, and the interaction between
nels, among them mailing lists and IRC are the most developers of different projects towards a common goal.
frequently used [21, 23, 25]. Mailing lists are used as Michlmayr [50] studied the impact of schedules on
public forums for asynchronous communication whereas release management in FOSS projects, with an emphasis
IRC is used as instant messaging for synchronous com- on time-based schedules in seven projects. He charac-
munication. Both communication channels correspond to terized the challenges in release management that FOSS
leaner channels because of lack the ability of conveying projects face and the practices they use to cope with them.
nonverbal cues and the limited feedback [41]. Building on top of these contributions, this paper con-
Leaner communication channels are effective to process siders the communication needs to coordinate multiple
standard data and well understood messages, however, teams and projects in software ecosystems with focus on
they may require rules and procedures. The complexity release management.
in the communication increases when there are multi- To overcome the challenge imposed by the appar-
ple teams or projects within an ecosystem that require ent informality in the FOSS development, Erenkrantz
coordination, and who may have multiple conflicting [19] examined the release management in three FOSS
interpretations of the same piece of information. High projects and proposed a taxonomy for identifying com-
ambiguity in an organization means confusion and lack of mon properties to compare the release management in
understanding [14]. FOSS projects. The properties evaluated were: release
When the differentiation between teams and projects is authority (who decides the release content), versioning
small, but with high interdependence, then the coordina- (what is the scheme to name the release versions), pre-
tion can rely on leaner communication channels because release testing, approval of releases (who approves a the
the ambiguity is low. When the differences are high, software is ready to be released), distribution (how the
then a communication channel with high richness can software is distributed), and formats (in which formats
help reduce ambiguity, which may be challenging for a the software is released). We did not find evidence of other
FOSS ecosystem to use. The frequency of communication studies using this taxonomy.
will depend on the interdependence between them. The
higher the dependency, the higher the coordination needs. 2.3 Background on selected case: the GNOME ecosystem
Michlmayr and Fitzgerald [51] reported that the parallel The GNOME Project was started in 1997 by Miguel de
and independent nature of FOSS development reduces the Icaza and Federico Mena-Quintero to create a collec-
amount of active coordination needed in such projects. tion of libraries and applications that could make Linux
Yet, it is important to synchronize teams and projects a viable alternative in the desktop. The main compo-
regularly to establish awareness of changes that may nents of GNOME are: an easy-to-use GUI environment,
create conflict. a suite of applications for general use (for example,
From a cognitive point of view, the media richness email client, web browser, music player), and a collec-
of communication channels is not enough to get the tion of tools and libraries to develop applications for
information understood by the participants. The par- GNOME [22]. All of these components are highly inte-
ticipants must be motivated to process a message and grated, resulting in a common product: the GNOME
have the ability to process it [63]. Richer communication Desktop.
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 5 of 24

2.3.1 Organization of the GNOME ecosystem can be translatable, and maintain the tools that facili-
From an organizational point of view, GNOME is a feder- tate the work for developers and translators. Like project
ation of projects in which each project acts independently teams, they have their own internal structures and deci-
of the rest and has its own internal organization, yet they sion making processes, and act independently of other
collaborate to create the GNOME Desktop. teams; however, their purpose is to help other projects on
To organize around these highly integrated compo- specific tasks.
nents a non-profit organization was created in 2000: the
GNOME Foundation [22]. According to official state- 2.3.3 Relation between projects and cross-cutting teams
ments, the goals of the GNOME Foundation are: (1) to In GNOME, the release management tasks are performed
create a legal entity around GNOME (2) to manage the by the release team. This team does not have any official
infrastructure to develop and deploy GNOME, and (3) to power over any other team or its members. However, the
coordinate releases. release team decides which projects to include—and by
The GNOME Foundation does not have direct power extension, to exclude from—the official GNOME Desktop
over the individual projects or developers, most of whom release.
are either volunteers or paid employees of companies. The release team decisions are expected to help in
Instead, it aims to fulfill its goals by creating consensus the scheduling of activities of the cross-cutting teams.
and policies. The GNOME Foundation is headed by a For example, the Translation Team requires time without
Board of Directors that is democratically elected by the changes to the user interface to translate applications into
developers who are Foundation members. Any developer different languages. This demand can be satisfied better at
who has made a non-trivial contribution to GNOME can the end of a release cycle.
apply to become a Foundation member, a membership
that has to be renewed every two years [73]. The Char- 2.3.4 Previous studies of GNOME
ter of the GNOME Foundation states that one of the first The GNOME project has been widely studied. There are
duties of the Board of Directors was to appoint a Release studies on the workload of contributors and projects in the
Management Team [74]. GNOME ecosystem. Vasilescu et al. [78] determined that
The GNOME Foundation’s Board of Directors receives the workload varies depending of the type of contributor.
input from an Advisory Board. The Advisory Board is Koch and Schneider [39], and German [22] reported that
comprised of members of companies who directly fund the distribution of workload with respect to file touches
GNOME. The Board of Directors delegates administra- is left–skewed, where few developers contribute most of
tion tasks to an executive director and technical issues to code. Casebolt et al. [11] compared authoring with respect
the release team. to the file size, and suggested that large files are likely to be
authored by one dominant contributor. Lungu et al. [46]
2.3.2 Cross-cutting teams focused on the visualization of the source code activity
Cross-cutting teams are teams who contribute to multi- in the GNOME ecosystem over time, and distinguished
ple projects within the GNOME ecosystem; they provide three phases in GNOME’s lifetime: introduction, growth,
specialized expertise on areas that are common across all and maturity.
projects, and that usually individual projects may lack. Several studies have focused on GNOME’s bug database
Examples of such teams are the Translation Team, the (Bugzilla), whose purpose have been: (1) predict the bug
Accessibility Team, as well as teams for Quality Assurance severity [40, 42] (2) determine quality of bug reports
and Documentation. Cross-cutting teams are responsible [2, 69], and (3) determine the efficiency of developers to
for supporting the activities of project teams and the over- address issues [44].
all success of GNOME as an integrated environment. For Studies related to communication channels have been
instance, the Accessibility Team makes sure that every focused in set of projects, for example, Shihab et al. [71]
application in GNOME can be used by users with disabil- mined the meeting logs of the GTK+ project (a core
ities; the Accessibility Team develops libraries to enable library in the GNOME ecosystem) held on IRC (Internet
applications to interact properly with screen readers, Relay Chat). Pagano and Maalej [57] used LDA to explore
braille keyboards, and other similar devices, and simul- how developers communicate through blogs. One of the
taneously, the Accessibility Team works in every other outcomes was that developers usually write blog posts
library and application in GNOME to use such APIs. The after an engineering activity such as committing a new
Translator Team makes sure the applications, with their feature, fixing a complex or important bug, or releasing a
respective documentation, are available in multiple lan- new version of a piece of software. Lungu et al. [47] argued
guages, and that these translations are consistent across that studies based on multiple projects treated individu-
applications; to accomplish that, the Translator Team ally, and not as part of an ecosystem, miss the opportunity
monitor that every text available in the user interfaces to study the context of the projects.
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 6 of 24

3 Study design 6947 messages (an average of 214 messages per month).
To answer the research questions, we used a mixed meth- These were grouped into 945 discussions with 1 to 50
ods approach [18] that employs data collection and anal- participants each, and a median of 2 participants per
ysis with both quantitative and qualitative data analysis discussion.
[13, 66, 82]. The study was composed of four steps: (1) we To associate multiple email addresses with a single
identified the main communication channel used for high individual, we used an approach similar to the clus-
level coordination between projects and teams within the ter algorithm described by Bird et al. [6]. We created
ecosystem (2) we collected and cleaned the data from that clusters of similar identities and then manually pro-
channel (3) we analyzed the data collected and extracted cessed them. To create the clusters we used both name
discussion themes, and (4) we conducted interviews to tri- and email; we first normalized the names, then we
angulate our findings and obtain additional insights from looked for name similarities, name-email similarities, and
developers. email similarities. To match identities, we also collected
names and email addresses from other data sources,
3.1 Communication channel selection such as commit logs and projects’ metadata. Based on
To identify the communication channels used for release GNOME’s account name policy [72], we merged email
management, we learned about the GNOME organiza- addresses ending in gnome.org that had the same user
tion by gathering and consolidating information found name (for example, we merged in [email protected] email
on its website. Two main communication channels are addresses like [email protected], [email protected], and
recommended: mailing lists and IRC. We focused on mail- [email protected]).
ing lists, as they are archived and publicly available. We
did not find evidence that communication over IRC was 3.3 Analysis
archived by GNOME, which makes its historical analysis We followed a Grounded theory [12, 13] approach to ana-
harder, if not impossible. lyze the discussions in the desktop-devel-list mailing list.
In Grounded theory, researchers label or code openly the
3.2 Data collection and cleaning data to uncover themes and extract concepts. Through
We identified 285 mailing lists archived in the GNOME manual analysis we segmented the email subjects into cat-
ecosystem. We searched for mailing lists used for cross- egories and labeled them with a term, extracting themes
project communication and release management. We from the discussion threads.
found that the release team recommends to its new team To code the messages we read the email subjects and
members to follow two mailing lists (desktop-devel-list associated a code to each thread. The code then repre-
and release-team) to help new release team members sented the message’s theme. Whenever the subject was
grasp background information about the development unclear, we read the discussion thread in detail, and
process within the ecosystem [76]. The subscription to searched in other data sources (for example, wiki, web-
the release-team mailing list is limited to the release team sites, related bugs and source code commits referenced
members, therefore, it is an internal mailing list and no in the discussion) for additional clues about the topic
a cross-project communication channel. Because we are discussed. Thus, we also considered the role in the ecosys-
interested in cross-project communication and coordina- tem of the person initiating a discussion, the roles of
tion within the software ecosystem, we focused our study the other participants in the discussion, the number
in the main channel that serves that purpose. of messages in such discussion, the number of partici-
We identified the Desktop Development mailing list [75] pants in a discussion, and the time in the release cycle
as the main channel for information related to release were the discussion occurred—from early planning to
management: it is where the discussion of the desktop and finally releasing a stable version. We used those details
platform development takes place. To study the commu- as follow:
nication across several releases, we retrieved data for 32
months spanning from January 2009 to August 2011. We Role (initiator). To know an individual’s status in a
used MLStats [64] to split into threads the mailing list project within the ecosystem, and the potential moti-
archive data sets. We chose this period because it com- vations to bring a topic to discuss. We assumed that
prises 5 release cycles, including the transition between the intention of a message may vary depending of the
two major releases–from the series 2.x to 3.x. The transi- sender (user, regular developer, project maintainer,
tion from the series 1.x to 2.x lead to frustrations among or team member).
developers, as well as skepticism that a—back then new— Role (participants). To know specialties and type of
time-based release would allow to pursue a new major discussion they became involved with. We could dis-
version [50]. Therefore, the transition between major tinguish among people who replied to regular devel-
releases was compelling to study. In total, we analyzed opers or newcomers in the mailing list, and whether
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 7 of 24

developers would participate in familiar subjects or and release management process. We conducted semi-
in broader discussions. structured interviews with GNOME developers who had
Number of messages. To order the discussions. Discus- actively participated in the discussions we studied. We
sions with only one message (no reply) were left to recruited 10 (out of the top 35 candidates) developers
the end. during GNOME’s main conference, the GUADEC, where
Number of participants. To order the discussions. Dis- we performed the interviews in person. The length of
cussions with several participants were investigated the interviews varied from 26 to 93 min. All our inter-
with more detail. views were recorded, later transcribed, and code following
Release cycle time. To contextualize the discussions a Grounded theory [12, 13] approach. We added labels
studied and determine discussion patterns that next to each answer in the transcriptions, in particular
depended on the stage in the release cycle. to determine when there were several topics combined in
the same answer. Then we grouped the common themes
We clustered codes into categories of communication across interviews, and manually analyzed them. The cod-
and coordination. The first author manually categorized ing was performed by the first author, and reviewed and
the email subject fields, which were presented to the discussed with the fourth author.
other authors for discussion, avoid misinterpretation, and The interviews consisted of three parts: (1) inquiry
to derive categories. Later, we validated these categories about roles in the project and communication channels
through interviews with the corresponding developers. our interviewees used (2) to comment on our findings;
to probe the extend to which our findings matched their
3.3.1 Social network analysis
perception of their and others’ communication and collab-
To determine key developers in GNOME’s release man-
oration activities (3) to comment on specific interactions
agement, we conducted a social network analysis of
with other developers and on the circumstances in which
the mailing list. In this social network, a node rep-
they would feel inclined to talk with them.
resents a participant in a discussion. A participant
First, we asked each interviewee questions of the use of
who replies an email is connected to all the previous
communication channels as consumers and producers of
authors who have participated in the same discussion
information, frequency they used each channel, how and
thread sorted chronologically. As Bohn et al. [7], we
when they used each channel, and the importance they
assume a respondent is aware of all the previous emails
gave to each channel and to elaborate their answers. We
in the same discussion thread. An edge between two
also asked each interviewee how their roles influenced the
nodes represents—undirected—communication between
use of certain channels, and how they take decisions when
two developers who share some interest in the topic
there were disagreements between developers in charge of
discussed.
different components in the project.
We explored this social network using Gephi [3]. We
Second, we probed the extend to which our findings
applied the ForceAtlas algorithm [33] provided by Gephi
matched their perception of their and others’ communi-
[3]. This algorithm spatializes small-world networks with
cation and collaboration activities. We presented to our
an emphasis on layouts to support analysts interpreting
interviewees our categorization of the communication
the graph. It pushes influential nodes to the centre and less
in the desktop-devel-list mailing list, the distribution of
influential ones to the border.
the question types, what were their perceptions of our
We determined influential nodes by calculating the
findings, and what we could have missed.
degree centrality and eigenvector centrality. We calculated
Finally, we used the social network to ask the inter-
degree centrality to determine key participants in discus-
viewees about their interactions with other developers
sions based on the numbers of messages sent or received
on the mailing list. To make it easier to spot the inter-
by a developer. The eigenvector centrality determined
viewees in the social network, we printed custom social
the influence of certain developers in the social network.
network charts per developer, highlighting their interac-
Although degree centrality also measures the influence,
tions with others developers. In an open question style, we
eigenvector centrality favors nodes connected to other
asked each interviewee about their interactions with other
nodes that are themselves central within the network.
developers, and to elaborate the circumstances they would
Through betweenness centrality, we determined gate-
feel inclined to participate with them, their relationship
keepers between developers. The higher the betweenness,
if they had any, if they were aware of amount of interac-
the higher the potential of an actor to be a gatekeeper [70].
tions they had (for example, their importance in the social
3.4 Interviews and triangulation network). To enable us to engage in the interviews bet-
The purpose of interviewing developers was twofold: first, ter, we familiarized ourselves with the type of discussions
to triangulate our findings, and second, to enrich our find- that each of these developers participated, and selected
ing with additional insights of the development practices the ones we considered may bring us richer answers
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 8 of 24

(in case we needed to remind the interviewee their can lead to a generalization through analytical generaliza-
interactions). tion, which is performed by comparing the characteristics
of a case to a possible target [20]. The case study presented
3.5 Threats to validity can facilitate the analytical generalization and comparison
In this section we discuss potential threats to the validity with other cases.
we identified on this case study and its results.
4 Findings
3.5.1 Construct validity In this section we present our findings structured by the
Construct validity refers to whether the studied param- respective research questions they answer. We report our
eters are relevant to the research questions, and actually findings based on the analysis of mailing list communi-
measure the social constructs or concepts intended to cation, social network analysis, interviews. To illustrate
be studied. Our analysis is based on data we extracted some findings, we provide quotations from interviews and
from public archives. We found two main communica- give examples of developer viewpoints. Among similar
tion channels in GNOME: IRC and mailing lists. We also opinions, we chose to quote only the one we considered
found several secondary communication channels, such the most representative for each case
as blogs and conferences. As we focused on communica-
tion on one mailing list in our study, we might have missed 4.1 What are the communication channels used for
some interactions that happened on other channels, such release management?
as IRC which is not archived. There could also be GNOME In our interviews, we found that the release team may
developers who do not participate in the mailing lists at monitor a variety of communication channels to have
all and instead rely on other communication channels. multiple sources of information that could be relevant
However, previous research suggests that the majority of to a release. All these communication channels can help
discussions occur in mailing lists [6, 21, 22, 54, 55]. We the release team to track the development progress in
also triangulated our results by interviewing key devel- GNOME. As indicated by a former release team member:
opers we identified. It is thus unlikely that our analysis
missed important coordination types, patterns, strategies, “[The release team] may include any input [—data
or challenges. source or communication channel—] when they decide.”

According to our analysis of mailing lists and follow-

3.5.2 Internal validity
up interviews, however, the release team prioritizes in
Internal validity relates to the validity of causal infer-
four of them. This is consistent with the guide for new
ences made by the study, and the researcher bias is a
release team members [76], which recommends par-
threat to the internal validity. The first author manually
ticipating in three mailing lists (release-team, desktop-
categorized the email subject fields, and he might have
devel-list, and devel-announce-list) and one IRC channel
introduced subjective bias in the results. We followed
(#release-team).
Creswell’s guidelines [13] for coding, which consists of
In this section, we report the main communication
abstracting common patterns in the communication pro-
channels, provide an overview of the other communica-
cess. This activity involves segmenting sentences—in this
tion channels, and describe how they are used for release
case an email’s subject field—into categories and labeling
management.
them with a term. The first author extracted the topics to
build the categories based on the interpretation of the sub-
4.1.1 Main communication channels
ject field of each email thread. To avoid misinterpreting
the actual discussions, before the coding, the first author Mailing lists. In GNOME, there are internal and global
familiarized himself with the email threads, read some mailing lists. The former are used by teams for their own
of the messages to obtain more contextual information, purposes, the latter are used to discuss topics that concern
and discussed with the other researchers in the team to the whole ecosystem. The release team uses an internal
soundcheck intermediate results and particular interpre- mailing list (release-team) to discuss and decide issues
tations of the data. Finally, the results were triangulated by directly related to release management, and a global one
interviewing developers. (desktop-devel-list) for the whole ecosystem.

“ If you [need] high level coordination that affect the

3.5.3 External validity entire project that tends to be on the mailing lists.”
External validity is concerned with the extent to which it
is possible to generalize the findings. In this paper, we pre- Membership to the internal list is limited to the release
sented a single case study, which may impose a threat to team members, although it can receive emails from any
generalization of the results. However, a single study case address and the archives are publicly available.
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 9 of 24

IRC. An interactive chat system. Similar to mailing lists, discussions can be either about process management,
there are internal and global chat channels. The release technical issues, or both.
team holds meetings once or twice per release cycle using From our analysis of the desktop-devel-list mailing list,
an internal channel (#release-team), which is also used nine discussion categories emerged. Five of them are
for discussions within the team and for developers to get directly related to release management activities:
quick answers on release management. For awareness of
the ecosystem, the release team monitors #gnome-hackers. Request for comments. Long-term proposals that affect
the entire ecosystem and require a high level of coordina-
“If people are already involved in working on something, tion. They may involve discussing the vision of the project
IRC works very nicely for coordination.” for the next releases and beyond or major changes whose
execution could take one or more releases. These dis-
4.1.2 Other communication channels cussions start at the beginning of each release cycle, and
Bugzilla, the web-based bug tracking system, is used to revisited during the release cycle. The release team gauges
keep track of features and critical bugs for future releases the overall sentiments. Examples: “empathy integration
[76]. The bug tracker is also used in conjunction with with the desktop”, “Consolidating Core Desktop libraries”,
mailing lists and IRC to obtain awareness of issues that “RFC: gtk-doc and gobject introspection”.
must be solved or require further discussion. Figure 1 shows that requests for comments happen
A wiki is used to maintain information of the release through the whole development cycle in spite that these
process, provides instructions for developers to make discussions are encouraged at the beginning of the cycle.
releases, and details of the current release schedule, such The x-axis shows the milestones of the release cycle (com-
as important dates. pare Fig. 2), and the y-axis shows a box plot of the number
In GNOME, the developers’ blogs are aggregated in a of discussions we found in each milestone.
common location called Planet (“a window into the world,
work and lives of GNOME hackers and contributors” [80]. Proposals and discussions. Short-term proposals
Some release team members use them to communicate focused on the current release cycle and tied to a par-
release-related decisions and to inform others about the ticular project, but with potential indirect impact on
release status, as well to monitor any concern from devel- other projects or teams. For example, a project wanting
opers, who express their points of view regarding the to use a library that is external to GNOME must submit
project. a proposal. Other projects interested in the library might
Face-to-face interactions occur in conferences and hack- support the idea or raise concerns if they are already
fests. During the annual conference, the release team dis- using an alternative library. The release team may raise
cusses GNOME’s future with developers. Hackfests are concerns regarding the long-term sustainability of the
focused face-to-face meetings of developers to work on external library—such as development activity, availabil-
a specific project, feature, or release; and depending on ity, or the library’s track record regarding security fixes.
the topic, some release team members are invited to par- Examples: “systemd as external dependency”, “Module
ticipate to bring their perspective. Although face-to-face Proposal: GNOME Shell”, “New proposed GnomeGoal:
interactions are highly valued because of the “high band- Add code coverage support”.
width”, the participation is limited only to the developers Figure 3 shows that proposals and discussions happen
able to attend. through the whole cycle.
Announcement Notifications for developers about the
In GNOME, the release team uses mailing lists and
status of a component or the whole project. The purpose
IRC as the main communication channels for coor-
is to raise awareness among developers and keep them
dination; for long term discussions, and for quicker
engaged. Announcements include the releases of new ver-
decisions that involve less than four people, respec-
sions, a new branch, new external dependencies, and
tively. Regardless, the release team might use multiple
status reports of the project goals. Examples: “GNOME
channels as input to gauge their decisions, including
3.0 Release Candidate (2.91.92) Released!”, “GNOME 3.0
face–to–face meetings.
Blocker Report”.
Figure 4 shows when the announcements take place
during the development cycle.
4.2 How do developers communicate and coordinate for
release management? Schedule reminders. Specific type of announcement
We found that developers use different communication used by the release team to send periodic reminders of
channels, some of them specific to a particular topic or the release cycle’s stage. The release team reminds devel-
project and others for wider discussion. In the latter, opers to release a new version, start the period of feature
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 10 of 24

Fig. 1 Request for comments during the release cycle

proposals, and so on. Its nature and recurrence make controls the changes (See Section 4.4). The discussion is
it worth a category by itself. Examples: “Release Notes open to everyone, but the decision is taken by the release
time!”, “GNOME 2.29.90 beta tarballs due”, “Last call for team, the Documentation Team, or the Translation Team.
comments on module proposals”. These requests require a timely decision as they occur
Figure 5 shows that schedule reminders happen through close to the release date. All decisions require at least
the whole cycle, however, some milestones receive more two votes from the release team. Changes in translat-
reminders than others. able strings will also require the approval of the Docu-
mentation and Translation Teams. Changes in the user
Request for approval. Request to break the freeze period interface will also require the approval of the Documenta-
at the end of the release cycle, once the release team tion Team [76]. Examples: “Hard code freeze break request

Fig. 2 GNOME six-month release schedule in weeks and its milestones. A release cycle starts immediately after a major release. The stable version is
kept in a branch for bug fixes, whereas the regular development continues in the main branch. The release cycle starts with a release meeting to
evaluate the last cycle, and to discuss the next cycle. The stages drive the type of communication. This illustration is based on data obtained from
multiple release schedules available on the release team’s wiki page and from our interviewees
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 11 of 24

Fig. 3 Proposals and discussions during the release cycle

Fig. 4 Announcements during the release cycle

Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 12 of 24

Fig. 5 Schedule reminders during the release cycle

for gvfs”, “[Freeze break request] gtksourceview crash”,

“String change in gnome-session”. The release schedule of GNOME guides the type
Figure 6 shows that requests for approval happen and timing of coordination activities discussed in the
at the end of the development cycle, in the period main communication channel. The scope of discus-
when the release team must approve changes to the sions span from long-term to short-term planning, and
project. from the entire ecosystem to localized in particular
Table 1 presents the amount of discussions and projects
messages during the period studied. Both help balance
their importance. Although there are less Request for
comments and Proposal and discussions than Announce- 4.3 Who are the key actors in the release management
ments, the proportion of messages of each of them process?
reflects that those are the core of the discussions in the As described in Section 3, we conducted a social net-
mailing list. work analysis to determine key developers in the release
We noticed that discussions started by well-known management process, which we then complemented with
developers attract other well-known developers, more interviews. Figure 7 shows such a social network. We
than discussions started by other people. Our intervie- present the reach of six different release team mem-
wees reported that they would be more inclined to partic- bers in the same social network, whose interactions are
ipate in a discussion started by known developers, as they highlighted in each subfigure. The box in each subfig-
already know their expertise. ure surrounds the developers (nodes) that interact directly
The remaining four categories are less relevant to with each release team member. Thus, we can observe the
release management activities: Events coordination (spe- scope of interaction of each release team member within
cial type of announcement related to the organization the social network.
of conferences, sprints, or hackfests), expertise seeking Among the three major nodes, the bigger one is the
(questions on seeking others working on or in charge of release-team mailing list in which only release team mem-
a specific part in GNOME), knowledge seeking (questions bers participate. The release-team mailing list has a nor-
from developers on specific organizational issues), and malized eigenvector of 1.0, which means that this node
Out of scope (any other message). is the most influential in the social network. In other
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 13 of 24

Fig. 6 Request for approvals during the release cycle

words, the release-team list is usually added to discus- lists from the social network, that is, to visualize bet-
sions to make release team members aware of them. On ter the developers. With respect to the other two major
the opposite side, its betweenness centrality is 0.0: the nodes, one is a senior release team member (highlighted
release-team list is not a gatekeeper or bridge between in more detail in Fig. 7e) and the another one a core
developers at all. As mailing lists are not associated with developer.
any person and do not send emails, this is expected. The Considering the prominence of the release team mail-
eigenvector and betweenness centrality values for release- ing list in the social network, the overall coverage of
team list were the same before we pruned other mailing the release team members in the discussions (Fig. 7),

Table 1 Summary of discussions and messages per category

Category Discussions Messages Median of messages per
# % # % Discussion Release
Discussions related to release management
Announcement 238 25.19 740 10.65 1 413
Proposals and discussions 219 23.17 2074 29.85 4 427
Request for approval 22 2.33 83 1.19 3 18
Request for comments 181 19.15 2505 36.06 6 1192
Schedule reminders 45 4.76 236 3.40 2 12

Discussions unrelated to release management

Events coordination 27 2.86 44 0.63 1 120
Expertise seeking 25 2.65 184 2.65 3 70
Knowledge seeking 151 15.98 764 11.00 3 971
Out of scope 37 3.92 317 4.56 2 26

Total 945 100.00 6947 100.00

Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 14 of 24

a b c

d e f

Fig. 7 Scope of interaction of six different release team members in the mailing list social network. The underlying social network is the same. Each
graph highlights the direct interaction of a different release team member with other developers. Two participants are connected if one of them
replies to the other. The size of the node represents the number of messages that a participant is involved. Red (dark) color edges indicate direct
interaction (neighbors), orange (mild) color edges indicate a tie among developers to whom a release team member has direct interaction, and grey
(pale) color represents the remaining participants. The biggest node close to the center is the release team mailing list

and the proportion of discussions related to release man- Other members then do not participate in the public
agement, we can infer that desktop-devel-list is rele- discussion.
vant for the release management process. The list is
described as being for general use, however the top- “When someone from the release team takes ownership
ics that emerged and the influence of the release-team of a topic, for instance, in a mailing list, if we agree with
indicate that this mailing list is used for release man- this person we can let this person handle the topic and so
agement communication and coordination within the we do not participate in the discussion, and we also have
ecosystem. a lot of discussion on the release team mailing list and
The release team members tend to participate in a wide on IRC, which does not appear on desktop-devel-list.”
range of discussions. In the social network, this would
mean being connected to the majority of the nodes. How- Members of the release team also contribute to other
ever, a release team member is less prone to participate areas of the project, which are not restricted to soft-
in a discussion where other release team members are ware programming. As a matter of fact, some release
already participating. According to our interviewees, if a team members do not code. This provides the release
release team member is already taking care of a discus- team with awareness and a closer connection to differ-
sion, the other members would leave them to lead the ent areas of the project. The areas can be documentation,
discussion. When members of the release team have dif- translation, accessibility, quality assurance, system admin-
ferent opinions, they discuss them in their internal mailing istration, and, in general, anything necessary to develop
list. Once they reach consensus, one of them goes back a software project. Most of these areas are represented
to the discussion on the global mailing list and contin- by teams. The more diverse the release team members
ues the discussion as a representative of the release team. are, the most representative the release team would be
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 15 of 24

of the whole project. That keeps the release team aware Directors. While the Board of Directors is not directly
of the different points of view of contributors earlier in involved in day-to-day activities, it has the power to dis-
the development process; and by increasing the areas of solve the release team. The GNOME Foundation mem-
participation, the teams would be more willing to listen bers are encouraged to participate in the discussion to
the release team. In other words, the more diverse the affect the decisions of the release team. In extreme cases of
release team members are, the wider its coverage would disagreement, members can propose a referendum [74].
be. When a member leaves, the release team members dis- As we described in Section 4.2, the release schedule
cuss which areas need improvement and recruit someone of GNOME guides the type and timing of coordination
accordingly. activities discussed in the main communication chan-
nel. Each of the resulting categories of communica-
“When somebody wants to leave the release team, we do
tion can be mapped to the release team objectives.
discuss which areas we would like to have more
Thus, the first objective maps to Request for com-
coverage [by release team members] ... to get a better
ments and Proposals and discussions; the second maps
flow of information and to also have some influence in
to Proposals and discussions, Schedule reminders, and
both directions.”
Request for approval; and the third objective maps
The diversity in the composition of the release team to Announcement, Schedule reminders, and Request for
works in both ways: it helps the release team to have first approval.
hand insights from a variety of teams or projects, and it From our analysis of mailing lists, the release team
helps projects and teams to have first hand access to the leads the discussions to define the requirements of a
release team. Furthermore, the diversity helps the release GNOME Release. These discussions occur during the fea-
team to better address different sensibilities within the ture proposals stage at the beginning of every release cycle.
ecosystem, especially in controversial topics. GNOME releases follow a time-based release cycle of six
months (26 weeks). Figure 2 illustrates the release cycle. A
“Is is little bit about peer groups, [...] who works with release cycle starts immediately after a major release. The
whom [...] in a topic that is a bit heated [...] somebody stable version is kept in a branch for bug fixes, whereas
from the release team who is in the same team that this the regular development continues in the main branch.
person answers, or I even ask ‘you have a better The release cycle starts with a release meeting to evalu-
connection to this person, could you provide the ate the last cycle, and to discuss the next cycle [76]. At
answer?’ ” this point, the release team creates a schedule of activities
The release team is comprised of nine individuals, and to deliver a release on time. The release team keeps the
to support diversity across supporting organizations, the teams informed of this schedule, verifying that the activ-
release team does not allow that more than two members ities are completed as required. In one of the interviews,
share the same affiliation—directly or indirectly [74]. a release team member described, in general terms, how
the schedule is created:

In GNOME, the release team members participate “GNOME is expected [by distributions] to release a new
in most of the discussions, although rarely more than version at the end of March and at the end of
one member participate in the same discussion. This September. This is well known among most developers.
unwritten policy reduces the possibility of showing [However,] we propose a schedule trying, for example, to
conflicting views between each other in public forums, not have a release on Christmas or Easter weekend, or
minimizing any potential confusion among develop- when people are expected to travel, like before or after
ers. Through social network analysis we visualized GUADEC [the GNOME conference].”
such behaviour, which is inline with the diversity in the
composition of the release team. During the first 20 weeks of a release cycle, there are
development releases every four weeks [77]. In the 21st
week, a stabilization phase begins with the release of a
4.4 What are the release management tasks in a FOSS first beta version. The stabilization is characterized by an
ecosystem? incremental freeze period: after this point, every change
The objectives of the release team are (1) defining the requires the approval of the release team. When the first
requirements of GNOME releases, (2) coordinating and freeze starts, it is not allowed to introduce new features
communicating with projects and teams; and (3) ship- nor user interfaces changes; the former is to focus in fix-
ping a release within defined quality and time specifica- ing issues and finishing the features already started, and
tions. The release team makes all the decisions regarding the later, is to give enough time to the Documentation
release management and is accountable to the Board of Team to make the manuals. When the second freeze starts,
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 16 of 24

a new restriction is added on top of the previous ones: it to perform a task depending of their experience, workload,
is forbidden to change any strings exposed to the users; or interest.
this allows the Documentation Team to polish the screen
shots for the documentation, and the Translator Team to The release team defines what a GNOME release is,
polish the translation of the user interface of applications sets the schedule, coordinates with projects and cross-
to multiple languages. The third and last freeze focuses on cutting teams to reach the goal on time, integrates
testing and fixing critical bugs, no changes can be made and validates the product as a whole, and releases
without approval by the release team. In week 26, the final GNOME. Because the release team lacks power over
version is released and a new cycle begins. the developers, it relies on building consensus on
The schedule planning takes in account activities such technical merits to convince the developers of their
as short-term and long-term proposals and discussions, judgment.
development, testing, and translations. As we reported in
Section 4.2, the release schedule drives the main types
of communication for coordinating the ecosystem. Based 4.5 What are the challenges that release managers face in
on the schedule, developers propose new features early a FOSS ecosystem?
in the release cycle which are openly discussed in the From our analysis and interviews, we identified the
mailing list. The proposals are expected to have a work- four major challenges that release managers face in the
ing plan and the approval of the maintainers in charge GNOME ecosystem, they: (1) need to coordinate projects
of the projects involved. To help reaching consensus, the and teams of volunteers without direct power over them
release team may guide the discussions to increase the (2) keep the build process manageable (3) monitor for
community participation, make sure that all major con- unplanned changes, and (4) test the GNOME release.
cerns from developers are raised and addressed, minimize
potential conflicts between proposals and long term plan, 4.5.1 Coordinate projects and teams of volunteers without
and keep under control new dependencies. Because of direct power over them
the lack power over developers, the release team must rely GNOME contributors participate as volunteers, even
on their social skills and technical merits before taking though some of them are paid by external companies for
decisions that may be controversial within the ecosystem their involvement. Projects are “owned” by the contribu-
(see Section 4.5.1); however, the diversity of backgrounds tors who actively work on them, and these people make
among release team members is useful to understand and decisions regarding their projects.
better address the variety of projects and teams within the
ecosystem. “Maintainers have the last word most of the time. If the
Our data shows how, to ship a release within defined conflict is about a maintainer not agreeing with your
quality and time specifications, the release team takes vision ..., with specific technical decision, then it is [the
control of the changes planned to be included in the maintainer’s call].”
release. As the release date approaches, the project main-
tainers require approval to make changes in their projects. The release team lacks of power to mandate developers
The release team also coordinates the release notes, work- to perform a task, it relies on building consensus based
ing with developers and teams—such as the marketing on technical merit and engaging developers to embrace
team—to write cohesive release notes for GNOME. the release process as theirs. One challenge the release
To make a release, the release team builds every com- team faces is to convince developers of its judgment and
ponent and validates that the software runs as expected. knowledge in the release process.
If a component fails to build the release team will get “It is difficult to coordinate well; there are so many
in touch with the developers of the failing component to people, so many teams. You need to be sure that
fix the build. Release team members acknowledged that everybody is aware on what is going on, that everybody
this is one of the most time-consuming and challenging is really involved when you need input. It is hard to
tasks. The purpose of continuously building and testing a coordinate people, it is really hard ... we try to do the
planned release is to enable the release team to monitor best we can, but still is not perfect.”
the quality of the product during the whole release cycle,
determine critical bugs and follow-up with developers to The release team builds awareness of the whole release
fix them. They also need to coordinate with distributors process by increasing the community participation. The
of GNOME regarding potential issues. time-based schedule facilitates this task by providing the
Our interviews confirm that within the release team same information to everyone beforehand [53], providing
there are no official roles. The tasks are self-assigned developers a sense of ownership of specific tasks and to
among release team members themselves, who volunteer become more involved in the process. This emphasizes
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 17 of 24

the importance of social skills and power of persuasion of To enable applications to be ported to multiple operat-
the release team members. ing systems and architectures, in the GNOME ecosystem
the core libraries are multi-platform. However, the sup-
4.5.2 Keep the build process manageable port for other operating systems is limited by the number
GNOME is composed of multiple piece of software, each developers working on them. Because the main platform
one with its own set of dependencies. When the num- of development is Linux, some breaks in other oper-
ber dependencies grows, building the whole GNOME ating systems (Windows or FreeBSD) may be noticed
becomes cumbersome as it takes longer, and with more late in the development process if nobody monitors
points of build failures. As a consequence, less volun- them.
teers build and test the whole GNOME before the release, Each project can decide on its own whether to add a new
which in turn increases the workload of the release team. public API. However, the release team monitors the API
The release team addresses the scalability issue by keep- and ABI stability, and makes sure the API documentation
ing the building stack as small as possible, however, it is up-to-date. To this end, the release team needs to detect
is challenging to keep the stack small. We learned this API changes and make sure they follow the programming
observation directly from the interviews, as a release team guidelines.
member stated:

“In GNOME 3, we tried to make the stack smaller, [by 4.5.4 Test the GNOME release
reducing] the set of modules. For a short while we The number of projects to coordinate, as well as depen-
managed to get it below 200 [dependencies]. But then, dencies on external projects, make cumbersome testing
new dependencies trap you back and now we have like the latest development version of GNOME. These qual-
220 or so.” ity assurance activities are performed by a small group of
developers, mainly the release team as who is in charge
Our interviews show that one way to make the building of continuous integration. In the words of a release team
stack smaller is by avoid managing external dependen- member, continuous integration is a necessity:
cies whenever is possible. To do so, the release team
defines two kind of dependencies: system dependencies
“[full automated continuous integration] would allow
and regular dependencies. The system dependencies are
us [to be] more aggressive: if something causes a
the preferred external dependencies as they are mature
problem, we can just back it out. Nowadays we commit
enough to be readily available in the most common distri-
something [that] works in our systems, and people keep
butions. The regular dependencies are any other and must
working on top. [Months] later, we find out ... problems
be built by GNOME, they can be software within GNOME
somewhere else, but nobody noticed them because
or an external dependency.
nobody managed to build the whole tree and actually
4.5.3 Monitor for unplanned changes test it.”
Changes in the Application Programming Interfaces (API)
and Application Binary Interfaces (ABI) of libraries pose a OSTree [79] is a project that aims to address this issue by
challenge to release managers. The libraries that GNOME continuously building GNOME and providing a testable
provides try to guarantee stability in both API and ABI; system ready to be downloaded and run. The release team
thus, any application that uses a public API of a stable uses it to build and test GNOME. Although promising,
series will continue working with future releases with- it may require intervention from the release team when
out recompilation. Because the GNOME stack has sev- some builds fail.
eral libraries, each one maintained by different people, it
is challenging to track unintentional breakages before a
release. Some changes in the API or ABI might work well The challenges of the release team in GNOME are
in some configurations, but break in others; or may be associated with the size and complexity of manag-
specific for a platform or architecture. To illustrate this ing multiple independent projects, and developed by
observation, a release team member indicated: volunteers in a distributed setting.

“A change ... that works fine in my local system, maybe

breaks some application somewhere else in the stack, or 5 Discussion
maybe it breaks only on a 32-bits system that I don’t In this section, we discuss our findings and present the
test locally because my laptop is 64-bits. Or in some lessons we learned from studying release management in
parts of our stack ... we have to be worried about the GNOME ecosystem. Our empirical investigation was
Windows or FreeBSD.” based on three theories: the media richness theory, the
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 18 of 24

channel expansion theory, and the theory of shared under- ecosystems because the community of developers have
standing. Based on these, we arrived to a set of lessons established a common ground. Olson and Olson argue
learned. the more common ground people can establish, the eas-
ier the communication and the greater the productivity
5.1 Media richness theory [56]. They also argue that when people have established
Media richness theory [14] argues that the communication little common ground, even if they have met in per-
channels and organizational structure play an important son or using high bandwidth channels, there will be low
role to reduce uncertainty and ambiguity in the orga- communication productivity regardless of the commu-
nizational processes. In a community of developers, the nication channel. The properties discussed here are in
selection of a communication channel delimits who can line with the related research literature on media chan-
participate and how much can be communicated in a nels [14, 41], except one that we did not find evidence
period of time. In FOSS, developers need to find a bal- of being addressed: the difference in English fluency.
ance between inclusion (number of participants) and the The asynchronous channels provide a better platform
“bandwidth” provided by the communication channel. for communication and are more participatory for those
The “bandwidth” in a communication channel corre- who do not speak English fluently. We can argue that
sponds to the number of cues in which an information is another instance of “richness media paradox” [63],
can be transferred [14]. The cues can be verbal (speech, where the rich media can simultaneously improve and
writing) or non–verbal (seeing, touching, tone of voice, impair the communication; in this particular case, the rich
vocal inflection, physical gesture, smelling, touching) media can impair the participation of non-native English
[14, 16, 17, 62]. speakers.
In our observations, participants value synchronous
and asynchronous communication. Therefore, an ecosys-
tem may consider using a combination of both type of Lesson 2: Provide a common place for coordination
media channels: asynchronous and synchronous. Asyn- for an ecosystem. Every software project has its
chronous channels, like mailing lists, allow a wide range own communication channel infrastructure, such as
of participants, can be an egalitarian medium (explained their own git repository or mailing list. However,
in detail below), and be archived (and searchable). Syn- to coordinate multiple projects is necessary a com-
chronous channels, like face–to–face interactions and mon infrastructure across projects. This facilitates
video-conferencing, allow higher bandwidth, but are less the communication to flow from the release team
“open” as it may exclude participants as they cannot attend to the projects and vice versa. In the GNOME
to a conference, or some participants may not be as fluent ecosystem, this is performed by having an asyn-
as English-native speakers. chronous ecosystem-wide mailing list for high-level
discussions, and an synchronous ecosystem-wide
IRC channel for quick feedback. Thus, an asyn-
Lesson 1: Ensure that the release team follows the chronous communication channel (such as mailing
main communication channels used by developers. list) is ideal for the main coordination activities,
The release team needs to communicate in a vari- and a synchronous channel (particularly face–to–
ety of ways. They use electronic channels that vary face interactions at conferences or sprints) is good for
from asynchronous (such as email and blogs) to more synchronization of activities among developers.
direct, interactive ones (such as IRC). They value
face-to-face communication; for this purpose they
organize gatherings (such as conferences and hack-
fests) where the release team can host sessions to In a FOSS ecosystem, with the variety of cultural and
address specific issues, or communicate one-on-one technical backgrounds of its members, the main com-
with some contributors. munication channel for coordination is asynchronous
(usually mailing). Email is egalitarian because it allows
contributors with different levels of English skills to par-
ticipate in equal terms (something that it is hard to achieve
Regardless of having communication channels that pro- in synchronous channels, where contributors with better
vide higher bandwidth, an important factor documented language skills can dominate a discussion). In an overview
by Olsen and Olsen [56] is the knowledge that the par- of the research literature, we did not find references to lan-
ticipants have in common, and they are aware that they guage barriers in the use of communication channels in
have it in common; this concept is known as common software development, perhaps because they did not study
ground. The use of mailing lists can succeed in FOSS teams with the same level of variability of national origins
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 19 of 24

as the FOSS ecosystem we studied. This finding may have

implication also in any regular FOSS project whose con- Lesson 4: Aim for a diverse release team. This
tributors proceed from a variety of cultural and technical implies that its members should be recruited from
backgrounds. different teams and with different skill sets. It helps
Face—to—face interactions at conferences and hack- having first-hand knowledge and understanding of
fests are appreciated by most of the interviewees in spite the different projects and teams, and to be able to
of its lack of inclusiveness. It is not-inclusive because reach everybody in the ecosystem. This diversity is
not all developers have the opportunity to attend to con- also likely to provide different points of views. They
ferences or gatherings (because of limited budget, work also need to be (or at least have been) members of
restriction, or other restrictions), and even if they attend the teams that they expect to guide. By being “one of
they might not be present during a particular discussion. them”, both sides will be able feel more affinity to the
In addition, conferences and hackfests provide opportu- challenges and problems of the other side, especially
nities for socialization and to establish group identity, when the release team makes decisions that contra-
both enhance the respect of social norms. These social vene the wishes of a given team. In a way, members
norms are particularly important to deal with excep- of the release team are not only release managers, but
tional events, such as, the potential lack of responsiveness they are also representatives of the teams. They are
of a developer or delays in the development of a given expected to make the best decisions that benefit both
feature [65]. the ecosystem and the individual teams as a whole.

Lesson 3: Consider including both good technical The GNOME release team has used different strategies
and social skills in a release team. Different visions to cope with the lack of official power over developers,
of the project might create friction between devel- and the diversity of projects to coordinate. For exam-
opers and release managers, as their expectations for ple, the release team presents an unified position to the
what should be in a release might differ. Technical ecosystem, informs constantly the ecosystem about the
skills are needed to understand the technical aspects release process, looks pro-actively to reach all members
of the project, and to build consensus on technical of the ecosystem, and keeps itself aware of the ecosystem.
merits; technical skills are also needed to gain respect Another strategy followed by the release team is to recruit
from their peers and to convince developers of their key contributors from different teams into the release
judgment. The release managers need social skills to team. The recruited contributors by the release team may
convince developers to perform the necessary actions or may not be leaders (maintainers) of their correspond-
to deliver the software on time, especially because ing projects, however, they represent different groups of
release managers lack direct power over developers. developers.
By comparing the results of the analysis of discussions in
the mailing list against the interviews, we found that some
Achieving agreement between participants may be release team members underestimate their role because
more difficult in electronic media channels than face– of lack of official power over developers—their decisions
to–face interactions [81]. Therefore, virtual teams rely on could be challenged by developers at any time.
trust; but it takes time to establish trust in complex envi- We found that the release team decisions are respected
ronments [32, 43, 50] like in a FOSS ecosystem. Building even when there is disagreement. For example, in 2010,
trust is important for team coordination, as it has been the release team decided that GNOME 3.0 was not ready
reported that the lack of trust is a barrier to team coordi- yet. Instead, it would make a maintenance release of
nation that geographically distributed organizations face the GNOME 2.x series (GNOME 2.32). This decision
[28, 29]. was announced, first, during the major GNOME con-
To build trust, the GNOME release team is composed ference (GUADEC), and second, in the desktop-devel-
of members of the community who work on different list mailing list [61]. The announcement triggered a
projects and teams. Therefore, they are exposed to the strong disagreement by a group of vocal core devel-
same issues that other contributors might face, they can opers, who argued that this decision would delay: (1)
raise an issue before it escalates, or they can find better porting applications to the new platform (2) testing the
ways to communicate with certain groups of developers. new GNOME Desktop in the wild, where it is actu-
The diversity in the release team composition can provide ally tested after a release. To highlight their disagree-
different backgrounds, which helps enrich the discus- ment, some developers hung a banner during GUADEC
sions and to increase awareness across different projects stating “Down w/release team” and the symbol of anarchy
and teams. (see Fig. 8). In GNOME, the maintainers of each project
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 20 of 24

by the release team; every developer participates in the

discussions and the maintainers of each project take
the decisions. The release team members see them-
selves as peers of the developers; they build trust based
on technical merits to reach consensus and they align
the developers towards a common goal: the integrated
product.
Michlmayr et al. [50, 52] argue that a set of clear poli-
cies and deadlines, which are followed and enforced, helps
build trust in complex FOSS projects. Hence, it is impor-
tant to follow and enforce policies and deadlines, oth-
erwise the effect may be the opposite: the loss of trust
in the work of the release managers. As an example of
Fig. 8 Banner hung by GNOME developers to show their such enforcement, according to Michlmayr [52], release
dissatisfaction with the release team. The banner was hung during
managers can proactively omit or postpone unfinished
GUADEC 2010, where the release team proposed the delay the release
of GNOME 3.0, later announced in the desktop-devel-list mailing list features.
According to the theory of shared understanding [1],
the formalization of a process in a software project helps
reduce the overall complexity, and once the stakeholders
are familiarized with the process itself, they can make
decide what to release, and therefore, the disagreeing
assumptions on parts of the organizations that are
developers could have released newer version of their
unfamiliar to them. Paraphrasing Aranda [1], the formal-
projects (for GNOME 3.0) regardless of the release team.
ization of the release process in a FOSS ecosystem, enables
However, the release team’s decision was respected, even
the coordination of a large group of people, and allows the
though it was unpopular.
ecosystem to grow. However, this formalization of pro-
cesses in our study is constrained to the management of
the release process, not how each project develops its
Lesson 5: Based on lack of power, lobbying and
own software.
consensus based management must be followed. To
We observed that the formalization of process described
build trust, raise awareness, and keep the ecosys-
by Aranda [1], and Michlmayr et al. [50, 52] correspond
tem aligned to the goals of the release process, the
to the definition of the release schedule and each one of
release team needs to be surrounded by contribu-
its stages. After a period of proposals and discussions, the
tors who are (or can become) “influencers”, because
release team decides the features will be part of the official
these influencers may already be trustworthy in dif-
release of GNOME. These features are offered by libraries
ferent parts of the ecosystem. Influencers can help
and applications, which once accepted must follow the
the release managers communicate more effectively
release schedule strictly. However, there are also applica-
with the whole ecosystem.
tions that follow the schedule even though they are not
required to do so. Again, this dynamic might also be over-
looked if projects are studied individually and not in the
5.2 Channel expansion and shared understanding context of the whole ecosystem.
theories We found that the communication activity in the
Channel expansion theory [10] presumes that as individ- desktop-devel-list mailing list is tied to the release
uals gain experience in the use of a channel they are able schedule. Five out of nine discussion categories in a
to use the media channel more effectively; such experi- general GNOME development mailing list were in related
ence involves the use of the channel itself, the organiza- to release management and showed temporal synchro-
tional context, the message topic, and the understanding nization with the development cycle schedule. One main
of how their co-participants communicate. Furthermore, reason for this is that some cross-cutting teams increase
according to Dennis and Valacich [16], the development their participation at specific stages of the process. The
of standards and norms increases with the experience that documentation and translation teams are more active in
a group gain, and as a result there may also experience an the mailing list at the end of the development cycle,
improvement in the interplay and the tasks they perform reviewing change proposals that might affect their work.
over time. The release team members play an active role in the dis-
We have seen that the communication flow is flat in cussion during the whole cycle, but publish reminders at
GNOME, the communication and coordination is driven key moments in the development cycle.
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 21 of 24

According to the discussions we studied in the GNOME limited communication through well defined channels.
ecosystem, the message subjects were predictable and However, Michlmayr and Fitzgerald [51] argue that reg-
tended to follow a common pattern at every release cycle ular synchronization helps raise awareness and reduce
(RQ2 in Section 4.2), patterns that were also inline with conflict. In an ecosystem, coordination is important to
the objectives of the release team (RQ4 in Section 4.4). We coordinate multiple projects if they work towards a com-
speculate that this behaviour occur because the GNOME mon integrated product, each project may have its own
ecosystem is a mature project. We based our speculation mailing list, but they still need a common channel for
in that over time developers find a common ground to cross–project coordination.
use more effectively the communication channels used In contrast to Guzzie et al. [26], we state that the use of
for coordination [56], which also is inline with the theory the mailing lists depends on the project dynamics, and the
of collaboration through open superposition by Howison dynamics of a FOSS ecosystem and regular FOSS projects
and Crowston [31]. may differ in terms of complexity and coordination needs.
Nevertheless, mailing lists can have multiple uses, and
projects and ecosystems may adapt or evolve their use of
Lesson 6: Help the release team in the coordination mailing lists over time. In the long term, developers with
process with a well defined schedule. Once the coordi- an established common ground may use a communication
nation process is internalized by the community, the channel to coordinate effectively [56]. We also disclose
release team can focus its efforts on other challenges. when and for what to use each channel. For this, we pro-
In addition, the time–based schedule release provides vide the rational from the GNOME release team. We can
the release team a powerful tool: even though the conclude that release management is behaving different
release team might not know beforehand the features from general development.
to be included in any release ahead, it makes it cer-
tain when the features need to be discussed, decided
and released. The time–based release schedule sets Lesson 7: Release team work is different from regu-
the expectations for developers and stakeholders, lar software work. Any software system needs to plan
enabling them to plan ahead with confidence. The and manage its releases. In large ecosystems of inter-
planning helps the ecosystem to develop features related (but independent) projects this task is much
incrementally. The tasks that might appear too large more complex than in a single system. The release
are likely to be planned in the long term, and deferred team plays a coordination role without participating
if they cannot be finished on time (“there will be directly in any particular project. The release man-
another release in six-months”). agement activities are not recorded in commits of
any project, but in discussions in various channels,
including email, IRC, and even face—to—face. For
researchers studying coordination, the release team
A challenge of time-based releases is choosing the right
role can be overlooked if not explicitly controlled for.
release frequency. Too frequent releases may limit inno-
vation as developers may target features that can be
implemented within the release interval. Too far apart
releases, may provide long-term stability but also be seen 6 Conclusions and outlook
as a sign of stagnation and drive contributors away of the We explored the GNOME ecosystem to gain a deeper
project [51]. understanding of its dynamics. We determined the main
Guzzi et al. [26] argue that the development mailing list communication channel used to coordinate the ecosys-
is one of several communication channels used in FOSS tem, extracted meaningful discussion topics, determined
projects. We concur, as we noticed in our case study that the relevant actors, whose later confirmed and enriched
developers communicate using IRC, face–to–face interac- our findings.
tions at conferences, sprints and hackfests, issue trackers The release team is a key player in the communica-
(Bugzilla), among others. Furthermore, Guzzi et al. [26] tion and coordination among developers in GNOME. The
determined that the mailing list only drives a few of communication coverage that the release team has in the
the coordination project discussions (3% among all the GNOME community is far-reaching. This phenomenon
discussions in the Lucene project), arguing that as a conse- has so far been undocumented. Our interviewees were
quence, the role of mailing lists had changed. For example, surprised by this finding, yet they all agreed that it
both Brooks [9] and Parnas [58] argue that when the tasks made sense.
are clearly divided, there is less coordination required; In GNOME, the release team members come from a
and according to Michlmayr [53] a decomposed system variety of teams or projects, as some of their members
has the advantage that allows the division of labour with acknowledged in the interviews. Some of them are from
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 22 of 24

the system administrators team, bug squadron, accessi- Ethics approval and consent to participate
bility team, or maintainers of individual projects. This The research was carried out in accordance with the Canadian Tri-Council
Policy Statement (TCPS 2): Ethical Conduct for Research Involving Humans,
variety allows the release team to monitor and address and has been approved by the Human Research Ethics Board of the University
almost all communications. Our interaction analysis could of Victoria, British Columbia, Canada. Informed consent was obtained from
be beneficial for the release team, either to detect commu- each developer interviewed. The protocol numbers approved for conducting
interviews is 12-024, and the protocol number of the waiver for studying
nication anomalies in time or to discard irrelevant issues archives publicly available is 12-023.
faster.
The release team leads the coordination efforts in the Competing interests
GNOME ecosystem, it is the glue that keeps multiple The authors declare that they have no competing interests.

projects and teams working together towards a goal. It is Publisher’s Note

a crucial team for the success of GNOME, even if some of Springer Nature remains neutral with regard to jurisdictional claims in
its members write little or no code at all. published maps and institutional affiliations.
The focus of our case study was an ecosystem “in-
Author details
the-small”. However, projects in an ecosystem are not 1 Department of Computer Science, University of Victoria, 3800 Finnerty Road,
developed in a vacuum, they have dependencies and other Victoria, British Columbia, Canada. 2 Chalmers | University of Gothenburg,
ecosystem may depend on them, as well. A study of an Gothenburg, Sweden.
ecosystem “in-the-large” may show interactions between
Received: 24 August 2016 Accepted: 1 August 2017
software ecosystems, with individuals acting as brokers
between them. As our results show, GNOME projects
already rely on external libraries, utilities, systems, and References
organizations that at least the release team needs to coor- 1. Aranda J. A Theory of Shared Understanding for Software Organizations:
PhD thesis, University of Toronto; 2010.
dinate with. Some of those external dependencies may be 2. Bachmann A, Bernstein A. When process data quality affects the number
part of another ecosystem, with developers in common of bugs: Correlations in software engineering datasets. In: Proceedings of
ecosystems who may act as bridges between ecosystems. the 7th IEEE Working Conference on Mining Software Repositories (MSR
2010). Cape Town: IEEE; 2010. p. 62–71.
The operational details of release management among 3. Bastian M, Heymann S, Jacomy M. Gephi: An Open Source Software for
ecosystems might vary. The characteristics of the release Exploring and Manipulating Networks. In: Proceedings of the
team, tasks, challenges, the interaction with projects and International Conference on Weblogs and Social Media; 2009. p. 361–2.
4. Berkus J. The 5 Types of Open Source Projects. 2005. Online. Visited on 28
teams, and the lessons learned of this case study can be Feb 2013. http://web.archive.org/web/20090130091039/http://
compared against other ecosystems in future research. powerpostgresql.com/5_types.
Specially, how the release management in ecosystems 5. Bird C. Sociotechnical coordination and collaboration in open source
software. In: Proceedings of the 27th IEEE International Conference on
cope with similar challenges than the GNOME ecosystem. Software Maintenance (ICSM 2011). Williamsburg: IEEE; 2011. p. 568–73.
The similarities may help build a theory of coordina- doi:10.1109/ICSM.2011.6080832.
tion and communication for release management in FOSS 6. Bird C, Gourley A, Devanbu P, Gertz M, Swaminathan A. Mining Email
Social Networks. In: Proceedings of the 3rd. International Workshop on
ecosystems. Mining Software Repositories. Shanghai: (MSR 2006); 2006. p. 137–43.
7. Bohn A, Feinerer I, Hornik K, Mair P. Content-Based Social Network
Abbreviations Analysis of Mailing Lists. R J. 2011;3(June):11–18.
ABI: Application binary interfaces; API: Application programming interfaces; 8. Bosch J. From Software Product Lines to Software Ecosystems. In:
FOSS: Free and Open source software; IRC: Internet relay chat; LDA: Latent Proceedings of the 13th International Software Product Line Conference
dirichlet allocation; MSR: Mining software repositories (SPLC 2009). San Francisco; 2009. p. 111–9.
9. Brooks Jr FP. The Mythical Man-Month: Essays on Software Engineering,
Acknowledgements 1st ed. Massachusetts: Addison-Wesley Publishing Company, Reading;
This paper is an extended version of the article presented at OSS 2016, under 1975, p. 195.
the title of “Herding Cats: A Case Study of Release Management in an Open 10. Carlson JR, Zmud RW. Channel Expansion Theory and the Experiential
Collaboration Ecosystem”. Acknowledgements for Claudio Saavedra for the Nature of Media Richness Perceptions. Acad Manag J. 1999;42(2):153–70.
photo used in Fig. 8 which was released under a Creative Commons License 11. Casebolt JR, Krein JL, MacLean AC, Knutson CD, Delorey DP. Author
(CC-NC-BY, https://flic.kr/p/8AsFbW). entropy vs. file size in the gnome suite of applications. In: Proceedings of
the 6th Ieee International Working Conference on Mining Software
Funding Repositories (MSR 2009). Vancouver: IEEE; 2009. p. 91–4.
This work was partially supported by the Natural Sciences and Engineering 12. Corbin JM, Strauss A. Grounded theory research: Procedures, canons, and
Research Council of Canada (NSERC). GPC was a PhD fellowship from Becas evaluative criteria. Qual Sociol. 1990;13(1):3–21.
Chile, granted by Government of Chile. The funding agency had no role in 13. Creswell JW. Research Design: Qualitative, Quantitative, and Mixed
study design, data collection and analysis, decision to publish, or preparation Methods Approachesvol. 2. Thousand Oaks: Sage Publications; 2009, p. 260.
of the manuscript. 14. Daft RL, Lengel RH. Organization Information Requirements, Media
Richness and Structural Design. Manag Sci. 1986;32(5):554–71.
Authors’ contributions 15. de Souza C, Froehlich J, Dourish P. Seeking the Source: Software Source
GPC carried out data-collection and analysis, conducted the interviews, and Code as a Social and Technical Artifact. In: Proceedings of the 2005
had a major role in drafting the manuscript. EK and LS participated in the International ACM SIGGROUP Conference on Supporting Group Work
discussion of the analysis, and drafted the manuscript. DMG provided (GROUP 2005). Sanibel Island: ACM; 2005. p. 197–206.
guidance with the research design, interviews, analysis, and drafted the 16. Dennis AR, Valacich JS. Rethinking media richness: towards a theory of
manuscript. All authors read and approved the final manuscript. media synchronicity. In: Proceedings of the 32nd Annual Hawaii
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 23 of 24

International Conference on Systems Sciences (hicss 1999). Maui: IEEE; 39. Koch S, Schneider G. Effort, co-operation and co-ordination in an open
1999. p. 1–10. doi:10.1109/HICSS.1999.772701. source software project: GNOME. Inf Syst J. 2002;12:27–42.
17. Dennis AR, Kinney ST, Hung Y-TC. Gender Differences in the Effects of 40. Lamkanfi A, Demeyer S, Giger E, Goethals B. Predicting the severity of a
Media Richness. Small Group Res. 1999;30(4):405–37. reported bug. In: Proceedings of the 7th IEEE Working Conference on
18. Easterbrook S, Singer J, Storey MA, Damian D. Selecting Empirical Mining Software Repositories (MSR 2010). Cape Town: IEEE; 2010. p. 1–10.
Methods for Software Engineering Research. In: Guide to Advanced 41. Lanubile F. Collaboration in Distributed Software Development. In:
Empirical Software Engineering. London: Springer; 2008. p. 285–311. Software Engineering; 2009. p. 174–93.
19. Erenkrantz JR. Release management within open source projects. In: 42. Linstead E, Baldi P. Mining the coherence of GNOME bug reports with
Proceedings of the 3rd Open Source Software . . . Portland; 2003. p. 51–5. statistical topic models. In: 2009 6th IEEE International Working
20. Flyvbjerg B. Five Misunderstandings About Case-Study Research. Qual Conference on Mining Software Repositories. Vancouver: IEEE; 2009. p.
Inq. 2006;12(2):219–45. 99–102.
21. Fogel K. Producing Open Source Software: How to Run a Successful Free 43. Ljungberg J. Open source movements as a model for organising. Eur J Inf
Software Project. Paramount: O’Reilly Media, Inc.; 2005. Syst. 2000;9(4):208–16.
22. German DM. The GNOME Project: A Case Study of Open Source, Global 44. Luijten B, Visser J, Zaidman A. Assessment of issue handling efficiency. In:
Software Development. Softw Process Improv Pract. 2003;8(4):201–15. Proceedings of the 7th IEEE Working Conference on Mining Software
23. German DM, Adams B, Hassan AE. The Evolution of the R Software Repositories (MSR 2010). Cape Town: IEEE; 2010. p. 94–7.
Ecosystem. In: Proceedings of the 17th European Conference on Software 45. Lungu M. Towards reverse engineering software ecosystems. In:
Maintenance and Reengineering (CSMR 2013). Williamsburg: IEEE; 2013. Proceedings of the 24th IEEE International Conference on Software
p. 243–52. doi:10.1109/CSMR.2013.33. Maintenance (ICSM 2008). Edmonton; 2008. p. 428–31.
24. Goeminne M, Mens T. Towards the Analysis of Evolution OSS Ecosystems. 46. Lungu M, Malnati J, Lanza M. Visualizing Gnome with the Small Project
In: Proceedings of the 8th BElgian-NEtherlands Software eVOLution Observatory. In: Proceedings of the 6th International Working Conference
Seminar (BENEVOL 2009); 2009. p. 30–5. on Mining Software Repositories (MSR 2009). Vancouver; 2009. p. 103–6.
25. Gutwin C, Penner R, Schneider K. Group awareness in distributed doi:10.1109/MSR.2009.5069487.
software development. In: Proceedings of the Conference on Computer 47. Lungu M, Lanza M, Gîrba T, Robbes R. The Small Project Observatory:
Supported Cooperative Work (CSCW 2004). Chicago; 2004. p. 72–81. Visualizing Software Ecosystems. Sci Comput Program. 2010;75(4):264–75.
26. Guzzi A, Bacchelli A, Lanza M, Pinzger M, Deursen AV. Communication 48. Markus ML. The governance of free/open source software projects:
in Open Source Software Development Mailing Lists. In: Proceedings of monolithic, multidimensional, or configurational? J Manag Governance.
the 10th Working Conference on Mining Software Repositories (MSR 2007;11(2):151–63.
2013). San Francisco: IEEE; 2013. p. 277–86. 49. Mens T, Goeminne M. Analysing the Evolution of Social Aspects of Open
27. Halverson CA, Ellis JB, Danis C, Kellogg WA. Designing task visualizations Source Software Ecosystems. In: Proceedings of the 3rd International
to support the coordination of work in software development. In: Workshop on Software Ecosystems (ISWSECO 2011). Brussels; 2011.
Proceedings of the Conference on Computer-Supported Cooperative p. 1–14.
Work (CSCW 2006). Banff; 2006. p. 39–48. 50. Michlmayr M. Quality Improvement in Volunteer Free and Open Source
28. Herbsleb JD, Grinter RE. Architectures, coordination, and distance: Software Projects Exploring the Impact of Release Management: PhD
Conway’s law and beyond. IEEE Softw. 1999;16(5):63–70. thesis, University of Cambridge; 2007.
29. Herbsleb JD, Grinter RE. Splitting the organization and integrating the 51. Michlmayr M, Fitzgerald B. Time-Based Release Management in Free
code: Conway’s Law Revisited. In: Proceedings of the 21st International and Open Source (FOSS) Projects. Int J Open Source Softw Process.
Conference on Software Engineering (ICSE 1999). Los Angeles: ACM Press; 2012;4(1):1–19.
1999. p. 85–95. 52. Michlmayr M, Fitzgerald B, Stol K-J. Why and How Should Open Source
30. Herbsleb J, Mockus A, Finholt TA, Grinter RE. An empirical study of Projects Adopt Time-Based Releases? IEEE Softw. 2015;32(2):55–63.
global software development: distance and speed. In: Proceedings of the 53. Michlmayr M, Hunt F, Probert D. Release Management in Free Software
23rd International Conference on Software Engineering ICSE 2001; 2001. Projects: Practices and Problems. In: Open Source Development,
p. 81–90. Adoption and Innovation; 2007. p. 295–300.
31. Howison J, Crowston K. Collaboration through open superposition: A 54. Mockus A, Fielding RT, Herbsleb JD. A case study of open source
theory of the open source way. MIS Q. 2014;38(1):29–50. software development: the Apache server. In: Proceedings of the 22nd
32. Iacono CS, Weisband S. Developing Trust in Virtual Teams. 30th Hawaii International Conference on Software Engineering (ICSE 2000). Limerick:
International Conference on System Sciences (HICSS) Volume 2: ACM; 2000. p. 263–72.
Information Systems Track-Collaboration Systems and Technology. 55. Mockus A, Fielding RT, Herbsleb JD. Two case studies of open source
1997412–420. software development: Apache and Mozilla. ACM Trans Softw Eng
33. Jacomy M, Venturini T, Heymann S, Bastian M. ForceAtlas2, a Methodol. 2002;11(3):309–46.
Continuous Graph Layout Algorithm for Handy Network Visualization 56. Olson GM, Olson JS. Distance matters. Human-Computer Interact.
Designed for the Gephi Software. PLoS ONE. 2014;9(6):98679. 2000;15(2):139–78.
34. Jansen S. Measuring the health of open source software ecosystems: 57. Pagano D, Maalej W. How do developers blog? In: Proceeding of the 8th
Beyond the scope of project health. Inf Softw Technol. 2014;56(11): Working Conference on Mining Software Repositories (MSR 2011).
1508–19. Honolulu: ACM Press; 2011. p. 123–32.
35. Jansen S, Finkelstein A, Brinkkemper S. A sense of community: A research 58. Parnas DL. On the criteria to be used in decomposing systems into
agenda for software ecosystems. In: Proceedings of the 31st International modules. Commun ACM. 1972;15(12):1053–8.
Conference on Software Engineering (ICSE 2009). Vancouver: IEEE; 2009. 59. Peiwei Mi, Scacchi W. Modeling Articulation Work in Software
p. 187–90. Engineering Processes. In: Proceedings of the 1st International
36. Jergensen C, Sarma A, Wagstrom P. The Onion Patch: Migration in Open Conference on the Software Process; 1991. p. 188–201.
Source Ecosystems. In: Proceedings of the 19th ACM SIGSOFT 60. Perry DE, Porter AA, Votta LG. Empirical Studies of Software Engineering.
Symposium and the 13th European Conference on Foundations of In: Proceedings of the Conference on The Future of Software Engineering
Software Engineering (ESEC/FSE 2011). Szeged; 2011. p. 70–80. (ICSE 2000); 2000. p. 345–55.
37. Knauss E, Damian D, Poo-Caamaño G, Cleland-Huang J. Detecting and 61. Péters F. GNOME 3.0 in March 2011. 2010. Online. Visited on 28 Feb 2014.
classifying patterns of requirements clarifications. In: 2012 20th IEEE https://mail.gnome.org/archives/desktop-devel-list/2010-July/
International Requirements Engineering Conference (RE 2012). Chicago; msg00133.html.
2012. p. 251–60. doi:10.1109/RE.2012.6345811. 62. Rasters G. Communication and Collaboration in Virtual Teams Did we get
38. Knauss E, Damian D, Knauss A, Borici A. Openness and requirements: the message? PhD thesis, Radboud Universiteit Nijmegen; 2004.
Opportunities and tradeoffs in software ecosystems. In: Proceedings 63. Robert LP, Dennis AR. Paradox of richness: A cognitive model of media
of the IEEE 22nd International Requirements Engineering Conference choice. IEEE Trans Prof Commun. 2005;48(1):10–21.
(RE 2014). Karlskrona, Sweden; 2014. p. 213–22. doi:10.1109/TPC.2003.843292.
Poo-Caamaño et al. Journal of Internet Services and Applications (2017) 8:12 Page 24 of 24

64. Robles G, González-Barahona JM, Izquierdo-Cortazar D, Herraiz I. Tools

for the Study of the Usual Data Sources found in Libre Software Projects.
Intl. J Open Source Softw Process. 2009;1(1):24–45.
doi:10.4018/jossp.2009010102.
65. Rocco E. Trust breaks down in electronic contexts but can be repaired by
some initial face-to-face contact. In: Proceedings of the Sigchi Conference
on Human Factors in Computing Systems - Chi ’98. New York: ACM Press;
1998. p. 496–502.
66. Runeson P, Host M, Rainer A, Regnell B. Case Study Research in Software
Engineering: Guidelines and Examples. Hoboken: Wiley Blackwell; 2012,
p. 256.
67. Sarma A, Maccherone L, Wagstrom P, Herbsleb JD. Tesseract: Interactive
visual exploration of socio-technical relationships in software
development. In: 2009 IEEE 31st International Conference on Software
Engineering. Vancouver: IEEE; 2009. p. 23–33.
68. Scacchi W, Alspaugh TA. Understanding the role of licenses and
evolution in open architecture software ecosystems. J Syst Softw.
2012;85(7):1479–94. doi:10.1016/j.jss.2012.03.033.
69. Schackmann H, Lichter H. Evaluating process quality in GNOME based on
change request data. In: 2009 6th Ieee International Working Conference
on Mining Software Repositories. Vancouver: IEEE; 2009. p. 95–8.
70. Scott JP. Social Network Analysis: A Handbook. Thousand Oaks: SAGE
Publications; 2000.
71. Shihab E, Hassan AE. On the use of Internet Relay Chat (IRC) meetings by
developers of the GNOME GTK+ project. In: 2009 6th Ieee International
Working Conference on Mining Software Repositories (MSR 2009).
Vancouver: IEEE; 2009. p. 107–10.
72. The GNOME Accounts Team. The GNOME Project. 2013. Visited on 28 Feb
2014. https://wiki.gnome.org/AccountsTeam/AccountNamePolicy.
73. The GNOME Foundation. GNOME Foundation Bylaws. The GNOME
Project. Boston; 2002. Visited on 28 Feb 2014. http://www.gnome.org/
wp-content/uploads/2012/02/bylaws.pdf.
74. The GNOME Foundation. GNOME Foundation Charter Draft 0.61. Online.
Boston; 2002. Visited on 28 Feb 2014. http://foundation.gnome.org/
charter.html.
75. The GNOME Project. GNOME Desktop Development List. 2001. Online.
Visited on 28 Feb 2014. https://mail.gnome.org/archives/desktop-devel-
list/.
76. The GNOME Release Team. Guide for New Release Team Members. 2011.
Online. Visited on 28 Feb 2014. https://wiki.gnome.org/ReleasePlanning/
NewReleaseTeamMembers.
77. The GNOME Release Team. Account Name Requirements. The GNOME
Project. 2013. Visited on 28 Feb 2014. https://wiki.gnome.org/
ReleasePlanning/TimeBased.
78. Vasilescu B, Serebrenik A, Goeminne M, Mens T. On the variation and
specialisation of workload - A case study of the GNOME ecosystem
community. Empir Softw Eng. 2014;19(4):955–1008.
79. Walters C, Poo-Caamaño G, German DM. The Future of Continuous
Integration in GNOME. In: Proceedings of the 1st Intl. Workshop on
Release Engineering (RELENG 2013). San Francisco: IEEE; 2013. p. 33–6.
80. Waugh J. Planet GNOME Guidelines. 2003. Online. Visited on 28 Feb 2014.
https://wiki.gnome.org/PlanetGnome.
81. Yamauchi Y, Yokozawa M, Shinohara T, Ishida T. Collaboration with Lean
Media: How Open-Source Software Succeeds. In: Proceedings of the
Conference on Computer Supported Cooperative Work (CSCW 2000).
Philadelphia; 2000. p. 329–38.
82. Yin RK. Case Study Research: Design and Methods (Applied Social
Research Methods), 4th ed. Thousand Oaks: Sage Publications; 2008.