Cited by 474Open Source Software InnovationsSoftware Engineering Techniques and PracticesWikis in Education and Collaboration

The social structure of free and open source software development

Open access
Crowston, Kevin, Howison, James·2005·First Monday

Abstract

Metaphors, such as the Cathedral and Bazaar, used to describe the organization of FLOSS projects typically place them in sharp contrast to proprietary development by emphasizing FLOSS’s distinctive social and communications structures. But what do we really know about the communication patterns of FLOSS projects? How generalizable are the projects that have been studied? Is there consistency across FLOSS projects? Questioning the assumption of distinctiveness is important because practitioner–advocates from within the FLOSS community rely on features of social structure to describe and account for some of the advantages of FLOSS production. To address this question, we examined 120 project teams from SourceForge, representing a wide range of FLOSS project types, for their communications centralization as revealed in the interactions in the bug tracking system. We found that FLOSS development teams vary widely in their communications centralization, from projects completely centered on one developer to projects that are highly decentralized and exhibit a distributed pattern of conversation between developers and active users. We suggest, therefore, that it is wrong to assume that FLOSS projects are distinguished by a particular social structure merely because they are FLOSS. Our findings suggest that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from "going open." In addition, the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams. We found that larger FLOSS teams tend to have more decentralized communication patterns, a finding that suggests interesting avenues for further research examining, for example, the relationship between communications structure and code modularity.

Integrity signals

Registry

Crossref · 10.5210/fm.v10i2.1207

Cites

Statistics

Recomputing p-values needs the paper’s full text.

Claims the paper makes

We couldn’t retrieve this paper’s full text, so its claims and self-check weren’t run. The registry and citation checks still apply.

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

  • Participation models such as the onion model and the core-periphery model become less hierarchical and more situational, as members can be peripheral in times of stability but become central agents during times of instability.

    “Accordingly, participation models such as the onion model (Nakakoji et al. 2002;Crowston and Howison 2005) and the core-periphery model (Mockus et al. 2002;Crowston et al. 2006) become less hierarchical and more situational, as members can be in peripheral positions in times of stability but become central agents during times of instability.”

Cited by

Sorted by citations

Authors
Crowston, K., & Howison, J.
Affiliations
Syracuse University (US)
Venue
First Monday
Published
2005-02-07
ISSN
  • 1396-0458 (ISSN-L)
  • 1396-0466
OpenAlex
W1965110090
Cited by
474
References
0
Citations by year
2026: 7 · 2025: 14 · 2024: 5 · 2023: 13 · 2022: 10 · 2021: 15 · 2020: 20 · 2019: 16 · 2018: 15 · 2017: 15 · 2016: 20 · 2015: 30 · 2014: 44 · 2013: 35 · 2012: 37
FWCI
71.02
Type
journal article
Language
en
Open access
Locations
  • First Monday (publishedVersion)
  • First Monday (acceptedVersion)
Topics
  • Physical Sciences › Computer Science › Computer Science Applications › Open Source Software Innovations
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Techniques and Practices
  • Social Sciences › Communication › Wikis in Education and Collaboration
Keywords
free and open source software, social structure, decentralized communication, SourceForge, bug tracking, team size, code modularity

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review