mgaughan/adaptation-slr
1
0
Fork 0
Code

31/34

Browse Source
This commit is contained in:
mgaughan 2025-07-28 11:33:07 -04:00
parent 80abfd40fa
commit 5648edec4c
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

@ -15,7 +15,7 @@ MVGUFG8P,conferencePaper,2016,"Crowston, Kevin; Shamshurin, Ivan",Core-Periphery
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"
FJSA37EW,journalArticle,2021,"Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, Ferdian",When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems,10.1145/3447245,,,,,
FJSA37EW,journalArticle,2021,"Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, Ferdian",When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems,10.1145/3447245,procedural-- breaking changes across ecosystems; both how do developers decide and mange the performance of breaking changes for their own package and how do they respond to when a dependency makes  a breaking change,"package maintainers within different ecosystems; these package maintainers are often the same as the project developers, but not always (59%). most were 33 year old males","first study; Eclipse, NPM and CRAN package ecosystems. second study; 18 different package ecosystems. “software ecosystems as communities built around shared programming languages, shared platforms, or shared dependency management tools, allowing developers to create packages that import and build on each others’ functionality.” ([Bogart et al., 2021, p. 3](zotero://select/library/items/FJSA37EW)) ([pdf](zotero://open-pdf/library/items/PJWUIBY2?page=3&annotation=DP2EWBXF)) Really takes a more ecosystem/environment-first perspective to the behavioral question, even though looking at the independent actions of developers. What seems to be the most important factor of the environment in the shaping of projects’ breaking change deployments are the rather gooey values and ideas held within the ecosystem, the norms around how packages relate to one another Though spoken values are putatively shared across the ecosystem, the implemented values and practices vary widely","mixed-methods; first an interview case study across three different package management environments, then a survey, mining, and document analysis study to look across 18 ecosystems first study; interviewing 28 developers across three ecosystems. sampling for package maintainers with both upstream and downstream dependencies; used inductive thematic coding second study: then tried to do a systematic mapping of values and practices in a broad sample of ecosystems. used a grounded approach to code the free response sections of the survey. then mining stated ecosystem policies and commit activity to see how different breaking changes were actually integrated into the project. sampling for study 2 was distinct form the sampling for study 1, however the research questions were largely derived from the interview study","“Another consequence of Eclipse’s stability, along with its use of semantic versioning, is that many packages have not changed their major version number in over 10 years” ([Bogart et al., 2021, p. 31](zotero://select/library/items/FJSA37EW)) ([pdf](zotero://open-pdf/library/items/PJWUIBY2?page=31&annotation=L49A55FP)) how do you study the absence of action?!"
72F8GVAP,journalArticle,2025,"Jahanshahi, Mahmoud; Reid, David; Mockus, Audris",Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development,10.1145/3715907,,,,,
QEKG8ISF,journalArticle,2016,"Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, Danny","ASE - Usage, costs, and benefits of continuous integration in open-source projects",10.1145/2970276.2970358,"Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability","OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds",OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that ,"mixed-methods: mining open source projects from GitHub while also surveying developers from popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects",he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems
ZGK4HR76,journalArticle,2015,"Vendome, Christopher; Linares-Vasquez, Mario; Bavota, Gabriele; Di Penta, Massimiliano; German, Daniel M.; Poshyvanyk, Denys",ICSME - When and why developers adopt and change software licenses,10.1109/icsm.2015.7332449,Procedural – license changes within OSS projects --- the change event is the real adaptation action; rationale for commercial reuse is also a motivating factor ,"OSS maintainers (Java, on GitHub) who change the license --- oftentimes this is a copyright holder or primary core contirbutor of the project ","nebulous environment of commercial reuse, ‘community’, and user base --- there’s also discussion around the role that changes to the broader dependency network play in the structure of the project and changes to the license",Mixed-methods; mining 16k java open source projects and their commits and then supplemented with survey study of 138 developers; sample of developers surveyed are from the trace data of the mined project actions --- specifically looking to identify projects that had shifted over time with regard to licensing,many of the intitial decisions and adaptations were motivated from a range of intrinsic and extrinsic motivations

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
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
18 FJSA37EW journalArticle 2021 Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, Ferdian When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems 10.1145/3447245 procedural-- breaking changes across ecosystems; both how do developers decide and mange the performance of breaking changes for their own package and how do they respond to when a dependency makes  a breaking change package maintainers within different ecosystems; these package maintainers are often the same as the project developers, but not always (59%). most were 33 year old males first study; Eclipse, NPM and CRAN package ecosystems. second study; 18 different package ecosystems. “software ecosystems as communities built around shared programming languages, shared platforms, or shared dependency management tools, allowing developers to create packages that import and build on each others’ functionality.” ([Bogart et al., 2021, p. 3](zotero://select/library/items/FJSA37EW)) ([pdf](zotero://open-pdf/library/items/PJWUIBY2?page=3&annotation=DP2EWBXF)) Really takes a more ecosystem/environment-first perspective to the behavioral question, even though looking at the independent actions of developers. What seems to be the most important factor of the environment in the shaping of projects’ breaking change deployments are the rather gooey values and ideas held within the ecosystem, the norms around how packages relate to one another Though spoken values are putatively shared across the ecosystem, the implemented values and practices vary widely mixed-methods; first an interview case study across three different package management environments, then a survey, mining, and document analysis study to look across 18 ecosystems first study; interviewing 28 developers across three ecosystems. sampling for package maintainers with both upstream and downstream dependencies; used inductive thematic coding second study: then tried to do a systematic mapping of values and practices in a broad sample of ecosystems. used a grounded approach to code the free response sections of the survey. then mining stated ecosystem policies and commit activity to see how different breaking changes were actually integrated into the project. sampling for study 2 was distinct form the sampling for study 1, however the research questions were largely derived from the interview study “Another consequence of Eclipse’s stability, along with its use of semantic versioning, is that many packages have not changed their major version number in over 10 years” ([Bogart et al., 2021, p. 31](zotero://select/library/items/FJSA37EW)) ([pdf](zotero://open-pdf/library/items/PJWUIBY2?page=31&annotation=L49A55FP)) how do you study the absence of action?!
19 72F8GVAP journalArticle 2025 Jahanshahi, Mahmoud; Reid, David; Mockus, Audris Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development 10.1145/3715907
20 QEKG8ISF journalArticle 2016 Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, Danny ASE - Usage, costs, and benefits of continuous integration in open-source projects 10.1145/2970276.2970358 Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that mixed-methods: mining open source projects from GitHub while also surveying developers from popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems
21 ZGK4HR76 journalArticle 2015 Vendome, Christopher; Linares-Vasquez, Mario; Bavota, Gabriele; Di Penta, Massimiliano; German, Daniel M.; Poshyvanyk, Denys ICSME - When and why developers adopt and change software licenses 10.1109/icsm.2015.7332449 Procedural – license changes within OSS projects --- the change event is the real adaptation action; rationale for commercial reuse is also a motivating factor OSS maintainers (Java, on GitHub) who change the license --- oftentimes this is a copyright holder or primary core contirbutor of the project nebulous environment of commercial reuse, ‘community’, and user base --- there’s also discussion around the role that changes to the broader dependency network play in the structure of the project and changes to the license Mixed-methods; mining 16k java open source projects and their commits and then supplemented with survey study of 138 developers; sample of developers surveyed are from the trace data of the mined project actions --- specifically looking to identify projects that had shifted over time with regard to licensing many of the intitial decisions and adaptations were motivated from a range of intrinsic and extrinsic motivations