mgaughan/adaptation-slr
1
0
Fork 0
Code

26/34

Browse Source
This commit is contained in:
mgaughan 2025-07-24 12:22:02 -04:00
parent 7d0b1339fc
commit 72d3e10aea
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

@ -6,7 +6,7 @@ U7U4YLVB,journalArticle,2023,"Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Ha
M6PP5MPQ,conferencePaper,2011,"Jensen, Chris; Scacchi, Walt",License Update and Migration Processes in Open Source Software Projects,https://doi.org/10.1007/978-3-642-24418-6_12,"Procedural – the adoption of a new contributor license agreement in a sponsored OSS project (NetBeans); the change also looks at the creation of a new license in Apache but because that takes place higher up than the project level, that is less relevant to this paper. Self evaluation of the success of the adaptive change is done before-hand by the Sun legal team; no real empirical evaluation in regards to the project environment. ","Employees at the sponsoring organization. NetBeans was sponsored by Sun Microsystems, so the discussion around the adoption of a new SLA and the language around the license were primarily litigated by Sun legal and Sun engineers, much to the chagrin of other contributors in the NetBeans project",American legal ecosystem and tort law. “Sun required full copyright authority to protect the NetBeans project from legal threats and provide Sun with the flexibility to adapt the NetBeans license over time.” affording the contributor as well as Sun independent copyright to the contributed source software,"qualitative case study; looking through the mailing list discussions surrounding the license changes, they built a bespoke piece of labeling software to look at the different themes within the messages as well as using more established CAQDAS methods for identifying emergent themes. ",pre-figuring adaptive change down the road received push-back from the community --- same thing happened in Apache but received less push back maybe because of community-based rationale and view of Apache
ENQ5AACF,journalArticle,2022,"Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk",Managing Episodic Volunteers in Free/Libre/Open Source Software Communities,10.1109/TSE.2020.2985093,,,,,
RN5Y3TN5,conferencePaper,2020,"Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A.",What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers,10.1145/3422392.3422459,organizational/procedural - adoption of code review bot; rationale: this code review bot will enhance feedback to developers contributing code; reducing maintainers effort when evaluating different parts of the code,OSS maintainers of projects that had adopted code review bots ,external/peripheral contributions from the fork of the project --- those waiting for code review --- self-assessment: internal metrics of amorphous normative goals such as reducing time to close on Prs; maintainers hoped to automate things as the number of contributions increased,qualitative survey: 27 maintainers re: the adoption of code review bots within the project. maintainers for projects who had adopted at least one code review bot. using the GHTorrent data set and who had contributed on either side of bot adoption --- card sorting thematic analysis of the survey responses --- discussion and consensus regarding the themes,a lot of internal rationalization when addressing different factors of being more ‘productive’ or lessening small labor within the project--- added noise and downside results from the adoption of the bots
HS8AQN5V,journalArticle,2010,"Sojer, Manuel; Henkel, Joachim","Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments",10.17705/1jais.00248,,,,,
HS8AQN5V,journalArticle,2010,"Sojer, Manuel; Henkel, Joachim","Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments",10.17705/1jais.00248,"technical- copy based reuse of projects and their code: rationale is the continuation of effective, efficient, and quality code; rationale that reuse makes the code more stable and compatible with standards; primary reasons developers don’t reuse more code is that there are few reusable resources for the current project/code search issues ",OSS developers on SourceForge; largely well-educated European Men in their 20s and 30s; who are very engaged in OSS networks and work,"Broader OSS environment of like projects or projects that are useful to the focal project because of adherence to standards, or quality thresholds; developer environment of SourceForge projects","mixed-methods; preliminary qualitative pilot interview study with 12 OSS developers, followed up with quantitative survey with 686 OSS developers quantitative survey with 686 OSS developers --- multivariate analyses of developers’ reuse behaviors; circulated survey on SourceForge to 7500 developers, asking for OSS developers’ input","Paper seems to be cosigning copy-based reuse as a useful way of building up OSS and constructing the project; Overly verbose article, did not need to be 46 pages, could have been far less Survey happens in 2009 Asking users to self-report hours spent on OSS seems lossy; but they are really attached to the method of using a lot of different statistical tests to go ‘establish validity’ of their studies"
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)

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
6 M6PP5MPQ conferencePaper 2011 Jensen, Chris; Scacchi, Walt License Update and Migration Processes in Open Source Software Projects https://doi.org/10.1007/978-3-642-24418-6_12 Procedural – the adoption of a new contributor license agreement in a sponsored OSS project (NetBeans); the change also looks at the creation of a new license in Apache but because that takes place higher up than the project level, that is less relevant to this paper. Self evaluation of the success of the adaptive change is done before-hand by the Sun legal team; no real empirical evaluation in regards to the project environment. Employees at the sponsoring organization. NetBeans was sponsored by Sun Microsystems, so the discussion around the adoption of a new SLA and the language around the license were primarily litigated by Sun legal and Sun engineers, much to the chagrin of other contributors in the NetBeans project American legal ecosystem and tort law. “Sun required full copyright authority to protect the NetBeans project from legal threats and provide Sun with the flexibility to adapt the NetBeans license over time.” affording the contributor as well as Sun independent copyright to the contributed source software qualitative case study; looking through the mailing list discussions surrounding the license changes, they built a bespoke piece of labeling software to look at the different themes within the messages as well as using more established CAQDAS methods for identifying emergent themes. pre-figuring adaptive change down the road received push-back from the community --- same thing happened in Apache but received less push back maybe because of community-based rationale and view of Apache
7 ENQ5AACF journalArticle 2022 Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk Managing Episodic Volunteers in Free/Libre/Open Source Software Communities 10.1109/TSE.2020.2985093
8 RN5Y3TN5 conferencePaper 2020 Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A. What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers 10.1145/3422392.3422459 organizational/procedural - adoption of code review bot; rationale: this code review bot will enhance feedback to developers contributing code; reducing maintainers effort when evaluating different parts of the code OSS maintainers of projects that had adopted code review bots external/peripheral contributions from the fork of the project --- those waiting for code review --- self-assessment: internal metrics of amorphous normative goals such as reducing time to close on Prs; maintainers hoped to automate things as the number of contributions increased qualitative survey: 27 maintainers re: the adoption of code review bots within the project. maintainers for projects who had adopted at least one code review bot. using the GHTorrent data set and who had contributed on either side of bot adoption --- card sorting thematic analysis of the survey responses --- discussion and consensus regarding the themes a lot of internal rationalization when addressing different factors of being more ‘productive’ or lessening small labor within the project--- added noise and downside results from the adoption of the bots
9 HS8AQN5V journalArticle 2010 Sojer, Manuel; Henkel, Joachim Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments 10.17705/1jais.00248 technical- copy based reuse of projects and their code: rationale is the continuation of effective, efficient, and quality code; rationale that reuse makes the code more stable and compatible with standards; primary reasons developers don’t reuse more code is that there are few reusable resources for the current project/code search issues OSS developers on SourceForge; largely well-educated European Men in their 20s and 30s; who are very engaged in OSS networks and work Broader OSS environment of like projects or projects that are useful to the focal project because of adherence to standards, or quality thresholds; developer environment of SourceForge projects mixed-methods; preliminary qualitative pilot interview study with 12 OSS developers, followed up with quantitative survey with 686 OSS developers quantitative survey with 686 OSS developers --- multivariate analyses of developers’ reuse behaviors; circulated survey on SourceForge to 7500 developers, asking for OSS developers’ input Paper seems to be cosigning copy-based reuse as a useful way of building up OSS and constructing the project; Overly verbose article, did not need to be 46 pages, could have been far less Survey happens in 2009 Asking users to self-report hours spent on OSS seems lossy; but they are really attached to the method of using a lot of different statistical tests to go ‘establish validity’ of their studies
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)