---
layout: default.html
title: "Is my Dependency Sustainable? A Systematic Mapping on Open Source Software Sustainability"
description: Synthesize how the wider concept of OSS sustainability is currently understood "in the wild", explore how it can be characterized, and discuss the impact a better understanding can have on more responsible OSS adoption.
permalink: /publications/fontes-design-2026/
pdf: /assets/docs/fontes-design-2026.pdf
doi: 10.1145/3786152.3788587
citation_title: "Is my Dependency Sustainable? A Systematic Mapping on Open Source Software Sustainability"
citation_authors:
  - Gabriel Silva Fontes
  - Vinicius dos Santos
  - Elisa Yumi Nakagawa
published_date: 2026-04-13
venue: 3rd International Workshop on Designing Software (Designing '26)
---

[PDF](/assets/docs/fontes-design-2026.pdf) · [10.1145/3786152.3788587](https://doi.org/10.1145/3786152.3788587)

Gabriel Silva Fontes · Vinicius dos Santos · Elisa Yumi Nakagawa  
3rd International Workshop on Designing Software (Designing ’26) · April 12–18, 2026 · Rio de Janeiro, Brazil

## Abstract

**Context:** With growing software reuse and interoperability, Open Source Software (OSS) is more ubiquitous than ever. Often sourced for free from volunteer-driven work, many developers lack awareness of the sustainability of OSS they depend on. Adopting OSS components while building software systems has long-lasting consequences, not only bringing benefits, but also risks. Understanding the sustainability of OSS dependencies thus becomes a critical activity during software design and development. However, OSS sustainability is not a very well-defined concept, thus making research and decisions regarding OSS adoption more difficult.

**Objective:** Synthesize how the wider concept of OSS sustainability is currently understood “in the wild”, explore how it can be characterized, and discuss the impact a better understanding can have on more responsible OSS adoption.

**Method:** We conducted a systematic mapping study (SMS) across 111 studies from the literature to extract sustainability understandings, synthetized into aspects of sustainability in OSS projects.

**Results:** Social and technical concerns are well-explored and reaffirm the importance of the OSS community. Individual, economic, and environmental definitions remain relatively underexplored. There is a growing usage of the term “sustainability” in OSS research. We propose 19 aspects that can be utilized to understand OSS sustainability.

**Conclusion:** Those aspects can be utilized by practitioners who rely on OSS to better understand the projects they depend upon, as well by researchers exploring this ecosystem.

**CCS Concepts:** Software and its engineering → Open source model; Risk management; Software evolution; Maintaining software

**Keywords:** Open Source, Open Source Software, Sustainability

## Introduction

Open Source Software (OSS) is widely used in a variety of activities in the modern economy ([Wachs et al. 2022](#ref-Wachs2022)). Present in most business domains, powering critical software infrastructure ([Eghbal 2016](#ref-Eghbal2016)), and prompting deep changes to quality through commodification pressure ([Linden, Lundell, and Marttiin 2009](#ref-Linden2009)), even in ecosystems dominated by proprietary software ([Alami 2020](#ref-S058); [Yin et al. 2022](#ref-S073)). OSS has become a sort of "ethereal" resource: ever-present, deeply involved with everything it touches, and unnoticed by untrained eyes ([Eghbal 2016](#ref-Eghbal2016); [Greenstein and Nagle 2014](#ref-Greenstein2014)).

Software Engineering (SE) researchers and practitioners foresee an ever-present risk with OSS long-term sustainability, as more than 80% of OSS projects are eventually abandoned ([Schweik and English 2012](#ref-Schweik2012)). It is a challenge to assure the continued existence and quality of a resource that is, by its nature, ever flowing, changing, and almost always distributed without warranties, making OSS adoption a risky decision often made in a non systematic manner. With most programming languages, frameworks, and deployment/orchestration tools being OSS, adopting OSS is frequently an architectural decision, thus hard to make and costly to change. As with all such decisions, the cheapest moment to make them is during the initial phases of software design, so evaluating the sustainability of OSS components becomes a critical design activity for practitioners.

Software sustainability is a relatively recent concept that encompasses multiple aspects in software development/maintenance ([Penzenstadler et al. 2012](#ref-Pezenstadler2012)). Sustainable software aims to not only meet present needs but enable future generations to continue creating and maintaining this software ([Becker et al. 2015](#ref-Becker2015)). Sustainability is described in literature as a systemic concept that cannot be comprehended without systemic thinking ([Voulvoulis et al. 2022](#ref-Voulvoulis2022)). To help researchers and software engineers understand, software sustainability dimensions are often used. The Karlskrona Manifesto defines five main dimensions for sustainability: economic, social, technical, individual, and environmental ([Becker et al. 2015](#ref-Becker2015)).

From a social perspective, sustainable software aims to ensure equitable access to resources and opportunities for all individuals and communities ([Lago et al. 2015](#ref-Lago2015)). Economically, it involves preserving long-term value and capital for stakeholders while minimizing risks and maximizing returns ([Lago et al. 2015](#ref-Lago2015); [Razavian, Procaccianti, and Tamburri 2014](#ref-Razavian2014)). Environmentally, it focuses on minimizing the consumption of natural resources and mitigating environmental impacts associated with software activities ([Lago et al. 2015](#ref-Lago2015)). Individually, it prioritizes the well-being and development of human beings, encompassing aspects such as mental and physical health, education, and mobility ([Becker et al. 2015](#ref-Becker2015); [Nazir et al. 2020](#ref-Nazir2020)). Finally, from a technical standpoint, sustainable software systems are designed for longevity, adaptability, and evolution in changing environments ([Lago et al. 2015](#ref-Lago2015)).

Achieving sustainability in software development involves addressing various challenges through the same five dimensions, including energy efficiency, social equity, economic viability, and environmental impact ([Hilty, Lohmann, and Huang 2011](#ref-Hilty2011Sustainability)). It requires integrating sustainability considerations into all phases of the software life-cycle, from requirements gathering and design to deployment and maintenance ([Venters et al. 2014](#ref-Venters2014)). Overall, being sustainable in the software development context means creating products that not only fulfill their intended purpose but also minimize negative impacts on society, economy, and the environment, thus continuing their existence for a longer period.

Open Source Software (OSS) aligns closely with the social dimension of sustainability, as it helps create a more equitable software development landscape. Social dimension emphasizes the preservation of communities that maintain and improve OSS, ensuring users have access to high-quality, efficient, and freely available software ([Becker et al. 2015](#ref-Becker2015)). OSS is typically sustained by self-organized communities ([Liu, Hansen, and Tu 2020](#ref-S014)) whose goal is to safeguard the ability of future developers to contribute and evolve the software. However, sustainability is a multifaceted concept that is not well-defined in the context of OSS, making it harder for adopters to evaluate the sustainability of their OSS dependencies while designing software systems. The existing body of knowledge on sustainability in OSS remains fragmented across many studies.

The research question (RQ) that has motivated this work is: “*How is sustainability understood in the OSS context?*”. Several other secondary studies were published about software sustainability ([Penzenstadler et al. 2012](#ref-Pezenstadler2012); [Mourão, Karita, and Carmo Machado 2018](#ref-Mourao2018); [Berntsen et al. 2016](#ref-Berntsen2016)). Linåker et al. ([Linåker, Papatheocharous, and Olsson 2022](#ref-Linaker2022)) published a secondary study on OSS health, which is related to sustainability, but not quite the same. Other authors (e.g., ([Chengalur-Smith, Sidorova, and Daniel 2010](#ref-S076); [Liao et al. 2018](#ref-S078))) conduct a longitudinal study on OSS project sustainability that examines the factors influencing the long-term sustainability of OSS, but do not map the literature insights about sustainability in this domain. Therefore, developing a clearer understanding of what software sustainability means in the OSS context is essential to tighten the relations between the OSS community, sustainability researchers, and practitioners trying to better understand their potential OSS dependencies.

This paper aims to map the understandings and aspects that define an OSS project as more sustainable. To do this, we performed a Systematic Mapping Study (SMS) that puts together 111 studies to extract (i) the current understanding of sustainability in OSS projects; (ii) Aspects that comprise or contribute to OSS sustainability; and (iii) future directions and insights from literature. The main contribution of this paper is to present a broader view of which aspects make up OSS sustainability. We propose 19 sustainability aspects of OSS projects that were classified into the five sustainability dimensions. In addition, those aspects revealed attention spots, such as the environmental concerns that are underexplored in the literature. We note that OSS culture influences the investigation, and it becomes a great opportunity to raise awareness on the overall sustainability problem in OSS, given how widely adopted OSS projects are.

The paper is structured as follows: Section [2](#research-method) presents the research method. Section [3](#results) describes the results of the SMS. Section [4](#discussion) discusses the SMS results, the threats to validity of our work, and actions performed to mitigate them. Section [5](#final-remarks) provides the final considerations and future research perspectives.

## Research Method

This study is a SMS that follows the guidelines of Petersen et al. ([Petersen, Vakkalanka, and Kuzniarz 2015](#ref-Petersen2015)). We follow the three-step process that encompasses planning, conduct, and results reporting, as shown in Figure [1](#fig:researchMethod). This section presents the first two steps (planning and conduct), outlining the most important elements of the SMS protocol. Section [3](#results) presents data synthesis results.

![SMS research method workflow](/assets/papers/design/method.drawio.svg)
{: #fig:researchMethod}

### Planning

This section reports important elements of our SMS protocol that enable further auditions and reproduction/updates. First, we defined our goal using the GQM (Goal Question Metric) ([Koziolek 2008](#ref-Koziolek2008)) approach as: analyzing primary studies *for the purpose of* identifying how sustainability has been understood/addressed in Open Source Software (OSS) *from the point of view of* SE researchers *in the context of* scientific literature. Based on this goal, we defined our research questions (RQs):

1.  How is sustainability understood in the OSS domain?

2.  Which aspects make an OSS projects more sustainable?

Our search string defines sustainability and OSS as major domains. As we intended to locate studies that address "sustainability" within "OSS", we joined the two with the ‘AND‘ operator. In addition, as OSS frequently appears as one of its synonyms, we joined those with the ‘OR‘ operator. Our final string was: `("sustainability") AND ("open source" OR "free software" OR "FLOSS" OR "OSS")`. This string was developed iteratively and pilot-tested to ensure sensitivity (capturing relevant studies) and precision (excluding irrelevant studies).

We adopted three databases (Scopus[^1], ACM Digital Library[^2], and IEEE Digital Library[^3]), considering they are the well-known and widely used publication databases in the computing area. For the selection, one inclusion criterion (IC) and five exclusion criteria (EC) were defined to ensure a transparent and replicable process: **IC1**: The study addresses sustainability and OSS. **EC1**: Full text of the study is not available. **EC2**: Study is a shorter version of another. **EC3**: Study is a summary of a conference/workshop. **EC4**: Study is not peer-reviewed. **EC5**: Study is written in a language other than English.

### Conducting

Studies collection in electronic databases started by adapting the generic search string to each database. Scopus permits searching three metadata fields (title, abstract, and keywords) simultaneously. ACM Digital Library and IEEE require executing the search separately for each metadata field and combining them into a single studies dataset. We did not limit our search to publication period or field (like Computer Science), aiming to reach as many studies as possible.

Figure [1](#fig:researchMethod) illustrates the search process and scrutiny. Our systematic search initially retrieved a total of 2,428 studies (1,560 from Scopus, 172 from ACM Digital Library, and 696 from IEEE Digital Library). Following deduplication based on DOI, and when necessary, title and year, 1,946 unique studies remained. A first selection was conducted by screening titles, abstracts, and keywords against the inclusion and exclusion criteria, resulting in 333 studies for full-text assessment. During the second selection, all 333 studies were fully read and re-evaluated according to the same criteria, yielding 111 unique studies that are presented in Table [1](#selected-studies). The selection process counts on a main researcher who was responsible for performing the first selection. In addition, an experienced researcher in sustainability and the SMS process double-checked the selections; finally, conflicts were resolved in consensus meetings.

#### Set of studies selected {#selected-studies}

| ID | Authors | Year | ID | Authors | Year |
|:---|:---|:---|:---|:---|:---|
| [S001](https://doi.org/10.1002/smr.2270) | Mora‐Cantallops et al. | 2020 | [S044](https://doi.org/10.1109/tr.2022.3176733) | Zhang et al. | 2023 |
| [S002](https://doi.org/10.1007/978-3-030-54997-8_10) | Suleimenov et al. | 2020 | [S045](https://doi.org/10.1109/tse.2018.2872713) | Barcomb et al. | 2020 |
| [S003](https://doi.org/10.1007/978-3-319-08581-4_13) | Mahaux et al. | 2015 | [S046](https://doi.org/10.1109/tse.2020.2985093) | Barcomb et al. | 2022 |
| [S004](https://doi.org/10.1007/978-3-642-13244-5_23) | Wiggins et al. | 2010 | [S047](https://doi.org/10.1109/tse.2021.3053403) | Li et al. | 2022 |
| [S005](https://doi.org/10.1007/978-3-642-24418-6_26) | Arantes et al. | 2011 | [S048](https://doi.org/10.1109/tse.2022.3156071) | Yue et al. | 2023 |
| [S006](https://doi.org/10.1007/978-3-642-33442-9_1) | Robles et al. | 2012 | [S049](https://doi.org/10.1109/tse.2023.3242415) | Tan et al. | 2023 |
| [S007](https://doi.org/10.1007/978-3-642-33442-9_14) | Petrinja et al. | 2012 | [S050](https://doi.org/10.1145/2536536.2536560) | Macho et al. | 2013 |
| [S008](https://doi.org/10.1007/978-3-642-33442-9_19) | Barham et al. | 2012 | [S051](https://doi.org/10.1145/2593702.2593704) | Steinmacher et al. | 2014 |
| [S009](https://doi.org/10.1007/978-3-642-33442-9_2) | Riehle et al. | 2012 | [S052](https://doi.org/10.1145/3106237.3106287) | Zhou et al. | 2017 |
| [S010](https://doi.org/10.1007/978-3-642-33442-9_21) | Nyman et al. | 2012 | [S053](https://doi.org/10.1145/3236024.3236062) | Valiev et al. | 2018 |
| [S011](https://doi.org/10.1007/s10664-021-10012-6) | Calefato et al. | 2022 | [S054](https://doi.org/10.1145/3239235.3240501) | Coelho et al. | 2018 |
| [S012](https://doi.org/10.1016/j.chb.2008.04.009) | Nov et al. | 2008 | [S055](https://doi.org/10.1145/3306446.3340825) | Gasparini et al. | 2019 |
| [S013](https://doi.org/10.1016/j.chb.2019.02.005) | Poba-Nzaou et al. | 2019 | [S056](https://doi.org/10.1145/3359224) | Qiu et al. | 2019 |
| [S014](https://doi.org/10.1016/j.infoandorg.2019.100274) | Liu et al. | 2020 | [S057](https://doi.org/10.1145/3377811.3380920) | Tan et al. | 2020 |
| [S015](https://doi.org/10.1016/j.is.2014.10.005) | Ghapanchi et al. | 2015 | [S058](https://doi.org/10.1145/3377812.3381402) | Alami et al. | 2020 |
| [S016](https://doi.org/10.1016/j.jsis.2012.07.004) | Santos et al. | 2013 | [S059](https://doi.org/10.1145/3383219.3383242) | Alami et al. | 2020 |
| [S017](https://doi.org/10.1016/j.jss.2013.11.1077) | Gamalielsson et al. | 2014 | [S060](https://doi.org/10.1145/3415251) | Trinkenreich et al. | 2020 |
| [S018](https://doi.org/10.1016/j.jss.2019.110452) | Butler et al. | 2020 | [S061](https://doi.org/10.1145/3468264.3468563) | Yin et al. | 2021 |
| [S019](https://doi.org/10.1109/chase.2015.9) | Hata et al. | 2015 | [S062](https://doi.org/10.1145/3491102.3501822) | Zhang et al. | 2022 |
| [S020](https://doi.org/10.1109/compsac54236.2022.00144) | Wang et al. | 2022 | [S063](https://doi.org/10.1145/3510003.3510116) | Shimada et al. | 2022 |
| [S021](https://doi.org/10.1109/hicss.2011.264) | Jensen et al. | 2011 | [S064](https://doi.org/10.1145/3510003.3510121) | Fang et al. | 2022 |
| [S022](https://doi.org/10.1109/hicss.2014.406) | Carillo et al. | 2014 | [S065](https://doi.org/10.1145/3510003.3510196) | Xiao et al. | 2022 |
| [S023](https://doi.org/10.1109/icse-nier58687.2023.00010) | Sajadi et al. | 2023 | [S066](https://doi.org/10.1145/3510454.3522685) | Gray et al. | 2022 |
| [S024](https://doi.org/10.1109/icse-seet58685.2023.00037) | He et al. | 2023 | [S067](https://doi.org/10.1145/3510849) | Zhang et al. | 2022 |
| [S025](https://doi.org/10.1109/icse.2003.1201220) | Ye et al. | 2003 | [S068](https://doi.org/10.1145/3524842.3528506) | Ramchandran et al. | 2022 |
| [S026](https://doi.org/10.1109/icse.2012.6227030) | Zanetti et al. | 2012 | [S069](https://doi.org/10.1145/3531056.3542767) | Zhou et al. | 2022 |
| [S027](https://doi.org/10.1109/icse.2015.184) | Izquierdo et al. | 2015 | [S070](https://doi.org/10.1145/3540250.3549117) | Zhang et al. | 2022 |
| [S028](https://doi.org/10.1109/icse.2019.00100) | Barcomb et al. | 2019 | [S071](https://doi.org/10.1145/3540250.3549132) | Stanciulescu et al. | 2022 |
| [S029](https://doi.org/10.1109/icse43902.2021.00093) | Dias et al. | 2021 | [S072](https://doi.org/10.1145/3543873.3587336) | Dam et al. | 2023 |
| [S030](https://doi.org/10.1109/icse48619.2023.00038) | Trinkenreich et al. | 2023 | [S073](https://doi.org/10.1145/3555129) | Yin et al. | 2022 |
| [S031](https://doi.org/10.1109/icse48619.2023.00066) | Yin et al. | 2023 | [S074](https://doi.org/10.1145/512035.512055) | Nakakoji et al. | 2002 |
| [S032](https://doi.org/10.1109/icse48619.2023.00218) | Guizani et al. | 2023 | [S075](https://doi.org/10.1587/transinf.2015edp7363) | Onoue et al. | 2016 |
| [S033](https://doi.org/10.1109/mc.2020.2998235) | Hasselbring et al. | 2020 | [S076](https://doi.org/10.17705/1jais.00244) | Chengalur-Smith et al. | 2010 |
| [S034](https://doi.org/10.1109/mc.2021.3133052) | Zhang et al. | 2022 | [S077](https://doi.org/10.3390/su13031079) | Papamichail et al. | 2021 |
| [S035](https://doi.org/10.1109/msr.2007.23) | Bird et al. | 2007 | [S078](https://doi.org/10.3390/sym10120747) | Liao et al. | 2018 |
| [S036](https://doi.org/10.1109/msr.2009.5069497) | Robles et al. | 2009 | [S079](https://doi.org/10.5210/fm.v0i0.1470) | Perens et al. | 2005 |
| [S037](https://doi.org/10.1109/msr.2017.37) | Gupta et al. | 2017 | [S080](http://aisel.aisnet.org/amcis2005/435) | Ju Long et al. | 2005 |
| [S038](https://doi.org/10.1109/saner.2016.27) | Rastogi et al. | 2016 | [S081](https://aisel.aisnet.org/ecis2013_rip/2) | Carillo et al. | 2013 |
| [S039](https://doi.org/10.1109/saner50967.2021.00054) | Horiguchi et al. | 2021 | [S082](https://aisel.aisnet.org/icis2013/proceedings/ResearchInProgress/31) | Carillo et al. | 2013 |
| [S040](https://doi.org/10.1109/saner50967.2021.00060) | Chouchen et al. | 2021 | [S083](https://aisel.aisnet.org/icis2016/ManagingIS/Presentations/10/) | Atiq et al. | 2016 |
| [S041](https://doi.org/10.1109/saner56733.2023.00012) | Xia et al. | 2023 | [S084](https://aisel.aisnet.org/pacis2017/75) | Chua et al. | 2017 |
| [S042](https://doi.org/10.1109/sbes.2010.26) | Terceiro et al. | 2010 | [S085](https://aisel.aisnet.org/iceb2006/41) | Vainio et al. | 2006 |
| [S043](https://doi.org/10.1109/SoHeal52568.2021.00010) | Goggins et al. | 2021 | [S086](https://ieeexplore.ieee.org/document/5602062) | Sethanandha et al. | 2010 |
| [S087](https://doi.org/10.1002/smr.2597) | Kritikos et al. | 2024 | [S088](https://doi.org/10.1109/MCSE.2024.3414951) | Schwarts et al. | 2024 |
| [S089](https://doi.org/10.1177/14614448221090474) | O’Neil et al. | 2024 | [S090](https://doi.org/10.1109/TCSS.2024.3476198) | Chang et al. | 2024 |
| [S091](https://doi.org/10.1145/3611643.3616349) | Xiao et al. | 2023 | [S092](https://doi.org/10.1371/journal.pcbi.1012045) | Sonabend et al. | 2024 |
| [S093](https://doi.org/10.1002/smr.2645) | Han et al. | 2024 | [S094](https://doi.org/10.1109/TSE.2022.3225197) | Wattanakriengkrai et al. | 2023 |
| [S095](https://doi.org/10.1145/3611643.3617849) | Nguyen et al. | 2023 | [S096](https://aisel.aisnet.org/amcis2024/vcc/vcc/9/) | Sokyina et al. | 2024 |
| [S097](https://doi.org/10.1109/VL/HCC60511.2024.00056) | Santos, Italo | 2024 | [S098](https://doi.org/10.1145/3663529.3663777) | Khan et al. | 2024 |
| [S099](https://doi.org/10.1145/3597503.3639197) | Zhang et al. | 2024 | [S100](https://doi.org/10.1145/3613904.3642541) | Jahn et al. | 2024 |
| [S101](https://doi.org/10.1145/3597503.3608142) | Fang et al. | 2024 | [S102](https://doi.org/10.1016/j.infsof.2024.107470) | Feng et al. | 2024 |
| [S103](https://doi.org/10.1109/SANER60148.2024.00106) | Han et al. | 2024 | [S104](https://doi.org/10.1145/3674805.3686667) | Linåker et al. | 2024 |
| [S105](https://doi.org/10.1145/3609437.3609454) | Wang et al. | 2023 | [S106](https://doi.org/10.1145/3618305.3623598) | Wilson, Katrina | 2023 |
| [S107](https://doi.org/10.1145/3611643.3616282) | Fang et al. | 2023 | [S108](https://doi.org/10.1109/ISSREW63542.2024.00058) | Hovhannisyan et al. | 2024 |
| [S109](https://doi.org/10.1145/3691620.3695286) | Adejumo et al. | 2024 | [S110](https://doi.org/10.1109/SERA61261.2024.10685609) | Wattanakriengkrai et al. | 2024 |
| [S111](https://doi.org/10.1007/978-3-642-55128-4_21) | Steinmacher et al. | 2014 |  |  |  |

Set of studies selected

![Overall view of studies (distribution by publication year, venue type, and study type)](/assets/papers/design/Figure_1.png)
{: #fig:per-year}

The synthesis process for identifying OSS sustainability aspects involved a systematic three-step approach. First, fragment extraction was performed, where relevant portions of each study that discussed sustainability were carefully located. To support this process, we used an extraction form that recorded paper metadata (DOI, title, authors, publication year, venue, and venue type), along with the sustainability-related fragments. The extracted data was synthesized using thematic analysis ([Cruzes and Dyba 2011](#ref-Cruzes2011)), applying both open and axial coding. Based on this, we developed a coding scheme for qualitative synthesis, classifying sustainability-related concepts in OSS.

Our first step in the analysis was to select fragments and extract terms from all the studies obtained through the SMS. The terms were deduplicated and factored into a set of what we called sustainability aspects. These aspects were further grouped according to their sustainability dimension (social, technical, individual, economic, environmental). We then show how the studies our SMS selected were classified according to these aspects in Section [3.2](#sustainability-aspects).

The full replication kit, containing a complete list of studies, selection decisions, raw data extracted, and synthesized data is available in the external material.

## Results

This section presents the data synthesis from the selected studies, followed by the answers to RQs.

### Overview of Studies

Figure [2](#fig:per-year) shows the distribution of studies according to their publication year, venue, and type. The studies span 21 years, starting in 2002, with the majority of publications concentrated in the last few years.

The growing understanding of Software Sustainability as a multidisciplinary and systemic concept could explain the increasing number of publications. Many of the individual concerns have been previously researched without an explicit mention of sustainability itself. Concerning publication venues, around two-thirds of studies were published in event proceedings (i.e., 77), while one-third (i.e., 33) were published in journals, and a single book chapter. The increasing number of journal papers may indicate that the topic is becoming more mature over time.

### Sustainability Aspects

Our sustainability aspects were derived from the set of OSS sustainability terms that our SMS extracted. Their intent is to be able to fully express every sustainability concern our selected studies address, while minimizing overlap. The aspects are grouped within established software sustainability dimensions (social, technical, individual, economic, and environmental). These are defined as follows:

#### Social Dimension

This dimension covers the human and community aspects of open-source software (OSS) projects. It emphasizes the interactions, governance, and social structures that sustain participation and collaboration.

1.  **Contributor Retention**: Also called "stickiness"([Hata et al. 2015](#ref-S019)). The probability of continued contributions over time. It reflects the project’s ability to keep its contributors engaged and motivated.

2.  **Contributor Attraction**: Also called "magnetism"([Hata et al. 2015](#ref-S019)). The ability to attract new contributors is often linked to the project’s popularity, niche, and functionality, as most contributors are also users/stakeholders.

3.  **Internal Communication**: The effectiveness of communication among peers fosters a sense of community and belonging. It is related to governance transparency.

4.  **Governance Structure**: The structure, transparency, legitimacy, and consistency of leadership, regarding decision-making and project management.

5.  **Openness/Onboarding**: The onboarding process and the project’s attitude toward new contributors. This is highly related to governance and heavily affects contributor retention.

6.  **Project Legitimacy**: The perception of the project, which can sometimes be enhanced through marketing. It is composed of smaller characteristics, such as popularity, niche, and age. Niche size interacts with other aspects (such as quality and feature set), increasing popularity. A popular project attracts users who may become contributors, forming a virtuous cycle ([Santos et al. 2013](#ref-S016)). Age, when combined with other aspects (e.g. sustained activity and maintainability) is a frequently used and accurate measure for sustainability.

7.  **External Communication/Ecosystem**: The project’s relationship with outside projects and its cooperation with external entities, which can enhance features and quality (e.g. through interoperability).

#### Technical Dimension

This dimension highlights the software engineering aspects of OSS projects. It focuses on the practices, architecture, and development processes that determine the project’s long-term sustainability and adaptability.

1.  **Sustained Activity**: One of the most frequently used measures. The ongoing software development activity, including the production of artifacts (release rate, issues, patches) and response times. Heavily influenced by contributor retention and governance; contributes to retention and attraction.

2.  **Functionality, Scope**: The relevance of functional requirements to stakeholders and the project’s ability to evolve and incorporate new features over time. Having exclusive functionality on a niche that usually lacks frequently leads to increased project popularity and legitimacy.

3.  **Quality Assurance**: The processes for bug resolution, adherence to quality standards, and testing, which contribute to the software’s maintainability and increases its capability of incorporating new features without regressions, which otherwise often cost legitimacy.

4.  **Methodologies, Practices**: The development methodologies and practices adopted by the project, which influence its maintainability, contributor retention, and quality.

5.  **Architecture, Maintainability**: The design of the software architecture, including modularity and code complexity, it affects contributor retention, leads to increased quality and is the limiting factor for development scalability (thus impacting feature set).

6.  **Licensing**: Licensing policies, usually static over the project lifetime, impacting how the software can be used and contributed to. Similarly to governance, it interacts in a very complex way with other aspects. However, there is no conclusive research linking specific license types (e.g. permissive VS copyleft) to higher sustainability.

#### Individual Dimension

This dimension captures the characteristics of individual contributors. It considers their motivations, knowledge, and skills, which directly affect the quality and direction of the project.

1.  **Personal Motivations**: The individual motivations of contributors, which are often influenced by the sense of community, project niche, and feature set. Influences attraction and retention.

2.  **Personal Knowledge**: The technical expertise and skills of individual contributors. It is affected by project niche/size and affects the quality and feature set of the project.

#### Economic Dimension

This dimension deals with the financial aspects of sustainability in OSS projects. It highlights the availability, management, and monetization of resources that enable long-term development.

1.  **Financial Resources**: The attraction and management of financial resources, including foundations, crowdfunding, and sponsorships. This influences and is influenced by internal monetization and governance.

2.  **External Monetization**: The ways external actors monetize their involvement with the project and their actions towards it. Includes paid contributors. Highly related to external communication and openness.

3.  **Internal Monetization**: The use of project funds to pay contributors, often seen in projects with corporate governance. The backing organization is, therefore, a heavy factor in the project’s continued development.

#### Environmental Dimension

This dimension focuses on the environmental implications of OSS projects.

1.  **Environmental Requirements**: The concerns related to the project’s environmental impact. It is sometimes seen in the form of regulatory compliance (thus relates to governance).

#### OSS sustainability aspects {#oss-sustainability-aspects-table}

| **Dimension** | **ID** | **Aspect** | **Studies** |
|:--:|:--:|:--:|:---|
| Social | A1 | **Contributor Retention** | S012, S013, S016, S017, S019, S025, S028, S030, S036, S037, S040, S045, S046, S047, S048, S049, S050, S051, S053, S056, S058, S059, S065, S066, S072, S074, S075, S076, S081, S082, S086, S087, S090, S092, S097, S098, S099, S102, S107, S111 |
| 2-4 | A2 | **Contributor Attraction** | S005, S013, S015, S016, S019, S021, S024, S030, S031, S037, S039, S043, S047, S051, S053, S056, S059, S064, S065, S071, S073, S076, S099, S102, S104, S107 |
| 2-4 | A3 | **Internal Communication** | S002, S003, S012, S013, S014, S017, S022, S023, S027, S029, S003, S030, S031, S043, S061, S068, S069, S071, S073, S076, S081, S083, S084, S085, S087, S092, S096, S097, S100, S102, S104, S106, S111 |
| 2-4 | A4 | **Governance Structure** | S012, S013, S014, S017, S027, S029, S031, S043, S057, S058, S060, S061, S065, S071, S072, S073, S080, S084, S085, S009, S087, S089, S097, S102, S104, S105 |
| 2-4 | A5 | **Openness/Onboarding** | S003, S035, S041, S043, S055, S056, S057, S058, S059, S060, S067, S070, S078, S081, S082, S087, S097, S099, S102, S104, S109, S110, S111 |
| 2-4 | A6 | **Legitimacy** | S006, S007, S015, S043, S053, S064, S071, S076, S078, S080, S088, S095, S098, S101, S107 |
| 2-4 | A7 | **External Communication/Ecosystem** | S012, S013, S014, S043, S045, S006, S069, S071, S087, S104, S107, S110 |
| 2-4 Technical | A8 | **Sustained Activity** | S004, S007, S010, S011, S013, S015, S016, S018, S033, S034, S038, S041, S043, S054, S068, S071, S072, S073, S076, S078, S088, S091, S092, S093, S095, S098, S103 |
| 2-4 | A9 | **Functionality/Scope** | S003, S010, S013, S015, S017, S018, S029, S032, S044, S053, S071, S077, S078, S079, S087, S088, S092, S095 |
| 2-4 | A10 | **Quality Assurance** | S008, S010, S013, S015, S018, S029, S040, S041, S043, S058, S059, S064, S071, S087, S092 |
| 2-4 | A11 | **Methodologies/Practices** | S001, S004, S005, S008, S019, S040, S043, S052, S058, S065, S071, S086, S087, S090, S092, S094, S108, S111 |
| 2-4 | A12 | **Architecture/Maintainability** | S001, S005, S015, S026, S042, S052, S053, S077, S087, S094, S111 |
| 2-4 | A13 | **Licensing** | S017, S013, S015, S087, S092 |
| 2-4 Individual | A14 | **Personal Motivations** | S012, S018, S056, S058, S069, S083, S110 |
| 2-4 | A15 | **Personal Knowledge** | S015, S018, S002, S085, S100, S102, S106, S111 |
| 2-4 Economic | A16 | **Financial Resources** | S013, S015, S016, S020, S032, S043, S005, S062, S063, S064, S076, S085, S087, S089, S092, S104, S110 |
| 2-4 | A17 | **External Monetization** | S012, S014, S015, S034, S052, S067, S070, S079, S087, S092, S099, S104, S106 |
| 2-4 | A18 | **Internal Monetization** | S019, S020, S079, S083, S087, S092 |
| 2-4 Environmental | A19 | **Environmental Requirements** | S003 |
| 2-4 |  |  |  |

Table [[table:aspects]](#oss-sustainability-aspects-table) shows an overview of our aspects, and which studies address each of them. We can see that concerns overwhelmingly fit the technical and/or social sustainability dimensions, especially concerns that are frequently used as a measure of sustainability (e.g. sustained activity and contributor retention([Chengalur-Smith, Sidorova, and Daniel 2010](#ref-S076))). The technical and social concerns are also closely related, as they form a virtuous cycle([Santos et al. 2013](#ref-S016)) of project legitimacy, attraction, and activity([Chengalur-Smith, Sidorova, and Daniel 2010](#ref-S076)). Corporate involvement is also a relevant concern, as it bridges the economic (internal/external monetization) and social (governance([Nakakoji et al. 2002](#ref-S074))) dimensions.

### OSS sustainability understandings

Sustainability in the OSS domain encompasses a project’s long-term viability and ability to continue delivering value (S010, S033, S098). It refers to the software potential to maintain the functionality and evolution of the software system in the future (S044). A core characteristic of sustainable software is its ability to exhibit software development and maintenance activity over the long term (S013, S076), ensuring it remains active for a longer period of time (S076) and can evolve to incorporate new demands over time (S029). Sustainability also means creating the necessary conditions for future generations to use and evolve present artifacts (S077).

From a technical perspective, sustainability is closely tied to the software’s inherent qualities and structure. Projects need to maintain high-quality standards and implement rigorous methodologies (S008). Being technically sustainable means overcoming inherent challenges of OSS like software complexity and its non-uniform evolution, which can pose threats (S001, S013). Long-living projects usually adopt modular structures and less complex code are incentives for developers and contribute significantly to maintainability (S005, S026, S042, S053). Also, other factors can contribute to sustaining OSS, for instance, the project’s ability to reduce bugs and ensure stability (S013), along with a high probability of new revisions being published and consistent maintenance (S007, S071, S095), are also important for tecnical sustainability.

A cornerstone of OSS sustainability is the underlying community of contributors (S002, S017, S025, S074). This involves the continuous attraction of new and retention of existing contributors (S013, S021, S024, S030, S037, S039, S099, S102, S107), recognizing that contributor disengagement threatens sustainability (S066, S090). Essential social aspects include the knowledge and skills contributors bring (S002, S012), fostering community growth (S005, S043, S102), building interpersonal trust (S023), ensuring fairness and acknowledging contributors’ motivations (S012, S083, S096, S106). Effective governance rules (S027, S031, S055, S058, S070, S072, S089) with clear leadership (S017), a participative development process (S003), and transparent communication (S013, S029, S074, S100, S104) are vital. Mentoring and support to newcomers (S048, S049, S058, S060, S071, S102) along with promoting an open and inclusive atmosphere and diversity (S061, S092, S097, S099, S102, S104) are also critical for retaining members and promoting long-term success.

Despite OSS having a facilitated distribution due to its free licenses, financial resources (S005, S043, S062, S063, S084, S092), sponsorships, and fundraising (S013, S019, S020, S064, S095, S104) are important for project progress and sustainability. The increasing commercial participation and firm involvement in OSS projects have significant consequences for sustainability (S014, S034, S052, S053, S067, S070, S078, S082, S089, S099), bringing benefits, as well as new challenges, to OSS communities. Sustainability plays an important role in the overall open-source ecosystem (S069, S094, S107), which means that OSS is part of long and complex chain of software dependencies that depends on financial support directly or indirectly.

On an individual level, it is heavily influenced by the contributors themselves, particularly their knowledge and skills (S002) and their intrinsic motivations to participate (S012, S083, S096, S106). Factors such as fairness and perceptions of justice within the project community significantly affect contributors’ willingness to engage (S012, S083). A developer’s feelings of identity and belonging are also crucial for their retention and the project’s long-term survival (S030), while the presence of toxic behaviors among developers can critically jeopardize community sustainability (S096, S104). From an environmental perspective, sustainability is understood to include broader ecological and social requirements (S003), which is not incorrect, but represents a disconnection between OSS development and other environmental aspects.

## Discussion

This section presents our main findings, outlines some future work, and discusses the threats to the validity of this work, along with the countermeasures we have applied to address them.

### Main Findings

The main findings resulting from our investigation are:

- **A way to evaluate OSS sustainability while designing software**: Our proposed aspects’ main intended usage is as a starting point for more specific evaluation frameworks (e.g. with actual metrics). With that said, we believe that these are already useful to practitioners as high-level guidance on key concerns they should be on the look out for while adopting OSS dependencies. We propose that further discussion and research about how OSS sustainability could be evaluated in a more systematic way during software design phases should follow.

- **Sustainability of OSS is uncontrollable, but can be understood**: The first step for organizations when designing their applications is to recognize that they have no significant control (in most cases) over OSS projects. Considering the wide range of factors affecting sustainability across various dimensions, only systemic and high-level actions have a direct impact on the sustainability of OSS. However, designers can and should understand all aspects that affect the sustainability of projects used as dependencies.

- **Sustainability aligns with OSS culture and values:** OSS is deeply rooted in a culture of collaboration and knowledge sharing, rather than profit-seeking. This culture seems to directly shape the factors that contribute to project sustainability. Introducing sustainability concerns to OSS development community could strengthen OSS, as economic and environmental dimensions, which often conflict in proprietary software development, tend to be more aligned within OSS.

- **Privileged and underexplored dimensions:** Current research tends to prioritize technical and social aspects, with limited attention to individual, economic, and particularly environmental dimensions. The scarcity of studies addressing environmental issues within OSS hints that the relation between the OSS communities and the environmental impacts of their software has not yet been well explored.

- **Sustainability systemic effects awareness:** Adopting a sustainability/aware vision aligns OSS projects with long-term goals. While most research emphasizes sustainability in software i.e., enhancing maintainability and system endurance, domain-specific studies highlight sustainability by software, showing how software can support social, environmental, and organizational goals. This approach encourages system designers and architects to consider the broader systemic effects of their decisions, integrating sustainability into every stage of software engineering.

### Future Work

The future is bright for further research within OSS sustainability. OSS sustainability is different enough from general software sustainability to warrant its own specificities, currently being matured by the research community to move towards widely accepted understandings. Thus research into any of the aspects will be helpful to further their current understanding.

The diversity of sustainability understandings might warrant surveys to gauge how researchers and practitioners from different segments understand the concept, helping understand whether a wide consensus is possible and, if so, what it would look like depending on the demographic.

Our proposed aspects are theoretical, thus they provide mostly a conceptual framework for practitioners to think about OSS sustainability, whether they are adopters or contributors. Researchers can build upon these aspects to create more specific guidance and/or metrics to complement them, working as tools that can be directly used by practitioners to evaluate OSS sustainability.

This study’s results can also be useful for future mappings and/or reviews in the OSS sustainability area. By including all of the aspects as synonyms of sustainability, it is possible to locate studies that are sustainability adjacent but don’t address it by name directly. This includes important, older, sustainability-related studies from periods where the sustainability terminology was very rarely used.

### Threats to Validity

Errors could occur during SMS execution, especially during study selection. This could compromise the SMS coverage. To address this possible bias, we developed a detailed protocol based on ([Petersen, Vakkalanka, and Kuzniarz 2015](#ref-Petersen2015)), validated by a senior SMS expert, and resolved disagreements through consensus meetings. Similarly, the construction of categories, which requires the interpretation of fragments, may introduce mistakes. This was mitigated by multiple iterations and additional consensus meetings.

Another threat concerns the generalizability of our results, as most analyzed studies stem from academic initiatives, with limited representation from industry or OSS communities. This restricts the scope of our conclusions, which we deliberately confine to the academic context, while validation in industrial or community settings is left for future work. Additionally, our search strategy might not have retrieved all relevant studies. To mitigate this, we refined the search string through pilot studies and targeted well-known SE databases (Scopus, IEEE Xplore, ACM Digital Library). Although synonyms for “sustainability” could not be exhaustively captured, this limitation aligns with the study’s objective of clarifying the term’s meaning.

Finally, data interpretation poses a potential threat, as many findings rely on the classification of text passages. To reduce subjectivity, we held brainstorming sessions to ensure consistent interpretations of sustainability in OSS, and all extracted data was reviewed by all authors to avoid hasty or biased conclusions.

## Final Remarks

OSS has become a critical foundation of today’s digital infrastructure, yet its sustainability remains an open and multifaceted challenge. In this work, our objective was to clarify how sustainability is understood in the OSS domain, what dimensions and aspects influence it, how these aspects are addressed in research, and the impacts on the design of software systems. Our SMS put together studies from two decades of OSS and sustainability literature, revealing that while social and technical are well-explored, economic and especially environmental dimensions remain significantly underrepresented. The main contribution of this mapping is to provide an overview of sustainability aspects and their interrelations, helping with decisions regarding project direction as well as adoption concerns. By identifying 19 sustainability aspects across five dimensions, our results offer both a conceptual foundation and a practical reference for researchers, maintainers, and adopters who are interested in OSS projects being more resilient in the long term. This mapping raises awareness about the importance of introducing systemic vision to sustain the software ecosystem upon which much of society now depends.

## Acknowledgments

This study was supported by CNPq (313245/2021-5), FAPESP (2023/00488-5, 2025/06946-0), and CAPES (001).

## Appendix: Sustainability fragments and keywords {#sustainability-fragments}

<details markdown="1">
<summary>Relevant fragments and extracted keywords</summary>

| ID | Relevant fragment(s); extracted keywords in bold |
|:---|:---|
| [S001](https://doi.org/10.1002/smr.2270) | [...]its sustainability could be threatened by that **complexity** or **non-uniform** evolution of some packages. |
| [S002](https://doi.org/10.1007/978-3-030-54997-8_10) | The sustainability of an OSS project is heavily based on the **underlying community** of contributors and on the **knowledge and skills** they bring to the project |
| [S003](https://doi.org/10.1007/978-3-319-08581-4_13) | [...] we may confidently conclude that ‘sustainable systems’ are at least systems that **suit the needs of users** [...]. Beyond that, sustainable systems will have to take **ecological** and **social requirements** into account. it is not only the free and open character of the software but also the **participative development process** that is a factor of sustainability. |
| [S004](https://doi.org/10.1007/978-3-642-13244-5_23) | One of the more complex aspects of the original analysis is the qualification of **release rate** as an indicator of the sustainability of project activity. The assumption here is that projects which make releases too quickly cannot maintain the pace of activity [...]. |
| [S005](https://doi.org/10.1007/978-3-642-24418-6_26) | [...]we can say that the sustainability of OSS is closely related to three factors – **community growth**, **financial resources** and **software management** [...]. [...] **growth and continuity** of the community can result more naturally in **financial resources** that, if well managed, can be reversed in benefits to the community and encourage its growth, feeding the OSS sustainable life cycle. Factors related to **source code structure** can greatly contribute to OSS projects sustainability[...]. The code with a **modular structure** is an incentive for developers to enter and to continue in the project development. |
| [S006](https://doi.org/10.1007/978-3-642-33442-9_1) | [...] it provides information on the **outcome of the forks**, in order to see if forking undermines the sustainability of the projects. |
| [S007](https://doi.org/10.1007/978-3-642-33442-9_14) | An **growing number of users** and a **high probability of new revisions** being published is correlated with the sustainability of the project. |
| [S008](https://doi.org/10.1007/978-3-642-33442-9_19) | In the context of open source software, this includes raising the **quality standards** of products by implementing more complex processes and **rigorous methodologies**. |
| [S009](https://doi.org/10.1007/978-3-642-33442-9_2) | [...] **compatibility of a foundation with the projects' needs** is a crucial factor in ensuring the project's sustainability |
| [S010](https://doi.org/10.1007/978-3-642-33442-9_21) | In this paper we address the role of **code forking** [...] in ensuring the long-term sustainability of a software system. We take the view of the consumer and focus on two central elements: **quality** and **staying power** – how to create a **high-quality product** that is **usable as long as possible**. The **possibility to fork** is one of the key factors that ensure that open source will continue to evolve and thus remain sustainable. |
| [S011](https://doi.org/10.1007/s10664-021-10012-6) | projects depend on the **continuity of their development** communities to remain sustainable |
| [S012](https://doi.org/10.1016/j.chb.2008.04.009) | [...] in order to examine the sustainability potential of the open source model it is important to understand the relationship between **contribution motivations** and the **threat of external appropriation**<br><br>the sustainability of open source projects depends to a large extent on contributors’ willingness to contribute to such projects, which is, in turn, affected by **contributors’ motivations**, **fairness**, and **perceptions of the open source model’s justice**. |
| [S013](https://doi.org/10.1016/j.chb.2019.02.005) | OSS development project sustainability is defined as the ability of the project to exhibit **software development and maintenance activity over the long term**<br><br>**Make our software {stable** (reduce bugs)} **Feature set**<br><br>**Documentation**<br><br>**Reduce time between releases**<br><br>**Attract users/contributors**<br><br>**Keep users/contributors involved**<br><br>**Leverage the power of the leader/main company**<br><br>**Fundraising**<br><br>**Legal issues (license, copyright assignments)**<br><br>**Communication inside the project**<br><br>**Communication upstream/downstream** |
| [S014](https://doi.org/10.1016/j.infoandorg.2019.100274) | **Community governance**<br><br>**The role of commercial affiliates**<br><br>**Maintaining the family atmosphere**<br><br>**Cross-project knowledge sharing**<br><br>**Project coordination** |
| [S015](https://doi.org/10.1016/j.is.2014.10.005) | The results demonstrated a temporal persistence in the relationship between sustainability and the **speed of defect-removal** and **functionality-enhancement,** whereas the effect that the **defect-removal rate** and **functionality-enhancement** rate have on development sustainability was discovered to significantly decrease as the project grows **old**. Several researchers have studied open source software. Many of these have studied the various factors that drive OSS projects' development sustainability, including **developer and user attraction**, **development base** and **project age**, having developers with higher **levels of different skills**, **project status and activity**, having a **nonmarket sponsor**, and **having a copy-left licence**. In the existing OSS literature, there are few longitudinal studies that investigate the relationships between OSS sustainability and its antecedents. As an example, Midha [...] investigated the potential impact of certain factors (e.g. **software complexity** and **modularity**). [...] Subramaniam et al. examined the impact of some time-dependent predictors (e.g. **project status**) and some time-invariant predictors (e.g. **project licence**). |
| [S016](https://doi.org/10.1016/j.jsis.2012.07.004) | [...] examine what **attracts contributors**, creating an environment likely to improve and promote the project sustainably. As commercial organizations increasingly sanction an open source strategy, the **user uptake** will determine the level of **sponsorships**, and the sustainability of FOSP [...] groups of visitors, users and developers provide FOSP with varying and unique sets of development resources that together promote and improve the project towards the sustainability of **recruiting new resources** and generating more **work activities** and other indirect contributions[...]. |
| [S017](https://doi.org/10.1016/j.jss.2013.11.1077) | For this reason, **sustainability of communities** has been identified as essential for long-term sustainability of OSS. Earlier research also suggests that an effective **structure of governance** is a basis for healthy and sustainable OSS communities. [...] aspects such as **clear leadership**, congruence in terms of **project goals**, and good **team spirit** are of fundamental importance. [...]. Further, the **licensing** of OSS may affect the community. |
| [S018](https://doi.org/10.1016/j.jss.2019.110452) | The **long-term viability of a technical solution**. The concern being that if the project contributors **overreach their collective abilities** and their **capacity to develop** and maintain **good quality** software, then there is a risk the project may cease to be viable. |
| [S019](https://doi.org/10.1109/CHASE.2015.9) | **Maintaining and increasing the populations in software development communities** are challenges of OSS projects for sustainability. Yamashita et al. proposed a pair of population metrics, namely, **magnetism** and **stickiness** To increase the utility of writing code compared to the utility of just discussing, projects need to setup the **development environment**, which can decrease the **cost of writing code**. **Employment** is a big incentive to write code. The project itself or other third-parties can select this option. Although it is not easy to make innovations, innovations can **decrease the cost** and may **increase the reward**. For example, **developing new tools** like Git, a version control system, and deploying new services like GitHub, a web-base hosting service and social networking system for developers, can be regarded as such innovations. |
| [S020](https://doi.org/10.1109/COMPSAC54236.2022.00144) | Atiq et al. point out that the importance of **financial support** for the progress of OSS projects is well-recognized by the research community. And they find that proper **management** is essential to the projects’ sustainability, even if the financial benefits received by the developers are unequal. With the guidance of the overjustification theory, we analyze and the changes of users’ contributions and responses over time and discover that they become significantly more active after **getting sponsorships**. And we also find that **providing sponsorships** to developers can improve their own or contributed projects. |
| [S021](https://doi.org/10.1109/HICSS.2011.264) | [...] a continuous **influx of people willing to contribute** is essential to a FOSS project's sustainability. |
| [S022](https://doi.org/10.1109/HICSS.2014.406) | [...] identify the types and instances of **citizenship behaviors** that are critical to the functioning and sustainability of FLOSS communities. |
| [S023](https://doi.org/10.1109/icse-nier58687.2023.00010) | The overarching goal of this study is to bring to attention the importance of **interpersonal trust** in OSS sustainability. |
| [S024](https://doi.org/10.1109/icse-seet58685.2023.00037) | To secure sustainability, OSS projects need to maintain a **healthy influx of newcomers** |
| [S025](https://doi.org/10.1109/ICSE.2003.1201220) | A **large base of voluntarily contributing members** is one of the most important success factors of OSS[...] |
| [S026](https://doi.org/10.1109/ICSE.2012.6227030) | As an example, the **modularity of a software architecture**, which is considered a key feature that contributes to the sustainability of large scale projects [...] |
| [S027](https://doi.org/10.1109/ICSE.2015.184) | **Governance rules** enable the **coordination of developers** in order to advance the project during its whole lifespan and, more importantly, their **evolution** allows the project to adopt societal changes on the way people want to collaborate, thus promoting the sustainability of the development process. |
| [S028](https://doi.org/10.1109/ICSE.2019.00100) | A key concern in any FLOSS project is its sustainability, and a major factor that affects this is the project’s **ability to retain contributors** |
| [S029](https://doi.org/10.1109/ICSE43902.2021.00093) | Sustainability: to promote the project to **fulfill its goals**, to **survive changes**, and to **incorporate new demands over time**. **Maintainers** perform an unquestionably central work to the success and long-term sustainability of communities. [...] In fact, we found that **Communication** was considered the most important attribute of a great maintainer with **Quality Assurance** being the second-ranked [...]. |
| [S030](https://doi.org/10.1109/ICSE48619.2023.00038) | The sustainability and long-term survival of Open Source Software (OSS) projects depend not only on **attracting** but, more crucially, **retaining motivated developers**. The reasons behind a developer’s decision to stay or leave an OSS project can depend on different intrinsic or extrinsic factors, including an individual’s feelings of **identity** and **belonging** to the community. |
| [S031](https://doi.org/10.1109/ICSE48619.2023.00066) | Sustainable Open Source Software (OSS) projects are characterized by volunteering work, **continuous recruitment**, and **effective governance**. [...] sustainable projects during episodic changes can **adapt** themselves to institutional statements more efficiently [...] **changes in self-governance** can change the trajectory of project sustainability. Sustainable projects can process and **translate self-governance rules and policies into sociotechnical changes**, and vice versa, more effectively than unsustainable projects. |
| [S032](https://doi.org/10.1109/icse48619.2023.00218) | To help with sustainability, companies **contribute financially** as well as upstream fixes which in return prevents carrying any technical debt internally. To create a sustainable project, companies need to open-source projects **they use and care about** internally. |
| [S033](https://doi.org/10.1109/MC.2020.2998235) | [...] we consider research software as sustainable if it has a long **life span** and remains live. |
| [S034](https://doi.org/10.1109/MC.2021.3133052) | [...] **commercial participation** also brings challenges and risks to the **long-term development** of OSS and the sustainability of critical open source ecosystems. |
| [S035](https://doi.org/10.1109/MSR.2007.23) | Most projects carefully regulate **admission of outsiders** to full **developer privileges**[...]. Understanding the factors that influence the who, how and when of this process is critical, both for the sustainability of FLOSS projects, and for outside stakeholders who want to gain entry and succeed. |
| [S036](https://doi.org/10.1109/MSR.2009.5069497) | The **stability and permanence of [...] most active developers** is of great importance for the evolution and sustainability of the project. |
| [S037](https://doi.org/10.1109/MSR.2017.37) | **attracting new** and **retaining old contributors** for achieving sustainable success |
| [S038](https://doi.org/10.1109/SANER.2016.27) | To measure the sustainability of the developer community participation, we [...] measure the contribution of the developer community in terms of **software configuration management artifacts**. [...] we measure **commit counts** as a proxy of developer community participation and use commit counts per time-interval to measure the sustainability of the developer community participation. |
| [S039](https://doi.org/10.1109/SANER50967.2021.00054) | Since volunteer developers are free to participate in the development and also free to leave, OSS projects always seek **newcomers** and their contributions to make the projects sustainable |
| [S040](https://doi.org/10.1109/SANER50967.2021.00060) | In recent years, researchers and practitioners attempted to defined catalogs of MCR **anti-patterns**, which become a major problem that hinders software quality, maintainability and sustainability Hence, if reviews with divergent scores are not carefully resolved, they may contribute to a tense **reviewing culture** and may slow down integration and lead to detrimental effects on contributors’ **continuing participation** in the community affecting the sustainability of the project |
| [S041](https://doi.org/10.1109/SANER56733.2023.00012) | The **bus factor risk** is significant for project sustainability. Archived projects tend to have a smaller number of bus factor contributors, a higher **PR acceptance rate**, and a longer **issue response duration**. |
| [S042](https://doi.org/10.1109/SBES.2010.26) | Less **complex code** may facilitate the addition of new features and bug fixing in a sustainable way and therefore supports **maintainability**. |
| [S043](https://doi.org/10.1109/SoHeal52568.2021.00010) | Sustainability is signaled by three factors – **community growth**, **financial resources**, and **software management** Researchers define project health through the collection of success measures; including metrics related to project output, process, and the outcomes for project members. In this context, success is the result of project activity and the release of code, otherwise the project is abandoned. Further measures of success explore the growth and diversity of projects. Activity measures tell you when a project is finished; health and sustainability measures would identify that **trajectory** in advance. While sustainability evokes **shared commitment**, survivability aims to surface indications of a project’s vigor, resilience, and organization in the face of risk Sustainability and survivability, together, aspire to provide clear signals of a project’s likelihood to **continue producing quality software**. Much of the early literature on open source project health focused on success measures, however as open source health research has matured, the focus has moved to measures of sustainability and further, to an understanding that open source health must include considerations for **social interactions** and **project diversity** when estimating survivability. **Quality model** - **product quality**, **process maturity** and sustainability **Development Base** (size), **project age** and the **size of niche**<br><br>**Patch contribution** and **patch process**<br><br>**Community growth**, **financial resources** and **software management**<br><br>**Relationships among people, technologies, and organizations** Virtuous Circle - Feedback loop of open source **best practices**<br><br>**Ability to Fork**<br><br>**Commits**, **retention of committers** |
| [S044](https://doi.org/10.1109/tr.2022.3176733) | The sustainability of an OSS project refers to the potential initiative to maintain the **functionality and evolution** of the software system in the future |
| [S045](https://doi.org/10.1109/TSE.2018.2872713) | Furthermore, peripheral developers come with extensive **external social networks** that are important for the sustainability of FLOSS projects Given the observed prevalence of EV [Episodic Volunteering], and the limitations to volunteers becoming habitual, the effective **incorporation of episodic volunteers** may become an important competency in FLOSS project sustainability. |
| [S046](https://doi.org/10.1109/TSE.2020.2985093) | [...] it is of particular interest to understand how **episodic contributors** can be 'retained'[...]. Retention is appealing because returning contributors require less assistance than newcomers and **retention** is one of the key factors in FLOSS project sustainability. |
| [S047](https://doi.org/10.1109/TSE.2021.3053403) | The sustainability of OSS projects has attracted great interest from researchers. Previous studies have investigated the motivations behind and **barriers** to developers’ **joining** and **retention** in OSS projects. |
| [S048](https://doi.org/10.1109/tse.2022.3156071) | For an OSS project, good **support to newcomers**’ early career would help retain its most valuable asset, and motivate newcomers to make sustainable contributions, hence reducing the high **turnover** problem. |
| [S049](https://doi.org/10.1109/TSE.2023.3242415) | Investigating mentors’ engagement can help OSS communities to devise support mechanisms to optimize the **mentoring** process and further promote the healthy and sustainable development of communities. The sustainability of OSS projects depends on the continuous **inflow and retention** of newcomers |
| [S050](https://doi.org/10.1145/2536536.2536560) | [...] it is essential to **motivate, engage, and retain new developers** in order to promote a sustainable community in a project. |
| [S051](https://doi.org/10.1145/2593702.2593704) | Many projects leverage the **contribution of outsiders** and the sustainability of the project relies on **retaining** some of these newcomers. |
| [S052](https://doi.org/10.1145/3106237.3106287) | We find systematic differences among modules; these differences are stable over time, which suggests that certain **architectural features**, **commercial interests**, or module-specific **practices** lead to distinct sustainable equilibria. Our proposed framework to quantify **maintainer practices** and **productivity scaling** may lead to a better understanding of the factors that allow rapidly growing projects to be sustainable and to practices that reduce risk of project failures |
| [S053](https://doi.org/10.1145/3236024.3236062) | [...] projects may be considered sustainable from a code **maintainability perspective** if they conform to **modular and extensible architectures**, from a **community perspective** if they successfully **attract and retain newcomers**; and from an **economic perspective** if they ensure **low total cost of ownership** and **high added value**. For example, **competition** was listed as a major driving force behind one project. |
| [S054](https://doi.org/10.1145/3239235.3240501) | [...] the model proposed in this paper can be used by developers to check the **maintenance status** of an open source project, before deciding to use it. This information has a key value, since there is a growing concern on the sustainability of modern open source projects. |
| [S055](https://doi.org/10.1145/3306446.3340825) | In this work, we analyze open source projects to determine whether they exhibit a rich-club behavior, i.e., a phenomenon where contributors with a high number of collaborations (i.e., strongly connected within the collaboration network) are likely to cooperate with other well-connected individuals. The presence or absence of a **rich-club** has an impact on the sustainability and robustness |
| [S056](https://doi.org/10.1145/3359224) | Studying what makes projects attractive is especially important because, as opposed to individual motivation which is typically inherent to the potential contributors, **project attractiveness** can be to a larger extent controlled by the project maintainers, as we will argue in the remainder of this paper. Therefore, increasing project attractiveness has the potential not only to reduce some **onboarding barriers**, but also to improve the sustainability of open-source projects. Indeed, among the 11 participants who talked about **team size**, five mentioned reasons why a big project may be a better choice for newcomers. One reason is that with more contributors in the team, the project can be more sustainable. [...] stakeholders could focus on developing reliable new **signals** for the less readily observable project qualities we identified as important. Ultimately, these signals could help direct **contributor effort** to open-source projects where this effort is most needed, contributing to the sustainability of open-source ecosystems as a whole. [...] **lack of time or interest of the main contributors** poses serious sustainability risks. Recruiting **new contributors** can, therefore, help ensure the sustainability of open-source projects. |
| [S057](https://doi.org/10.1145/3377811.3380920) | For example, Zhou et al. found that the **distribution of work** among the Linux kernel maintainers followed the 80:20 rule for most modules, suggesting that a few maintainers may bear the brunt of the increased workload. These issues have caused OSS projects to increasingly worry about their sustainability. |
| [S058](https://doi.org/10.1145/3377812.3381402) | One perceived risk of using FOSS software in commercial environments is its sustainability. [...] . I propose to establish evidence of sustainability measures for **software quality** taking place in FOSS communities. I define sustainability of quality as the ability of the community to **continuously deliver software of industrial standards**. My PhD study is to demonstrate that FOSS communities gain sustainability for quality through **participation motives** (e.g. hackers ethics), a **governance mechanism for software change process**, and the adoption of **good practices in the pull request (PR) evaluation process**. **Participation sustainability** is an issue in some communities. For a FOSS project to remain sustainable, it must **evolve** with its user base and its developer base. |
| [S059](https://doi.org/10.1145/3383219.3383242) | [...] the community always needs **newcomers**, as creativity requires fresh minds and an ongoing flow of ideas and **new contributions**. Ostracizing those who are not inside the community may hinder its evolution and sustainability. Each PR governance reduces the threat of poor code. Consistency and governance create a culture of excellence. [...] This perspective contribute to the sustainability of **software quality** in FOSS. |
| [S060](https://doi.org/10.1145/3415251) | These **roles**, although known and important for the projects’ sustainability and **community evolution**, are often not formally recognized in OSS communities. |
| [S061](https://doi.org/10.1145/3468264.3468563) | [...] sustainability is a measure related more to the **human and social aspect** (e.g., the ability to take **responsible collective action**, and an **open and inclusive atmosphere**, etc.) than the technical aspect (defect density, technical advantage, etc.). |
| [S062](https://doi.org/10.1145/3491102.3501822) | A more relevant **[donation] mechanism** is needed to promote the healthy and sustainable development of the ecosystem. |
| [S063](https://doi.org/10.1145/3510003.3510116) | **Financial support** for OSS maintainers and developers is a major issue in terms of sustaining OSS projects, and the ability to donate to individuals is expected to support the sustainability of developers, projects, and community. |
| [S064](https://doi.org/10.1145/3510003.3510121) | A better understanding of the effectiveness of using social media to **attract attention** to OSS projects could directly impact the projects’ success and sustainability. For example, prior work found that **popular** OSS projects are perceived as having **higher quality** and better **community support**, tend to be more **attractive** to new contributors, and tend to be more successful at **fundraising**. That is, they tend to be more sustainable. |
| [S065](https://doi.org/10.1145/3510003.3510196) | One major challenge of OSS sustainability is to **attract** and **retain capable newcomers**. To help newcomers become familiar with an OSS project, GitHub provides a list of best **practices** [...]. Even if sufficient **documentation** is provided, it is still very challenging for newcomers to locate **suitable development tasks** to start with. |
| [S066](https://doi.org/10.1145/3510454.3522685) | **Contributors** are vital to the sustainability of open source ecosystems, and **disengagement** threatens that sustainability. |
| [S067](https://doi.org/10.1145/3510849) | To achieve **commercial goals**, companies have made substantial contributions to large open-source software (OSS)[...]. However, they often withdraw their employees for a variety of reasons, which may affect the sustainability of OSS projects. While the turnover of individual contributors has been extensively investigated, there is a lack of knowledge about the nature of **companies’ withdrawal**. |
| [S068](https://doi.org/10.1145/3524842.3528506) | Seeking less uncertainty, many OSS projects join established software communities [...] to **guide projects** toward sustainability. In recent work we showed that OSS project sustainability can be effectively predicted [...] from longitudinal project and process metrics supplemented by socio-technical network metrics (**developer communications** and **code contributions**), [...]. |
| [S069](https://doi.org/10.1145/3531056.3542767) | We, therefore, propose the concept of software digital sociology that represents mining abundant software-activity data to achieve such understanding. The research objects range from **individual learning**, **group collaboration**, and **ecosystem sustainability**, along with a particular focus on the complex **dependencies** coined as software supply chain. |
| [S070](https://doi.org/10.1145/3540250.3549117) | [...]. These strengths are threatened when a single organization can exert **exclusive control** over the future evolution of an OSS project, which in turn can jeopardize the future sustainability of OSS projects and ecosystems. The findings of this study may help OSS communities to increase their awareness of this issue and the associated risks, and adjust their **governance mechanisms** so as to ensure their future sustainability. As **corporate participation** in OSS ecosystems is growing, their influence on the **future evolution** of these ecosystems also becomes stronger, which in turn can have significant consequences for the sustainability of these ecosystems. |
| [S071](https://doi.org/10.1145/3540250.3549132) | [...] we hypothesize that sustainable projects may exhibit different **code** and **process patterns** than unsustainable ones, and that those patterns can grow more apparent as projects evolve over time. Apache Software Foundation (ASF), which provide common **standards** and **guidance** in exchange for higher community uniformity. The popularity and high standards of foundation supported projects can contribute to their continued sustainability, by **attracting** a steady supply of programmer effort. Those studies found that different **patterns of social interactions** and different **socio-technical behavior** mediate differential success outcomes, in particular with respect to sustainability metrics. This paper is a first step showing that it is possible to associate sustainability with **code, quality and process metrics**. During the incubation, the projects’ long-term goal is to become self-sustainable, i.e., the project’s community can **self-govern** itself to **sustain its activity and productivity over time**. To help incubating projects achieve such level of sustainability, ASF, different from most OSS foundations, provides each incubating project with in-depth **mentorship** from senior ASF committers. More recently, Yin et al. showed that socio-technical factors (mostly **social and technical networks**) can be used to forecast the incubation sustainability outcome for ASF incubator projects They found that a higher **bug-fixing** and **feature enhancement rate**, together with an **increase in the frequency of releases** helps with long term sustainability. From a sustainability perspective, minor contributors could become committers and maintainers of the project. Thus, projects and maintainers should consider **attracting** and **providing guidance** to minor contributors as a way of expanding the project’s community. |
| [S072](https://doi.org/10.1145/3543873.3587336) | [...] refers to a project’s ability to be **maintained and developed over time**, including aspects such as **governance and community engagement**. |
| [S073](https://doi.org/10.1145/3555129) | In this paper, we make the first effort toward understanding OSS project sustainability using a dual-view analysis, by combining institutional analysis with socio-technical systems analysis. In particular, we (i) use linguistic approaches to extract **institutional rules and norms** from OSS contributors’ communications to represent the evolution of their **governance systems**, and (ii) construct **socio-technical networks** based on longitudinal **collaboration records** to represent each project’s **organizational structure**.<br><br>In software engineering, the focus has been on understanding success and sustainability from the **socio-technical** perspective: the OSS developers’ **day-to-day activities** and the **artifacts** they create. In the management domain, on the other hand, emphasis has been on institutional designs [...] that **structure governance** and OSS **project administration**. [...] key hurdles that OSS projects have to demonstrate to graduate is that they can (1) **produce new releases**, and (2) show the **ability to attract new developers**. Both of these factors arguably are key to the sustainability of OSS projects. |
| [S074](https://doi.org/10.1145/512035.512055) | A **large base of voluntarily contributing members** is one of the most important success factors of OSS[...] |
| [S075](https://doi.org/10.1587/transinf.2015EDP7363) | Steinmacher et al. argued that the sustainability of many OSS projects relies on **retaining newcomers**. They discussed some barriers faced by newcomers to OSS [6]. |
| [S076](https://doi.org/10.17705/1jais.00244) | Sustainability is defined in this paper as the ability of the project to exhibit **software development and maintenance activity over the long term**. Sustainability is conceptualized as the **ability to remain active for a longer period of time** The **ability to attract resources** is an indicator of the perceived project **legitimacy**, which in turn is a strong predictor of the project’s future sustainability. [...] we believe that the **number of open and closed artifacts** is an appropriate measure of the sustainability of a FLOSS project. [...] project demographic characteristics such as **age and size**, as well as the **niche size** occupied by the project, influence the project’s ability to **attract and retain user and developer** resources in the future. |
| [S077](https://doi.org/10.3390/su13031079) | [...] inspired by the vital importance of sustainability as a concept that expresses the need to create the necessary **conditions for future generations to use and evolve present artifacts**, we target the software engineering domain and propose a systematic way towards measuring the extent to which a software artifact developed and applied in the cultural heritage domain is sustainable. This fact is more than evident considering that **maintainability** (the official term for sustainability in the software engineering language) is one of the most important quality characteristics according to ISO/IEC 25010:2011 |
| [S078](https://doi.org/10.3390/sym10120747) | Accordingly, we define open source ecosystem sustainability as the potential initiative of the software ecosystem to permanently **sustain or support its own dynamic health and its evolutionary evolution**. This definition includes two meanings: First, the system is now in a **state of steady development**; second, the system will continue to **be in that state in the future**. **Openness**: The ability of the entire ecosystem to communicate and transformation with the outside environment or within the ecosystem. **Integrity**: The internal composition, structure and function of an ecosystem and the integrity of its external biophysical environment. **Stability:** The anti-interference ability of the structure, state and behavior of the ecosystem. Including avoidance, tolerance and resilience. **Regulation**: The ecosystem has certain resistance to interference and has a certain ability to recover after being disturbed. It can coordinate and maintain stability. **Resilience**: The ability of ecosystems to maintain function under pressure. **Diversity**: Rich and balanced species within the ecosystem. **Productivity**: The biological production capacity of the ecosystem. **Organizational Structure**: Components and structures in the ecosystem.<br><br>**Drivers**: Natural or man-made disturbances or stress on ecosystems that change ecosystems. **Propensity for Growth**: Ecosystem growth is good. Activity. **Conform to Development Trend**: The ability to meet the needs of contemporary people. Extensibility. |
| [S079](https://doi.org/10.5210/fm.v0i0.1470) | [...] many people don't understand how Open Source could be economically sustainable, and some may even feel that its potential negative effect upon the proprietary software industry is an overall economic detriment. Fortunately, [...] Open Source is both sustainable and of tremendous benefit to the overall **economy**. |
| S080 | Our research identified several factors that influence the performance of the projects, including the less-explored **role of core developers** and the importance of **promoting the projects**. |
| S081 | [...] [this research] will help FLOSS communities in understanding the factors that contribute to the successful **socialization of new members**. It will thus help communities to tailor proper socialization initiatives that lead to behaviours that match **community values**, and increase the community’s sustainability |
| S082 | [...] this research project will help FOSS communities in understanding the factors that characterize the **socialization of new members** and will thus help communities in better designing socialization initiatives and programs [...] that will contribute to the survival, sustainability, and overall long-term success of FOSS communities. |
| S083 | Since the current model of OSS development depends on this volunteer workforce, who are **ideologically motivated**, introducing **compensations/rewards that are not transparent** and community oriented, may alienate volunteers and threaten the sustainability of OSS communities. As volunteers’ **motivation to associate with**, and contribute via these communities is vital to the sustainability of OSS development [...] Developers perceive asymmetry in compensation/rewards when they believe that funds/resources available to a project have been **distributed unequally/unfairly/asymmetrically**. Our findings suggest that OSS projects where only some people get financial benefits may fail if they are **mismanaged**. From our empirical research, we suggest that **fair-terms, transparency through effective communication** are essential to OSS project sustainability, even if the governing agency have a policy of unequal financial benefits. |
| S084 | The contributions of this paper include [...] providing a quick reference check for those interested in conducting research on understanding developer **forking motivation** reasons and consequences [...] to predict project survivability and sustainability [...]. |
| S085 | The social sustainability of a community depends on the **individual characteristics of its members**, on its **size and form**, and the **division of labor and power** in the community. Cultural aspects of interaction depend on **interpretation, language, and coherent patterns of behaviour**. The most recent economic literature is dealing with the companies’ |
| S086 | An improved **patch contribution process** will lower the **contribution barrier**, helping to improve the sustainability of critical open source projects. Our study of open source projects generally supports the idea that a managed **patch contribution process** improves project sustainability. |
| [S087](https://doi.org/10.1002/smr.2597) | **Architecture**, **Maintanability**, **Security and testing**, **License**, **Market**, **Support**, **Initialization**, **Dependencies**, **Reuse**, **Development process and governance**, **Developer base**, **User base. Robustness**, **Scalability**, **Usability**, **Effectiveness**, **Corrections**, **Improvements**, **Security**, **Test process**, **Coverage**, **License Type**, **Dual Licensing**, **Commercial resources**, **Commercial training**, **Industry Adoption**, **Nonprofit / foundation support**, **For profit / company support**, **Donations**, **Installability**, **Configurability**, **Self Contained**, **Resource utilization**, **Complexity**, **Modularity**, **Instability**, **Cohesion**, **Governance model**, **Project roadmap**, **Code of conduct**, **Documentation standards**, **Coding standarads**, **Developer attracted**, **Active developers**, **Number of open issues**, **Open versus closed issues**, **Source code documentation**, **Localization process**, **Issue tracking activity**, **User guide.** |
| [S088](https://doi.org/10.1109/MCSE.2024.3414951) | We posit that a project’s need for sustainability support can be determined by comparing measures of **active use** to measures of **active maintenance**. |
| [S089](https://doi.org/10.1177/14614448221090474) | [...] **firms control** who can commit to a given repository and who cannot (typically, only firm employees can commit, whereas others need to obtain approval via pull requests). This partly explains why firms remain the main contributor to a repository of a technology they initially released. The technology is therefore ‘open source’ in terms of the code license, but is not developed following an **open or shared governance model** whereby developers from different firms collectively decide its future direction (the Linux kernel is an obvious exception, as it features contributions from a very diverse group of firms).<br><br>It seems less controversial to suggest that increased **firm involvement** is likely to influence project decisions of all kinds, from technical to licensing ones. And indeed the open status of industrial public goods is now at risk.<br><br>We mapped a firm-project FOSS coproduction network on GitHub, which was dominated by a minority of key players, such as Linux and Microsoft. We found diverse **firm contributory models**, including quasi-monopolies, indirect cooperation between firms, and extreme fragmentation in the case of Linux. Despite **paid workers** making the majority of contributions, **unpaid workers** played a significant role, indicating the informal nature of these hybrid work arrangements.<br><br>Our mapping of exclusive firm ‘contribution territories’ led us to define indirect firm cooperation as ‘selective’ and raises the question of the existence of ‘contribution deserts’ – projects and code that are neglected by large IT **firms** and can only rely on **volunteer labor**, despite being important for the sustainability and diversity of the open source ecosystem. |
| [S090](https://doi.org/10.1109/TCSS.2024.3476198) | The practical significance of this research lies in the ability to accurately predict **developer churn**, enabling open-source communities to proactively **retain** core developers and enhance the sustainability of their projects.<br><br>By leveraging historical data, this model takes into consideration various factors such as developers’ **activities**, **collaborative networks**, and **community context information**. |
| [S091](https://doi.org/10.1145/3611643.3616349) | In this paper, we use **sustained activity** as the main proxy for studying OSS sustainability, following previous work.<br><br>We further find that **issue comments** from non-code contributors (#iss_comment_n) are positively related to sustained activity.<br><br>Our results suggest that projects, especially organizational projects, should pay attention to the **retention** of **experienced core developers** (with higher #issue_all_c, #pro_oneyear_c) and **active** **peripheral contributors** (for higher cmt_dev_std, #cmt_p).<br><br>Therefore, we suggest that initial project maintainers should be careful not to let these **“process” activities** take up too much time and effort, since some non-code activities take resources and sometimes slow down development activities.<br><br>Finally, since the **presence of organizations and companies** has largely positive effects in our analysis, we are interested in the underlying mechanisms and the roles that organizations and companies may play during OSS launching. |
| [S092](https://doi.org/10.1371/journal.pcbi.1012045) | Without an active and engaged community of users, the software fails to **solve a real-world problem** and will not be impactful. [...] if the software continues to be relevant, then community managers or equivalent should be engaged to ensure the **community is active**, provides **feedback** and **reports bugs** [...].<br><br>Maintaining and sustaining code is simplest when a community is most active; however, even without an active community, **code** should be routinely **updated and maintained**. **Bug fixing** is required to ensure the software remains **trustworthy**, and implementing **new features** is required to ensure the software remains relevant. **Automated testing** of code is best practice and should be implemented by developers whenever possible. [...] developers should also consider how **stakeholder engagement** and **end-user testing** should be incorporated into ongoing testing and maintenance.<br><br>Finally, **funding** for software can be acquired via **grant funding**, creating **software as a service**, **offering tiered subscriptions** (e.g., for quicker bug fixing), **dual-licensing**, and other models—there is no turnkey solution for financial sustainability and all software will need a bespoke solution. [...] |
| [S093](https://doi.org/10.1002/smr.2645) | [...] we use the **number of commits over time** to characterize the sustainability of projects. |
| [S094](https://doi.org/10.1109/TSE.2022.3225197) | Sustainability is particularly visible in the complex and often brittle **dependency chains** in OSS library ecosystems like npm, PyPi, and CRAN. |
| [S095](https://doi.org/10.1145/3611643.3617849) | The risk of packages severely losing downloads (i.e. peaking) decreases when they are more **consistently maintained**.<br><br>[...] the effects of no maintenance, particularly read-only archived projects, on package downloads decreases for **smaller** **projects** [...]<br><br>[...] projects progressively become less satisfactory unless **continually adapted**. [...] **small** and widely-reused projects to be **feature-complete** and less dependent on maintainers to thrive. |
| S096 | The emerging threat of **toxic behaviors** in developer interactions is a critical issue jeopardizing the sustainability of OSS communities. |
| [S097](https://doi.org/10.1109/VL/HCC60511.2024.00056) | However, **newcomers** face several **barriers** in the OSS context [...]. These barriers differently affect **underrepresented populations** [...]. The consequences of these challenges [...] add to the **diversity** imbalance in OSS. |
| [S098](https://doi.org/10.1145/3663529.3663777) | In the context of OSS projects, sustainability refers to the ability of a project to maintain its **longevity**, **relevance**, and **effectiveness** over time.<br><br>[...] the article by Yin et al. found that the number of **active developers** positively associates with the sustainability outcome [...]. |
| [S099](https://doi.org/10.1145/3597503.3639197) | A key factor for the sustainability of OSS projects is to **attract long-term contributors**.<br><br>Zhang et al. found a positive association between the **diversity** of contribution models and the number of volunteers and a negative impact of **company domination** on the sustainability of OSS projects. Valiev et al., however, found that the **involvement of companies** has a significant effect on the sustainability of projects in the PyPI ecosystem.<br><br>This indicates that, although women usually have a low percentage in many OSS projects, promoting **gender diversity** is worthwhile in OSS development (or at least the Rust community).<br><br>We find that core **paid developers** tend to contribute more frequently; commits contributed by one-time **paid developers** have bigger sizes; peripheral **paid developers** implement more features; and **being paid** plays a positive role in becoming a long-term contributor.<br><br>**Companies** **should become more sensitive to** **how they engage with OSS** communities, in certain ways as suggested by this study. |
| [S100](https://doi.org/10.1145/3613904.3642541) | We conclude that an environment that is open for **communication** and **multidisciplinary collaboration** facilitates the opportunities of serendipitous support and ultimately increases the sustainability of FOSS projects. |
| [S101](https://doi.org/10.1145/3597503.3608142) | Empirical evidence suggests that more **atypical projects** tend to draw more attention from users, possibly due to a **competitive advantage** relative to other packages available to the open-source community. However, more atypical projects tend to be developed by a smaller set of contributors, which could lead to problems in their sustainability.<br><br>We found that **innovative projects** tend to **draw more attention**, primarily in the form of GitHub stars, and **more contributors**, especially **in the long term**. At the same time, we found that innovative projects **require more effort** from developers on average and face greater challenges with sustaining their activity. |
| [S102](https://doi.org/10.1016/j.infsof.2024.107470) | Mentoring goes beyond assisting contributors in overcoming technical and systemic challenges; it also serves as an essential instrument in fostering a sustainable, **diverse**, and **inclusive** collaboration environment. Mentors help with **technical challenges** by guiding mentees and fostering a culture of **knowledge-sharing** and **collaboration**. Ultimately, today’s mentees evolve into tomorrow’s mentors [2,9]. Shifting to **diversity**, mentoring can be strategically designed to pair individuals based on geographical or cultural demographics. This approach directly counteracts biases and fosters a welcoming, **inclusive** OSS community. This can simultaneously help **community growth** and sustainability, **attracting** and **retaining** contributors for OSS projects’ long-term success. |
| [S103](https://doi.org/10.1109/SANER60148.2024.00106) | [...] we consider a DL package as “sustainable” if it has **sustained activity** in its last 12 months prior to its most recent commit. |
| [S104](https://doi.org/10.1145/3674805.3686667) | Amount of **perceived work** for maintainers generated from the OSS community (e.g., support requests, bug fixes, community management) need to balance against maintainers’ capacity.<br><br>Creating a **work-life balance** requires **personal prioritization** by the maintainer over their perceived or experienced need to maintain their projects.<br><br>**Toxicity** is commonly experienced and requires a proactive approach and building of a **positive culture** enforced, e.g., through a **code of conduct**.<br><br>**Episodic contributors** should be **encouraged and empowered** to make their contributions as **high quality** as possible.<br><br>A Sense of **inclusiveness** is considered pivotal for new contributors to stay around. Highlighted means include **encouragement** and **appreciation** for contributions, **openness in decision-making**, and **responsiveness** in answers.<br><br>Awareness and actions are needed to address the potential negative impact of a project’s characteristics (e.g., **programming language**, **position in the stack**, and general **stability**) on the **attractiveness** of new contributors.<br><br>Maintainers need help with **marketing** and **outreach**, as they may feel uncomfortable and prefer to focus on technical aspects of their projects.<br><br>Sharing knowledge in **communication** and **documentation** decreases dependency on the single maintainer while improving **onboarding** and **inclusiveness**.<br><br>**Contribution barriers** need to be removed while **support measures** help increase the quality of contributions without consuming too much of the maintainers’ available time.<br><br>**Full-time employment** dedicated to working on projects is seen as a dream by many [...].<br><br>Being able to spend part-time **employment** to maintain a project is viewed favorably [...].<br><br>**Building a business** comes with many variants and is considered risky to different extents. Prioritizing the needs of **paying customers** and the **community** requires a delicate balance.<br><br>Personal **sponsorship** is considered a symbol of gratitude, while corporate sponsorship is more significant. None is, however, considered a **sustainable source of income**. |
| [S105](https://doi.org/10.1145/3609437.3609454) | A well-functioning **voting system** is indicative of a project’s potential for success and sustainability |
| [S106](https://doi.org/10.1145/3618305.3623598) | This raises the question of whether **unpaid** open-source developers feel more motivated by their ability to put **values** into action than paid ones.<br><br>**Have fun Community Spread knowledge Skill development Values into actions Duty to users Personal use Organization's reputation Collaboration Commercial use Improve existing projets** |
| [S107](https://doi.org/10.1145/3611643.3616282) | However, much less is known about how factors external to the project, related to its **position and role in the overall open-source ecosystem**, impact the process of **attracting and retaining new** **contributors**.<br><br>The prevailing empirical studies on open-source sustainability, and attracting new contributors in particular, have focused on the influence of project-level characteristics. In our paper, we provide an alternative, **ecosystem-level perspective** by suggesting the project’s **labor pool** as an important factor.<br><br>While open-source developers and researchers have devoted much effort to making individual projects more successful and sustainable, little was discussed about the influence of those efforts on other projects in the **ecosystem**. |
| [S108](https://doi.org/10.1109/ISSREW63542.2024.00058) | [...] maintaining **up-todate documentation** alongside code changes is critical for project sustainability. |
| [S109](https://doi.org/10.1145/3691620.3695286) | [...] the open-source software community has faced various **onboarding** challenges over the past decades which has posed a threat to its sustainability |
| [S110](https://doi.org/10.1109/SERA61261.2024.10685609) | In a survey of 49 developers from the NPM ecosystem, we find that developers are more likely to maintain **their own packages** rather than contribute to **the ecosystem**.<br><br>For researchers, this study calls for more research into how the different **relationships between developers** of a package may assist it with its sustainability.<br><br>First, we observe that **personal drivers** are the key factors behind developers making contributions to their own packages (40 responses). They also reserve more **challenging** tasks for own packages, as oppose to trying to make to other packages. Second, we find that developers contribute to other packages more due to **professional** (39 responses) rather than personal **drivers**. |
| [S111](https://doi.org/10.1007/978-3-642-55128-4_21) | [...] **motivate**, **engage**, and **retain** new developers is the way to promote a sustainable amount of developers in a project.<br><br>[...] presents five categories: **Social Interactions**, **Finding a Way to Start**, **Documentation Problems**, **Code Issues**, and **Newcomers’ Knowledge**. |

</details>

## References

Alami, Adam. 2020. “The Sustainability of Quality in Free and Open Source Software.” In *Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Companion Proceedings*, 222–25. ICSE ’20. ACM. <https://doi.org/10.1145/3377812.3381402>.
{: #ref-S058}

Becker, Christoph, Ruzanna Chitchyan, Leticia Duboc, Steve Easterbrook, Birgit Penzenstadler, Norbert Seyff, and Colin C. Venters. 2015. “Sustainability Design and Software: The Karlskrona Manifesto.” In *37th International Conference on Software Engineering (ICSE)*, 2:467–76. Florence, Italy.
{: #ref-Becker2015}

Berntsen, Kristina Rakneberg, Morten Rismo Olsen, Narayan Limbu, An Thien Tran, and Ricardo Colomo-Palacios. 2016. “Sustainability in Software Engineering - a Systematic Mapping.” In *Trends and Applications in Software Engineering*, 23–32. Springer International Publishing.
{: #ref-Berntsen2016}

Chengalur-Smith, Indushobha, Anna Sidorova, and Sherae Daniel. 2010. “Sustainability of Free/Libre Open Source Projects: A Longitudinal Study.” *Journal of the Association for Information Systems* 11 (11): 657–83. <https://doi.org/10.17705/1jais.00244>.
{: #ref-S076}

Cruzes, Daniela S., and Tore Dyba. 2011. “Recommended Steps for Thematic Synthesis in Software Engineering.” In *International Symposium on Empirical Software Engineering and Measurement (ESEM)*, 275–84. Banff, AB, Canada.
{: #ref-Cruzes2011}

Eghbal, Nadia. 2016. “Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure.” Ford Foundation. <https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/>.
{: #ref-Eghbal2016}

Greenstein, Shane, and Frank Nagle. 2014. “Digital Dark Matter and the Economic Contribution of Apache.” *Research Policy* 43 (4): 623–31. https://doi.org/<https://doi.org/10.1016/j.respol.2014.01.003>.
{: #ref-Greenstein2014}

Hata, Hideaki, Taiki Todo, Saya Onoue, and Kenichi Matsumoto. 2015. “Characteristics of Sustainable OSS Projects: A Theoretical and Empirical Study.” In *2015 IEEE/ACM 8th International Workshop on Cooperative and Human Aspects of Software Engineering*, 15–21. IEEE. <https://doi.org/10.1109/chase.2015.9>.
{: #ref-S019}

Hilty, L., W. Lohmann, and E. M. Huang. 2011. “Sustainability and ICT - an Overview of the Field.” PhD thesis. *Notizie Di POLITEIA*. Tipolito Subalpina.
{: #ref-Hilty2011Sustainability}

Koziolek, Heiko. 2008. “Goal, Question, Metric.” In *Dependability Metrics*, 39–42. Springer Berlin Heidelberg.
{: #ref-Koziolek2008}

Lago, Patricia, Sedef Akinli Koçak, Ivica Crnkovic, and Birgit Penzenstadler. 2015. “Framing Sustainability as a Property of Software Quality.” *ACM Communications* 58 (10): 70–78.
{: #ref-Lago2015}

Liao, Zhifang, Libing Deng, Xiaoping Fan, Yan Zhang, Hui Liu, Xiaofei Qi, and Yun Zhou. 2018. “Empirical Research on the Evaluation Model and Method of Sustainability of the Open Source Ecosystem.” *Symmetry* 10 (12): 747. <https://doi.org/10.3390/sym10120747>.
{: #ref-S078}

Linåker, Johan, Efi Papatheocharous, and Thomas Olsson. 2022. “How to Characterize the Health of an Open Source Software Project? A Snowball Literature Review of an Emerging Practice.” In *Proceedings of the 18th International Symposium on Open Collaboration*. OpenSym ’22. Madrid, Spain: Association for Computing Machinery. <https://doi.org/10.1145/3555051.3555067>.
{: #ref-Linaker2022}

Linden, Frank van der, Bjorn Lundell, and Pentti Marttiin. 2009. “Commodification of Industrial Software: A Case for Open Source.” *IEEE Softw.* 26 (4). <https://doi.org/10.1109/MS.2009.88>.
{: #ref-Linden2009}

Liu, Manlu, Sean Hansen, and Qiang Tu. 2020. “Keeping the Family Together: Sustainability and Modularity in Community Source Development.” *Information and Organization* 30 (1): 100274. <https://doi.org/10.1016/j.infoandorg.2019.100274>.
{: #ref-S014}

Mourão, Brunna C., Leila Karita, and Ivan do Carmo Machado. 2018. “Green and Sustainable Software Engineering - a Systematic Mapping Study.” In *17th Brazilian Symposium on Software Quality (SBQS)*, 121–30. Curitiba, Brazil.
{: #ref-Mourao2018}

Nakakoji, Kumiyo, Yasuhiro Yamamoto, Yoshiyuki Nishinaka, Kouichi Kishida, and Yunwen Ye. 2002. “Evolution Patterns of Open-Source Software Systems and Communities.” In *Proceedings of the International Workshop on Principles of Software Evolution*, 76–85. IWPSE02. ACM. <https://doi.org/10.1145/512035.512055>.
{: #ref-S074}

Nazir, Sumaira, Nargis Fatima, Suriayati Chuprat, Haslina Sarkan, Nurulhuda F, and Nilam N. A. Sjarif. 2020. “Sustainable Software Engineering: A Perspective of Individual Sustainability.” *International Journal on Advanced Science, Engineering and Information Technology* 10 (2): 676.
{: #ref-Nazir2020}

Penzenstadler, B., V. Bauer, C. Calero, and X. Franch. 2012. “Sustainability in Software Engineering: A Systematic Literature Review.” In *16th International Conference on Evaluation Assessment in Software Engineering (EASE)*, 32–41. Ciudad Real, Spain.
{: #ref-Pezenstadler2012}

Petersen, Kai, Sairam Vakkalanka, and Ludwik Kuzniarz. 2015. “Guidelines for Conducting Systematic Mapping Studies in Software Engineering: An Update.” *Information and Software Technology* 64: 1–18.
{: #ref-Petersen2015}

Razavian, Maryam, Giuseppe Procaccianti, and Damian Andrew Tamburri. 2014. “Four-Dimensional Sustainable e-Services.” In *Informatics for Environmental Protection, Sustainable Development and Risk Management*. Oldenburg, Germany.
{: #ref-Razavian2014}

Santos, Carlos, George Kuk, Fabio Kon, and John Pearson. 2013. “The Attraction of Contributors in Free and Open Source Software Projects.” *The Journal of Strategic Information Systems* 22 (1): 26–45. <https://doi.org/10.1016/j.jsis.2012.07.004>.
{: #ref-S016}

Schweik, Charles M, and Robert C English. 2012. *Internet Success: A Study of Open-Source Software Commons*. MIT Press.
{: #ref-Schweik2012}

Venters, Colin C., Lydia Lau, Michael K. Griffiths, Violeta Holmes, Rupert R. Ward, Caroline Jay, Charlie E. Dibsdale, and Jie Xu. 2014. “The Blind Men and the Elephant: Towards an Empirical Evaluation Framework for Software Sustainability.” *Journal of Open Research Software* 2 (1).
{: #ref-Venters2014}

Voulvoulis, N., T. Giakoumis, C. Hunt, V. Kioupi, N. Petrou, I. Souliotis, C. Vaghela, and WIH. binti Wan Rosely. 2022. “Systems Thinking as a Paradigm Shift for Sustainability Transformation.” *Global Environmental Change* 75: 102544.
{: #ref-Voulvoulis2022}

Wachs, Johannes, Mariusz Nitecki, William Schueller, and Axel Polleres. 2022. “The Geography of Open Source Software: Evidence from GitHub.” *Technological Forecasting and Social Change* 176 (March): 121478.
{: #ref-Wachs2022}

Yin, Likang, Mahasweta Chakraborti, Yibo Yan, Charles Schweik, Seth Frey, and Vladimir Filkov. 2022. “Open Source Software Sustainability: Combining Institutional Analysis and Socio-Technical Networks.” *Proceedings of the ACM on Human-Computer Interaction* 6 (CSCW2): 1–23. <https://doi.org/10.1145/3555129>.
{: #ref-S073}

[^1]: https://scopus.com

[^2]: https://dl.acm.org

[^3]: https://ieeexplore.ieee.org
