How app companies use GitHub: on modes of valuation in the digital attention economy

ABSTRACT

This paper contributes to political economic debates on the digital economy and software production by attending to the ‘hybridity’ of economic forms in digital markets. It adds to a nascent literature on hybridity by going close to the processes of code-production. Methodologically, we ambitiously combine in-situ ethnography with netnographic observation and qualitative interviews in a thickly multi-situated analysis of Danish proprietary app developers’ use of the code-repository Github commonly associated with free and open source software (F/OSS) projects. By attending to the situated practices of everyday coding within ‘app-centric media,’ we show how proprietary developers engage in hybrid practices that both align, but are also partly at odds with the overarching frame of commercial exchanges in which they operate. We argue that these practices form part of four boundary crossing, salient modes of valuation within Danish app-development, which at once destabilize and maintain traditional boundaries between proprietary and F/OSS code. While our analysis concerns a Danish app economy, it serves to demonstrate how hybridity beyond commercial exchange forms a fundamental part of both software materiality, practices and values within situated digital markets. This, thereby, is crucial to grasping the valuations and mechanisms at work furthering the digital attention economy.

KEYWORDS:

• Digital attention economy
• valuation
• platform
• software development
• work

Introduction: code, proprietary and otherwise

This article starts from, closely analyzes, and attempts to theorize the kind of puzzling dualities and implicit tensions that emerged from fieldwork among proprietary app developers at the Danish app company Monocle,¹ when trying to understand their use of the software repository platform Github. Built on top of the version control system for code called ‘Git,’ Github is a for-profit company offering a (partly free) cloud-based service that helps developers store, manage, track, and control changes to their code when collaborating. As such, Github is widely seen, hailed, and discussed as integral to the movement and the practices of free and/or open-source software (F/OSS). What is less obvious, and what we explore in this article, is that Github also plays a significant role in worlds of proprietary software development. How it does so – through what practices and organizationally relevant modes of valuation – provides a key entrance point, we argue, to wider questions about how code production and digital economies function today.

Traditionally, boundaries between proprietary and F/OSS code have been strongly demarcated, empirically and analytically (Barbrook 1998). However, recent and insightful political-economic analyses have demonstrated how practices of ‘hybridity’ within the so-called digital attention economy are on the ascendency. Here, studies show that corporate involvement in F/OSS projects is increasing (Birkinbine 2020); and conversely, how F/OSS-like relations of gift-giving partake in circuits of market relations (Fourcade and Kluttz 2020). Specifically, the ‘mobile app-centric’ (Daubs and Manzerolle 2016) media environment dominated by the duopoly of IOS (Apple) and Android (Google) is also increasingly structured around a hybrid ‘carefully monitored attention economy’ (Daubs and Manzerolle 2016, 58) where services are offered for ‘free’ based on users ‘donating’ data resold for advertising, thereby monetizing attention. In such ways, the hybridity of F/OSS and proprietary spheres of code has arguably become constitutive of globalized, digital and app-producing relations of production.

What is less obvious, however, and what we try to elucidate in the present article, is what code-based hybridity means and implies from the viewpoint of proprietary app developers and their work. Here, while some parts of the literature portray developers like Monocle as largely ‘subsumed’ by the sheer dominance of Apple and Google (Daubs and Manzerolle 2016), others (Fourcade and Kluttz 2020) build on the hybridity trope to note that many of the on-going exchanges between platforms, developers, and users are in fact not monetized nor fully explained by market-mediated dominance relations. Relatedly, but adding to this, we show in this article through the study of Github use by Danish developers how a number of F/OSS-like practices of code sharing, collaboration, and community-building enter into and co-constitute proprietary app development in this context – a world otherwise strongly constituted around code-as-commodity, leading also to tensions of value and valuation.

In making this argument, we seek to provide a more situated and practice-based view on digital attention economies from that of extant political-economic studies. Indeed, our study builds from an initial sense of empirical puzzlement: how come, in the market context just sketched, one consistently finds professional developers in the Danish App-market engaging in F/OSS-like practices using Github? What can we learn about organizationally salient modes of valuing code and coding practices from studying the plural ways proprietary app developers use Github as part of their work? In asking these questions, we follow others in software and code studies to the effect that, to fully grasp how digital attention economies function, we need to understand ‘who makes code, and what sustains such operations.’ (Parikka 2014, 35). More specifically, we argue that by attending to the details of how Github is used to configure code (Mackenzie 2018), we gain more fine-grained insights into what ‘hybridity’ means and implies in the work of proprietary app developers. In addition, by taking a point of departure in a Danish context, influenced by a different socio-legal context than, for instance, Silicon Valley, we empirically attend to the possible variance of valuations within (and possibly across) digital attention economies.

As we unfold in the next section, making this argument implies bringing valuation studies more firmly into dialogue with the political-economic literature just sketched, to show how plural modes of valuation co-exist in alignment and tension in proprietary app development. Our empirical study draws on a multi-situated approach (Dieter et al. 2019), integrating three different qualitative data sources. Specifically, alongside in-situ company ethnography in Monocle, we draw also on Github digital ethnography or netnography (Kozinets 2019) as well as ethnographic interviewing (Spradley 1979), together allowing us a field – or market-level view. For present purposes, focusing on app companies in a place like Denmark provides, we believe, a suitable vantage point onto ‘hybrid’ valuation practices. This is true since it addresses questions of the globalized relations of app production from a distinctly situated perspective, at once heavily enrolled in and somewhat to the margins of ‘Silicon Valley-centric’ digital political economies. Our findings therefore point to practices and valuations across F/OSS and proprietary coding within a Danish app-market setting intertwined with a European legal context and possibly inflecting cultural values of international coding communities in locally specific ways, different from a US (and specifically Silicon Valley) setting which has dominated much of the literature on digital attention economies. Such a differently situated approach, we argue, re-orient attempts at theorizing the digital attention economy, opening up for attention to multiple valuations and practices.

The article unfolds as follows. The next section unpacks our notion of modes of valuation, placing this within valuation studies and setting it in dialogue with political-economic approaches. Having accounted for our methodology, our analysis focuses on four recurrent modes of valuation – tied to code configuration, collaboration, community-building, and professional ideals – which emerged as salient from across our data sources. Through this analysis, we demonstrate that proprietary developers’ everyday practices on Github at once re-create (fuzzy) boundaries of F/OSS and proprietary coding spheres (Rolandsson, Bergquist, and Ljungberg 2011), while at the same time enacting boundary-crossing modes of valuation that stand in tension with proprietary concerns. In the discussion and concluding parts, we relate this observation as a salient feature of digital attention economies writ large, suggesting that it specifies further what the hybridity of F/OSS and proprietary practices entails, in the shape of what we dub a ‘zone of attraction’ for professional coders.

