adaptation-slr/070725_papers_master.csv

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	Procedural --- focal change is the organizational prioritization of usability. Change agent within the project identified usability as a critical deficiency of the project, installing usability as a mindset; external; redirecting the project’s focus towards usability, mitigating the extreme focus on technicality. initially proposed by a newcomer to the project, who became the change agent for the project, and made the explicit decision to launch a process of change for the project. the adaptation remained inthe background for 5 years; delayed implementation of the adaptive change--- proposed in 2001 and then not adopted until 2006. -     change agent needed to wade through a wide range of bureaucracy and muddled-ness in order to advocate for the change and get it implemented - a lot of the hierarchy and burarucracy continues within things	specific contributors to the TYPO3 project who are not necessarily high in the hierarchy when the strategic change begins… there is some accumulation of social capital and status that is developed through the act of whipping for a given change gaining legitimacy from the project founder and other developers higher up in the project; this requires strategic action by both the change agent and the higher ups in hte project, the higher ups redirect attention back towards the change agent and build up his status within the OSS project the construction of the change agent is two-sided, from the individual as well as from the surrounding hierarchy	project user space of TYPO3; some of the other changes were made for internal reasons surrounding productivity or transparency---- but two others were made for the sake of product usability for users; the usability question ---> the project was directly compared to WordPress and Drupal in the discussions around usability, prompting a direct comparison with environmental competitors	qualitative --- longitudinal qualitative case study of TYPO3; four years of project development from 2006-2010. focusing on one strategic change initiative carried out to try to redirect the project’s focus towards product usability and user satisfaction; nonrandom sampling for the case study to look at representative example and a mature case; TYPO3: public CMS with small group of developers working on R&D. Now a more mature project with larger user base working on similar stuff (registered developer boom from 2003-2005 was the reason for studying the project); data sources: interviews, observations of meetings, community mailing lists, and archival data; most of the interviews were with the core members/higher up on the hierarchy of the system; might be a sampling bias towards the higher up structure of things; qualitative analysis of the data --- looking at the emergence of organizational practices within the grounded setting of the data; used grounded theory analysis methods to identify different concepts and relationships within the data; four categories to use to analyze the mechanisms employed to address deliberate change	deliberate change as the object of study in and of itself; trying to generalize their single case study with the development of a model?; using/parrotting the core/peripheral model of OSS development, meritocracy argument, and motivations things; argument that leadership power is necessary for overcoming the friction of deliberate change; most of the interviews were with the core members/higher up on the hierarchy of the system; might be a sampling bias towards the higher up structure of things
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	Procedural – moderation strategies in response to misconduct by contributors from GitHub; rationale to address influx of activity or misconduct -- organizing formal moderation teams within the project -- when the projects get popular and large, formal moderation teams follow to address misconduct; in both organizational structure and moderation strategy, OSS projects adapt their procedure to match the demands of contributor misconduct	moderators or maintainers of 10 open source projects, these projects have varying sizes --- 13 men and 1 women; these are maintainers or moderators within projects, meaning that they are relatively priveliged and higher up in the governance of the library	GitHub as a hosting platform for different open source projects --- the environment consists of internal project collaborators and external (non-collaborator) contributors. The platform of GitHub expands the scope of work that project maintainers are tasked with doing. Project maintainers must now handle the chores of managing new contributors and moderating discussions The platformed nature of GitHub supports contributor misconduct, as different external contributors are drawn to projects without fully understanding their implications. T	qualitative interviews with 14 developers who moderate or maintain projects with ranging sizes semi-structured interviews, transcripts were anlayzed using bottom-up, thematic analysis of the interviews. specified bottom-up affinity coding before code and theme synthesis into common themes and traits	Not even looking at procedural changes around technical labor, instead looking at procedural changes around non-technical labor -- this is similar to the Geiger paper; Sometimes the project tries to explicitly and intentionally change the environment. e.g. reporting misconduct-ing users to GitHub the platform as a way to minimize the impact of misconduct users to the project
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	procedural -- -the management of episodic volunteers within FLOSS communities; concerns with EV -> worries about how the shape of the environment will impact the project’s knowledge transfer and development. There are 65 practices that community managers adopt to manage EV contributions ranging from preparing the engaged community to restructuring project governance	FLOSS community managers of BIG OSS projects and ecosystems and communities; sampled through a variety of specific and targeted ways. one-third of them female	Immediate environment --- episodic volunteers who circulate around the project, infrequently but consistently contributing --- these episodic contributors shape how the project operates and its organization --- but aren’t quite a part of the project; In this, there’s an interesting litigation of the porous-ness of the FLOSS project, without specific inclusion/exclusion rights, there’s very little keeping things together besides shared goals; Many of the concerns with EV participation are rooted in the concerns around the integration of EVs into the full-membership of the project. the community managers are worried about the ways that community managers may continue to be marginalized	qualitative --- policy Delphi study (set of interviews with experts in the field) 24 community managers from 22 different FLOSS communities/projects Delphi method developed to arrive at consensus amongst a group of experts for how things /should/ go; policy Delphi method was developed to study specific arguments and positions, rather than consensus brainstorming -> enriching -> refining. generating concerns and perspectives; developing them, then polishing for the production of the final set of themes, practices and ideas	65 practices actually have very little description of how many projects use them or how widely adopted these practices are across different kinds of settings. I’m still not so happy about the lack of /REAL/ empirics here--- yes the opinions of the different experts are good and useful, but they leave a lot of information about how these projects ACTUALLY use practices to address EV on the floor
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)
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
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	technical-  copy-based software reuse; black-box reuse (using a dependency manager, not touching the depended-upon code) and white box reuse (copying the original code and committing the duplicate code to the focal repository); prevalent, 6.9% of code in OSS is reused at least once, and each reused blob is copied to an average of 24 other projects; 80% of OSS projects have reused blobs from another project at least once; all types of projects big and small; (see notes in the bottom re: timeliness of this); seems to be a cultural thing for each ecosystem in terms of modularity and copying things over --- same with R, though that might also be explained by R code being very specific and statistics oriented, while R-type projects are more likely to pull in other code into their project; Reusers deny reusing the code? seems that its a taboo adaptation --- one that carries a lot of stigma with it; rationale: developers reuse code to incorporate existing functionalities into their projects -- in order to save time and effort in development. or reusing resources.	commit author who introduced the reused blob in the destination repository. ‘reuser’ is the correct term because the individual could be anyone in the destination project, who just happened to introduce the pre-existing code into things.	The first-introduced of the blob is the external environment that the focal project is engaging with. E.g. if the blob first appears in project A, then project B does a white-box reuse, then project A is the environment of project B. I guess this is also bidirectional, though the original commit has little conception of the environment when writing the original piece of code.	mixed-methods; repository mining first and then a survey to follow.; mining: measurement framework of tracking repository blobs and their inclusion over time in different repositories and projects; by using the blob approach, they are able to compare hashes of code versions across the entire code ecosystem, tracing the origins of a specific piece of code across different repos in a way that the other identification of clones cannot --- Conversely, “This means that copy-based reuse is detected only if an entire file is duplicated without any alterations [46].” ([Jahanshahi et al., 2025, p. 10](zotero://select/library/items/72F8GVAP)) ([pdf](zotero://open-pdf/library/items/QC47MLLB?page=10&annotation=QMLZXAVJ)) This feels like an enormous blind spot when mapping the usage of copy-based reuse, as it only accounts for full and total copying of the original blob. There are so many instances of reuse where the file is copied only piecemeal!; given the scale of the data, the time-complexity was expected to take about a week. Per their estimation, looking for code-based reuse at a finer level of granularity than this would be prohibitive in terms of length of time.; for mining, only looking at the original versions of the project, no derivative forks.; also statistically modeled whether or not the different characteristics of a given project impacted its likelihood of reuse; alternatively, whether characteristics of the original hosting project impact whether the blob is copied over to a new project; because they mined using the WorldOfCode dataset, they are making the claim that their empirical analysis encapsulates ‘almost the entire OSS ecosystem’; They tried to do stratified sampling across different instances of the copy-based reuse that they had identified in the project. they DO use the results from the quantitative side of the methods in order to find the sample for the qualitative side; -     three waves of surveys: first picking 24 developers for an initial survey of open-ended questions; second a big survey of 724 subjects; then a bigger survey of 8734 subjects.; - they received 247 complete responses from reusers and 127 from creators; low low response rate!; Thematic analysis of the qualitative data, looking at the different free response as well as quantitative things	in terms of adaptation, the paper explicitly cites social contaigion theory for spreading the practice of software reuse “2 Associated Risks” ([Jahanshahi et al., 2025, p. 4](zotero://select/library/items/72F8GVAP)) ([pdf](zotero://open-pdf/library/items/QC47MLLB?page=4&annotation=BCIFZUKB)) highlighting how the adaptive  action could be bad for the focal project; also though framing it in the positive sense when looking at the different importance of the project Is this currently a common adaptive action? It seems as though it is very dependent on when things are written and copied (like, decades ago) in terms of prevalence?
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
22	PSZSSAS3	journalArticle	2017	Ding, Hui; Ma, Wanwangying; Chen, Lin; Zhou, Yuming; Xu, Baowen	APSEC - An Empirical Study on Downstream Workarounds for Cross-Project Bugs	10.1109/apsec.2017.38	Technical – downstream workarounds from errors and bugs and undesirable method behavior introduced by upstream dependencies -- common workaround per prior literature -- workarounds fall into four common patterns: using a different method, wrapping the current method in a conditional per input, augmenting input to match method, augmenting method output to match downstream	OSS project developers of downstream scientific python libraries on GitHub	packaging ecosystems, Scientific python dependency ecosystem on GitHub	mixed-methods; though statistical methods were used in evaluating hypotheses or finding differences in the workarounds; manual methods were used for cross-project bugs with workarounds in the first place as well as some characterization of the bugs	the short-term adaptations are meaningfully different than the long-term fixes across the environment there’s a lot of similarity in the kinds of cross-project bugs that run into this problem/adaptation --- often when the downstream project encounters an emergent case that is untested by the upstream repository
23	V3F8FYG5	journalArticle	2018	Meloca, Rômulo; Pinto, Gustavo; Baiser, Leonardo; Mattos, Marco; Polato, Ivanilton; Wiese, Igor; German, Daniel M.	Understanding the usage, impact, and adoption of non-OSI approved licenses	10.1145/3196398.3196427	Organizational / procedural-- adoption of non OSI approved licenses or change to OSI-approved license --- the majority of the changes in either direction were from the adoption or deletion of a license (which happened to be OSI compliant) --- RQ3 provides naivete or lack of care for reasoning for moves into non-approved licenses	OSS package publishers --- some of whom have published packages with non-OSI approved licenses	governing body --- OSI is an open source regulator, vets the software license to make sure that it’s either open source or not --Also looking at compliance within three well-known open source libraries: NPM, RubyGems and CRAN; these enviroments are kinda nested within the focal environment, compliance in terms of sync with dependencies --- check of ‘success’ or anything: majority of the time, surveyed developers are not checking whether the different licenses they select are conforming, or adhering to anything	Mixed-methods: mining packages from the three different package manager environments -- pulled down a bunch of package data from the different ecosystems and looked through their license change over specified versions: a survey with the publishers of the package. sampled from NPM. open responses were qualitatively coded by pairs of researchers	not happy with the way that the different segments of the project are conflated with each other --- what use is the response of developers who use specific non-compliant licenses when the majority of non-compliance evolution is deletion or lack of license? --- different sets of populations between different methods sections of the research --- “developers might not fully understand the effect of the adaptive action that they’re taking” --- contributors ‘dont care; about the licenses they use
24	6AQY86BW	journalArticle	2022	Businge, John; Openja, Moses; Nadi, Sarah; Berger, Thorsten	Reuse and maintenance practices among divergent forks in three software ecosystems	10.1007/s10664-021-10078-2	technical - maintenance of reused software in variant forks of software projects; little active upkeep/code propogation in mainline-fork pairs in the three ecosystems that were studied. “The most used code propagation technique is git merge/rebase that is used in 33 % of Android mainline-fork pairs, 11 % of JavaScript pairs, and 18 % of .NET pairs.” ([Businge, 2022, p. 3](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=3&annotation=8ZBR7I8S)) \--- still not much in comparison to the rest of the thing; merge is the primary activity, with rebase and others less common; variant forks are consistently reaffirmed as variant through the continual publishing of distinct packages and separate code; no one is using the social coding mechanisms of GitHub to send changes up OR downstream; the PR-integration is lacking, though variant fork maintainers do send it more up than mainline sends down; There are also very few direct merge/rebase edits; though the ones that are there are often mainline -> fork changes. this is the most used code maintenance tool out of the three that were studied by the paper	maintainers of variants within software families, either as the mainline variant or the forked derivative with the upkeep of ‘downstream’ variant forks of the mainline project again, though the actions of the contributors are somewhat subsumed to the broader analysis of the ecosystem and the project; by not naming the variant maintainer, the labor of that maintainer is lost “We present the results of code propagation between family variants in terms of propagated commits, while differentiating the propagation mechanisms we explained in Sections 2 and 3.3.” ([Businge, 2022, p. 27](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=27&annotation=MGPHUZ3Q)) \--- this is actually talking about actions that maintainers are taking, whcih takes up time and effort	the “software family” the ecosystem of forks and dependencies of similar software across different projects; specifically looking at the environmental relationship between a mainline project and a divergent derivative fork   The vast majority of these families only have two projects in it; one mainline and one derivative. There are some more larger ones in JS but by-and-large, the variant families are pretty small! often the variant forks are popular -- but hte mainlines are still more popular, whcih makes sense; given that the mainline is the primary Though these are all families of like-purposed software libraries, they are pretty variable between different projects.	quantitative -- software mining across repositories  in Android, .Net, and JavaScript on GitHub Android: 38 software families with 54 forked apps; looked for Android apps that also had a listing on Google Play .Net: 526 software families with 590 mainline-fork pairs JavaScript: 8837 software families with 10,357 mainline fork pairs Using a platform external to GitHub to identify whether or not the fork is divergent or social Looking at environment characteristics -     family size, how many variant forks - dependencies , number of dependencies wthin each family - Other characteristics for Android Looking at maintenance activities (only for JavaScript and .NET) popularity metrics were largely derived from application or package downloads across different settings maintenance:     to ID code propagation, categorizing commits according to the different propagation actions	Interesting, direct integration is used more than Git “An earlier version of this work appeared as a conference paper (Businge et al. 2018).” ([Businge, 2022, p. 4](zotero://select/library/items/6AQY86BW)) ([pdf](zotero://open-pdf/library/items/GHTJQP37?page=4&annotation=Q77PWHPW)) \-- this is the more comprehensive and fleshed out journal version Not entirely equivalent across the different ecosystems that were studied. e.g. Android maintenance activities were not evaluated. Interesting that some variant forks have the same owner as the mainline repository. goes into deep specificity about testing a specific kind of edge case for their comparison script, which is good, I guess
25	YJREPLGY	journalArticle	2023	Venturini, Daniel; Cogo, Filipe Roseiro; Polato, Ivanilton; Gerosa, Marco A.; Wiese, Igor Scaliante	I Depended on You and You Broke Me: An Empirical Study of Manifesting Breaking Changes in Client Packages	10.1145/3576037	Technical – rectification of breaking changes introduced to client packages in npm by provider packages; in general, the provider fixes the breaking change in a subsequent minor or patch release --- so the adaptive action is to kind of… wait and request that the thing is changed. ( on average, in 7 days)--- when the client does adapt to address the breaking change --- sometime clients downgrade to get out of the breaking change	OSS maintainers/contributors to the downstream repository whose functionality is broken because of the upstream dependency change	dependency ecosystems/package management systems, specifically -- the proliferation of breaking changes across the dependency ecosystem ; the dependency network is the environment but the breaking change is the antecedent cause specifically, the project looks at changes and adaptation within the npm packaging ecosystem  --- npm is the primary package manager for JavaScript, with more than 1 million packages	mixed-methods; repository mining and statistical modeling of build changes in the npm ecosystem and then qualitative validation of breaking changes and the client packages’ adaptation to them.	“Client packages recovered manifesting breaking changes in 39.1% of cases, including clients and transitive providers.” ([Venturini, 2023, p. 20] This actually seems almost impossibly low, what do you mean it recovers in 39.1% of cases? Shouldn't it be recovering in like... all cases? ++ primarily looking at the environmental antecedent as the objects of study rather than the adaptation as the objects of study
26	QIVH9LJG	journalArticle	2017	Abdalkareem, Rabe; Nourry, Olivier; Wehaibi, ; Mujahid, Suhaib; Shihab, Emad	Why do developers use trivial packages? an empirical case study on npm	10.1145/3106237.3106267	technical: code reuse: trivial package reuse: rationale – trivial packages provide well-implemented and tested code from the packaging ecosystem: enables adherence to the quality testing of the broader ecosystem	application developers; professional JS developers; many long-tenured	package management systems: npm – node.js; change adheres project to well-tested and implemented environment; there are a lot of trivial packages; no project evaluation of change ‘success’ wrt environment	mixed methods: pilot survey – data mining – follow up survey – data mining to validate survey responses: sampling from prior methods step: skews to university; survey free-response answers were analyzed with qualitative coding – grounded theory methods	internal motivations for productiivty: many also stated that reuse was bad: developers aware that the change may represent existential risk for themselves; in adapting may also introduce more threats
27	TFDYF5UM	journalArticle	2011	Capiluppi, Andrea; Stol, Klaas-Jan; Boldyreff, Cornelia	Software Reuse in Open Source: A Case Study	10.4018/jossp.2011070102	technical - software reuse of FFMpeg components either through static or dynamic linking. --- only components, not the entire project	OSS contributors of projects that are reusing components of FFmpeg -- however, these contributors are hardly interrogated, identified, or named. Instead they are abstracted away from --- rather their actions are given primacy	projects that can use things from the FFmpeg project--- that have functionality adjacent enough to the project to make sense to copy; FFMpeg and its popularity is the environment that projects are optimizing their fit to	quantitative, descriptive case study -- mining projects for theFFMpeg components across their code base collected longitudinal snapshots of FFmpeg over months, got 100 data points then connected links to other uses of those components NO mention of looking at the other OSS systems that utilize the copied library? Or if it does do this, there’s little mention across the methods section	Other software reuse papers have argued against the practice as being bad --- this one argues for it! gets way too in the weeds with its work, ends up just being muddled by the middle of the results section maybe getting out over their skis in terms of identifying the different quality of build components within the system Just not a very good paper, poor communication of its methods and overly ambitious claims within its findings the actor is minimized, loses agency in the paper on this
28	XDY5INZ6	conferencePaper	2018	Lotter, Adriaan; Licorish, Sherlock A.; Savarimuthu, Bastin Tony Roy; Meldrum, Sarah	Code Reuse in Stack Overflow and Popular Open Source Java Projects	10.1109/ASWEC.2018.00027	technical -- code reuse from Stack Overflow within popular Java OSS projects--  rationale is copying from stackoverflow or other popular projects, which inherently increases technical fit with the environment --- disregarding within project copying, that is almost a meaningless metric copying between projects is larger (in size of code segment that’s copied over) and may be more prevalent?	OSS project developers for popular/well-regarded projects -- I guess this action is also at the developer/contributor level.	The most popular Java OSS projects on SourceForge and GitHub --- in 2017, which projects had the highest weekly popularity and contained requisite Java code or, alternatively, the projects that had the highest popularity on SourceForge; Also looking at all Java StackOverflow comments from 2014-2017. pulling out the code snippets from these answers	quantitative repo mining from Stack Overflow and most popular Java projects --- focusing on weekly and all-time popularity for GitHub and SourceForge metrics --- used near-OTS code reuse identification software changing parameters for a few things ; reliant on syntax and token similarity, not AST for analysis	paper finger wags about code reuse the whole time, discussing how it’s not a good practice. Adaptive change can lead to adherence to substandard environmental norms. Seems like code reuse from Stack Overflow isn’t even that prevalent? Not a very good paper honestly; never discusses when the code was reused within or in which direction --- it’s cross sectional data!! How can you even make an argument surrounding copying, which is a time-dependent action!
29	MBVCDT66	journalArticle	2023	He, Runzhi; He, Hao; Zhang, Yuxia; Zhou, Minghui	Automating Dependency Updates in Practice: An Exploratory Study on GitHub Dependabot	10.1109/TSE.2023.3278129	organizational/procedural -- adoption of dependabot--- stated rationale: managing project dependencies --- specifically, keeping project dependencies up to date ---	OSS developers for projects that have adopted dependabot --- specifically, developers who are likely to be familiar with dependabot and its workings	GitHub ---- specifically the projects on GitHub but often, the platform itself structures the environment that projects operate in --- also dependency networks, the reasoning why dependabot is used is for projects to align better with the dependencies that they’re reliant on	mixed-methods, EDA and a developer survey --- from a sample of 1823 projects, mining the PRs made by Dependabot with a survey of the projects’ developers (n131)--- sampled for the survey from the projects that were identified in the mining scenario -- a lot of researcher selection in finding maintainers who are likely to be familiar with it	a lot of analysis on whether or not adopting dependabot works, like whether the thing that people are doing to adapt is… actually working… even though dependabot is not that useful for automatic updates, many developers believe that it is useful for notifying updates
30	DGV2UJNM	conferencePaper	2020	Zhou, Shurui; Vasilescu, Bogdan; Kästner, Christian	How has forking changed in the last 20 years? a study of hard forks on GitHub	10.1145/3377811.3380412	technical and procedural --- the changing of a fork from social to hard in GitHub;the forks often start social, but then move to hard once obstacles to contributing upstream were found, whether that be unresponsive maintainers or rejected pull requests	GitHub repo owners of hard-forked OSS projects are the ones who effect the adaptive change ; though the quantitative sample looks at 15,306 hard forks on GitHub (initiated/shepherded by the owners of those hard forks), the interview sample looks at 15 owners of forked libraries --- these are long-tenured OSS contributors	forking networks on GitHub, the environmental characteristics are unresponsive upstream projects or barriers to contributing to the upstream project; the hard fork is downstream of the construction of the upstream project as external to the social fork	mixed-methods; mining and classifying hard-forked projects and then interviewing the owners of those repositories/maintainers of upstream; heuristic classifier to find hard forks, qualitative card sorting to characterize them; qualitative interviews to gain perspective -- interview sample created from identifying hard forked projects and authors	hard forks are, generally, a rare phenomenon across GitHub -- though the scale of GitHub means that the total number of these forks is actually pretty large; another verification of respondent claims: “we see little evidence of actual synchronization or merging across forks in the repositories:” ([Zhou et al., 2020, p. 453
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	procedural, license adoption and change in a wide range of OSS projects on GitHub. why do people add or change licenses? ranging from internal fixes to explicitly external decision making surrounding the demands of users	contributors/maintainers of the project; those who can change the project’s license --- the contributor is rarely mentioned or identified, things happen but the action data is the focal point, not the contributor or the contributor’s actions; some discussion of the contributor in terms of the project ‘developer’ or ‘contributor’ and some allusions to governance structures impacting how and when licenses are changed (e.g. cannot change license until subset of contributors sign off’)	he project’s broader user/dependency environment? environment of code reuse and reproduction. dependency or user environments making requests for more legibility or accessibility for license use. License adoptions and changes are adaptive to the direct requests of the environment, where the issue-created makes a demand for a certain procedural functionlaity within the project ; there are a subset of focal changes that are independent of the broader environment entirely and are solely concerned with the internal workings of the project	mixed-methods; first a longitudinal analysis of license changes within Java projects on GitHub. Then qualitative analysis of 1160 projects in different programming languages to look at commit messages and other stuff that has to do with changing the license It seems like the quantitative analysis has little significance other than to establish the scale and frequency with which this is happening across the empirical space. Right, like the meaning/depth is really in the qualitative evaluation, this just tracks how often these things happen quantitative analysis -- collected all commit data for random sample of Java projects on GitHub and then tracked commits where the (coarse-level) license changed from one distinct thing to another. in the end, identifying 1833 license changes with the quantitative analysis; matching these changes to the commit messages/issue reports qualitative analsysis: used a different sampling method to find the sample of the qualitative study; using qualitative open coding to look at the different moments of selecting code changes for projects e.g. the initial adoption of licenses and the license migration did somewhat contrived diverisity analysis of the projects in their data set to evaluate how much coverage of open source ecosystem they were able to get with their two data sets --- through the ways that they analyzed this, the data set was representative . Kind of an interesting breadth-based diversity metric analysis, trying to figure out what characteristics of broader open source are met by the projects in the data set.	big issue i have with this lies in the methods section for identifying license changes, they use two different ways of identifying license changes --- in the quantitative way they mind across code source and in the qualitative study they keyword search across commit messages it doesn’t seem like they accounted for when a project drops its license during a period of litigation surrounding the new/next license selection e.g. apache -> no license could be followed by no license -> LGPL but apache -> LGPL isn’t really optimized
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	DOI: 10.1007/978-3-642-21347-2_16	Technical – software reuse in Java projects - the reuse itself motivates the project to fit closer with the environment (using the code from the environment in the project)	Contributors to Java OSS projects in this data set	20 of the most downloaded stable projects writte in Java on SourceForge. when using quantitative methods, reuse is only compared against 22 popular Java libraries --- when using manual inspection, it can be other things but contingent on personal evaluation	mixed-methods analysis of code reuse in 20 Java projects. First using computational comparison software to ID reuse and copied code. then using a different heuristic with manual inspection to also try to ID copied code. There was a slightly different byte-code level computational comparison used in the black-box identification.	establishing how widely prevalent the code in the environment is --- e.g. 90% of projects in their data set reuse code from different projects similar to the other heinemann paper --- i thik that one was an extentions of this one “We selected 22 libraries which are commonly reused based on our experience with both own development projects and systems we analyzed during earlier studies.” ([Heinemann et al., 2011, p. 211](zotero://select/library/items/3Y9YKK5M)) ([pdf](zotero://open-pdf/library/items/KV55AS6A?page=5&annotation=SGBGKMI9)) how is this remotely comprehensive of the different libraries and environmental spaces that Java projects might pull from to reuse? I strongly dislike the methods of only selecting a specific subset of projects to test the reuse against --- given how constrained the empirical setting is, I’m skeptical of assigning too much weight to these results as representative or even indicative