pith. sign in

arxiv: 1906.08058 · v1 · pith:ELT6P2CNnew · submitted 2019-06-19 · 💻 cs.SE

On the abandonment and survival of open source projects: An empirical investigation

Guilherme Avelino , Eleni Constantinou , Marco Tulio Valente , Alexander Serebrenik This is my paper

Pith reviewed 2026-05-25 20:07 UTC · model grok-4.3

classification 💻 cs.SE
keywords open source projectsproject abandonmentcore developersGitHubempirical studysoftware maintenancemaintainer motivationproject survival
0
0 comments X

The pith

315 of 1,932 popular GitHub projects were abandoned, but 41% survived after new core developers took over.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper measures how often popular open source projects lose their original core developers and stop being maintained. It reports that 16 percent of the studied projects reached this state, yet 41 percent of those cases continued because new people became the main developers. It also reports survey results from the new maintainers on what prompted them to step in and what obstacles they met. Readers care because many widely used tools and libraries depend on a handful of active contributors, so patterns of loss and recovery affect real software reliability.

Core claim

Out of 1,932 popular GitHub projects, 315 (16%) were abandoned after the original core developers stopped contributing. Of those abandoned projects, 128 (41%) survived when new core developers assumed the maintenance work. A survey of the new maintainers shows that most knew the risks of abandonment when they began contributing, that personal use of the project was their main reason to get involved, that human and social factors mattered most in deciding to contribute, and that lack of time plus difficulty obtaining push access were the chief barriers they faced.

What carries the argument

Operational definitions that label core developers by commit volume, label a project abandoned when original cores stop activity, and label it surviving when new cores continue activity, combined with a survey of the new maintainers.

If this is right

  • Abandonment occurs in 16% of popular open source projects even when they start with many users.
  • New core developers rescue 41% of the projects that lose their original cores.
  • New maintainers are typically already using the project and aware of the risk before they begin contributing.
  • Human and social factors outweigh purely technical ones when deciding to take over an abandoned project.
  • Lack of time and difficulty gaining write access are the two largest practical obstacles for potential new maintainers.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Platforms could add automated notices when core activity drops, giving potential rescuers earlier warning.
  • Projects that publish clear contribution guidelines and access processes may see higher rescue rates.
  • The dominance of personal usage as a motive suggests that widely adopted but lightly maintained libraries are the ones most likely to find new maintainers.
  • Community health metrics that track social ties among contributors could predict survival better than activity counts alone.

Load-bearing premise

The selection of the 1,932 popular GitHub projects and the operational definitions used to identify core developers, project abandonment, and survival accurately reflect real-world dynamics without selection bias or measurement error.

What would settle it

Re-running the entire analysis on the same 1,932 projects but with a different inactivity threshold for declaring abandonment or a different commit-count cutoff for identifying core developers, and obtaining abandonment or survival percentages that differ by more than a few points.

Figures

Figures reproduced from arXiv: 1906.08058 by Alexander Serebrenik, Eleni Constantinou, Guilherme Avelino, Marco Tulio Valente.

