The GNOME project: a case study of open source, global software development

Germán, Daniel M.

doi:10.1002/spip.189

Cited by 131 publications

(116 citation statements)

References 11 publications

Supporting

Mentioning

109

Contrasting

Unclassified

Order By: Relevance

“…There could also be GNOME developers who do not participate in the mailing lists at all and instead rely on other communication channels. However, previous research suggests that the majority of discussions occur in mailing lists [6,21,22,54,55]. We also triangulated our results by interviewing key developers we identified.…”

Section: Construct Validitymentioning

confidence: 73%

“…The main components of GNOME are: an easy-to-use GUI environment, a suite of applications for general use (for example, email client, web browser, music player), and a collection of tools and libraries to develop applications for GNOME [22]. All of these components are highly integrated, resulting in a common product: the GNOME Desktop.…”

Section: Background On Selected Case: the Gnome Ecosystemmentioning

confidence: 99%

“…To organize around these highly integrated components a non-profit organization was created in 2000: the GNOME Foundation [22]. According to official statements, the goals of the GNOME Foundation are: (1) to create a legal entity around GNOME (2) to manage the infrastructure to develop and deploy GNOME, and (3) to coordinate releases.…”

Section: Organization Of the Gnome Ecosystemmentioning

confidence: 99%

“…Vasilescu et al [78] determined that the workload varies depending of the type of contributor. Koch and Schneider [39], and German [22] reported that the distribution of workload with respect to file touches is left-skewed, where few developers contribute most of code. Casebolt et al [11] compared authoring with respect to the file size, and suggested that large files are likely to be authored by one dominant contributor.…”

Section: Previous Studies Of Gnomementioning

confidence: 99%

“…We chose GNOME because it is a large and mature software ecosystem [49], it has been studied before [22,36,39,46,47,67,79], its official release is a single product comprised of many independent and distributed projects, and more important, it has a successful and stable release schedule: a new GNOME release is issued every six months. We studied the high level communication of the release management process across five releases.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management

Poo-Caamaño

Knauss

Singer

et al. 2017

J Internet Serv Appl

Self Cite

View full text Add to dashboard Cite

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.

show abstract

Section: Construct Validitymentioning

confidence: 73%

Section: Background On Selected Case: the Gnome Ecosystemmentioning

confidence: 99%

Section: Organization Of the Gnome Ecosystemmentioning

confidence: 99%

Section: Previous Studies Of Gnomementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management

Poo-Caamaño

Knauss

Singer

et al. 2017

J Internet Serv Appl

Self Cite

View full text Add to dashboard Cite

show abstract

Impacts of networking effects on software reliability growth processes: A multi‐attribute utility theory approach

Wen

2019

Quality & Reliability Eng

View full text Add to dashboard Cite

Software reliability growth models, which are based on nonhomogeneous Poisson processes, are widely adopted tools when describing the stochastic failure behavior and measuring the reliability growth in software systems. Faults in the systems, which eventually cause the failures, are usually connected with each other in complicated ways. Considering a group of networked faults, we raise a new model to examine the reliability of software systems and assess the model's performance from real-world data sets. Our numerical studies show that the new model, capturing networking effects among faults, well fits the failure data. We also formally study the optimal software release policy using the multi-attribute utility theory (MAUT), considering both the reliability attribute and the cost attribute. We find that, if the networking effects among different layers of faults were ignored by the software testing team, the best time to release the software package to the market would be much later while the utility reaches its maximum. Sensitivity analysis is further delivered. KEYWORDS multi-attribute utility theory, networking effects, nonhomogeneous poisson processes, software release policy, software reliability growth model 1952

show abstract

How are decisions made in open source software communities? — Uncovering rationale from python email repositories

Sharma

Savarimuthu

Stanger

2023

J Software Evolu Process

View full text Add to dashboard Cite

Group decision‐making (GDM) processes shape the evolution of open source software (OSS) products, thus playing an important role in the governance of open source software communities. While these GDM processes have attracted the attention of researchers, the rationale behind decisions, that is, how decisions are made that enhance the OSS, have not received much attention. This work bridges this gap by extracting these rationales from a large open source repository comprising 1.55 million emails available in Python development archives. This work makes a methodological contribution by presenting a heuristics‐based rationale extraction system called Rationale Miner that employs information retrieval, natural language processing, and heuristics‐based techniques. Using these techniques, it extracts the rationale behind specific decisions (for example, whether a new module was added based on core developer consensus or a benevolent dictator's pronouncement). This work unearths 11 such rationales behind decisions in the Python community and thus makes a knowledge contribution. It also analyzes the prevalence of these rationales across all PEPs and three sub‐types of PEPs: Process, Informational, and Standard Track PEPs. The effectiveness of our contributions has been positively evaluated using quantitative and qualitative approaches (e.g., comparison against baselines for rationale identification showed up to 47% improvement in the most conservative case, and feedback from the Python steering committee showed the accurate identification of rationales respectively). The approach proposed in this work can be used and extended to discover the rationale behind decisions that remain hidden in communication repositories of other OSS projects, which will make the decision‐making (DM) process transparent to stakeholders and encourage decision‐makers to be more accountable.

show abstract

The GNOME project: a case study of open source, global software development

Cited by 131 publications

References 11 publications

Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management

Herding cats in a FOSS ecosystem: a tale of communication and coordination for release management

Impacts of networking effects on software reliability growth processes: A multi‐attribute utility theory approach

How are decisions made in open source software communities? — Uncovering rationale from python email repositories

Contact Info

Product

Resources

About