1
0
adaptation-slr/070725_papers_master.csv
2025-07-10 22:17:16 -04:00

18 KiB
Raw Blame History

1KeyItem TypePublication YearAuthorTitleDOIChange characteristics (blue)Actors (purple)Environmental characteristics (green)Methods details (orange)Misc. (red)
2LB5MEY9SjournalArticle2017Norskov, Sladjana; Kesting, Peter; Ulhoi, John ParmDeliberate change without hierarchical influence? The case of collaborative OSS communities10.1108/IJOA-08-2016-1050
3KUWLMFWMjournalArticle2017Santos, Carlos Denner D60osChanges in free and open source software licenses: managerial interventions and variations on project attractiveness10.1186/s13174-017-0062-3
4SJEI288CconferencePaper2024Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, ChrisAn Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software10.1145/3674805.3686692technical 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 GDPROSS 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 themesdevelopers 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
5U7U4YLVBjournalArticle2023Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi"Nip it in the Bud": Moderation Strategies in Open Source Software Projects and the Role of Bots10.1145/3610092
6M6PP5MPQconferencePaper2011Jensen, Chris; Scacchi, WaltLicense Update and Migration Processes in Open Source Software Projectshttps://doi.org/10.1007/978-3-642-24418-6_12
7ENQ5AACFjournalArticle2022Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, DirkManaging Episodic Volunteers in Free/Libre/Open Source Software Communities10.1109/TSE.2020.2985093
8RN5Y3TN5conferencePaper2020Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A.What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers10.1145/3422392.3422459organizational/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 codeOSS 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 increasedqualitative 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 themesa 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
9HS8AQN5VjournalArticle2010Sojer, Manuel; Henkel, JoachimCode Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments10.17705/1jais.00248
10GGZV58MQjournalArticle2021Klug, Daniel; Bogart, Christopher; Herbsleb, James D."They Can Only Ever Guide": How an Open Source Software Community Uses Roadmaps to Coordinate Effort10.1145/3449232
11JL6YZE5SjournalArticle2023Hu, Jin; Hu, Daning; Yang, Xuan; Chau, MichaelThe impacts of lockdown on open source software contributions during the COVID-19 pandemic10.1016/j.respol.2023.104885
12XPC3Y8HHjournalArticle2020Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn; Brax, Christoffer; Mattsson, Anders; Gustaysson, Tomas; Feist, Jonas; Lonroth, ErikMaintaining interoperability in open source software: A case study of the Apache PDFBox project10.1016/j.jss.2019.110452
134V42NWTTjournalArticle2016Adams, Bram; Kavanagh, Ryan; Hassan, Ahmed E.; German, Daniel M.An empirical study of integration activities in distributions of open source software10.1007/s10664-015-9371-y
14MVGUFG8PconferencePaper2016Crowston, Kevin; Shamshurin, IvanCore-Periphery Communication and the Success of Free/Libre Open Source Software Projects10.1007/978-3-319-39225-7_4
15WE8VYWEXjournalArticle2021Geiger, R. Stuart; Howard, Dorothy; Irani, LillyThe Labor of Maintaining and Scaling Free and Open-Source Software Projects10.1145/3449249organizational/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 its 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 tooenvironment 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: NAqualitative 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
163F7CJATBjournalArticle2022Yin, Likang; Chakraborti, Mahasweta; Yan, Yibo; Schweik, Charles; Frey, Seth; Filkov, VladimirOpen Source Software Sustainability: Combining Institutional Analysis and Socio-Technical Networks10.1145/3555129
17BFEMKQCRjournalArticle2014Gamalielsson, Jonas; Lundell, BjörnSustainability 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
18FJSA37EWjournalArticle2021Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, FerdianWhen and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems10.1145/3447245
1972F8GVAPjournalArticle2025Jahanshahi, Mahmoud; Reid, David; Mockus, AudrisBeyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development10.1145/3715907
20QEKG8ISFjournalArticle2016Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, DannyASE - Usage, costs, and benefits of continuous integration in open-source projects10.1145/2970276.2970358
21ZGK4HR76journalArticle2015Vendome, Christopher; Linares-Vasquez, Mario; Bavota, Gabriele; Di Penta, Massimiliano; German, Daniel M.; Poshyvanyk, DenysICSME - When and why developers adopt and change software licenses10.1109/icsm.2015.7332449
22PSZSSAS3journalArticle2017Ding, Hui; Ma, Wanwangying; Chen, Lin; Zhou, Yuming; Xu, BaowenAPSEC - An Empirical Study on Downstream Workarounds for Cross-Project Bugs10.1109/apsec.2017.38
23V3F8FYG5journalArticle2018Meloca, 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 licenses10.1145/3196398.3196427Organizational / 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 licensesOSS 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 its 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 anythingMixed-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 theyre taking” --- contributors dont care; about the licenses they use
246AQY86BWjournalArticle2022Businge, John; Openja, Moses; Nadi, Sarah; Berger, ThorstenReuse and maintenance practices among divergent forks in three software ecosystems10.1007/s10664-021-10078-2
25YJREPLGYjournalArticle2023Venturini, Daniel; Cogo, Filipe Roseiro; Polato, Ivanilton; Gerosa, Marco A.; Wiese, Igor ScalianteI Depended on You and You Broke Me: An Empirical Study of Manifesting Breaking Changes in Client Packages10.1145/3576037
26QIVH9LJGjournalArticle2017Abdalkareem, Rabe; Nourry, Olivier; Wehaibi, ; Mujahid, Suhaib; Shihab, EmadWhy do developers use trivial packages? an empirical case study on npm10.1145/3106237.3106267technical: 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 ecosystemapplication developers; professional JS developers; many long-tenuredpackage 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 environmentmixed 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 methodsinternal 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
27TFDYF5UMjournalArticle2011Capiluppi, Andrea; Stol, Klaas-Jan; Boldyreff, CorneliaSoftware Reuse in Open Source: A Case Study10.4018/jossp.2011070102
28XDY5INZ6conferencePaper2018Lotter, Adriaan; Licorish, Sherlock A.; Savarimuthu, Bastin Tony Roy; Meldrum, SarahCode Reuse in Stack Overflow and Popular Open Source Java Projects10.1109/ASWEC.2018.00027
29MBVCDT66journalArticle2023He, Runzhi; He, Hao; Zhang, Yuxia; Zhou, MinghuiAutomating Dependency Updates in Practice: An Exploratory Study on GitHub Dependabot10.1109/TSE.2023.3278129organizational/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 workingsGitHub ---- 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 theyre reliant onmixed-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 ita 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
30DGV2UJNMconferencePaper2020Zhou, Shurui; Vasilescu, Bogdan; Kästner, ChristianHow has forking changed in the last 20 years? a study of hard forks on GitHub10.1145/3377811.3380412
31QLSEMWTQjournalArticle2017Vendome, Christopher; Bavota, Gabriele; Penta, Massimiliano Di; Linares-Vásquez, Mario; German, Daniel; Poshyvanyk, DenysLicense usage and changes: a large-scale study on gitHub10.1007/s10664-016-9438-4
325E2EWRQNjournalArticle2020Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, EmadOn the impact of using trivial packages: an empirical case study on npm and PyPI10.1007/s10664-019-09792-9technical: 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 ecosystemapplication developers: long-tenured JS and Python coders: largely professional but some independentspackage 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
33P3MTJWXPconferencePaper2022Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, HuaiminWho, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Githubs Sponsor Mechanism10.1145/3491102.3501822procedural/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 projectsGitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the projects 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 surveyagain a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didnt 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
34DW9Q2W6VconferencePaper2022Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, CoenVariant Forks - Motivations and Impediments10.1109/SANER53432.2022.00105
353Y9YKK5MconferencePaper2011Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, MaximilianOn the Extent and Nature of Software Reuse in Open Source Java Projects