From 60d4d113f71b5114157c5294568f0151eb304510 Mon Sep 17 00:00:00 2001 From: mgaughan Date: Fri, 5 Sep 2025 12:20:44 -0500 Subject: [PATCH] *finalized* analytical memos --- 090225_analytical_memos.txt | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/090225_analytical_memos.txt b/090225_analytical_memos.txt index 4c05c2d..d8e9346 100644 --- a/090225_analytical_memos.txt +++ b/090225_analytical_memos.txt @@ -1,21 +1,32 @@ 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: -economic competition doesn't quite fit but noneconomic competition does +- 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 +- 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? @@ -25,6 +36,8 @@ What methods do they use? - 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? @@ -35,8 +48,11 @@ Who are doing the changes? 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 +- 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 @@ -57,11 +73,13 @@ What are the motivations for adaptive changes/ what are the environmental pressu 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 -- TODO: where does tool development sit within this? +- 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 +- 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?