From political economy to modes of valuation in the digital attention economy

From its origins, the digital realm writ large has been characterized as a ‘miscegenation’ (Barbrook 1998) between ideals of ‘free sharing’ of information and code and the enclosing and privatization of code through property laws. These two spheres have often been demarcated by practitioners in the field, such as developers, as well as by researchers, as two different and opposing fields of practices, in terms of their orienting values related to either gift-giving or commodity production (Barbrook 1998). The advent of F/OSS challenged orthodox understandings of software work as most effectively organized within markets and corporate settings (Weber 2004; Ghosh 2005). Following, open source coding and projects have been studiedly intensely, characterized both as largely ‘counter-cultural,’ oriented to purportedly political values of autonomy and community (i.e. Kelty 2008; Coleman 2012), or as spaces for barter or a modern commons (Weber 2004; Ghosh 2005). While recognizing the in principle hybridity, these studies largely focus on explaining F/OSS practices, demarcating such practices as separate from practices within proprietary settings oriented around code-as-commodity.

Increasingly, however, concomitant with real-world developments already noted, scholars have moved to recognize not only the in-principle interdependence (Barbrook 1998), but also the actual, practice-level ‘hybridity’ (Fourcade and Kluttz 2020; Elder-Vass 2016) of proprietary and F/OSS-based spheres of code production. For instance, Birkinbine (2020) points out how the largest software companies dominating much of the software field are increasingly incorporating F/OSS communities and F/OSS-like practices into their market models. Similarly, albeit more generally, Fourcade and Kluttz (2020) seek to re-conceptualize the digital attention economy from that of ‘surveillance capitalism,’ in Zuboff’s (2019) much-vaunted terms, to a set of unequal exchanges and power-laden interdependences marked by what they term ‘accumulation by gift.’ Here, the practical hybridity of F/OSS-like gift relations and proprietary market relations is put center stage, in ways that suggestively point to the many locations and forms of such hybridity as fruitful sites of study.

Overall, arguments around the hybridity of code and coding practices thus land amidst a quickly expanding scholarly field of digital political economy. Here, scholars attend to a range of different-but-related questions, including the growing significance of platforms as socio-technical intermediaries that restructure digital ‘market encounters’ (e.g. Langley and Leyshon 2017; Kenney and Zysman 2020; Srnicek 2016); the financial investment structures undergirding digital production (ie. Birch, Cochrane, and Ward 2021); and the way large-scale tech corporations exploit and incorporate voluntary or ‘free’ labor (e.g. Parikka 2014). Rather than attempt to cover this field in its entirely, we focus in our study on the more delineated domain of app development, in terms of what the hybridity of proprietary and F/OSS-informed coding practices mean and entail in this organizational work context. In addition, we situate ourselves from a point of departure among Danish app developers and companies, at a different vantage point from much of the above literature. This in turn means engaging what Daubs and Manzerolle (2016) call today’s ‘app-centric’ media environment.

In their study of the globalized relations of production, or ‘value networks,’ that constitute today’s app markets – integrated, as noted, in a digital attention economy based on the commodification of user data – Daubs and Manzerolle (2016) portray decentralized app developers such as those we study as occupying a distinct, political-economic role. This is the role, put briefly, of having their ‘cognitive labour’ subsumed by the duopoly of IOS (Apple) and Android (Google) controlling the globalized app market. In addition to controlling market access via App-store and Google play, Apple and Google actively facilitate some of the most important means of software production, such as code-languages, Application Programming Interfaces (API’s) and frameworks for mobile app creation, thereby exerting control at-a-distance. In this situation, ‘commodification forms a central part of the assemblage of app-centric media’ (Daubs and Manzerolle 2016, 64), to the extent that even in projects partly or fully committed to open source application development, ‘escaping the dynamics of cognitive capitalism is practically impossible.’ (Daubs and Manzerolle 2016, 64).

In our study, we take these political-economic observations as a key point of departure, even as we also seek to add more nuance to the portrait of app development, by focusing more strongly than Daubs and Manzerolle on what hybridity implies in practice. Hence, while there is no doubt that the duopoly of Apple and Google heavily shape the marketplace, the business models, the technical infrastructures, and the coding practices of app developers in Denmark and elsewhere, we take inspiration from arguments around hybridity to suggest that the latter practices also bear the imprints, sometimes through visible tensions, of more F/OSS-like practices and value commitments. To paraphrase the argument of Fourcade and Kluttz (2020): many important exchanges and relations active in proprietary app development, we suggest, are in fact not monetized or (directly) turned into commodities; even as they may, ultimately, serve proprietary ends. Moreover, and adding to this, this implies that we need to understand the field of value tension within which proprietary code is actually made in mundane practices.

Motivating our study, then, we locate two gaps in the existing, political-economic literature. First, on the empirical level, we need studies that focus more closely on the mundane, situated practices whereby proprietary code is actually created, also from the margins of Silicon Valley. To counter the sense, as Daubs and Manzerolle (2016, 62) put it, that code and coding in floor-level development practice is increasingly ‘abstracted away’ via processes of commodification, we thus follow others (Elder-Vass 2016; Fourcade and Kluttz 2020) in pursuing a more situated view of the various, more heterogeneous processes upholding the app-based digital attention economy. Here, as we unfold below, Github provides a highly suitable empirical entrance point, as a technical infrastructure whereby and in which proprietary and F/OSS coding practices encounter each other in particular ways (Mackenzie 2018). Second, and related, we need to conceptually expand and nuance the political-economic notion of ‘value networks,’ as well as the previously noted pre-set ideas of proprietary and F/OSS code as pertaining to mutually exclusive value-spheres (i.e. commodities versus gifts). For this purpose, versions of valuation studies, we will argue, can guide us in paying more situated attention to organizationally salient modes of valuation in proprietary coding work.

