mgaughan/adaptation-slr
1
0
Fork 0
Code

29/34

Browse Source
This commit is contained in:
mgaughan 2025-07-25 13:01:32 -04:00
parent 3fbc12447f
commit 036d42e17e
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

@ -10,7 +10,7 @@ HS8AQN5V,journalArticle,2010,"Sojer, Manuel; Henkel, Joachim","Code Reuse in Ope
GGZV58MQ,journalArticle,2021,"Klug, Daniel; Bogart, Christopher; Herbsleb, James D.","""They Can Only Ever Guide"": How an Open Source Software Community Uses Roadmaps to Coordinate Effort",10.1145/3449232,"procedural --- Use of project roadmaps --- ecosystem/project (porous distinction between the two) grows larger, with different stakeholders and goals --- to organize this (identifying consensus around project goals) roadmaps are used to structure things -- articulated work for the core members of the project ; team members followed the guide far more than other contributors -- goal of the roadmap is to make the trajectory more visible for external parties; 5.1.4; the roadmap is critical for helping communicate work to external parties, to help users plan,","maybe the change is especially relevant for core team members --- for them the roadmap structures their priorities and aims; OSS contributors to the Rust project, either core (contributing to blog posts or team members) or more peripheral (have committed to the compiler project)","infrastructural OSS  ecosystem, the Rust programming language ecosystem. --- the road-mapping architecture occurs across the ecosystem, encapsulating different repositories within the Rust project",mixed methods single case study and email interviews --- selection of a \`revelatory case’ for Rust and its roadmap evolution ; collected multimodal data across settings and then followed up with Rust contributors to try to contextualize finidngs/observations;sampled for email interview from the core develoeprs identified through data mining (2018 road map); always ends up with qual coding/analysis for the text data --- more rigorously inductive than computational approaches,"there’s a difference in the roadmap’s presentation/ostensible utility and its utility in practice --- while it seems lo be a top-down directive, in fact it is a reflection of bottom-up interest and labor promises; litany of rationales and motivations for the creation of the roadmap, environmental pressures and inputs are only one part of that. so many internal reasons, change is not often articulated in terms of the external pressures, instead the self-organization of tings is useful for structuring the different feature developments; adaptive change (roadmap) does not occur in a vacuum, it needs to be cultivated and supported through the other documents like READMEs or GOVERNANCE documents;  the roadmapping architecture enc"
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,,,,,
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,"technical-- integration of  packages (external code libraries and projects) into local, system-specific environment adapting the ecosystem’s internality to the external environment of the upstream software; more details int he notes on Zotero","package maintainers in Debian, Ubuntu, and FreeBSD; within these systems, maintainers are formally elevated contributors with enhanced privileges and rights",The environment is actually the broader ecosystem of software that COULD be useful for the OSS operating system distribution. e.g. you package software into your project because the external software is going to be useful for the project as a whole and needs to fit the specific operating system,"qualitative case study analysis of longitudinal historical data re: historical change and bugs in each distribution --- selected Debian, Ubuntu, and FreeBSD because the distributions are the most successful oss operating systems and deal with a lot of integration. these operating system distributions are also ones with long histories a lot of computational data collection and sampling construction in order to gain confidence that the data that’s been examined is representative of the broader distribution sample iterative expansive qualitative study, growing the different sources of data and evaluations that you’re looking at inductive qualitative tagging of package versions that use integration activities from copied code --- then tagging for the type of integration activity used by the package maintainer -- iterative refinement across different authors once the integration practices were refined, then the results were sanity-checked with maintainers from the ddistribution communities --- validating the findings of the case study","the aim of the paper is to identify the breadth and regularity of these integration activities within the OSS distributions really reliant on the authors’ internal evaluation of intent and action in the integration activity Also contains their own environmental change through upstream patch submission or lobbying They don’t actually go long on all of the integration practices that they observe in their case study --- generally unhappy a bit with their expert validation; not so much useful for the framing of adaptation, though im sure useful for the real-world recommendations"
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"

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
10 GGZV58MQ journalArticle 2021 Klug, Daniel; Bogart, Christopher; Herbsleb, James D. "They Can Only Ever Guide": How an Open Source Software Community Uses Roadmaps to Coordinate Effort 10.1145/3449232 procedural --- Use of project roadmaps --- ecosystem/project (porous distinction between the two) grows larger, with different stakeholders and goals --- to organize this (identifying consensus around project goals) roadmaps are used to structure things -- articulated work for the core members of the project ; team members followed the guide far more than other contributors -- goal of the roadmap is to make the trajectory more visible for external parties; 5.1.4; the roadmap is critical for helping communicate work to external parties, to help users plan, maybe the change is especially relevant for core team members --- for them the roadmap structures their priorities and aims; OSS contributors to the Rust project, either core (contributing to blog posts or team members) or more peripheral (have committed to the compiler project) infrastructural OSS  ecosystem, the Rust programming language ecosystem. --- the road-mapping architecture occurs across the ecosystem, encapsulating different repositories within the Rust project mixed methods single case study and email interviews --- selection of a \`revelatory case’ for Rust and its roadmap evolution ; collected multimodal data across settings and then followed up with Rust contributors to try to contextualize finidngs/observations;sampled for email interview from the core develoeprs identified through data mining (2018 road map); always ends up with qual coding/analysis for the text data --- more rigorously inductive than computational approaches there’s a difference in the roadmap’s presentation/ostensible utility and its utility in practice --- while it seems lo be a top-down directive, in fact it is a reflection of bottom-up interest and labor promises; litany of rationales and motivations for the creation of the roadmap, environmental pressures and inputs are only one part of that. so many internal reasons, change is not often articulated in terms of the external pressures, instead the self-organization of tings is useful for structuring the different feature developments; adaptive change (roadmap) does not occur in a vacuum, it needs to be cultivated and supported through the other documents like READMEs or GOVERNANCE documents;  the roadmapping architecture enc
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 technical-- integration of  packages (external code libraries and projects) into local, system-specific environment adapting the ecosystem’s internality to the external environment of the upstream software; more details int he notes on Zotero package maintainers in Debian, Ubuntu, and FreeBSD; within these systems, maintainers are formally elevated contributors with enhanced privileges and rights The environment is actually the broader ecosystem of software that COULD be useful for the OSS operating system distribution. e.g. you package software into your project because the external software is going to be useful for the project as a whole and needs to fit the specific operating system qualitative case study analysis of longitudinal historical data re: historical change and bugs in each distribution --- selected Debian, Ubuntu, and FreeBSD because the distributions are the most successful oss operating systems and deal with a lot of integration. these operating system distributions are also ones with long histories a lot of computational data collection and sampling construction in order to gain confidence that the data that’s been examined is representative of the broader distribution sample iterative expansive qualitative study, growing the different sources of data and evaluations that you’re looking at inductive qualitative tagging of package versions that use integration activities from copied code --- then tagging for the type of integration activity used by the package maintainer -- iterative refinement across different authors once the integration practices were refined, then the results were sanity-checked with maintainers from the ddistribution communities --- validating the findings of the case study the aim of the paper is to identify the breadth and regularity of these integration activities within the OSS distributions really reliant on the authors’ internal evaluation of intent and action in the integration activity Also contains their own environmental change through upstream patch submission or lobbying They don’t actually go long on all of the integration practices that they observe in their case study --- generally unhappy a bit with their expert validation; not so much useful for the framing of adaptation, though im sure useful for the real-world recommendations
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