99 lines
8.1 KiB
Plaintext
99 lines
8.1 KiB
Plaintext
background:
|
|
how has FLOSS engineering traditionally been looked at?
|
|
- evolution / sustainability
|
|
- extending the metaphor while trying to recenter the agency of FOSS developers
|
|
- Sarta "much lke a living organism, when an organization changes sometime and survives, it looks "as if" it has adapted to its environment" (p44)
|
|
|
|
why include forking (definition of new project in relation to the environment) rather than established project
|
|
- as studies included show, the legacy resource base of the upstream project can be conveyed to the downstream project with little friction
|
|
- the porousness of FLOSS projects is a critical departure from the formal organizations that have been canonically studied in organizational adaptation research
|
|
- to frame the hard fork as `new' does not account for its relational construction with established contributors, communities, and resources
|
|
|
|
formal organizations -> open source software projects:
|
|
- adaptation may fit open source better than framing of strategic change given the heterogenous desires of different OSS developers, not everyone wants a large project
|
|
- economic competition doesn't quite fit but noneconomic competition does
|
|
- looking at the ill-defined attention and user markets that surround each project
|
|
- the attention markets create competition (esp. WRT hard forks)
|
|
|
|
notes:
|
|
- code reuse by definition is an intentional act with observable outcomes that moves the project towards convergence
|
|
- convergence is operationalized in different ways
|
|
|
|
analysis:
|
|
|
|
GENERAL PAPER CHARACTERISTICS
|
|
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 (fit, not necessarily performance driven)
|
|
- how many papers focus on boundary management? 5(He, Geiger, Wessel, Barcomb, Hsieh) ; how many papers focus on act of forking? (Businge, Zhou, Gamalielsson) more focuse on the vnrionemnt of forking
|
|
- 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)
|
|
- the methods section should be a table in the paper e.g. Floor's literature review
|
|
- the specificity of a case study is well-suited to this type of research, where intention is critical; but it leaves the papers with replicability limitations and meta-analyses with generalizeability issues.
|
|
-
|
|
|
|
INTERNAL DYNAMICS
|
|
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)
|
|
- orthodox organizational adaptation research focuses on managerial power within firms, this finds analogues within project hierarchies
|
|
|
|
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 (GDPR, scaling) though some recognition of adaptation importance (Sojer) and some even disavowall (Jahanshahi)
|
|
- often do not evaluate whether the changes "work" so to speak; many of the changes "work" as an inclusion criteria for their study
|
|
- many of the changes imply benefits to standardization, centralization, and transparency for projects
|
|
- not always; the fit isn't necessarily performance-based
|
|
- productivity and labor-saving are a main motivation of these different actions; event when convergence is intentional, labor displacement is similarly important
|
|
|
|
typology of adaptation:
|
|
- internal 18
|
|
- market 4 NOTE: sampling criteria may have been biased against market adaptations, pre-eminent focus on external environment
|
|
- institutional 13
|
|
- double code on Bogart 2021
|
|
|
|
ENVIRONMENTAL ISSUES:
|
|
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 as trigger (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)
|
|
- consequences can be widespread and may be technical reconstruction or affective shifts within the project
|
|
|
|
Are there any relational components in which the environment and the project are reflexing off of each other?
|
|
- many recommendations and suggestions from the research center on moving the environment closer to the organization
|
|
- some of the management of breaking changes in dependency networks look at the strategic nonadaption or ways of flagging internal change to the external envrionment
|
|
- where does tool development sit within this?
|
|
- recommendations for configurable and contextualized tool development are not environment-side, though do preserve project activity in a way that is interesting
|
|
- technosolutionism in HCI; why must we always build an automated tool to fix the human problem of work? (social trust issue re: dependabot and moderating bots)
|
|
|
|
Environmental multiplicity
|
|
- the social coding platforms (some proprietary) are often intractable from different environments that surround and impact projects
|
|
- environmental multiplicity muddies the adaptive analysis; are the influx of prospective contributors that need to be moderated idiosyncratic to a project? a product of GitHub's social network; does GitHub's permutation of what it means to participate in OSS (see Dabbish on social coding) exist as a relevant environment outside of a project's idiosyncratic 'market'? to what extent are any of these social coding platforms just conduits for existing developer motivations and activity?
|
|
|
|
WHATS NEXT:
|
|
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
|
|
- more clarity on the level-of-analysis within FLOSS studies, the conflation of the individual developer and the project are difficult, even if they reflect the empirical reality.
|
|
- 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
|
|
- meaningfully studying convergence is a continual issue --- especially when evaluating non-performance metrics
|
|
- against the longstanding focus on survival as evidence of adaptation or conflation of adaptation with performance
|
|
- post-hoc stories about the causal relationship between strategic change and survival are lazy and not useful; GDPR and others show adaptation can be negative on performance
|