As mentioned, contrary to our initial expectations that proprietary code-work would be kept entirely private within app companies, F/OSS-like practices turned out to play a significant part in app development, as mediated not least on the Github platform. Github, Adrian Mackenzie (2018) argues, acts as a vast socio-technical assemblage bringing together a whole ensemble of code-based and related practices – of forking, branching, committing, sharing, searching and so on – whereby millions of users across domains of F/OSS and proprietary software development, as well as science, journalism and beyond, potentially or actually exchange and coordinate work. During recent years, Mackenzie shows, Github has in some ways moved towards more legal and technical openness (i.e. stressing F/OSS practices), while at the same time playing an explicit part in intense processes of commercialization (encapsulated in the 2018 acquisition of Github by Microsoft). In this view, then, Github is both a hybrid and hybridizing socio-material configuration.

Rather than asking how Github facilitates proprietary app development processes in particular ways, however, Mackenzie’s own study is interested mainly in Github-based processes of capitalization, i.e. how the sheer vastness of Github (’48 million users’) is variously mobilized as part of turning coding infrastructures into investment assets (see also Muniesa et al. 2017). While our own study thus follows Mackenzie in viewing Github as a heterogeneous or hybrid socio-material configuration, we suggest that his rather unilateral focus on capitalization practices, tied to monetary investments, actually stands in some tension with this very conceptualization. Hence, by shifting our empirical attention to how Github mediates the hybridity of proprietary and F/OSS-like app coding practices, and by bringing in more situated concepts from valuation studies (as per below), we seek in this study to expand the analytical frame towards various other-than-monetary modes of valuation at work in how app companies use Github.

As such, aided by the reworking of political-economic approaches to digital hybridity, we seek to take seriously the nature of Github as a site where a multiplicity of coding practices, institutions, and forms of valuation meet (Mackenzie 2018) – thereby acknowledging the power of capitalization, yet without a priori subsuming all practices of proprietary software development to capital, either. Ultimately, while differences and boundaries exist, we argue that we need to think the hybridity of the digital attention economy as involving, on the ground, a fuzzy zone of intersecting logics and constraints, difficult to capture in the binary of proprietary versus F/OSS (see Figure 1 in upcoming section on empirical analysis). This suggestion is again in tune with more empirically oriented software research, we argue, such as on how software libraries and other ‘boundary resources’ in software development in fact exhibit an inherent cohabitation of open source community-based, small-and-medium-size local proprietary, and big-tech infrastructural components (Fink et al. 2020; Birkinbine 2020).

Figure 1. Zones of Github practices among proprietary app companies.

For purposes of studying this zone of intersecting logics and constraints, and how it shapes proprietary app development work in organizationally salient ways via Github mediation, versions of valuation studies, as noted, provided suitable conceptual leverage. Invoking the broadly pragmatist approach to valuations as situated in concrete and material practices, we take as point of departure an understanding of valuation as ‘any social practice where the value or values of something is established, assessed, negotiated, provoked, maintained, constructed and/or contested’ (Doganova et al. 2014; 87 in Hauge 2016, 127). Along such lines, valuation studies writ large has tended towards a focus on the study of ‘valuation devices’ as socio-technical assemblages that perform the act of measuring, ranking, or rating; practices that affect – and create – valuations of what is made to count (Hauge 2016). On the other hand, approaches to valuation have sometimes drawn on prior conceptualisations of the meaning-frames of valuation, for instance as formed by ‘cultural logics’ that frame the act of ascribing value (Fourcade 2011).

In this article, our specific approach is inspired by that of Amalie Hauge (2016), who draws on organization studies to depart from the strong focus on valuation devices, yet still retains a situated attention to valuation practices by operationalizing ‘modes of valuation’ (see also Stark 2011). Modes of valuation here are not bound up to specific devices of valuation that enact explicit rankings, but follow Vatin in the more ‘mundane sense of valuation’ in ‘thinking about the value and valuation in the activity of work itself’ (Vatin 2013; 46 in Hauge 2019, 49). Hauge points out that ‘organisations are already filled with ideas of what is valuable, implicitly defined in the work of their members’ (Hauge 2016, 127). To understand the practices of valuation within an organization thus means attending to multiple, simultaneously working modes of valuation. Modes of valuation are ‘dynamic and situated in concrete practices, constituting what counts as valuable’ (Hauge 2016, 129). Through this focus, one attends to practices that are assessed according to a common frame of reference, what can be understood as ‘a grammar of assessment’ (Hauge 2016, 128). Sets of practices thereby attain collective recognition of their value linked to explicated valuations. With this approach, we can attend to multiple ‘modes of valuation’ within our field of research, without a priori analytically determining coding practices as either F/OSS or proprietary.

In sum, our focus in this article on the diverse modes of valuation at stake when proprietary app developers in Denmark use public Github as a code-sharing repository is motivated by a twin attention to situated processes of app development, on the one hand, and to the analytical possibilities thereby opened up for grasping better the hybrid traits of wider digital attention economies across geographical areas, on the other hand. We turn now to account for the methods we have used towards this twin aim, branching out from in-situ fieldwork in Monocle to encompass a broader market level.

Methodology: more-than-platform ethnography

Overall, our methodology combines the depth of in-situ observations, pertaining in our case to the company Monocle, with the width of mapping practices across a broader socio-technical field, in our case pertaining to Github use among Danish app companies more generally. Moreover, along both of these axes, we combine offline and online forms of data. For Monocle as a well-delineated field-site, we combine long-term in-situ ethnography with netnographic observations on their Github profile; and for the wider mapping, we again use netnographic Github observations but combine them here with strategically selected, ethnographic interviews covering a spread of app companies. Together, we argue, these qualitative method combinations strike a suitable balance between depth and width, allowing us to both discover and ground salient modes of valuation.

The in-situ observational material for this article builds on five months of fieldwork at the company Monocle, undertaken by the first author. The first author closely observed daily coding practices of the developers within the company and conducted semi-formal interviews (Spradley 1979) with all of them (the chief technical officer (CTO), senior and non-senior developers). Ethnographic examples in the analytical sections include both senior and non-senior developers. Working in parallel and utilizing the methodological affordances of GitHub for netnographic study and analysis (Turner 2019; Kozinets 2019), the second author combed through the Github profile of Monocle, including its repositories and sub-folders of code-snippets and documentation. The data-collection process formed an iterative process between these two angles of observation which mutually informed each other, such that questions arising from in-situ fieldwork led to new directions for netnographic analysis, and vice versa.