Figure 1
Figure 1. Figure 1: TFDD on composer/satis a project, including three months [12], six months [13], [14], and one year [15], [16]. We experimentally test the sensitivity of five thresholds, in Section III-C, and select the one-year threshold as it is the least sensitive to error. Example: For the sake of simplicity we do not reproduce the algorithm here, instead we illustrate how it is used in our context [PITH_FULL_IMAGE:fi… view at source ↗
Figure 2
Figure 2. Figure 2: Surviving TFDD on composer/satis Table I NUMBER OF PROJECTS BY LANGUAGE. Language Projects Language Projects Ruby 398 (21%) PHP 334 (17%) JavaScript 342 (17%) Python 297 (15%) C/C++ 335 (17%) Java 226 (12%) III. STUDY DESIGN We adopt a mixed-methods approach and combine a large scale analysis of version control repository data with a sur￾vey. Mixed-methods are appropriate for the pragmatic stance common in… view at source ↗
Figure 4
Figure 4. Figure 4: Percentage of aliases in each project language with fewest projects (226 projects, 12%) [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: TF of the 1,932 projects in our dataset 66% 24% 7% 3% <1% <1% 0 20 40 60 1 2 3 4 5 6 7 Truck factor TFDD (%) [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Projects facing TFDDs et al. [6] that reported that 65% of the evaluated systems have TF ≤ 2, based on a sample of 133 popular GitHub projects. Most open source projects have low TFs. In a sample of 1,932 projects, 57% have TF = 1 and 25% have TF = 2. The highest TF in our sample is 26 developers. In the remainder of this section, we describe a quantitative exploration of the collected data, aiming to answ… view at source ↗
Figure 7
Figure 7. Figure 7: Contributions to PointCloudLibrary/pcl over time (screenshot from [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: When do TFDDs happen (counting from the repositories creation) [PITH_FULL_IMAGE:figures/full_fig_p005_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Number of commits after the last observed TFDDs [PITH_FULL_IMAGE:figures/full_fig_p005_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Percentage of commits after the last observed TFDDs [PITH_FULL_IMAGE:figures/full_fig_p006_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Number of developers, commits and files, and project age for [PITH_FULL_IMAGE:figures/full_fig_p006_12.png] view at source ↗
read the original abstract

Background: Evolution of open source projects frequently depends on a small number of core developers. The loss of such core developers might be detrimental for projects and even threaten their entire continuation. However, it is possible that new core developers assume the project maintenance and allow the project to survive. Aims: The objective of this paper is to provide empirical evidence on: 1) the frequency of project abandonment and survival, 2) the differences between abandoned and surviving projects, and 3) the motivation and difficulties faced when assuming an abandoned project. Method: We adopt a mixed-methods approach to investigate project abandonment and survival. We carefully select 1,932 popular GitHub projects and recover the abandoned and surviving projects, and conduct a survey with developers that have been instrumental in the survival of the projects. Results: We found that 315 projects (16%) were abandoned and 128 of these projects (41%) survived because of new core developers who assumed the project development. The survey indicates that (i) in most cases the new maintainers were aware of the project abandonment risks when they started to contribute; (ii) their own usage of the systems is the main motivation to contribute to such projects; (iii) human and social factors played a key role when making these contributions; and (iv) lack of time and the difficulty to obtain push access to the repositories are the main barriers faced by them. Conclusions: Project abandonment is a reality even in large open source projects and our work enables a better understanding of such risks, as well as highlights ways in avoiding them.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper reports a mixed-methods study of 1,932 popular GitHub projects that identifies 315 (16%) as abandoned and 128 of those (41%) as having survived through takeover by new core developers. It further presents survey results from the new maintainers indicating awareness of risks, usage-driven motivation, importance of human/social factors, and barriers of time and push-access.

Significance. If the measurement definitions prove robust, the work supplies concrete frequencies and qualitative insights into OSS project abandonment and recovery that are directly useful for maintainers, platforms, and researchers studying sustainability.

major comments (2)
  1. [Aims and Method] Aims and Method sections: the operational definitions of project abandonment (inactivity window), core-developer status (commit-count cutoff), and survival via new-core transition are presented without accompanying sensitivity analysis or external validation against ground-truth maintainer labels. Because the headline counts (315/1932 and 128/315) and the survey sample are direct functions of these thresholds, modest changes in the cutoffs would alter both the reported percentages and the set of projects surveyed.
  2. [Method] Method section: the selection criteria that produced the initial 1,932 projects and the procedure for identifying which developers received the survey are not accompanied by quantitative checks for selection bias or coverage of the target population of new maintainers.
minor comments (1)
  1. [Abstract] Abstract and Results: the survey response rate and the exact number of respondents are not stated, making it difficult to assess the strength of the four listed survey findings.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments on our manuscript. The points raised about methodological transparency are well taken, and we outline below how we will strengthen the paper in response.

read point-by-point responses

  1. Referee: [Aims and Method] Aims and Method sections: the operational definitions of project abandonment (inactivity window), core-developer status (commit-count cutoff), and survival via new-core transition are presented without accompanying sensitivity analysis or external validation against ground-truth maintainer labels. Because the headline counts (315/1932 and 128/315) and the survey sample are direct functions of these thresholds, modest changes in the cutoffs would alter both the reported percentages and the set of projects surveyed.

    Authors: We agree that sensitivity analysis is needed to demonstrate robustness. In the revised manuscript we will add a dedicated subsection that varies the inactivity window (e.g., 12 vs. 24 months), the commit-count threshold for core-developer status, and the criteria used to detect new-core transitions, reporting how the 16 % and 41 % figures change. Regarding external validation, obtaining ground-truth labels at scale from original maintainers is impractical; however, we will expand the limitations section to discuss this constraint explicitly and describe the manual spot-checks we already performed on a random sample of projects to confirm the definitions. These additions will be made. revision: yes

  2. Referee: [Method] Method section: the selection criteria that produced the initial 1,932 projects and the procedure for identifying which developers received the survey are not accompanied by quantitative checks for selection bias or coverage of the target population of new maintainers.

    Authors: We accept that quantitative checks for selection bias are warranted. We will extend the Method section with (i) a comparison of the 1,932 selected projects against a broader sample of popular GitHub repositories on dimensions such as stars, forks, age, and contributor count, and (ii) survey response-rate statistics together with a comparison of respondent versus non-respondent developer profiles (based on contribution history) and an explicit discussion of coverage of the new-maintainer population. These checks will be incorporated in the revision. revision: yes

Circularity Check

0 steps flagged

No circularity: purely empirical data analysis and survey with no derivations or self-referential logic

full rationale

The paper is an empirical investigation using project selection from GitHub, operational definitions for abandonment/survival/core developers, frequency counts, and a developer survey. No mathematical derivations, equations, fitted parameters presented as predictions, or load-bearing self-citations appear in the abstract, aims, method, or results. The 16% and 41% figures are direct counts from the selected dataset under the stated rules, not outputs of any model that reduces to its inputs by construction. The study is self-contained against external benchmarks (GitHub data and survey responses) with no reduction of claims to prior author work or definitional tautologies.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The claims depend on domain assumptions about how to measure project health and contributor roles in open source, with no free parameters or invented entities.

axioms (2)
  • domain assumption Projects are abandoned when core developers are lost
    Central to identifying the 315 abandoned projects in the results.
  • domain assumption New core developers can be identified as those assuming maintenance after abandonment
    Used to count the 128 surviving projects and frame the survey.

pith-pipeline@v0.9.0 · 5823 in / 1280 out tokens · 48888 ms · 2026-05-25T20:07:29.066484+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

53 extracted references · 53 canonical work pages

  1. [1]

    Roads and bridges: The unseen labor behind our digital infrastructure,

    N. Eghbal, “Roads and bridges: The unseen labor behind our digital infrastructure,” Ford Foundation, Tech. Rep., 2016

    work page 2016

  2. [2]

    The matter of heartbleed,

    Z. Durumeric, F. Li, J. Kasten, J. Amann, J. Beekman, M. Payer, N. Weaver, D. Adrian, V . Paxson, M. Bailey, and J. A. Halderman, “The matter of heartbleed,” in IMC, 2014, pp. 475–488

    work page 2014

  3. [3]

    Williams and R

    L. Williams and R. Kessler, Pair Programming Illuminated. Addison Wesley, 2003

    work page 2003

  4. [4]

    Are developers complying with the process,

    N. Zazworka, K. Stapel, E. Knauss, F. Shull, V . R. Basili, and K. Schnei- der, “Are developers complying with the process,” in ESEM, 2010

    work page 2010

  5. [5]

    Assessing the bus factor of Git repositories,

    V . Cosentino, J. L. C. Izquierdo, and J. Cabot, “Assessing the bus factor of Git repositories,” in SANER, 2015, pp. 499–503

    work page 2015

  6. [6]

    A novel approach for estimating truck factors,

    G. Avelino, L. Passos, A. C. Hora, and M. T. Valente, “A novel approach for estimating truck factors,” in ICPC, 2016, pp. 1–10

    work page 2016

  7. [7]

    Selecting Empirical Methods for Software Engineering Research,

    S. Easterbrook, J. Singer, M.-A. Storey, and D. Damian, “Selecting Empirical Methods for Software Engineering Research,” in Guide to Advanced Empirical Software Engineering , F. Shull, J. Singer, and D. I. K. Sjøberg, Eds. Springer, 2008, pp. 285–311

    work page 2008

  8. [8]

    Why Good Developers Write Bad Code: An Observational Case Study of the Impacts of Organizational Factors on Software Quality,

    M. Lavallee and P. N. Robillard, “Why Good Developers Write Bad Code: An Observational Case Study of the Impacts of Organizational Factors on Software Quality,” in ICSE, 2015, pp. 677–687

    work page 2015

  9. [9]

    A degree-of- knowledge model to capture source code familiarity,

    T. Fritz, J. Ou, G. C. Murphy, and E. Murphy-Hill, “A degree-of- knowledge model to capture source code familiarity,” in ICSE, 2010, pp. 385–394

    work page 2010

  10. [10]

    Degree-of- knowledge: modeling a developer’s knowledge of code,

    T. Fritz, G. C. Murphy, E. Murphy-Hill, J. Ou, and E. Hill, “Degree-of- knowledge: modeling a developer’s knowledge of code,”Transactions on Software Engineering and Methodology , vol. 23, no. 2, pp. 14:1–14:42, 2014

    work page 2014

  11. [11]

    A comparison of three algorithms for computing truck factors,

    M. Ferreira, M. T. Valente, and K. Ferreira, “A comparison of three algorithms for computing truck factors,” in ICPC, 2017, pp. 207–217

    work page 2017

  12. [12]

    Socio-technical evolution of the Ruby ecosystem in GitHub,

    E. Constantinou and T. Mens, “Socio-technical evolution of the Ruby ecosystem in GitHub,” in SANER, 2017, pp. 34–44

    work page 2017

  13. [13]

    Developer turnover in global, in- dustrial open source projects: Insights from applying survival analysis,

    B. Lin, G. Robles, and A. Serebrenik, “Developer turnover in global, in- dustrial open source projects: Insights from applying survival analysis,” in ICGSE, 2017, pp. 66–75

    work page 2017

  14. [14]

    Impact of developer turnover on quality in open-source software,

    M. Foucault, M. Palyart, X. Blanc, G. C. Murphy, and J.-R. Falleri, “Impact of developer turnover on quality in open-source software,” in FSE, 2015, pp. 829–841

    work page 2015

  15. [15]

    Using software archaeology to measure knowledge loss in software projects due to developer turnover,

    D. Izquierdo-Cortazar, G. Robles, F. Ortega, and J. M. Gonzalez- Barahona, “Using software archaeology to measure knowledge loss in software projects due to developer turnover,” in HICSS, 2009, pp. 1–10

    work page 2009

  16. [16]

    An empirical comparison of developer retention in the rubygems and npm software ecosystems,

    E. Constantinou and T. Mens, “An empirical comparison of developer retention in the rubygems and npm software ecosystems,” Innovations in Systems and Software Engineering , vol. 13, no. 2-3, pp. 101–115, 2017

    work page 2017

  17. [17]

    An in-depth study of the promises and perils of mining GitHub,

    E. Kalliamvakou, G. Gousios, K. Blincoe, L. Singer, D. M. German, and D. Damian, “An in-depth study of the promises and perils of mining GitHub,” Empirical Software Engineering , 2015

    work page 2015

  18. [18]

    Curating github for engineered software projects,

    N. Munaiah, S. Kroh, C. Cabrey, and M. Nagappan, “Curating github for engineered software projects,” Empirical Software Engineering, vol. 22, no. 6, pp. 3219–3253, 2017

    work page 2017

  19. [19]

    Who’s who in Gnome: Using LSA to merge software repository identities,

    E. Kouters, B. Vasilescu, A. Serebrenik, and M. G. J. van den Brand, “Who’s who in Gnome: Using LSA to merge software repository identities,” in ICSM, 2012, pp. 592–595

    work page 2012

  20. [20]

    A comparison of identity merge algorithms for software repositories,

    M. Goeminne and T. Mens, “A comparison of identity merge algorithms for software repositories,” Science of Computer Programming , vol. 78, no. 8, pp. 971–986, 2013

    work page 2013

  21. [21]

    Who is who in the mailing list? comparing six disambiguation heuristics to identify multiple addresses of a participant,

    I. S. Wiese, J. T. da Silva, I. Steinmacher, C. Treude, and M. A. Gerosa, “Who is who in the mailing list? comparing six disambiguation heuristics to identify multiple addresses of a participant,” in ICSME, 2016, pp. 345–355

    work page 2016

  22. [22]

    R. J. Grissom and J. J. Kim, Effect Sizes for Research: A Broad Practical Approach. Erlbaum Associates Publishers, 01 2005

    work page 2005

  23. [23]

    Appropriate statistics for ordinal level data: Should we really be using t-test and Cohen’sd for evaluating group differences on the NSSE and other surveys?

    J. Romano, J. Kromrey, J. Coraggio, and J. Skowronek, “Appropriate statistics for ordinal level data: Should we really be using t-test and Cohen’sd for evaluating group differences on the NSSE and other surveys?” in annual meeting of the Florida Association of Institutional Research, 2006, pp. 1–3

    work page 2006

  24. [24]

    Controlling the false discovery rate: A practical and powerful approach to multiple testing,

    Y . Benjamini and Y . Hochberg, “Controlling the false discovery rate: A practical and powerful approach to multiple testing,” Journal of the Royal Statistical Society , vol. 57, no. 1, p. 289â ˘A¸ S300, 1995

    work page 1995

  25. [25]

    Agile software testing in a large-scale project,

    D. Talby, A. Keren, O. Hazzan, and Y . Dubinsky, “Agile software testing in a large-scale project,” IEEE Software, vol. 23, no. 4, pp. 30–37, July 2006

    work page 2006

  26. [26]

    Mining version histories for detecting code smells,

    F. Palomba, G. Bavota, M. Di Penta, R. Oliveto, D. Poshyvanyk, and A. De Lucia, “Mining version histories for detecting code smells,” Transactions on Software Engineering, vol. 41, no. 5, pp. 462–489, 2015

    work page 2015

  27. [27]

    Perceptions of diversity on GitHub: A user survey,

    B. Vasilescu, V . Filkov, and A. Serebrenik, “Perceptions of diversity on GitHub: A user survey,” in CHASE, 2015, pp. 50–56

    work page 2015

  28. [28]

    Recommended Steps for Thematic Synthesis in Software Engineering,

    D. S. Cruzes and T. Dyba, “Recommended Steps for Thematic Synthesis in Software Engineering,” in ESEM, 2011, pp. 275–284

    work page 2011

  29. [29]

    Team knowledge and coordination in geographically distributed software de- velopment,

    J. A. Espinosa, S. Slaughter, R. E. Kraut, and J. D. Herbsleb, “Team knowledge and coordination in geographically distributed software de- velopment,” Journal of Management Information Systems , vol. 24, pp. 135–169, 2007

    work page 2007

  30. [30]

    How peripheral developers contribute to open-source software development,

    P. Setia, B. Rajagopalan, V . Sambamurthy, and R. Calantone, “How peripheral developers contribute to open-source software development,” Information Systems Research , vol. 23, no. 1, pp. 144–163, Mar. 2012. [Online]. Available: http://dx.doi.org/10.1287/isre.1100.0311

    work page doi:10.1287/isre.1100.0311 2012

  31. [31]

    An empirical study on the structural complexity introduced by core and peripheral developers in free software projects,

    A. Terceiro, L. R. Rios, and C. Chavez, “An empirical study on the structural complexity introduced by core and peripheral developers in free software projects,” in 2010 Brazilian Symposium on Software Engineering, 2010, pp. 21–29

    work page 2010

  32. [32]

    Poster: How do community smells influence code smells,

    F. Palomba, D. A. Tamburri, A. Serebrenik, A. Zaidman, F. Arcelli Fontana, and R. Oliveto, “Poster: How do community smells influence code smells,” in ICSE, 2018

    work page 2018

  33. [33]

    Programs, Life Cycles, and Laws of Software Evolu- tion,

    M. M. Lehman, “Programs, Life Cycles, and Laws of Software Evolu- tion,” Proceedings of the IEEE , vol. 68, no. 9, pp. 1060–1076, 1980

    work page 1980

  34. [34]

    Are heroes common in FLOSS projects?

    F. Ricca and A. Marchetto, “Are heroes common in FLOSS projects?” in ESEM, 2010, pp. 1–4

    work page 2010

  35. [35]

    Is my project’s truck factor low?

    M. Torchiano, F. Ricca, and A. Marchetto, “Is my project’s truck factor low?” in WETSoM, 2011, pp. 12–18

    work page 2011

  36. [36]

    On the difficulty of comput- ing the truck factor,

    F. Ricca, A. Marchetto, and M. Torchiano, “On the difficulty of comput- ing the truck factor,” in Product-Focused Software Process Improvement. Springer, 2011, vol. 6759, pp. 337–351

    work page 2011

  37. [37]

    Algorithmic complexity of the truck factor calculation,

    C. Hannebauer and V . Gruhn, “Algorithmic complexity of the truck factor calculation,” in PROFES, 2014, pp. 119–133

    work page 2014

  38. [38]

    Quantifying and mitigating turnover-induced knowledge loss,

    P. C. Rigby, Y . C. Zhu, S. M. Donadelli, and A. Mockus, “Quantifying and mitigating turnover-induced knowledge loss,” in ICSE, 2016, pp. 1006–1016

    work page 2016

  39. [39]

    Revisiting turnover-induced knowledge loss in software projects,

    M. Nassif and M. P. Robillard, “Revisiting turnover-induced knowledge loss in software projects,” in ICSME, 2017, pp. 261–272

    work page 2017

  40. [40]

    A study of the organizational dynamics of software teams,

    M. Hilton and A. Begel, “A study of the organizational dynamics of software teams,” in ICSE-SEIP, 2018, pp. 1–10

    work page 2018

  41. [41]

    Gender and tenure diversity in github teams,

    B. Vasilescu, D. Posnett, B. Ray, M. G. J. van den Brand, A. Serebrenik, P. T. Devanbu, and V . Filkov, “Gender and tenure diversity in github teams,” in CHI, 2015, pp. 3789–3798

    work page 2015

  42. [42]

    Going farther together: the impact of social capital on sustained participation in open source,

    H. S. Qiu, A. Nolte, A. Brown, A. Serebrenik, and B. Vasilescu, “Going farther together: the impact of social capital on sustained participation in open source,” in ICSE, G. Mussbacher, J. M. Atlee, and T. Bultan, Eds. IEEE / ACM, 2019, pp. 688–699

    work page 2019

  43. [43]

    Why do people give up flossing? A study of contributor disengagement in open source,

    C. Miller, D. G. Widder, C. Kästner, and B. Vasilescu, “Why do people give up flossing? A study of contributor disengagement in open source,” in OSS, ser. IFIP Advances in Information and Communication Technology, F. Bordeleau, A. Sillitti, P. Meirelles, and V . Lenarduzzi, Eds., vol. 556. Springer, 2019, pp. 116–129

    work page 2019

  44. [44]

    Why do developers take breaks from contributing to OSS projects? A preliminary analysis,

    G. Iaffaldano, I. Steinmacher, F. Calefato, M. A. Gerosa, and F. Lanubile, “Why do developers take breaks from contributing to OSS projects? A preliminary analysis,” CoRR, vol. abs/1903.09528, 2019. [Online]. Available: http://arxiv.org/abs/1903.09528

    work page arXiv 1903

  45. [45]

    Understanding the Impressions, Motivations, and Barriers of One Time Code Contributors to FLOSS Projects: A Survey,

    A. Lee, J. C. Carver, and A. Bosu, “Understanding the Impressions, Motivations, and Barriers of One Time Code Contributors to FLOSS Projects: A Survey,” in ICSE, 2017, pp. 187–197

    work page 2017

  46. [46]

    More Common Than You Think: An In-depth Study of Casual Contributors,

    G. Pinto, I. Steinmacher, and M. A. Gerosa, “More Common Than You Think: An In-depth Study of Casual Contributors,” in SANER, 2016, pp. 112–123

    work page 2016

  47. [47]

    Social Barriers Faced by Newcomers Placing Their First Contribution in Open Source Software Projects,

    I. Steinmacher, T. Conte, M. A. Gerosa, and D. Redmiles, “Social Barriers Faced by Newcomers Placing Their First Contribution in Open Source Software Projects,” in CSCW, 2015, pp. 1379–1392

    work page 2015

  48. [48]

    Overcoming open source project entry barriers with a portal for newcomers,

    I. Steinmacher, T. U. Conte, C. Treude, and M. A. Gerosa, “Overcoming open source project entry barriers with a portal for newcomers,” in ICSE, 2016, pp. 273–284

    work page 2016

  49. [49]

    Why We Engage in FLOSS: Answers from Core Developers,

    J. Coelho, M. T. Valente, L. L. Silva, and A. Hora, “Why We Engage in FLOSS: Answers from Core Developers,” in CHASE, 2018

    work page 2018

  50. [50]

    Why modern open source projects fail,

    J. Coelho and M. T. Valente, “Why modern open source projects fail,” in FSE, 2017, pp. 186–196

    work page 2017

  51. [51]

    Adams, E

    B. Adams, E. Constantinou, T. Mens, and G. Robles, Eds., Proceedings of the 1st International Workshop on Software Health, SoHeal@ICSE 2018, Gothenburg, Sweden, May 27, 2018 . ACM, 2018. [Online]. Available: https://doi.org/10.1145/3194124

    work page doi:10.1145/3194124 2018

  52. [52]

    Code of conduct in open source projects,

    P. Tourani, B. Adams, and A. Serebrenik, “Code of conduct in open source projects,” in SANER, M. Pinzger, G. Bavota, and A. Marcus, Eds. IEEE Computer Society, 2017, pp. 24–33

    work page 2017

  53. [53]

    Anger and its direction in collaborative software development,

    D. Gachechiladze, F. Lanubile, N. Novielli, and A. Serebrenik, “Anger and its direction in collaborative software development,” in ICSE NIER. IEEE Computer Society, 2017, pp. 11–14

    work page 2017