platform governance research network


Kind of submission:


The economic, social and cultural influences of the digital platforms has been investigated on the public level—that is, at the level at which it interfaces with end-users, whether producers, consumers or prosumers (Gillespie 2010, Van Dijck 2013, Srnicek 2016, among others). As such, platforms have been understood as semi-open: they allow for a large range of defined behaviours, usually provided through Application Programming Interfaces (APIs). These APIs act primarily as a membrane: they specify internally the ways in which one can interact with the platform, creating a clear separation between the software run by the platform holder (often privately or publicly-owned corporations, such as Facebook’s Graph API, Google’s Cloud Platform or Apple’s App Store).

In parallel, open-source development has gained more and more traction as a viable alternative to traditional, closed-source models. This paradigm, users have total visibility on the code of the application, and are able to copy, modify and (under certain conditions) redistribute it. As such, more and more private organizations adopt an open-source model for their own products, resulting in a “private-collective” model for innovation (Von Hippel, Von Krog, 2003). The clear separation that APIs enforce between developers as a part of the public and developers as part of the organization recedes from view, as each seem to become co-creators of the same code, in a conflictual process sometimes akin to openwashing (Morozov, 2013).

This contribution analyzes open-source development on a corporate-owned project as an extension of the politics of platforms into a new domain, that of the creation process of those platforms. While not devoid of politics (Weber, 2000), the incursion of private companies into open source development raises questions about the entanglement of the actual making/coding of platforms and their activity as executed software. To what extent is that incursion challenging the monopoly of platform owners, or reinforcing its algorithmic governance over developers and, ultimately, users? As developers no longer applications which interface with a platform’s API, but rather contribute to the API itself, to what extent are platforms reconfiguring into a public-facing ecosystem?

In order to examine those questions, I propose to look at two specific cases: Facebook’s React and Google’s TensorFlow. First developed internally, these two projects have been released to the public on the GitHub platform, allowing developers to inspect, use, improve and copy the code base, and they have now become dominant forces in their sector. By examining the projects’ histories and developments, its discourses (both from their original organizations, and from the individual developers), as well as the socio-technical ecosystems that have developed around them, I intend to lay out new forms of entanglement in terms of ownership, value-creation and long-term, technological path-dependency.


Platforms have historically been clearly defined in their membrane: anyone can interface, but only through their explicit, privately controlled API (Facebook’s Graph API, Google’s Cloud Platform, Apple’s App Store) that are static. However, with the rise of open-source development (even further, I’d say), and specifically the rise of GitHub/GitLab and bootcamps, there are more and more entry level people who are looking for easy frameworks to start with.

Control through co-creation?

Platforms used to control economical and cultural content, and they now control technical content in a new way (it’s not so much an ecosystem, because you can’t actually contribute to xcode)

This draws on the politics of open-source as well (just because it’s FOSS doesn’t mean it’s beautiful and perfect)

bespoke code Von Hippel, Von Krog perversion of the open-source model? weber, 2000

political agnoticism of FOSS [] what kind of culture does it create? openwashing

the mixing between open-source and closed-platforms through contribution to core project + making plug-ins



case studies:


how open is open enough -> continuous feedback and self-organizing