mgaughan/adaptation-slr
1
0
Fork 0
Code

33/34

Browse Source
This commit is contained in:
mgaughan 2025-07-29 20:32:00 -04:00
parent 75e9b1602c
commit f387493d42
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

@ -21,7 +21,7 @@ QEKG8ISF,journalArticle,2016,"Hilton, Michael; Tunnell, Timothy; Huang, Kai; Mar
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,"Technical – downstream workarounds from errors and bugs and undesirable method behavior introduced by upstream dependencies -- common workaround per prior literature -- workarounds fall into four common patterns: using a different method, wrapping the current method in a conditional per input, augmenting input to match method, augmenting method output to match downstream ",OSS project developers of downstream scientific python libraries on GitHub ,"packaging ecosystems, Scientific python dependency ecosystem on GitHub",mixed-methods; though statistical methods were used in evaluating hypotheses or finding differences in the workarounds; manual methods were used for cross-project bugs with workarounds in the first place as well as some characterization of the bugs ,the short-term adaptations are meaningfully different than the long-term fixes across the environment there’s a lot of similarity in the kinds of cross-project bugs that run into this problem/adaptation --- often when the downstream project encounters an emergent case that is untested by the upstream repository
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
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,,,,,
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,"technical - maintenance of reused software in variant forks of software projects; little active upkeep/code propogation in mainline-fork pairs in the three ecosystems that were studied. “The most used code propagation technique is git merge/rebase that is used in 33 % of Android mainline-fork pairs, 11 % of JavaScript pairs, and 18 % of .NET pairs.” ([Businge, 2022, p. 3](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=3&annotation=8ZBR7I8S)) \--- still not much in comparison to the rest of the thing; merge is the primary activity, with rebase and others less common; variant forks are consistently reaffirmed as variant through the continual publishing of distinct packages and separate code; no one is using the social coding mechanisms of GitHub to send changes up OR downstream; the PR-integration is lacking, though variant fork maintainers do send it more up than mainline sends down; There are also very few direct merge/rebase edits; though the ones that are there are often mainline -> fork changes. this is the most used code maintenance tool out of the three that were studied by the paper","maintainers of variants within software families, either as the mainline variant or the forked derivative with the upkeep of ‘downstream’ variant forks of the mainline project again, though the actions of the contributors are somewhat subsumed to the broader analysis of the ecosystem and the project; by not naming the variant maintainer, the labor of that maintainer is lost “We present the results of code propagation between family variants in terms of propagated commits, while differentiating the propagation mechanisms we explained in Sections 2 and 3.3.” ([Businge, 2022, p. 27](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=27&annotation=MGPHUZ3Q)) \--- this is actually talking about actions that maintainers are taking, whcih takes up time and effort","the “software family” the ecosystem of forks and dependencies of similar software across different projects; specifically looking at the environmental relationship between a mainline project and a divergent derivative fork   The vast majority of these families only have two projects in it; one mainline and one derivative. There are some more larger ones in JS but by-and-large, the variant families are pretty small! often the variant forks are popular -- but hte mainlines are still more popular, whcih makes sense; given that the mainline is the primary Though these are all families of like-purposed software libraries, they are pretty variable between different projects.","quantitative -- software mining across repositories  in Android, .Net, and JavaScript on GitHub Android: 38 software families with 54 forked apps; looked for Android apps that also had a listing on Google Play .Net: 526 software families with 590 mainline-fork pairs JavaScript: 8837 software families with 10,357 mainline fork pairs Using a platform external to GitHub to identify whether or not the fork is divergent or social Looking at environment characteristics -     family size, how many variant forks - dependencies , number of dependencies wthin each family - Other characteristics for Android Looking at maintenance activities (only for JavaScript and .NET) popularity metrics were largely derived from application or package downloads across different settings maintenance:     to ID code propagation, categorizing commits according to the different propagation actions","Interesting, direct integration is used more than Git “An earlier version of this work appeared as a conference paper (Businge et al. 2018).” ([Businge, 2022, p. 4](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=4&annotation=Q77PWHPW)) \-- this is the more comprehensive and fleshed out journal version Not entirely equivalent across the different ecosystems that were studied. e.g. Android maintenance activities were not evaluated. Interesting that some variant forks have the same owner as the mainline repository. goes into deep specificity about testing a specific kind of edge case for their comparison script, which is good, I guess"
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,"Technical – rectification of breaking changes introduced to client packages in npm by provider packages; in general, the provider fixes the breaking change in a subsequent minor or patch release --- so the adaptive action is to kind of… wait and request that the thing is changed. ( on average, in 7 days)--- when the client does adapt to address the breaking change --- sometime clients downgrade to get out of the breaking change",OSS maintainers/contributors to the downstream repository whose functionality is broken because of the upstream dependency change,"dependency ecosystems/package management systems, specifically -- the proliferation of breaking changes across the dependency ecosystem ; the dependency network is the environment but the breaking change is the antecedent cause specifically, the project looks at changes and adaptation within the npm packaging ecosystem  --- npm is the primary package manager for JavaScript, with more than 1 million packages",mixed-methods; repository mining and statistical modeling of build changes in the npm ecosystem and then qualitative validation of breaking changes and the client packages’ adaptation to them. ,"“Client packages recovered manifesting breaking changes in 39.1% of cases, including clients and transitive providers.” ([Venturini, 2023, p. 20] This actually seems almost impossibly low, what do you mean it recovers in 39.1% of cases? Shouldn't it be recovering in like... all cases? ++ primarily looking at the environmental antecedent as the objects of study rather than the adaptation as the objects of study"
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
TFDYF5UM,journalArticle,2011,"Capiluppi, Andrea; Stol, Klaas-Jan; Boldyreff, Cornelia",Software Reuse in Open Source: A Case Study,10.4018/jossp.2011070102,"technical - software reuse of FFMpeg components either through static or dynamic linking. --- only components, not the entire project","OSS contributors of projects that are reusing components of FFmpeg -- however, these contributors are hardly interrogated, identified, or named. Instead they are abstracted away from --- rather their actions are given primacy",projects that can use things from the FFmpeg project--- that have functionality adjacent enough to the project to make sense to copy; FFMpeg and its popularity is the environment that projects are optimizing their fit to ,"quantitative, descriptive case study -- mining projects for theFFMpeg components across their code base collected longitudinal snapshots of FFmpeg over months, got 100 data points then connected links to other uses of those components NO mention of looking at the other OSS systems that utilize the copied library? Or if it does do this, there’s little mention across the methods section","Other software reuse papers have argued against the practice as being bad --- this one argues for it! gets way too in the weeds with its work, ends up just being muddled by the middle of the results section maybe getting out over their skis in terms of identifying the different quality of build components within the system Just not a very good paper, poor communication of its methods and overly ambitious claims within its findings the actor is minimized, loses agency in the paper on this"

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
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 Technical – downstream workarounds from errors and bugs and undesirable method behavior introduced by upstream dependencies -- common workaround per prior literature -- workarounds fall into four common patterns: using a different method, wrapping the current method in a conditional per input, augmenting input to match method, augmenting method output to match downstream OSS project developers of downstream scientific python libraries on GitHub packaging ecosystems, Scientific python dependency ecosystem on GitHub mixed-methods; though statistical methods were used in evaluating hypotheses or finding differences in the workarounds; manual methods were used for cross-project bugs with workarounds in the first place as well as some characterization of the bugs the short-term adaptations are meaningfully different than the long-term fixes across the environment there’s a lot of similarity in the kinds of cross-project bugs that run into this problem/adaptation --- often when the downstream project encounters an emergent case that is untested by the upstream repository
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 technical - maintenance of reused software in variant forks of software projects; little active upkeep/code propogation in mainline-fork pairs in the three ecosystems that were studied. “The most used code propagation technique is git merge/rebase that is used in 33 % of Android mainline-fork pairs, 11 % of JavaScript pairs, and 18 % of .NET pairs.” ([Businge, 2022, p. 3](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=3&annotation=8ZBR7I8S)) \--- still not much in comparison to the rest of the thing; merge is the primary activity, with rebase and others less common; variant forks are consistently reaffirmed as variant through the continual publishing of distinct packages and separate code; no one is using the social coding mechanisms of GitHub to send changes up OR downstream; the PR-integration is lacking, though variant fork maintainers do send it more up than mainline sends down; There are also very few direct merge/rebase edits; though the ones that are there are often mainline -> fork changes. this is the most used code maintenance tool out of the three that were studied by the paper maintainers of variants within software families, either as the mainline variant or the forked derivative with the upkeep of ‘downstream’ variant forks of the mainline project again, though the actions of the contributors are somewhat subsumed to the broader analysis of the ecosystem and the project; by not naming the variant maintainer, the labor of that maintainer is lost “We present the results of code propagation between family variants in terms of propagated commits, while differentiating the propagation mechanisms we explained in Sections 2 and 3.3.” ([Businge, 2022, p. 27](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=27&annotation=MGPHUZ3Q)) \--- this is actually talking about actions that maintainers are taking, whcih takes up time and effort the “software family” the ecosystem of forks and dependencies of similar software across different projects; specifically looking at the environmental relationship between a mainline project and a divergent derivative fork   The vast majority of these families only have two projects in it; one mainline and one derivative. There are some more larger ones in JS but by-and-large, the variant families are pretty small! often the variant forks are popular -- but hte mainlines are still more popular, whcih makes sense; given that the mainline is the primary Though these are all families of like-purposed software libraries, they are pretty variable between different projects. quantitative -- software mining across repositories  in Android, .Net, and JavaScript on GitHub Android: 38 software families with 54 forked apps; looked for Android apps that also had a listing on Google Play .Net: 526 software families with 590 mainline-fork pairs JavaScript: 8837 software families with 10,357 mainline fork pairs Using a platform external to GitHub to identify whether or not the fork is divergent or social Looking at environment characteristics -     family size, how many variant forks - dependencies , number of dependencies wthin each family - Other characteristics for Android Looking at maintenance activities (only for JavaScript and .NET) popularity metrics were largely derived from application or package downloads across different settings maintenance:     to ID code propagation, categorizing commits according to the different propagation actions Interesting, direct integration is used more than Git “An earlier version of this work appeared as a conference paper (Businge et al. 2018).” ([Businge, 2022, p. 4](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=4&annotation=Q77PWHPW)) \-- this is the more comprehensive and fleshed out journal version Not entirely equivalent across the different ecosystems that were studied. e.g. Android maintenance activities were not evaluated. Interesting that some variant forks have the same owner as the mainline repository. goes into deep specificity about testing a specific kind of edge case for their comparison script, which is good, I guess
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 Technical – rectification of breaking changes introduced to client packages in npm by provider packages; in general, the provider fixes the breaking change in a subsequent minor or patch release --- so the adaptive action is to kind of… wait and request that the thing is changed. ( on average, in 7 days)--- when the client does adapt to address the breaking change --- sometime clients downgrade to get out of the breaking change OSS maintainers/contributors to the downstream repository whose functionality is broken because of the upstream dependency change dependency ecosystems/package management systems, specifically -- the proliferation of breaking changes across the dependency ecosystem ; the dependency network is the environment but the breaking change is the antecedent cause specifically, the project looks at changes and adaptation within the npm packaging ecosystem  --- npm is the primary package manager for JavaScript, with more than 1 million packages mixed-methods; repository mining and statistical modeling of build changes in the npm ecosystem and then qualitative validation of breaking changes and the client packages’ adaptation to them. “Client packages recovered manifesting breaking changes in 39.1% of cases, including clients and transitive providers.” ([Venturini, 2023, p. 20] This actually seems almost impossibly low, what do you mean it recovers in 39.1% of cases? Shouldn't it be recovering in like... all cases? ++ primarily looking at the environmental antecedent as the objects of study rather than the adaptation as the objects of study
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 technical - software reuse of FFMpeg components either through static or dynamic linking. --- only components, not the entire project OSS contributors of projects that are reusing components of FFmpeg -- however, these contributors are hardly interrogated, identified, or named. Instead they are abstracted away from --- rather their actions are given primacy projects that can use things from the FFmpeg project--- that have functionality adjacent enough to the project to make sense to copy; FFMpeg and its popularity is the environment that projects are optimizing their fit to quantitative, descriptive case study -- mining projects for theFFMpeg components across their code base collected longitudinal snapshots of FFmpeg over months, got 100 data points then connected links to other uses of those components NO mention of looking at the other OSS systems that utilize the copied library? Or if it does do this, there’s little mention across the methods section Other software reuse papers have argued against the practice as being bad --- this one argues for it! gets way too in the weeds with its work, ends up just being muddled by the middle of the results section maybe getting out over their skis in terms of identifying the different quality of build components within the system Just not a very good paper, poor communication of its methods and overly ambitious claims within its findings the actor is minimized, loses agency in the paper on this