mgaughan/adaptation-slr
1
0
Fork 0
Code

10/34

Browse Source
This commit is contained in:
mgaughan 2025-07-11 15:49:28 -04:00
parent f4cc5b26c5
commit c37ed9aaa8
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
070725_papers_master.csv
View File

@ -17,7 +17,7 @@ WE8VYWEX,journalArticle,2021,"Geiger, R. Stuart; Howard, Dorothy; Irani, Lilly",
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,,,,,
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,,,,,
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,,,,,
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,,,,,
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,"Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability","OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds",OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that ,"mixed-methods: mining open source projects from GitHub while also surveying developers from popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects",he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems
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,Procedural – license changes within OSS projects --- the change event is the real adaptation action; rationale for commercial reuse is also a motivating factor ,"OSS maintainers (Java, on GitHub) who change the license --- oftentimes this is a copyright holder or primary core contirbutor of the project ","nebulous environment of commercial reuse, ‘community’, and user base --- there’s also discussion around the role that changes to the broader dependency network play in the structure of the project and changes to the license",Mixed-methods; mining 16k java open source projects and their commits and then supplemented with survey study of 138 developers; sample of developers surveyed are from the trace data of the mined project actions --- specifically looking to identify projects that had shifted over time with regard to licensing,many of the intitial decisions and adaptations were motivated from a range of intrinsic and extrinsic motivations
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,,,,,
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

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
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 Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that mixed-methods: mining open source projects from GitHub while also surveying developers from popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems
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 Procedural – license changes within OSS projects --- the change event is the real adaptation action; rationale for commercial reuse is also a motivating factor OSS maintainers (Java, on GitHub) who change the license --- oftentimes this is a copyright holder or primary core contirbutor of the project nebulous environment of commercial reuse, ‘community’, and user base --- there’s also discussion around the role that changes to the broader dependency network play in the structure of the project and changes to the license Mixed-methods; mining 16k java open source projects and their commits and then supplemented with survey study of 138 developers; sample of developers surveyed are from the trace data of the mined project actions --- specifically looking to identify projects that had shifted over time with regard to licensing many of the intitial decisions and adaptations were motivated from a range of intrinsic and extrinsic motivations
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