mgaughan/adaptation-slr
1
0
Fork 0
Code

18/34

Browse Source
This commit is contained in:
mgaughan 2025-07-18 17:30:58 -04:00
parent c62ff32268
commit 21d533d6f1
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
070725_papers_master.csv
View File

@ -1,6 +1,6 @@
Key,Item Type,Publication Year,Author,Title,DOI,Change characteristics (blue),Actors (purple),Environmental characteristics (green),Methods details (orange),Misc. (red)
LB5MEY9S,journalArticle,2017,"Norskov, Sladjana; Kesting, Peter; Ulhoi, John Parm",Deliberate change without hierarchical influence? The case of collaborative OSS communities,10.1108/IJOA-08-2016-1050,,,,,
KUWLMFWM,journalArticle,2017,"Santos, Carlos Denner D60os",Changes in free and open source software licenses: managerial interventions and variations on project attractiveness,10.1186/s13174-017-0062-3,,,,,
KUWLMFWM,journalArticle,2017,"Santos, Carlos Denner D60os",Changes in free and open source software licenses: managerial interventions and variations on project attractiveness,10.1186/s13174-017-0062-3,"procedural --- license changes. managerial interventions in the nature of the license selected for the project; loosening the license makes the project more attractive, restricting it makes it less attractive; but asymmetric impacts though, there are more specific gradations of usefulness when moving between licenses than listed above",contributors to OSS projects --- ostensibly maintainers who are able to write to the license and switch the listed license. the project uses the framing of “managers” of OSS projects but it’s entirely backwards and should be disregarded.,"environment of attractiveness, as defined through lookups, selections and stated intent to download. as parts of this, project user base, attractiveness through use and downloads make up the environment.",Quantitative --- mining OSS projects on source forge that have had interventions/changes to their license selection then comparing against download and popularity data,"Mapping org studeis brain uncritically onto FOSS projects leads to failures within the empirical study; Just not very good, really grandiose in its claims; not sure how they’re going to isolate managerial intervention within the structure of OSS projects which,… rather famously do not have managers"
SJEI288C,conferencePaper,2024,"Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, Chris",An Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software,10.1145/3674805.3686692,technical and organizational/procedural: broad compliance with GDPR; increased development work and attention devoted to compliance with GDPR features and PRs -- increases to the technical management of data --- organizational: slowed down development timelines immensely --- organization: GDPR compliance requires and overhaul of --- consultation with legal team is a change in and of itself ; one that decreased productivity; technical because the technical aspects of the code were the things regulated by GDPR,OSS project developers --- some of whom had submitted GDPR compliance Prs ,"geopolitical legal regulation --- data privacy and rights regulation --- EU --- from a technical level, this is a non-functional requirement ---internal evaluation of change success within environment: consultation with legal counsel --- self-assessment --- “most of the resources on the internet are wrong”","Mixed-methods: pilot interview study with three developers; survey with 56 developers; mined Prs from GitHub, some sampling for survey done from activity data mined from GitHub ; grounded thematic coding methods for analysis of free responses/qualitative themes","developers not happy about compliance --- frustration of internal productivity in order to comply with the standard--- unhappiness also with the standard itself, not just what the compliance does to the project"
U7U4YLVB,journalArticle,2023,"Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi","""Nip it in the Bud"": Moderation Strategies in Open Source Software Projects and the Role of Bots",10.1145/3610092,,,,,
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,,,,,
@ -9,7 +9,7 @@ RN5Y3TN5,conferencePaper,2020,"Wessel, Mairieli; Serebrenik, Alexander; Wiese, I
HS8AQN5V,journalArticle,2010,"Sojer, Manuel; Henkel, Joachim","Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments",10.17705/1jais.00248,,,,,
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,,,,,
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,,,,,
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"
@ -31,5 +31,5 @@ DGV2UJNM,conferencePaper,2020,"Zhou, Shurui; Vasilescu, Bogdan; Kästner, Christ
QLSEMWTQ,journalArticle,2017,"Vendome, Christopher; Bavota, Gabriele; Penta, Massimiliano Di; Linares-Vásquez, Mario; German, Daniel; Poshyvanyk, Denys",License usage and changes: a large-scale study on gitHub,10.1007/s10664-016-9438-4,,,,,
5E2EWRQN,journalArticle,2020,"Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, Emad",On the impact of using trivial packages: an empirical case study on npm and PyPI,10.1007/s10664-019-09792-9,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: long-tenured JS and Python coders: largely professional but some independents,package managemeny systems: npm and PyPI: change adheres project to well-tested and implemented environment: 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 ,internal motivations for productiivty: many also stated that reuse was bad: paper spends a lot of time defining trivial packages
P3MTJWXP,conferencePaper,2022,"Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, Huaimin","Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism",10.1145/3491102.3501822,procedural/organizational: developer adoption and participation in the GitHub sponsors program --- rationale for adopting the sponsorship model: I should be rewarded or recognized for my OSS work ,"OSS developers, but not necessarily those with big commits or key contributions, the popular ones who work on big projects","GitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the project’s activity are restricted by GitHub as a platform --- to what extent is broader social environment (intrinsic desire for payment) also the environment here?",mixed-methods -- both data mining and survey; quantitative data mining of different sponsorship events within GitHub --- pulling a lot of data on the individual sponsorships and the sponsoring events --- statistic modeling (lmer) of maintainer/contributor balance etc.; Sampling from the data mining to identify the relevant population.; qualitative already with a questionnaire about the why and what questions.  -- survey looked up the expectations and rationales for using the sponsor feature ; two-stage survey,"again a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didn’t hold up!; configurable adaptations more throughout this, not the first paper that discusses this; environment (GitHub) is incredibly deterministic in establishing who adapts/adopts the feature --- instead of being an amorphous social pressure or anything like that --- it is a platform trying to get you to use their most recent feature; intersection of rationales for doing things sit at the intersection of intrinsic and extrinsic motivations"
DW9Q2W6V,conferencePaper,2022,"Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, Coen",Variant Forks - Motivations and Impediments,10.1109/SANER53432.2022.00105,,,,,
DW9Q2W6V,conferencePaper,2022,"Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, Coen",Variant Forks - Motivations and Impediments,10.1109/SANER53432.2022.00105,"technical change rooted in procedural motivations ---- creating variant of existing project in order to redirect the technical aims of the work. The creation of the variant fork is switching the social fork from contributing back to mainline to being more of a hard fork. creating a ‘variant fork’ of a project on a social coding platform -- variant fork is the same as hard fork I think. --- technical maintenance, wanting to change something and running into issues contributing back to the project or wanting to redirect the features ;; addition of different types of things","OSS maintainers who support the variant fork, who walked away from the upstream mainline project in order to create a new repository and effort",the environment is the newly-constructed relationship between the fork project and its upstream mainline. The actions of the mainline thus become the rationale for moving the fork from social to variant. ,"Mixed-methods – largely a survey with 105 maintainers of social fork projects; 12 questions, 15 minutes long of surveying authors. then selected things Likert scales and free responses from the survey responses. But also Sampled for variant forks through heuristic-based mining of platforms like Libraries.io and GitHub. Then also collected popularity metrics for the forks and their variants --- leading to mixed-methods analysis, even though the quantitative side of it is weak… to say the least.",Interesting that the categories of technical and procedural run into issues when the motivations are based in the procedural gripes with technical maintenance
3Y9YKK5M,conferencePaper,2011,"Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, Maximilian",On the Extent and Nature of Software Reuse in Open Source Java Projects,,,,,,

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
2 LB5MEY9S journalArticle 2017 Norskov, Sladjana; Kesting, Peter; Ulhoi, John Parm Deliberate change without hierarchical influence? The case of collaborative OSS communities 10.1108/IJOA-08-2016-1050
3 KUWLMFWM journalArticle 2017 Santos, Carlos Denner D60os Changes in free and open source software licenses: managerial interventions and variations on project attractiveness 10.1186/s13174-017-0062-3 procedural --- license changes. managerial interventions in the nature of the license selected for the project; loosening the license makes the project more attractive, restricting it makes it less attractive; but asymmetric impacts though, there are more specific gradations of usefulness when moving between licenses than listed above contributors to OSS projects --- ostensibly maintainers who are able to write to the license and switch the listed license. the project uses the framing of “managers” of OSS projects but it’s entirely backwards and should be disregarded. environment of attractiveness, as defined through lookups, selections and stated intent to download. as parts of this, project user base, attractiveness through use and downloads make up the environment. Quantitative --- mining OSS projects on source forge that have had interventions/changes to their license selection then comparing against download and popularity data Mapping org studeis brain uncritically onto FOSS projects leads to failures within the empirical study; Just not very good, really grandiose in its claims; not sure how they’re going to isolate managerial intervention within the structure of OSS projects which,… rather famously do not have managers
4 SJEI288C conferencePaper 2024 Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, Chris An Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software 10.1145/3674805.3686692 technical and organizational/procedural: broad compliance with GDPR; increased development work and attention devoted to compliance with GDPR features and PRs -- increases to the technical management of data --- organizational: slowed down development timelines immensely --- organization: GDPR compliance requires and overhaul of --- consultation with legal team is a change in and of itself ; one that decreased productivity; technical because the technical aspects of the code were the things regulated by GDPR OSS project developers --- some of whom had submitted GDPR compliance Prs geopolitical legal regulation --- data privacy and rights regulation --- EU --- from a technical level, this is a non-functional requirement ---internal evaluation of change success within environment: consultation with legal counsel --- self-assessment --- “most of the resources on the internet are wrong” Mixed-methods: pilot interview study with three developers; survey with 56 developers; mined Prs from GitHub, some sampling for survey done from activity data mined from GitHub ; grounded thematic coding methods for analysis of free responses/qualitative themes developers not happy about compliance --- frustration of internal productivity in order to comply with the standard--- unhappiness also with the standard itself, not just what the compliance does to the project
5 U7U4YLVB journalArticle 2023 Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi "Nip it in the Bud": Moderation Strategies in Open Source Software Projects and the Role of Bots 10.1145/3610092
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
9 HS8AQN5V journalArticle 2010 Sojer, Manuel; Henkel, Joachim Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments 10.17705/1jais.00248
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
14 MVGUFG8P conferencePaper 2016 Crowston, Kevin; Shamshurin, Ivan Core-Periphery Communication and the Success of Free/Libre Open Source Software Projects 10.1007/978-3-319-39225-7_4
15 WE8VYWEX journalArticle 2021 Geiger, R. Stuart; Howard, Dorothy; Irani, Lilly The Labor of Maintaining and Scaling Free and Open-Source Software Projects 10.1145/3449249 organizational/procedural – projects have to reconstruct their processes and organization in order to comply with shifting expectations of scale. trust scaling requires new forms of code review… formalizing it while also trusting designated individuals to adhere to it --- this may seem like a technical process but in reality it’s organizational, as it expresses the direction of the project and the way of doing. OSS project maintainers, largely white, male from the global north, and young-ish, --- from a range of project types too environment is infrastructural mapping of project for other organizations --- as projects scale…also GitHub as an environment that creates pressures around presentation and reputation. the ecosystem turns from interdependent to competitive as projects scale within it -- the project reshapes the environment --- maintainers have to directly manage this new environment and set of relationships --- sometimes, maintainers choose to consolidate like-projects within an ecosystem. Check of success: NA qualitative interview study: semi-structured interviews with maintainers during 2019-2020. non-random sampling. tried to interview maintainers from a breadth of environments and projects; recruited from a breadth of settings. Interpretive grounded theory for qualitative analysis. adaptive change becomes an ‘overwhelming and never-ending chore’--- environmental demands from users are disrespectful, entitled, and demanding in terms of time and attention. Burn out because of ‘what was expected’ of maintainers as they scale out
31 QLSEMWTQ journalArticle 2017 Vendome, Christopher; Bavota, Gabriele; Penta, Massimiliano Di; Linares-Vásquez, Mario; German, Daniel; Poshyvanyk, Denys License usage and changes: a large-scale study on gitHub 10.1007/s10664-016-9438-4
32 5E2EWRQN journalArticle 2020 Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, Emad On the impact of using trivial packages: an empirical case study on npm and PyPI 10.1007/s10664-019-09792-9 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: long-tenured JS and Python coders: largely professional but some independents package managemeny systems: npm and PyPI: change adheres project to well-tested and implemented environment: 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 internal motivations for productiivty: many also stated that reuse was bad: paper spends a lot of time defining trivial packages
33 P3MTJWXP conferencePaper 2022 Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, Huaimin Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism 10.1145/3491102.3501822 procedural/organizational: developer adoption and participation in the GitHub sponsors program --- rationale for adopting the sponsorship model: I should be rewarded or recognized for my OSS work OSS developers, but not necessarily those with big commits or key contributions, the popular ones who work on big projects GitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the project’s activity are restricted by GitHub as a platform --- to what extent is broader social environment (intrinsic desire for payment) also the environment here? mixed-methods -- both data mining and survey; quantitative data mining of different sponsorship events within GitHub --- pulling a lot of data on the individual sponsorships and the sponsoring events --- statistic modeling (lmer) of maintainer/contributor balance etc.; Sampling from the data mining to identify the relevant population.; qualitative already with a questionnaire about the why and what questions.  -- survey looked up the expectations and rationales for using the sponsor feature ; two-stage survey again a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didn’t hold up!; configurable adaptations more throughout this, not the first paper that discusses this; environment (GitHub) is incredibly deterministic in establishing who adapts/adopts the feature --- instead of being an amorphous social pressure or anything like that --- it is a platform trying to get you to use their most recent feature; intersection of rationales for doing things sit at the intersection of intrinsic and extrinsic motivations
34 DW9Q2W6V conferencePaper 2022 Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, Coen Variant Forks - Motivations and Impediments 10.1109/SANER53432.2022.00105 technical change rooted in procedural motivations ---- creating variant of existing project in order to redirect the technical aims of the work. The creation of the variant fork is switching the social fork from contributing back to mainline to being more of a hard fork. creating a ‘variant fork’ of a project on a social coding platform -- variant fork is the same as hard fork I think. --- technical maintenance, wanting to change something and running into issues contributing back to the project or wanting to redirect the features ;; addition of different types of things OSS maintainers who support the variant fork, who walked away from the upstream mainline project in order to create a new repository and effort the environment is the newly-constructed relationship between the fork project and its upstream mainline. The actions of the mainline thus become the rationale for moving the fork from social to variant. Mixed-methods – largely a survey with 105 maintainers of social fork projects; 12 questions, 15 minutes long of surveying authors. then selected things Likert scales and free responses from the survey responses. But also Sampled for variant forks through heuristic-based mining of platforms like Libraries.io and GitHub. Then also collected popularity metrics for the forks and their variants --- leading to mixed-methods analysis, even though the quantitative side of it is weak… to say the least. Interesting that the categories of technical and procedural run into issues when the motivations are based in the procedural gripes with technical maintenance
35 3Y9YKK5M conferencePaper 2011 Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, Maximilian On the Extent and Nature of Software Reuse in Open Source Java Projects