Cited by 196Open Source Software InnovationsSoftware Engineering Techniques and PracticesSoftware Engineering Research

Core and Periphery in Free/Libre and Open Source Software Team Communications

Open access
Crowston, K., Kangning Wei, Qing Li, Howison, J.·2006·Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS'06)

Abstract

The concept of the core group of developers is important and often discussed in empirical studies of FLOSS projects. This paper examines the question, "how does one empirically distinguish the core?" Being able to identify the core members of a FLOSS development project is important because many of the processes necessary for successful projects likely involve core members differently than peripheral members, so analyses that mix the two groups will likely yield invalid results. We compare 3 analysis approaches to identify the core: the named list of developers, a Bradford’s law analysis that takes as the core the most frequent contributors and a social network analysis of the interaction pattern that identifies the core in a core-and-periphery structure. We apply these measures to the interactions around bug fixing for 116 SourceForge projects. The 3 techniques identify different individuals as core members; examination of which individuals are identified leads to suggestions for refining the measures. All 3 measures though suggest that the core of FLOSS projects is a small fraction of the total number of contributors.

Integrity signals

Registry

Crossref · 10.1109/hicss.2006.101

Cites

1 of 1 references verified0 citation errors · 0 not checkable

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?

  • Core contributors were classified using contributors' level of activity during the pretreatment period, measured by number of commits, into core contributors (top 25%) and peripheral contributors (rest 75%).

    “For the conceptualization of core contributors we used contributors' level of activity during the pretreatment period, measured by the number of commits, to classify contributors into core contributors (top 25%) and peripheral contributors (rest 75%) (Setia et al. 2012, Crowston et al. 2006).”
  • Both internal members (vendors and project contributors) and peripheral members (project users and open source foundations) can create collective action threats through situational and cross-project changes in member positions.

    “In this, our research highlights how both internal members (i.e., vendors and project contributors) and peripheral members (i.e., project users and open source foundations) can create collective action threats though situational and cross-project changes in member positions (Nakakoji et al. 2002;Crowston et al. 2006).”
  • Core developers primarily design the overall architecture, write code, maintain control over the codebase, and guide the long-term development of the project.

    “Core developers primarily design the overall architecture, write code, maintain control over the codebase, and guide the long-term development of the project”
  • Peripheral developers contribute code on a more irregular basis and tend to focus on bug fixes and incremental feature additions.

    “peripheral developers contribute code on a more irregular basis and tend to focus on bug fixes and incremental feature additions (Crowston et al. 2006, Setia et al. 2012, Gousios et al. 2014).”

Cites

Flagged first, then by citations

Cited by

Sorted by citations

Authors
Crowston, K., Wei, K., Li, Q., & Howison, J.
Affiliations
Syracuse University (US)
Venue
Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS'06)
Publisher
IEEE
Published
2006
Pages
118a-118a
ISSN
1530-1605 (ISSN-L)
OpenAlex
W2099162911
Cited by
196
References
1
Citations by year
2026: 7 · 2025: 7 · 2024: 9 · 2023: 8 · 2022: 8 · 2021: 8 · 2020: 16 · 2019: 13 · 2018: 6 · 2017: 11 · 2016: 11 · 2015: 10 · 2014: 7 · 2013: 14 · 2012: 8
FWCI
10.44
Type
conference paper
Language
en
Open access
Licence
cc-by
Locations
  • Hawaii International Conference on System Sciences (HICSS) (publishedVersion)
  • KiltHub Repository (submittedVersion)
  • Figshare (submittedVersion, cc-by)
  • KiltHub Repository
Topics
  • Physical Sciences › Computer Science › Computer Science Applications › Open Source Software Innovations
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Techniques and Practices
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Research
Keywords
free and open source software, core developers, core-periphery structure, developer communication, social network analysis, Bradford's law, bug fixes, open source software development

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