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