18 KiB
18 KiB
1 | Key | Item Type | Publication Year | Author | Title | DOI | Change characteristics (blue) | Actors (purple) | Environmental characteristics (green) | Methods details (orange) | Misc. (red) |
---|---|---|---|---|---|---|---|---|---|---|---|
2 | LB5MEY9S | journalArticle | 2017 | Norskov, Sladjana; Kesting, Peter; Ulhoi, John Parm | Deliberate change without hierarchical influence? The case of collaborative OSS communities | 10.1108/IJOA-08-2016-1050 | |||||
3 | KUWLMFWM | journalArticle | 2017 | Santos, Carlos Denner D60os | Changes in free and open source software licenses: managerial interventions and variations on project attractiveness | 10.1186/s13174-017-0062-3 | |||||
4 | SJEI288C | conferencePaper | 2024 | Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, Chris | An Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software | 10.1145/3674805.3686692 | technical and organizational/procedural: broad compliance with GDPR; increased development work and attention devoted to compliance with GDPR features and PRs -- increases to the technical management of data --- organizational: slowed down development timelines immensely --- organization: GDPR compliance requires and overhaul of --- consultation with legal team is a change in and of itself ; one that decreased productivity; technical because the technical aspects of the code were the things regulated by GDPR | OSS project developers --- some of whom had submitted GDPR compliance Prs | geopolitical legal regulation --- data privacy and rights regulation --- EU --- from a technical level, this is a non-functional requirement ---internal evaluation of change success within environment: consultation with legal counsel --- self-assessment --- “most of the resources on the internet are wrong” | Mixed-methods: pilot interview study with three developers; survey with 56 developers; mined Prs from GitHub, some sampling for survey done from activity data mined from GitHub ; grounded thematic coding methods for analysis of free responses/qualitative themes | developers not happy about compliance --- frustration of internal productivity in order to comply with the standard--- unhappiness also with the standard itself, not just what the compliance does to the project |
5 | U7U4YLVB | journalArticle | 2023 | Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi | "Nip it in the Bud": Moderation Strategies in Open Source Software Projects and the Role of Bots | 10.1145/3610092 | |||||
6 | M6PP5MPQ | conferencePaper | 2011 | Jensen, Chris; Scacchi, Walt | License Update and Migration Processes in Open Source Software Projects | https://doi.org/10.1007/978-3-642-24418-6_12 | |||||
7 | ENQ5AACF | journalArticle | 2022 | Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk | Managing Episodic Volunteers in Free/Libre/Open Source Software Communities | 10.1109/TSE.2020.2985093 | |||||
8 | RN5Y3TN5 | conferencePaper | 2020 | Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A. | What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers | 10.1145/3422392.3422459 | organizational/procedural - adoption of code review bot; rationale: this code review bot will enhance feedback to developers contributing code; reducing maintainers effort when evaluating different parts of the code | OSS maintainers of projects that had adopted code review bots | external/peripheral contributions from the fork of the project --- those waiting for code review --- self-assessment: internal metrics of amorphous normative goals such as reducing time to close on Prs; maintainers hoped to automate things as the number of contributions increased | qualitative survey: 27 maintainers re: the adoption of code review bots within the project. maintainers for projects who had adopted at least one code review bot. using the GHTorrent data set and who had contributed on either side of bot adoption --- card sorting thematic analysis of the survey responses --- discussion and consensus regarding the themes | a lot of internal rationalization when addressing different factors of being more ‘productive’ or lessening small labor within the project--- added noise and downside results from the adoption of the bots |
9 | HS8AQN5V | journalArticle | 2010 | Sojer, Manuel; Henkel, Joachim | Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments | 10.17705/1jais.00248 | |||||
10 | GGZV58MQ | journalArticle | 2021 | Klug, Daniel; Bogart, Christopher; Herbsleb, James D. | "They Can Only Ever Guide": How an Open Source Software Community Uses Roadmaps to Coordinate Effort | 10.1145/3449232 | |||||
11 | JL6YZE5S | journalArticle | 2023 | Hu, Jin; Hu, Daning; Yang, Xuan; Chau, Michael | The impacts of lockdown on open source software contributions during the COVID-19 pandemic | 10.1016/j.respol.2023.104885 | |||||
12 | XPC3Y8HH | journalArticle | 2020 | Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn; Brax, Christoffer; Mattsson, Anders; Gustaysson, Tomas; Feist, Jonas; Lonroth, Erik | Maintaining interoperability in open source software: A case study of the Apache PDFBox project | 10.1016/j.jss.2019.110452 | |||||
13 | 4V42NWTT | journalArticle | 2016 | Adams, Bram; Kavanagh, Ryan; Hassan, Ahmed E.; German, Daniel M. | An empirical study of integration activities in distributions of open source software | 10.1007/s10664-015-9371-y | |||||
14 | MVGUFG8P | conferencePaper | 2016 | Crowston, Kevin; Shamshurin, Ivan | Core-Periphery Communication and the Success of Free/Libre Open Source Software Projects | 10.1007/978-3-319-39225-7_4 | |||||
15 | WE8VYWEX | journalArticle | 2021 | Geiger, R. Stuart; Howard, Dorothy; Irani, Lilly | The Labor of Maintaining and Scaling Free and Open-Source Software Projects | 10.1145/3449249 | organizational/procedural – projects have to reconstruct their processes and organization in order to comply with shifting expectations of scale. trust scaling requires new forms of code review… formalizing it while also trusting designated individuals to adhere to it --- this may seem like a technical process but in reality it’s organizational, as it expresses the direction of the project and the way of doing. | OSS project maintainers, largely white, male from the global north, and young-ish, --- from a range of project types too | environment is infrastructural mapping of project for other organizations --- as projects scale…also GitHub as an environment that creates pressures around presentation and reputation. the ecosystem turns from interdependent to competitive as projects scale within it -- the project reshapes the environment --- maintainers have to directly manage this new environment and set of relationships --- sometimes, maintainers choose to consolidate like-projects within an ecosystem. Check of success: NA | qualitative interview study: semi-structured interviews with maintainers during 2019-2020. non-random sampling. tried to interview maintainers from a breadth of environments and projects; recruited from a breadth of settings. Interpretive grounded theory for qualitative analysis. | adaptive change becomes an ‘overwhelming and never-ending chore’--- environmental demands from users are disrespectful, entitled, and demanding in terms of time and attention. Burn out because of ‘what was expected’ of maintainers as they scale out |
16 | 3F7CJATB | journalArticle | 2022 | Yin, Likang; Chakraborti, Mahasweta; Yan, Yibo; Schweik, Charles; Frey, Seth; Filkov, Vladimir | Open Source Software Sustainability: Combining Institutional Analysis and Socio-Technical Networks | 10.1145/3555129 | |||||
17 | BFEMKQCR | journalArticle | 2014 | Gamalielsson, Jonas; Lundell, Björn | Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved? | https://doi.org/10.1016/j.jss.2013.11.1077 | |||||
18 | FJSA37EW | journalArticle | 2021 | Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, Ferdian | When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems | 10.1145/3447245 | |||||
19 | 72F8GVAP | journalArticle | 2025 | Jahanshahi, Mahmoud; Reid, David; Mockus, Audris | Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development | 10.1145/3715907 | |||||
20 | QEKG8ISF | journalArticle | 2016 | Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, Danny | ASE - Usage, costs, and benefits of continuous integration in open-source projects | 10.1145/2970276.2970358 | |||||
21 | ZGK4HR76 | journalArticle | 2015 | Vendome, Christopher; Linares-Vasquez, Mario; Bavota, Gabriele; Di Penta, Massimiliano; German, Daniel M.; Poshyvanyk, Denys | ICSME - When and why developers adopt and change software licenses | 10.1109/icsm.2015.7332449 | |||||
22 | PSZSSAS3 | journalArticle | 2017 | Ding, Hui; Ma, Wanwangying; Chen, Lin; Zhou, Yuming; Xu, Baowen | APSEC - An Empirical Study on Downstream Workarounds for Cross-Project Bugs | 10.1109/apsec.2017.38 | |||||
23 | V3F8FYG5 | journalArticle | 2018 | Meloca, Rômulo; Pinto, Gustavo; Baiser, Leonardo; Mattos, Marco; Polato, Ivanilton; Wiese, Igor; German, Daniel M. | Understanding the usage, impact, and adoption of non-OSI approved licenses | 10.1145/3196398.3196427 | Organizational / procedural-- adoption of non OSI approved licenses or change to OSI-approved license --- the majority of the changes in either direction were from the adoption or deletion of a license (which happened to be OSI compliant) --- RQ3 provides naivete or lack of care for reasoning for moves into non-approved licenses | OSS package publishers --- some of whom have published packages with non-OSI approved licenses | governing body --- OSI is an open source regulator, vets the software license to make sure that it’s either open source or not --Also looking at compliance within three well-known open source libraries: NPM, RubyGems and CRAN; these enviroments are kinda nested within the focal environment, compliance in terms of sync with dependencies --- check of ‘success’ or anything: majority of the time, surveyed developers are not checking whether the different licenses they select are conforming, or adhering to anything | Mixed-methods: mining packages from the three different package manager environments -- pulled down a bunch of package data from the different ecosystems and looked through their license change over specified versions: a survey with the publishers of the package. sampled from NPM. open responses were qualitatively coded by pairs of researchers | not happy with the way that the different segments of the project are conflated with each other --- what use is the response of developers who use specific non-compliant licenses when the majority of non-compliance evolution is deletion or lack of license? --- different sets of populations between different methods sections of the research --- “developers might not fully understand the effect of the adaptive action that they’re taking” --- contributors ‘dont care; about the licenses they use |
24 | 6AQY86BW | journalArticle | 2022 | Businge, John; Openja, Moses; Nadi, Sarah; Berger, Thorsten | Reuse and maintenance practices among divergent forks in three software ecosystems | 10.1007/s10664-021-10078-2 | |||||
25 | YJREPLGY | journalArticle | 2023 | Venturini, Daniel; Cogo, Filipe Roseiro; Polato, Ivanilton; Gerosa, Marco A.; Wiese, Igor Scaliante | I Depended on You and You Broke Me: An Empirical Study of Manifesting Breaking Changes in Client Packages | 10.1145/3576037 | |||||
26 | QIVH9LJG | journalArticle | 2017 | Abdalkareem, Rabe; Nourry, Olivier; Wehaibi, ; Mujahid, Suhaib; Shihab, Emad | Why do developers use trivial packages? an empirical case study on npm | 10.1145/3106237.3106267 | technical: code reuse: trivial package reuse: rationale – trivial packages provide well-implemented and tested code from the packaging ecosystem: enables adherence to the quality testing of the broader ecosystem | application developers; professional JS developers; many long-tenured | package management systems: npm – node.js; change adheres project to well-tested and implemented environment; there are a lot of trivial packages; no project evaluation of change ‘success’ wrt environment | mixed methods: pilot survey – data mining – follow up survey – data mining to validate survey responses: sampling from prior methods step: skews to university; survey free-response answers were analyzed with qualitative coding – grounded theory methods | internal motivations for productiivty: many also stated that reuse was bad: developers aware that the change may represent existential risk for themselves; in adapting may also introduce more threats |
27 | TFDYF5UM | journalArticle | 2011 | Capiluppi, Andrea; Stol, Klaas-Jan; Boldyreff, Cornelia | Software Reuse in Open Source: A Case Study | 10.4018/jossp.2011070102 | |||||
28 | XDY5INZ6 | conferencePaper | 2018 | Lotter, Adriaan; Licorish, Sherlock A.; Savarimuthu, Bastin Tony Roy; Meldrum, Sarah | Code Reuse in Stack Overflow and Popular Open Source Java Projects | 10.1109/ASWEC.2018.00027 | |||||
29 | MBVCDT66 | journalArticle | 2023 | He, Runzhi; He, Hao; Zhang, Yuxia; Zhou, Minghui | Automating Dependency Updates in Practice: An Exploratory Study on GitHub Dependabot | 10.1109/TSE.2023.3278129 | organizational/procedural -- adoption of dependabot--- stated rationale: managing project dependencies --- specifically, keeping project dependencies up to date --- | OSS developers for projects that have adopted dependabot --- specifically, developers who are likely to be familiar with dependabot and its workings | GitHub ---- specifically the projects on GitHub but often, the platform itself structures the environment that projects operate in --- also dependency networks, the reasoning why dependabot is used is for projects to align better with the dependencies that they’re reliant on | mixed-methods, EDA and a developer survey --- from a sample of 1823 projects, mining the PRs made by Dependabot with a survey of the projects’ developers (n131)--- sampled for the survey from the projects that were identified in the mining scenario -- a lot of researcher selection in finding maintainers who are likely to be familiar with it | a lot of analysis on whether or not adopting dependabot works, like whether the thing that people are doing to adapt is… actually working… even though dependabot is not that useful for automatic updates, many developers believe that it is useful for notifying updates |
30 | DGV2UJNM | conferencePaper | 2020 | Zhou, Shurui; Vasilescu, Bogdan; Kästner, Christian | How has forking changed in the last 20 years? a study of hard forks on GitHub | 10.1145/3377811.3380412 | |||||
31 | QLSEMWTQ | journalArticle | 2017 | Vendome, Christopher; Bavota, Gabriele; Penta, Massimiliano Di; Linares-Vásquez, Mario; German, Daniel; Poshyvanyk, Denys | License usage and changes: a large-scale study on gitHub | 10.1007/s10664-016-9438-4 | |||||
32 | 5E2EWRQN | journalArticle | 2020 | Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, Emad | On the impact of using trivial packages: an empirical case study on npm and PyPI | 10.1007/s10664-019-09792-9 | technical: code reuse: trivial package reuse: rationale – trivial packages provide well-implemented and tested code from the packaging ecosystem: enables adherence to the quality testing of the broader ecosystem | application developers: long-tenured JS and Python coders: largely professional but some independents | package managemeny systems: npm and PyPI: change adheres project to well-tested and implemented environment: no project evaluation of change ‘success’ wrt environment | mixed methods: pilot survey – data mining – follow up survey – data mining to validate survey responses: sampling from prior methods step: skews to university | internal motivations for productiivty: many also stated that reuse was bad: paper spends a lot of time defining trivial packages |
33 | P3MTJWXP | conferencePaper | 2022 | Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, Huaimin | Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism | 10.1145/3491102.3501822 | procedural/organizational: developer adoption and participation in the GitHub sponsors program --- rationale for adopting the sponsorship model: I should be rewarded or recognized for my OSS work | OSS developers, but not necessarily those with big commits or key contributions, the popular ones who work on big projects | GitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the project’s activity are restricted by GitHub as a platform --- to what extent is broader social environment (intrinsic desire for payment) also the environment here? | mixed-methods -- both data mining and survey; quantitative data mining of different sponsorship events within GitHub --- pulling a lot of data on the individual sponsorships and the sponsoring events --- statistic modeling (lmer) of maintainer/contributor balance etc.; Sampling from the data mining to identify the relevant population.; qualitative already with a questionnaire about the why and what questions. -- survey looked up the expectations and rationales for using the sponsor feature ; two-stage survey | again a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didn’t hold up!; configurable adaptations more throughout this, not the first paper that discusses this; environment (GitHub) is incredibly deterministic in establishing who adapts/adopts the feature --- instead of being an amorphous social pressure or anything like that --- it is a platform trying to get you to use their most recent feature; intersection of rationales for doing things sit at the intersection of intrinsic and extrinsic motivations |
34 | DW9Q2W6V | conferencePaper | 2022 | Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, Coen | Variant Forks - Motivations and Impediments | 10.1109/SANER53432.2022.00105 | |||||
35 | 3Y9YKK5M | conferencePaper | 2011 | Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, Maximilian | On the Extent and Nature of Software Reuse in Open Source Java Projects |