Through this dual entry to following practices across the online-offline divide within Monocle, we are inspired by what Dieter et al. (2019) call a ‘multi-situated’ approach to app studies. By this term, we understand for our purposes the attempt to make visible different and always partial and situated aspects of the infrastructural settings of specific apps, their development, circulation, and use as mundane software, in this specific company. This approach of ours responds, we believe, to the situation described by Dieter et al. (2019, 13) in terms of ‘obscured stakeholders’: The embedded nature of different infrastructural settings (i.e. Github) affords specific vantage points. The ability to tack back-and-forth between observations of annotated code (netnography) and observations of coding situations (ethnography) allowed us to better unfold the coding practices of Monocle app developers. More specifically, the combination has allowed us to pose informed and better-suited questions in the ethnographic situation.

To extend and qualify the material arising from our in-depth fieldwork we gradually expanded the width of our material online and offline, ending at a point of saturation where themes and patterns would start to (re-)emerge (Glaser and Strauss 1968). This expansion again followed an online and an offline trail. Online, we mapped Danish companies engaged in building apps and reached a total of 38 companies in Denmark, tentatively categorizing these according to five (ideal-)types according to size and function in a value chain or ‘value network’ (Daubs and Manzerolle 2016) sense. Monocle a small medium-sized company, after Danish company standards, turned out to be comfortably located in the middle in terms of size. We then conducted netnographic analysis of the Github profiles of 11 companies, making sure to cover different types of companies. Material analyzed included repository structures, files, code-snippets, annotations, and so on. Concurrently, we conducted (targeted) interviews (Spradley 1979) with developers (both CTO’s, senior and junior developers) from different types of companies on their company’s use of and their own engagements with, and perceptions of, Github. After conducting six interviews, and combining with the Github-based netnographic material, we experienced a point of saturation, whereby new observations and new interviews seemed mostly to confirm our emerging grasp on the four distinct modes of valuation in proprietary Github use. Overall, this second phase of our data collection again constituted an iterative process, bringing new questions back-and-forth between interviews and netnography, but also spurring new avenues to pursue in the fieldwork and netnographic analysis of Monocle.

To summarize, our methodology for exploring why and how companies engage publicly with Github has prioritized a multi-situated, mixed-methods qualitative approach, allowing us to distill four modes of valuation through an iterative process of reading and interpreting across materials. Importantly, these four modes of valuation form a cross-section of the practices in which any particular company, such as Monocle, engage on Github. While most of the companies in our analysis engage with several of these modes of valuation, not all companies necessarily engage with all modes. The aim of our inquiry, in other words, has been to explore and conceptualize the form and valuation of practices related to publicly engaging with Github among proprietary app developers, and not to assess the quantitative distribution or representative aspects of these. On the bases of our combining depth and width in the qualitative inquiry, however, we do claim that our analysis captures the most important modes of valuation active in the Danish app market as a socio-technical field – and, likely, also in wider geographies.

Valuation practices in proprietary Github use: empirical analyses

As should be clear from our discussions so far, Github use – even in the delimited field of Danish app companies – is a diverse phenomenon. For purposes of clarity, in Figure 1, we attempt to initially capture the ‘zones’ of hybrid Github practices that we encountered in our fieldwork. The figure distinguishes two ideal-typical axes of variation. One axis describes the range from private to public code. Here, the latter connotes publicized code under F/OSS licenses, i.e. code that is usable by others; whereas private code is either non-publicly available on Github or entirely proprietary. On the other axis, we distinguish the use of Github for internal project coordination from ‘general exchange.’ This continuum encapsulates, on the left hand, the use of Github’s versioning systems for a demarcated project, where participation is heavily controlled. On the right hand, we locate a sphere of practices that contributes to a non-centrally controlled collaboration, where the aim is to contribute to a non-definite group or ‘community.’

In our interviews with developers, the practice associated with the bottom-left corner of Figure 1, i.e. where companies are not present publicly on Github (except perhaps for a profile page) was widely seen as ‘expectable.’ The key argument among our interviewees was that for companies, it is ultimately about making money, and publishing code on Github is not essential to their business. Conversely, the ideal – if not always the practice – of F/OSS is encapsulated by the upper-right quadrant. Our main interest in the analysis that follows, by contrast, lies in the belt of practices going from the top-left to the bottom-right corner. Regarding the field of practices as zones with two continuums along two axes, rather than a singular contrast, highlights here the fact that a range of important practices fall in-between the ‘closed-off proprietary code’ versus ‘the F/OSS domain’ dichotomy.

In order to be publicly presentable and workable by others, code needs to be documented, such that it follows more or less established conventions. Therefore, publishing code in the public sphere of Github requires for companies to spend time and resources. In addition, from a purely competitive point of view, this may well seem, at least initially, as entailing a risk of handing their competitors a leg up. The practices and modes of valuation that we will now unfold all work against these constraints, signaling, we believe, that they are not epiphenomenal or incidental, but rather in many instances integral to company strategies. More specifically, we see the four modes – of code configuration, collaboration, community-building, and professional ideals – as sitting within an ambivalent domain shaped by the ideals and everyday working practices of developers as well as by the strategic, mainly capital-oriented interests of their companies. This is a point we return to in the subsequent discussion.

Linking code: configuring dependencies smartly

Foundationally, Github acts as an infrastructural platform for the linking of code-libraries (packages) and facilitating easy access to software tools; both elements that form routine parts of creating apps in private companies. As we will show in the following, the first mode of valuation accordingly stems from the infrastructural boundary space that Github provides which allows developers to create what they see as ‘good’ code by managing the ‘linking up’ of code – or configuring dependencies – in a particularly ‘smart’ way.

A typical example of the way code pieces are linked and built on other code pieces is illustrated in the screenshot below (Figure 2),² taken from our netnographic material detailing the metadata for a code-repository named MonocleRxSwift. Visible in the screenshot, MonocleRxSwift has several so-called dependencies (necessary linkages), amongst these are code-libraries created by Monocle themselves – such as MonocleServices – and code-libraries such as RxSwift, formed by the open-source community ReactiveX. MonocleRxSwift exemplifies how app-companies routinely build on their own libraries, alongside others’ code-libraries, to tailor their own software for building new apps. Via the Github platform, libraries from different sources, F/OSS and proprietary, can thereby be connected in order to build new code.

Figure 2. Proprietary and F/OSS dependencies configured for building new app code.

