51 lines
3.6 KiB
Plaintext
51 lines
3.6 KiB
Plaintext
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
|