mgaughan/adaptation-slr
1
0
Fork 0
Code

updating with 20/34

Browse Source
This commit is contained in:
mgaughan 2025-07-19 15:57:42 -04:00
parent 21d533d6f1
commit 2513e718f3
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
070725_papers_master.csv
View File

@ -13,16 +13,16 @@ XPC3Y8HH,journalArticle,2020,"Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn
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,,,,,
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,,,,,
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"
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,,,,,
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,"Procedural – discussion of governance in OSS projects ---- measured through identiification of Institutional Statements within Apache-incubator projects --- more functional-based discussions around IS statements precedes graduation from ASFI\*. more IS discussion in general precedes increased activity; more governance discussion from mentors (ASFI proxies) precedes engagement with the project. *However, without more robust description of the interpretation of the LDA topics, I have a bit of skepticism around this. There are other notes about evolution with regards to attracting contributors and setting up contributions, but that’s secondary to the adaptation discussion.","stakeholder agents for the OSS projects within ASFI (committers, contributors, mentors). Different than contributor or maintainer because the role of mentor is rather bespoke in this environment.","Apache Software Foundation incubator and graduation from the environment “Those having foundation support, like the ASF, may additionally be in the process of organizing the developers’ structured interactions under a second tier of governance prescriptions as required by the ASF Incubator.” ([Yin et al., 2022, p. 4]","quantitative ---- computationally modeling institutional norms and rules from OSS communications as well as socio-technical collaboration records; collecting data for both historical development activity such as commits and communications as well as project-level discussions regarding mailing list discussions creating a socio-technical network of collaboration for the different projects fine-tuning a BERT classifier to identify institutional statements with the ASF-specific language from different things; with this longitudinal data, they use Granger causality to identify “causal links” of different things. Limitations using granger causality when evaluating cause and effect; some discussed in RQ3 results","longstanding gripes about the generalizeability of ASF studies --- the isomorphic pressure is, I think, too big for any takeaway to be meaningfully transferred to other settings --- ;like this oper The ASFI can have mentors that represent the desires (re: fit) of the environment more broadly, directly adapting the focal project to the envrionment;s wants"
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,"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,"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 ,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
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,,,,,
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,,,,,
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,,,,,
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,"technical -- code reuse from Stack Overflow within popular Java OSS projects--  rationale is copying from stackoverflow or other popular projects, which inherently increases technical fit with the environment --- disregarding within project copying, that is almost a meaningless metric copying between projects is larger (in size of code segment that’s copied over) and may be more prevalent?",OSS project developers for popular/well-regarded projects -- I guess this action is also at the developer/contributor level.,"The most popular Java OSS projects on SourceForge and GitHub --- in 2017, which projects had the highest weekly popularity and contained requisite Java code or, alternatively, the projects that had the highest popularity on SourceForge; Also looking at all Java StackOverflow comments from 2014-2017. pulling out the code snippets from these answers","quantitative repo mining from Stack Overflow and most popular Java projects --- focusing on weekly and all-time popularity for GitHub and SourceForge metrics --- used near-OTS code reuse identification software changing parameters for a few things ; reliant on syntax and token similarity, not AST for analysis","paper finger wags about code reuse the whole time, discussing how it’s not a good practice. Adaptive change can lead to adherence to substandard environmental norms. Seems like code reuse from Stack Overflow isn’t even that prevalent? Not a very good paper honestly; never discusses when the code was reused within or in which direction --- it’s cross sectional data!! How can you even make an argument surrounding copying, which is a time-dependent action!"

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
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 Procedural – discussion of governance in OSS projects ---- measured through identiification of Institutional Statements within Apache-incubator projects --- more functional-based discussions around IS statements precedes graduation from ASFI\*. more IS discussion in general precedes increased activity; more governance discussion from mentors (ASFI proxies) precedes engagement with the project. *However, without more robust description of the interpretation of the LDA topics, I have a bit of skepticism around this. There are other notes about evolution with regards to attracting contributors and setting up contributions, but that’s secondary to the adaptation discussion. stakeholder agents for the OSS projects within ASFI (committers, contributors, mentors). Different than contributor or maintainer because the role of mentor is rather bespoke in this environment. Apache Software Foundation incubator and graduation from the environment “Those having foundation support, like the ASF, may additionally be in the process of organizing the developers’ structured interactions under a second tier of governance prescriptions as required by the ASF Incubator.” ([Yin et al., 2022, p. 4] quantitative ---- computationally modeling institutional norms and rules from OSS communications as well as socio-technical collaboration records; collecting data for both historical development activity such as commits and communications as well as project-level discussions regarding mailing list discussions creating a socio-technical network of collaboration for the different projects fine-tuning a BERT classifier to identify institutional statements with the ASF-specific language from different things; with this longitudinal data, they use Granger causality to identify “causal links” of different things. Limitations using granger causality when evaluating cause and effect; some discussed in RQ3 results longstanding gripes about the generalizeability of ASF studies --- the isomorphic pressure is, I think, too big for any takeaway to be meaningfully transferred to other settings --- ;like this oper The ASFI can have mentors that represent the desires (re: fit) of the environment more broadly, directly adapting the focal project to the envrionment;s wants
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 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 Scientific python dependency ecosystem 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
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
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 technical -- code reuse from Stack Overflow within popular Java OSS projects--  rationale is copying from stackoverflow or other popular projects, which inherently increases technical fit with the environment --- disregarding within project copying, that is almost a meaningless metric copying between projects is larger (in size of code segment that’s copied over) and may be more prevalent? OSS project developers for popular/well-regarded projects -- I guess this action is also at the developer/contributor level. The most popular Java OSS projects on SourceForge and GitHub --- in 2017, which projects had the highest weekly popularity and contained requisite Java code or, alternatively, the projects that had the highest popularity on SourceForge; Also looking at all Java StackOverflow comments from 2014-2017. pulling out the code snippets from these answers quantitative repo mining from Stack Overflow and most popular Java projects --- focusing on weekly and all-time popularity for GitHub and SourceForge metrics --- used near-OTS code reuse identification software changing parameters for a few things ; reliant on syntax and token similarity, not AST for analysis paper finger wags about code reuse the whole time, discussing how it’s not a good practice. Adaptive change can lead to adherence to substandard environmental norms. Seems like code reuse from Stack Overflow isn’t even that prevalent? Not a very good paper honestly; never discusses when the code was reused within or in which direction --- it’s cross sectional data!! How can you even make an argument surrounding copying, which is a time-dependent action!