What do most studies focus on?
- 14 papers focused on procedural change; 3 papers with both; 17 papers focused on technical change 
- 12 papers focus on some sort of code reuse; this can be either dependency management or copy-based reuse 
- 7 papers focus on license changes 
- outliers include focus on things like adaptation to covid-19 lockdowns, use of GitHub sponsors, compliance with GDPR. 

What methods do they use?
- 16 papers used mixed methods to study their adaptive change; 
	- 10 used the results from a primary quantitative method to identify the sampling for follow up interviews and survys
- 10 papers used some kind of case study in their analysis, either as the primary method or as a pilot study for later methods 
	- 15 looked at small, nonrepresentative samples 
	- the rest tried to use representative samples, and some tried to even use comprehensive samples (Jahansashi)  

Who are doing the changes?
- largely mature and long-tenured contributors who are high in the hierarchy of the project 
- sometimes even those who sit above the project, in a sponsoring organization (ASF, NetBeans, Oracle) 
- sometimes periphery or environment motivates the change, rarely do they implement it (and if they do, often with loaning of social capital) 

What do they find?
- internal downsides to adaptive change (often, makes project less rational and less productive) 
- affective dislike to things that change the status quo 
- often do not evaluate whether the changes "work" so to speak; many of the changes "work" as an inclusion criteria for their study 

What are the motivations for adaptive changes/ what are the environmental pressures (or fit) that motivate change?
- issues with environmental multiplicity, as noted by Sarta et al. 
- performance, legitimacy or survival Sarta et al. p.55
- GitHub is relevant, whether or not the social coding platform is the primary envrionment (more about the boundary issues) it often shapes what tools are available
- packaging systems s.a. NPM; dependency supply chains; code reuse is its own thing because the environment is anything that /could/ be useful
- often no precipitating event (21 of the studies lack such event, with special notes that it's not always the case e.g. Vendome 2017 and 2020), 
- fit is somewhat amorphous, but sometimes the environment will directly lodge complaint (Vendome 2017, 2020) or there's a technical break (GDPR, breaking changes)  

Are there any relational components in which the environment and the project are reflexing off of each other?
TODO: 

typology of adaption:
- internal (eighteen studies) 
- market (four studies) (LIMITATION: sampling criteria may have been biased against market adaptations with pre-eminent focus on external environment.) 
- institutional (thirteen studies)
- double code on (Bogart 2021, When and how to make breaking changes) 

What are the impacts on developers and implications for future research?
- largely focusing on tool development 
- more transparency, modularity, and configurability in both governance and tooling 
- many do not provide implications to practitioners, instead focusing on the academic framing of things 

Outstanding puzzles/curiosities
- hyper-focus on tool development in the implications and recommendations of the papers 
- more studies on the implications of supra-software environments 
	- the papers in this study are older, which means that there are opportunities for new geopolitical shifts to further different adaptive changes 
- more than a few studies concerned with boundary issues; the environment are the singular, amorphous user and prospective contributor bases of the project