*finalized* analytical memos

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?