Such code-linking practices form an integral part of contemporary code development, where apps are built out of a patchwork of pre-existing and tailored software packages. Github provides a socio-technical infrastructure in which code-libraries and snippets can be linked up in a manner that controls the linkages, while also allowing for incorporation of later developments in the packages that form part of the app. This makes Github one important venue, albeit not the only one, for enabling app-companies to engage in the wider ‘value networks’ of application development (Daubs and Manzerolle 2016). At the same time, this linking and configuring code requires constant work of maintenance on the part of professional coders.

Turning to an example, let us follow the events on a typical afternoon at Monocle. Senior app developer Michael is refactoring the code for one of their existing apps. In other words, he is optimizing the code so that functions are grouped together, the code becomes easier to read, and easier to scale up. ‘I want to go back and kick myself when I see this,’ he exclaims as he regroups code snippets. He originally built this code himself a couple of years ago, and its structuring now seems far from ideal. As he proceeds, Michael changes between re-working the private project code and clicking over to the open foundations on Github, such as MonocleRxSwift, onto which the private part is built. In updating the project, he notices that something is not working with MonocleRxSwift, to do with Cocoapods, a program they use to control the connections between code-libraries.

Following Michael’s work on the computer attests to the speed of ‘linking work’: In 10 min, he installs and incorporates pods MonocleRxSwift into the apps’ configuration file. Searches for ‘resolver cocoapods’ via Google, finds it and downloads. Saves the changes to Github as ‘added resolver.’ Saves another change as, ‘Updated pods-spec,’ and updates the version on Github from 2.0.1 to 3.1.2. Thinking he has solved the issue he runs the code for his project but ‘Generic S not found,’ the log tells him. While mumbling ‘that’s not true,’ Michael determinately clicks through the many file-folders that is the app project. Shortly after, he realizes that he seems to face a compatibility issue. Shifting back and forth between his project and the Github repositories of RxSwift and Realswift to check which version he has installed, he manages to align the different libraries and his project to compatible versions. Done, he saves the changes on Github and his project repository as ‘added pods to repos.’

When asking Michael a couple of months later about this updating work, he could not recall the specific incident. To a professional coder, the idea that you need to do this kind of compatibility work, updating the pod-specs from version 2.0.1 to version 3.1.2, is all common-sense and routine. As such, the episode illustrates the recurrent nature of this work. However, because code-libraries can come from different sources, and often still are alive – in the sense that developers add new updates to these libraries – companies like Monocle must make sure that such updates do not ‘break their apps.’ The management of boundaries and linkages between libraries therefore becomes an important task. F/OSS programs such as Cocoapods help manage these boundaries, giving control to the app developers, and are popular in proprietary software development. Such programs build on the infrastructure which Github provides, by being developed in open-source repositories on Github, and by Github facilitating the linking to such software. Github, in short, facilitates links on several ‘orders’ of code-management and facilitates that F/OSS code becomes part both of libraries and of the overall management of code-libraries.

However, the relations of specific programs and their connection(s) to Github is partly opaque or obscured within the overall socio-technical assemblage; including, it seems, occasionally for coders themselves. Different developers we interviewed had different assumptions, for example, on the question of whether one does, or does not, need a public Github profile to use F/OSS programs such as Cocoapods. Also, the snippet of ethnographic observation highlights the different temporalities involved in iterative processes of updating. Whereas crashes in an app may lead to an urgent update, refactoring of a project might lead to updates when the company is less busy; or new requirements from vendors like Apple Store or Google Play may set a future deadline for updating code-libraries. The traces of such continuous development of code-linking work are only partly captured through the commit and push history of Github repositories. However, by observing these practices in action, it becomes apparent how finished apps emerge here as fragile ‘things’ that require continuous update work within opaque settings to become functioning infrastructure (Star 1999).

In short, one important mode of valuation that Github facilitates for the app companies we studied stems from its role as infrastructural boundary space, in which connections between code-packages can be made and continually managed through update-style maintenance. The configuration for code-projects on Github allows for practicing a certain coding aesthetic, whereby code-relations are seen as being managed ‘smartly’ (cf. Coleman 2012).

Collaborating on repositories, feedback, and collective projects

In a second mode of valuation, Github affords value by structuring direct and indirect collaborations on code-projects in-between proprietary developers and companies. As we will show below, developers and companies value the particular ways that Github allows them to exchange code and knowledge, across companies. This mode of valuation thereby concerns the way proprietary companies collaborate within and across projects in an F/OSS like manner.

In the screenshot below from our netnographic material (Figure 3), we present an example of how repositories become linked in a directly collaborative setting; a relation firstly apparent (to us) when looking through the commit-history. To use the code in this specific Monocle repository, called beacon-bacon IOS, it is necessary to set up an API key. The API key, in turn, is sourced through code from a different company, namely INA. The use of the app-code on Monocle is thereby linked directly to the API-code on INA, indicating a collaboration.

Figure 3. Netnographic signs of direct collaboration between companies.

Talking with interlocutors in Monocle who took part in this software project, they confirmed our interpretation of intercompany collaboration. Specifically, while INA was responsible for the ‘backend, API and CMS,’ Monocle created an Apple and an Android app. The two owners of the companies had worked in the same office previously, and thereby gotten to know each other personally. Later on, this led to collaborations on various projects. Interlocutors pointed out how it is indeed common that multiple companies are part of a single software project, contributing respectively the back-end (data-structuring) and the front-end (interfaces) within the development of an app. Often one partner is the lead and ‘out-sources’ part of the project to others. These relations manifest in different ways, as companies may variously sit together in the same offices, interact via digital mediation, or out-source a job for an hourly rate without much intermittent interaction.

Some select companies in our netnographic material host several open Github repositories, seemingly aimed towards becoming a back-end hub for multiple and layered collaborative projects. However, for Monocle, as with many other companies, using public Github for these types of projects was not typical. The use of Github to develop projects in this publicly and directly collaborative way is dependent on all parties – notably including the customer – agreeing to such a Github presence, and is considered more risky than working in a private setting per default. On the other hand, by working through public Github, the partners have the benefit of being able to see the other partner’s code, and get easy access to knowledge of code updates and changes. This creates increased transparency for the project partners, compared to working with other interfaces and communicating back-and-forth between back-ends and front-ends via other channels.

