A Study of Social Interactions in Open Source Component Use
Bibliographic record
Abstract
All kinds of software projects, whether open or closed source, rely on open source components. Repositories that serve open source components to organizations, such as the Central Repository and npmjs.org, report billions of requests per year. Despite the widespread reliance of projects on open source components, little is known about the social interactions that occur between developers of a project using a component and developers of the component itself. In this paper, we investigate the social interactions that occur for 5,133 pairs of projects, from two different communities (Java and Ruby) representing user projects that depend on a component project. We consider such questions as how often are there social interactions when a component is used? When do the social interactions occur? And, why do social interactions occur? From our investigation, we observed that social interactions typically occur after a component has been chosen for use and relied upon. When social interactions occur, they most frequently begin with creating issues or feature requests. We also found that the more use a component receives, the less likely it is that developers of project using the component will interact with the component project, and when those interactions occur, they will be shorter in duration. Our results provide insight into how socio-technical interactions occur beyond the level of an individual or small group of projects previously studied by others and identify the need for a new model of socio-technical congruence for dependencies between, instead of within, projects.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.005 | 0.039 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.003 | 0.003 |
| Science and technology studies | 0.004 | 0.003 |
| Scholarly communication | 0.002 | 0.004 |
| Open science | 0.001 | 0.003 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.002 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".