mgaughan/adaptation-slr
1
0
Fork 0
Code

24/34

Browse Source
This commit is contained in:
mgaughan 2025-07-22 11:50:50 -04:00
parent 154eadda62
commit 0b8e944a41
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
070725_papers_master.csv
View File

@ -11,7 +11,7 @@ GGZV58MQ,journalArticle,2021,"Klug, Daniel; Bogart, Christopher; Herbsleb, James
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,procedural (LoD at individual contributor) --- contributions devoted to OSS projectss -- the rationale between increases or decreases in contribution activity was adaptation to fear and time availability surrounding Covid-19 and the lockdown in China ,"OSS contributors in Wuhan and Xian -- GitHub location within the regions selected; contributions are broad contributions to any project, not project-specific ;validation set looking at OSS developers in specific states in the US",geopolitical; Covid-19 pandemic- initiated lockdowns in China and the united states. Lockdown (environmental) characteristics are directly informed by the regime’s approach to Covid mitigation and management.,"mixed-methods; repository mining supplemented with survey study; primarily looking at commits s contributions; using difference-in-difference models to try to model the absence of F2F interactions, as such interactions are important motivators for contributors; survey study sampled from developers impacted by the two lockdowns that were studied-- specifically, sampled from the developers in the results from the mining","interesting sampling notes regarding prevalence of things in different geographies – using geographic proximity to establish matched pairs/similarity in the different cases; environmental factors were seemingly deterministic in the shape of the adaptations; not actually at the project-level, instead looking at contributions devoted to OSS projects, but the unit of analysis if the developer (maybe a note on the frailty of constraining the unit of analysis to project or individual level and the flexibility required to move between those in a thoughtful way)"
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,technical - actions to maintain interoperability --- decisions fall into four types: improve to match de facto reference implementation;  degrade to match the de facto reference implementation; improve to match standard; scope of implementation,"OSS contributors,maintainers and community of the ASF’s PDFBox --- the nature of the work varies for each of these contributor archetypes, many of the higher-level discussions surrounding different technical changes recess into the Apache way of organizing OSS work --- core developers take a front-and-center role in managing different types of changes with different rationales","two environments at play here; the putative standard of interoperability an the de-facto reference implementation of Adobe Acrobat. what technical changes are being made in the service of PDFBox’s interoperability ride in parallel across these rails --- throughout, the core developers are balancing internal demands and contexts on their adaptive changes",qualitative case study of PDFBox development over two years --- purposeful sampling for standards and collaboration-based OSS project, using a competing implementation as the synecdoche of the environmental standard (see more in the notes)
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,,,,,
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,"Procedural --- level of communication; More successful projects do use more communication than unsuccessful projects. In successful projects, both core and peripheral contributors communicate more than their partners in unsuccesful projects.",core and peripheral contributors in ASFI projects. -- core members contribute the most code and oversee the design and evolution of the project; peripheral members submit patches and provide testing etc. ,ASFI - incudbation process where projects are developed and mentored into ASF. graduation from the ASF is noted as ‘fit',Quantitative – statistical modeling of communication frequency. Then using ML models to classify when communications contained inclusive language and pronouns. ,How much of the adaptive form of the change is mapped on by the researcher? Not sure that the developer used more inclusive language in order to graduate from ASFI --- adaption seems like a purely rhetorical thing in this shape
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,"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,Procedural – creating hard fork of a prior project; making the prior project now an environmental factor in the construction of the new project. Ideologically motivated hard fork (at the time of forking) LO from OO. Adaptation in the construction of the hard fork means ideologically motivated restructuring of governance and licensing (further egalitatrian and copyleft) which is even different than the AOO proejct which also evolved from OO,"engaged contributors and maintainers of the LibreOffice project, a fork from the pre-existing OpenOffice project","OpenOffice derivative forks; OO was an open source productivity library that was bought by Sun and then sold to Oracle.; LO is an offshoot of the project by OO contributors who wanted to depart from the mainline software; AO is an offshoot that is the result of Oracle selling the OO project to Apache. In a way, cross-project competition in the same product space ","mixed-methods case study analysis of the OpenOffice project and its different derivative forks. first, quantitative analysis of the contribution patterns of the different projects and their forks; quantitative modeling spent a lot of time looking at passive evolution of projects rather than intentional adaptation. second, interview study talking to different active participants in the LO community --- qualitative analysis based in open coding/qual coding practices","Interesting notes about sustainable communities and what that might mean for the projects involved; contributor activity peaks during the fraught times within the project’s lifecycle, when there’s a lot of activity surrounding the hard fork from upstream"
@ -24,7 +24,7 @@ V3F8FYG5,journalArticle,2018,"Meloca, Rômulo; Pinto, Gustavo; Baiser, Leonardo;
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,"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,,,,,
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"
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!"
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"
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,"technical and procedural --- the changing of a fork from social to hard in GitHub;the forks often start social, but then move to hard once obstacles to contributing upstream were found, whether that be unresponsive maintainers or rejected pull requests","GitHub repo owners of hard-forked OSS projects are the ones who effect the adaptive change ; though the quantitative sample looks at 15,306 hard forks on GitHub (initiated/shepherded by the owners of those hard forks), the interview sample looks at 15 owners of forked libraries --- these are long-tenured OSS contributors ","forking networks on GitHub, the environmental characteristics are unresponsive upstream projects or barriers to contributing to the upstream project; the hard fork is downstream of the construction of the upstream project as external to the social fork","mixed-methods; mining and classifying hard-forked projects and then interviewing the owners of those repositories/maintainers of upstream; heuristic classifier to find hard forks, qualitative card sorting to characterize them; qualitative interviews to gain perspective -- interview sample created from identifying hard forked projects and authors ","hard forks are, generally, a rare phenomenon across GitHub -- though the scale of GitHub means that the total number of these forks is actually pretty large; another verification of respondent claims: “we see little evidence of actual synchronization or merging across forks in the repositories:” ([Zhou et al., 2020, p. 453"

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
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 procedural (LoD at individual contributor) --- contributions devoted to OSS projectss -- the rationale between increases or decreases in contribution activity was adaptation to fear and time availability surrounding Covid-19 and the lockdown in China OSS contributors in Wuhan and Xian -- GitHub location within the regions selected; contributions are broad contributions to any project, not project-specific ;validation set looking at OSS developers in specific states in the US geopolitical; Covid-19 pandemic- initiated lockdowns in China and the united states. Lockdown (environmental) characteristics are directly informed by the regime’s approach to Covid mitigation and management. mixed-methods; repository mining supplemented with survey study; primarily looking at commits s contributions; using difference-in-difference models to try to model the absence of F2F interactions, as such interactions are important motivators for contributors; survey study sampled from developers impacted by the two lockdowns that were studied-- specifically, sampled from the developers in the results from the mining interesting sampling notes regarding prevalence of things in different geographies – using geographic proximity to establish matched pairs/similarity in the different cases; environmental factors were seemingly deterministic in the shape of the adaptations; not actually at the project-level, instead looking at contributions devoted to OSS projects, but the unit of analysis if the developer (maybe a note on the frailty of constraining the unit of analysis to project or individual level and the flexibility required to move between those in a thoughtful way)
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 technical - actions to maintain interoperability --- decisions fall into four types: improve to match de facto reference implementation;  degrade to match the de facto reference implementation; improve to match standard; scope of implementation OSS contributors,maintainers and community of the ASF’s PDFBox --- the nature of the work varies for each of these contributor archetypes, many of the higher-level discussions surrounding different technical changes recess into the Apache way of organizing OSS work --- core developers take a front-and-center role in managing different types of changes with different rationales two environments at play here; the putative standard of interoperability an the de-facto reference implementation of Adobe Acrobat. what technical changes are being made in the service of PDFBox’s interoperability ride in parallel across these rails --- throughout, the core developers are balancing internal demands and contexts on their adaptive changes qualitative case study of PDFBox development over two years --- purposeful sampling for standards and collaboration-based OSS project using a competing implementation as the synecdoche of the environmental standard (see more in the notes)
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 Procedural --- level of communication; More successful projects do use more communication than unsuccessful projects. In successful projects, both core and peripheral contributors communicate more than their partners in unsuccesful projects. core and peripheral contributors in ASFI projects. -- core members contribute the most code and oversee the design and evolution of the project; peripheral members submit patches and provide testing etc. ASFI - incudbation process where projects are developed and mentored into ASF. graduation from the ASF is noted as ‘fit' Quantitative – statistical modeling of communication frequency. Then using ML models to classify when communications contained inclusive language and pronouns. How much of the adaptive form of the change is mapped on by the researcher? Not sure that the developer used more inclusive language in order to graduate from ASFI --- adaption seems like a purely rhetorical thing in this shape
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 Procedural – creating hard fork of a prior project; making the prior project now an environmental factor in the construction of the new project. Ideologically motivated hard fork (at the time of forking) LO from OO. Adaptation in the construction of the hard fork means ideologically motivated restructuring of governance and licensing (further egalitatrian and copyleft) which is even different than the AOO proejct which also evolved from OO engaged contributors and maintainers of the LibreOffice project, a fork from the pre-existing OpenOffice project OpenOffice derivative forks; OO was an open source productivity library that was bought by Sun and then sold to Oracle.; LO is an offshoot of the project by OO contributors who wanted to depart from the mainline software; AO is an offshoot that is the result of Oracle selling the OO project to Apache. In a way, cross-project competition in the same product space mixed-methods case study analysis of the OpenOffice project and its different derivative forks. first, quantitative analysis of the contribution patterns of the different projects and their forks; quantitative modeling spent a lot of time looking at passive evolution of projects rather than intentional adaptation. second, interview study talking to different active participants in the LO community --- qualitative analysis based in open coding/qual coding practices Interesting notes about sustainable communities and what that might mean for the projects involved; contributor activity peaks during the fraught times within the project’s lifecycle, when there’s a lot of activity surrounding the hard fork from upstream
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 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
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!
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 technical and procedural --- the changing of a fork from social to hard in GitHub;the forks often start social, but then move to hard once obstacles to contributing upstream were found, whether that be unresponsive maintainers or rejected pull requests GitHub repo owners of hard-forked OSS projects are the ones who effect the adaptive change ; though the quantitative sample looks at 15,306 hard forks on GitHub (initiated/shepherded by the owners of those hard forks), the interview sample looks at 15 owners of forked libraries --- these are long-tenured OSS contributors forking networks on GitHub, the environmental characteristics are unresponsive upstream projects or barriers to contributing to the upstream project; the hard fork is downstream of the construction of the upstream project as external to the social fork mixed-methods; mining and classifying hard-forked projects and then interviewing the owners of those repositories/maintainers of upstream; heuristic classifier to find hard forks, qualitative card sorting to characterize them; qualitative interviews to gain perspective -- interview sample created from identifying hard forked projects and authors hard forks are, generally, a rare phenomenon across GitHub -- though the scale of GitHub means that the total number of these forks is actually pretty large; another verification of respondent claims: “we see little evidence of actual synchronization or merging across forks in the repositories:” ([Zhou et al., 2020, p. 453