Key to this type of direct collaboration, in sum, is the differentiation of specializations in collaborative work on a common project, where companies do not (openly) compete. However, we also encountered a different and seemingly more indirect type of collaboration. Here companies fork others’ code-repositories, that is, they ‘clone’ code that they find useful from other companies. Besides the value that forking provides in accessing a ‘nice’ bit of code to solve a problem, developers describe the opportunity to engage with colleagues across companies as a positive value of such a practice:

I use Agency [other company] for our transactions on the app. Their (software) looks at the localization inside the app, to see which language it needs. It’s cool that if I experience a mistake, then I can go in and make an issue on their code, and then I get feedback on it.

Interviewees would point out that such mediated exchanges help both the code-provider and the one forking the code. In part, this mode of exchanging information on specific coding problems follows logics known from F/OSS collaboration (Rolandsson, Bergquist, and Ljungberg 2011). However, in contrast to F/OSS projects, the aim here is to use experiences from others, to further the companies’ own separate and proprietary code-development and projects. In the understanding of our interlocutors, in short, the two types of collaboration practices detailed – direct and indirect – both serve to further the development of a company’s production of ‘good’ code for their own app-projects.

To further sum up across the two sections so far, on linking code and collaborating on projects, what we have described are modes of valuation attached to Github’s affordances as spread out mainly on two key functions, of materially linking code and forking code, respectively. Both the first and second register help further a company’s aim of creating good code for particular app projects and are valued in reference to developing code effectively or ‘smartly.’ We turn now to analyze two further modes of valuation, which are tied less to particular coding projects and more to wider socio-technical affordances in enacting community (next section) and creating a specific company reputation with appeal to a certain professional ethos (sub-section four).

Enacting a developer’s community of exchange

Our Github netnography material indicates that many company-based repositories are in fact never picked up by others for collaboration or joint development. Most repositories have few or no followers, and fewer yet have branches or forks. On first sight, it might therefore seem as if these companies fail in their attempts with publicizing code. Through this third mode of valuation, however, we will argue that such a perception would be too hasty and narrowly functional. It overlooks how engaging with a developer’s community constituted through the everyday routines of coding is valued alongside ideals of (freely) sharing code among a community of peers, this we thereby term enacting a developer’s community of exchange.

From the Github data, we found that many app-company repositories present themselves as finished projects. We show a typical example below (Figure 4): the so-called MonocleFoundation, a library for apps which Monocle uses as a base for new projects. The extent to which Monocle and other companies encourage further collaboration on such repositories, by for instance descriptions and guidelines for commits, is negligible. The implication of this that they are not explicitly aimed towards developers outside the company was confirmed in our field and interview material. When not about actual engagement with other developers, interlocutors would sometimes be hard pressed to explain, not so much why they publish things on Github as such, but why they would publish a specific repository. They would respond with short statements like ‘it is nice to do’ or ‘it is to give back to the community.’

Figure 4. Proprietary software companies giving back to ‘the community.’

However, when talking to developers on a more general note, on why their companies would put up these templates and tools, typical answers would engage the qualities of a specific developer community, of which they felt part. One CTO explains it in the following way:

One could say that the developer community is a bit funny […], because we share so much […] knowledge and code [with each other]. This culture is also why there is so much progress, in my opinion, in our field. Constantly new technologies emerge, people share their code. If it all were closed source, I don’t believe we would have as much progress as we have now. […] [A]nd Github is a platform that has a big role in this […].

This CTO points to something we found time and again in our material: sharing code ‘is something we do,’ it is part of constituting and enacting a sense of a developer’s community.

To illustrate the point further, let us turn to the following episode from a common situation in Monocle. App developer Christian is about to begin a new project. This will be the first time he is beginning an app project from scratch. Currently, he is reading the website Medium on one screen and finding example apps on Github on the other. He explains that he wants to ‘get to know the structure and test it out.’ ‘We use MVVM (Model View View-model) modelling […] I haven’t built it from scratch before.’ When testing, Christian is using an app-simulator on his screen. In this setup, he can look simultaneously at the code and the way the app works, whenever he makes changes to the code. On the last screen, Christian has Stack Overflow open, intermittently looking up specific changes to the dummy app – such as an optimization function.

Github, as the episode illustrates, is commonly used to find test-apps and longer pieces of code, in situations where companies want to start a new project. In such situations, the found code-pieces are not deployed directly into developer’s own code, but rather serve for reference and inspiration. Conversely, this can be reciprocated by putting up your own test-apps or templates for others to see; something the android developers at Monocle in fact did a few weeks later. Here, Github sits amidst a wider media ecology of digital platforms and sites such as Stack Overflow and Medium which developers consult on a routine basis for different and specific purposes. Github, as the example suggests, is mainly consulted at the beginning of new projects for templates and examples, or for libraries that can solve issues in smarter ways. As one coder told us only partly in jest: ‘coding is about writing as little code yourself as possible.’ During ‘down-times’ of less hectic work coders skim medium – or framework-specific sites to see if there is something new to be aware of or a new tool to implement from Github.

In these processes, developers are continuously engaging in exchanges – reading or googling examples, or posting answers for others. These exchanges happen in a shared and formatted language of code and technical knowhow and on a relative limited number of common sites. As such, they serve to foster a wider sense of an ‘imagined’ developer community with which one is engaged, even without knowing the actual participants (or at least only a small portion of them). While ‘the community’ may sometimes consolidate around specific technologies, such as the laravel framework, its boundaries are generally fuzzy. When speaking, developers often refer to an encompassing ‘developer community’; and many of the key sites play into this (self-) conceptualization. Take for instance Github’s self-description: ‘GitHub is home to the world’s largest community of developers and their projects.’³

The community thus enacted is closely related to positively valued ideals amongst developers we interviewed, such as technological progress and openness. On an embodied level, engagement with ‘the community’ as a form of continual exchange arguably foster a kind of moral debt, prompting the need to ‘give back’ (Graeber 2014). Compared to the other modes of valuation, the practices here most closely resemble classical reciprocal gift exchange relations (Mauss 1997 [1950]). However, ‘giving back’ does not refer to fostering relations between specific individuals, but rather to enacting a partly imagined ‘community.’ Publicizing templates for apps on Github, in short, is a way to enact a continual commitment to this ‘community’ in daily practice – in ways that link, also, to broader organizational and professional questions to which we now turn.

Making a F/OSS-like name: linking organizational to professional ideals

Whereas the engagement just analyzed sits as part of everyday and partly individualized routines, there are also Github-based practices through which a company can attempt to ‘make a name’ within this wider community. Such reputational practices, and the way they link into more-or-less shared ideals of a professional ethos of ‘F/OSS-likeness’ even among (Danish) proprietary app developers, forms a distinct mode of valuation in Github use. This mode of valuation – making a F/OSS-like name – is thereby premised on linking what are arguably company aims (such as getting qualified labor) with professional ideals among developers.

From the netnographic material, it is evident that some Danish app companies have spent a significant amount of resources on stream-lining and building up their Github repositories and profiles. An example of this can be seen with the software consultancy company Agency (Figure 5), whose Github repository names are cleanly formalized and whose repository descriptions are well worked through. In addition, their Github profile contains information on the work they have done for open-source projects and the open-source community events they have participated in.

Figure 5. Proprietary app companies signaling proximity to the open-source world.

As mentioned, developers generally do not expect this kind of stream-lined profile from a proprietary company; but it is appreciated within the broader developer community, signaling as it does an ethos of openness. As noted, company-based tools commonly found on Github are made primarily through investments of ‘downtime,’ i.e. time in which developers are not engaged with a paying customer-project. Through such practices, developing code becomes a way for a company to invest in their own code-resources for future projects. However, the level to which some companies (like Agency) go in building and curating F/OSS-related code repositories on Github arguably goes beyond a purely functional, future investment. At stake, rather, are also broader material-symbolic questions, for the company and for individual developers.

At Monocle, the guys⁴ would regularly discuss new libraries and developments, echoing how open-source templates and libraries are commonly evaluated amongst developers. One day, the three guys sitting at ‘the android isle’ are talking about the pros and cons of programs that can help them manage animations for apps. Starting the discussion this time is Mads who has found a newly developed library, but is vary because you ‘quickly burn your fingers,’ that is, waste your time. ‘It is annoying to use three days on it and then it turns out to be a turd.’ At the company, they currently use Airbnb’s open-sourced framework Lottie, ‘a nice library.’ ‘You know it was developed by AirBnb?’ As Mads points out to the others, ‘I guess they want to “make a good name.”’

Indeed, this type of positive attraction towards new and F/OSS-based technologies was a regular part of the conversations at the company and a common theme in interviews, when asked about what was important for being a developer. App-developers would often mention that the field ‘moved fast’ and it is necessary to be on top of it. Not unlike among F/OSS coders and hackers (Coleman 2012), making a ‘nice’ piece of open-source software that solves a common problem or optimizes something is potentially a way to be known also in the proprietary part of ‘the community.’ Engaging in such work is also something that attracts certain developers, who strive to embody ideals of openness; and it was generally appreciated by all developers we talked to, who value openness as an ideal:

I know people who took pay-cuts […] [to] work on something in open source. […] [L]ike, imagine that you work as a chef in Noma [Michelin-starred restaurant]. You’re working at an incredible restaurant. […] But […] [t]he only people who can eat at Noma are some secret people […]. So I tell my friends, […] you can’t taste it, you can’t even understand what kind of dish I make. You just have to trust me it’s fucking delicious. […] [W]hat would you do, to get to work at a Noma where you could post stuff on Instagram and invite your parents to come and eat and take your friends? And … brag to all your competitors.

In part through Github use, some companies are apt, it seems, at linking up to the kinds of professional developer ideals expressed in this quote. Doing so, they create a ‘good name’ for themselves, aligning their company reputation to a wider, socio-professional ethos.

In fact, select companies such as Agency become hubs in their own networks of open-source code: smaller companies use these F/OSS-based repositories – and through the ensuing interaction also end up contributing to the development of such code-projects. This kind of practice means that companies ‘are in the right places,’ as one interlocutor described it. Github, in short, becomes a platform where relevant others can recognize companies according to values widely held within ‘the community.’ Investing in open-source code here implies investing in future relations, not least because such strategies may help attract talented coders – for whom there is an intense competition in this field, especially in the sense of ‘local talent’ with Danish-language qualifications. More generally, investing in F/OSS-based code is a way to make a ‘good’ name, establishing oneself as an ‘ethical’ player aligned to ideals of openness and transparency.

Discussion: hybrid zones of attraction in the digital attention economy?

In the preceding analysis, we have documented four organizationally salient modes of largely non-monetary valuation at work when proprietary app developers use Github – in ways partly aligned to, but also partly at odds with, the overarching frame of commercial exchanges in which they operate. To bring this observation back to the literature, our central suggestion is that attending more closely to the everyday practices of proprietary coding, in and beyond Github, allows for a fresh take on wider debates on the ‘hybridity’ (Fourcade and Kluttz 2020) of the digital attention economy, and of its ‘app-centric’ (Daubs and Manzerolle 2016) manifestation in particular, when it comes to relations between proprietary and F/OSS-based coding practices and values. In this section, we spell out and discuss these wider implications of our analysis via the notion of a hybrid ‘zone of attraction’ within which code for the digital attention economy comes into being.

App companies and their employees, we show, routinely engage with a range of Github-mediated, coding-based modes of valuation that are if not wholly ‘other’ to the commercial process, then at least connect to it only indirectly, partially, or tediously. Indeed, based on our analysis, we argue that a set of largely non-market-based modes of valuation to do with ideals of community and openness serve at once to create and maintain the boundary, as well as to configure a number of routinely boundary-spanning practices, between the spheres of F/OSS and proprietary code. These modes of valuation are therefore crucial, arguably, for understanding the emerging hybridity and variance in the core economic forms constituting the app economy, as well as the way that ‘values’ (in the plural) transfer across the ‘value networks’ (Daubs and Manzerolle 2016) of the digital attention economy as a whole.

When going close to the practices of producing proprietary code, it becomes apparent that the professional ethos and socialized practices of developers, with their resulting valuations of open and F/OSS-like coding practices, intertwine with and co-constitute but may at times also clash with the standard economic interests of app and other digital companies. In the existing (‘critical’) socio-cultural literature (e.g. Daubs and Manzerolle 2016; Mackenzie 2018; Langley and Leyshon 2017), this observation would in turn serve as a prelude to the widespread and indeed pertinent observation that ideals of open and collaborative creativity alive among professional coders is roundly instrumentalized as ‘cognitive labour’ in the service of capital accumulation in the ‘oligopolistic’ app economy dominated by Apple and Google. Indeed, as should be clear from quotes presented for our analysis, awareness of such potentially exploitative traits of the economy in which they work are quite alive and well among proprietary coders themselves.

What we propose, in turn, is not so much opposed to as perhaps perpendicular to these ‘critical’ observations (by analysts and actors alike), along the lines of the ‘accumulation by gifts’ highlighted by Fourcade and Kluttz (2020). Because the digital economy of app development depends, we argue, also on a set of non-market-based practices and modes of valuation, the everyday (re-)production of which it only partially but not fully controls, it fosters within itself a set of relative spaces or zones beyond commercialization per se. Or, better put, the very socio-technical boundaries demarcating digital capital from F/OSS-like relations are themselves routinely criss-crossed as part of proprietary app development. Ideals of ‘giving back’ to ‘the community,’ for instance, and the sense of moral debt it entails, or ideals of ‘smartly’ managed code and related update-work, are literally built into infrastructures of software connections, where certain pathways lure and push towards practices of opening op code as much as is possible within app companies. In other words, the multiplicity of valuations are built into the material infrastructure, are part of everyday routine practices, and are re-told in explicated evaluations of code and code-practices. As such, they are ‘baked into’ the very core of the digital attention economy. This is true, even as these practices ultimately depend, clearly, on their abilities to black-box, fend off, and sell proprietary code. These tensions and fuzzy boundaries is what we try to capture as a ‘zone of attraction’ towards ‘F/OSS-likeness’ within core work-spheres of the digital attention economy.

Hybridity, then, cuts both ways: even as worlds of F/OSS coding are increasingly being commercialized and instrumentalized, so too worlds of proprietary coding, we suggest, are increasingly ‘F/OSS-ified,’ becoming infused with practices and modes of valuation traveling in the other direction (Birkinbine 2020). What this implies for wider attempts at (re-)theorizing the digital attention economy, we believe, is that all such moves should start from acknowledging the consequentially situated, geography – and process-infused character of those boundary-blurring infrastructural configurations that today serve to separate and intrinsically link worlds of proprietary and F/OSS coding (Fourcade and Kluttz 2020). Quite likely, the fact that our analysis is situated in the Danish digital political economy, at once relatively marginal to but integrally woven into Silicon Valley-centric commercial value networks – and simultaneously subject to a relatively privacy – and rights-sensitive national and European governance setting as per the GDPR – matters to the analysis we have presented. We strongly encourage follow-up comparative work as a key avenue for corroborating and delimiting the modes of valuation that our analysis has brought to light, thereby also moving in the direction of situating digital attention economies in the plural.

Conclusion: situating code and its multiple modes of valuation?

In this article, we combine in-situ ethnography with netnographic observation and qualitative interviews to provide a thickly (multi-)situated analysis of recurring modes of valuation at work when proprietary developers active in the Danish app market make bits of their code available on the code-repository platform Github. While practices of publishing code on Github might be seen as contrary to standard expectations, we suggest that they are not for that reason epiphenomenal or inconsequential to how the wider digital attention economy is shaping up. Rather, as a ‘platform of platforms’ (Mackenzie 2018), we show how Github serves as a hybrid infrastructural assemblage for configuring a variety of everyday practices in proprietary code-making – of linking up and collaborating on code, and of enacting a sense of community and its proper professionalism. These largely non-monetary practices and modes of valuation, we suggest, work as a ‘zone of attraction’ at the heart of how proprietary code is made.

In doing so, such Github-based practices also serves to configure wider and indeed globalized moral-political economies and ‘value networks’ (Daubs and Manzerolle 2016) vis-à-vis each other, at once demarcating and putting into specific relations the spheres of companies and software radicals, big-tech corporations and F/OSS-based subcultures. Such awkward and tension-filled encounters are mediated centrally, we argue, by app developers whose market exchanges are centrally influenced but not entirely overdetermined by the globalized duopoly structure of Apple and Google. Attending closely to the practices of app developers in places like Denmark, we argue, allows one to recast and contribute to these wider political-economic debates, situating them more carefully in particular geographical, socio-material, and organizational work contexts. In the process, arguments around the constitutive ‘hybridity’ (Fourcade and Kluttz 2020) of proprietary and F/OSS-based relations in the digital attention economy also gain more texture, we suggest, by showing what hybridity actually means and implies in settings of app development. Importantly, it allows for a more differentiated conceptualization of value tensions, whereby hybridity is part at once of maintaining and destabilizing boundaries between proprietary and F/OSS code.

In the spirit of this overall argument for situating code and its modes of valuation, we are reluctant to draw strong conclusions on the generalizability or otherwise of our substantive findings, based as they likely are in part on specificities of the Danish app market. On this note, we invite follow-up research to corroborate or challenge our specific portrait of the ‘zone of attraction’ and attendant modes of non-monetary valuation at work in proprietary app development elsewhere, and indeed at other sites across the value networks of the globalized, app-based attention economy. That being said, and in conclusion, we do believe that our Denmark-based analysis carries import also for other settings, not least when it comes to understanding the emerging political economy of digitalization in Europe writ large in the post-GDPR era (cf. Smith 2019). Moreover, and on a methodological note, we hope that our analysis may inspire others to engage more concertedly in similarly ‘multi-situated’ (Dieter et al. 2019) app studies, tracing value networks as they unfold across the online-offline divide. In this respect, along with others (Mackenzie 2018), we argue that Github deserves to be recognized as a key site of emerging platform economies – a platform whose very multivalence may be emblematic, we suggest, of wider tendencies in the field.

Acknowledgements

We especially want to thank all employees at Monocle for granting us access, time, and encouragement for the field-based part of the research reported here. Further we would like to thank colleagues at DISTRACT, the Center for Social Data Science, and the Department of Anthropology for carefully reading earlier versions and giving valuable input. Lastly, we would also like the two anonymous reviewers for generous and helpful suggestions.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

This work was supported by the H2020 European Research Council (grant number 834540) as part of the project 'The Political Economy of Distraction in Digitized Denmark' (DISTRACT),

Notes

1 This is a pseudonym. Throughout this text, we take appropriate steps to preserve anonymity for all involved parties.

2 In fact, what we present here is a ’mock’ screenshot, (re-)created by ourselves to preserve the anonymity of the company and its employees.

3 [https://github.com/, accessed 2020.11.11.]

4 All developers at Monocle at present are men. While beyond the scope of our present paper, this observation and its implications for gendered and other actual and potential exclusions at work in app development writ large, deserves follow-up analysis.