> For the complete documentation index, see [llms.txt](https://meet-coop-1.gitbook.io/handbook-trial/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://meet-coop-1.gitbook.io/handbook-trial/1-principles/commoning/classic-floss-peer-to-peer-governance.md). # Classic FLOSS peer-to-peer governance Here we consider the most obvious frame for governance in a digital infrastructure - the P2P mode of free-libre open-source software development and use. > Work in progress. Updated: 11nov2021 > > This page is work in progress. But here is a **15min video** which locates this model within the four models of governance: [Governance & contribution in commons](https://de.meet.coop/playback/presentation/2.0/playback.html?meetingId=ff16731f1cbc3a25ea8332c15a0c65fb6e739b43-1636028334700) and here are [**the slides**](https://cloud.meet.coop/s/sGAfrdLbjZmJX65)**.** > > Play the video (a BBB room recording) in Firefox or Chrome on a laptop or desktop. Given that meet.coop runs on free-libre software, an obvious frame of governance lies in the p2p mode of the code community. Peer-to-peer is frequently spoken of in terms of contributions in commons. Nadia Eghbal has dug into the mythology and practice a bit deeper: [Ford Foundation study](https://www.fordfoundation.org/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf): *Roads & Bridges: The Unseen Labor Behind Our Digital Infrastructure*. Various things emerge. One is, not every project is performed with the same sense of contribution or **community**, and many are *one-person* projects that may not have a lot of future or past contribution in them. A second is, that benevolent dictatorship thro **private ownership and control** of basic infrastructure (servers, for example; or some basic admin practices) is a common mode in the ‘free’ software sphere. A third is, some traditions (‘free-libre’) have a strong motivation of commoning as an **opposition** to corporateness, while others (‘open-source’, or simply ‘agile’) have a basically **corporate** rationale and participation. And indeed, the main organ of the open-source code economy, gitHub, was bought by corporate giant Microsoft in 2018, from its ‘benevolent dictator’ owners, for $7.5bn. Thus, both community and commons have a somewhat tenuous foundation in the P2P code-producing tradition. In recent years many platforms or portals have been created, which hold free software tools, available for free use by anyone: date-polls for organising meetings (eg Framadate), shared word processors, spreadsheets and notepads (Etherpad/riseup pad), etc. See for example Agaric, on [free software infrastructure](https://agaric.coop/blog/daily-business-operations-using-free-software) . See also [Toolstack](/handbook-trial/1-principles/intentions/the-toolstack.md). The relationship of such tool-repositories with their (largely non-tech) users is not the same as with their (tech) creators and hosts. While the rationale behind mounting these tools for open access is **free-libre**, and the world that they emerge from is indeed *a commons of code* under collective stewardship, the rationale of their public availability is ‘free beer’: basically, like a food bank, an open storefront, a thrift shop. > These repositories are not commons, but *unregulated common pools*, curated and offered charitably (and maintained with ‘free’ labour, another problematic notion) by active participants in the *code* commons. However worthy it is, however, charitable giving is not a commons. In the schema below, these relationships are shown by: * A completed *curating/enjoying* loop for producer-user nerd-commoners, carrying out *stewarding* of the code commons under git **protocols**. Git is the universally-used machinery for peer-to-peer forking and merging of elements of code in a code repo - itself a *protocol commons*. This is coupled with . . * Open-access users - perhaps non-geeks, 'mere user-consumers' - out on a limb, **outside** the commons and, important for us here, outside the governance of either the code commons or the ‘free beer/foodbank’ open-access platform. ![Governance - Free-libre peer-to-peer](https://781026599-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MbjRiwwKa0TXyi4B5WE%2F-Me1SQAIGU7etLWv1UU4%2F-MeBUXwdr03B_uOCMfaY%2Fgovernance%20-%20floss.jpeg?alt=media\&token=c2b46a50-0e9c-4495-918e-9e4079b5e3af) #### Principles & protocols We can extract a few principles from this. First, **protocolling.** Participation of non-geek app users in a commons of *tool-provision* isn’t something that can be simply read off from the p2p practice of free-libre software **production**. Git-governance is governance by code producers, for *code producers*. Some other kind of practice is called for - even if a **commons of protocols** like git might be an interesting place to start thinking about machinery for governance. There might be some kind of protocol to reach for here: a **protocol for protocolling**, in an extended community of this kind, with widely divergent *kinds of members* and *contexts of usage* of tools. > This needs more work. Watch this space xxx And second, **commons of running code.** Rather than a commons of *code*, what we in principle are looking for is a commons of *running code*. That is, when non-tech users of free-software tools mobilise them from a hosted **platform** (like meet.coop users do, with BigBlueButton or Discourse), what matters to them is the *end-to-end continuity, stability, usefulness and useableness* of the entire system - from git repos for BBB, thro meet.coop's platform servers, across the Internet via their ISP, to their own individual devices and web browsers, and their own practical, in-context, present-moment usage of what's on their desktops - *the entire code-and-device ecology*. An infrastructure provider like meet.coop has somehow to achieve this. And the practice of free-libre *code commoning* isn’t necessarily a model that can furnish a whole lot in achieving this. Moreover, this is not so much a practice of 'governance' in any conventional sense, as a practice of **operational design** and enactment of work practices: perhaps [design justice](/handbook-trial/3-social-relations/dimensions-of-community-sectors-of-practice/the-toolstack-dimension-cultivating-activist-capability/design-justice.md) is a more helpful starting point. > What does it take, to steward a commons of running code - ie, a platform, a codebase, its server scripts, and all its participating devices, browsers and plugins - as distinct from a code commons? Watch this space xxx Third, however, there is **GENSET**: a principle that seems pretty useful. In the free-software world there’s an aesthetic of collaboration and sufficiency, facilitated by overarching frameworks of accepted design- and administrative- protocol. The principle is: **“Rough consensus, and code that runs”**. This is close to the sociocratic principle, of *“Good enough for now, and safe enough to try” (GENSET) -* making commitments by **consent** rather than consensus. ‘Code that runs’ is a literal requirement in meet.coop, the provider of platform-spaces. But it also is a metaphor for the ‘machinery’ that we need for operational and strategic steering of the **infrastructur**e, and the helpful, diverse **usages of infrastructure**, across a highly plural community who are by no means all going to want to do the same things with it. Oh, and here’s a fourth principle: **asset lock.** Remembering the gitHub/Microsoft story . . ownership of an infrastructure needs to be translated into residence of resources and rights, *in commons*, under commons stewardship, *in perpetuity*. #### Commons of (static) code vs commons of running code Here’s a scattering of further notes, perhaps to be incorporated above. > xxx Include a clarification on ‘free-libre’ from Snowflake : xxx Contributing ‘code that runs’ in a code commons . . Test suites mean that ‘valuing’ is mechanical. **Platforms** that *really help* is another kind of matter from *code* that runs. This is a matter for practices of value(ing) rather than metrics? xxx ‘**Reputation**’ - see Eghbal. Reputation metrics - eg badges yuk. Is 'knowable community’ among active contributors possible in meet.coop? [Dunbar's number](https://en.wikipedia.org/wiki/Dunbar%27s_number) - 150 stable relationships? (Actually, debunked, confidence limits span from 2 to 520. Whatever - there's a principle here rather than a specific number?).There are many (a majority of) passive users - members who ‘just want the light to come on’? See [Full-range commoning](/handbook-trial/1-principles/commoning/full-range-commoning-the-contribution-of-care-work.md). How many active contributors are there in in stewarding? Probably this amounts to the size of a ‘board’ or a **council**? See [Assemblies - Roots movements](/handbook-trial/1-principles/commoning/assemblies-governance-in-roots-movement-organisations.md). xxx The **labour of maintainance** (and its cost) is a major feature of infrastructures. - See Eghbal, above, and [*The maintainers*](https://themaintainers.org/). xxx maintainance as a pivotal issue in infrastructure - See Eghbal, and [The maintainers](https://themaintainers.org/). See also: OpenCollective [Public Digital Infrastructure Research Grant](https://opencollective.com/research-grants#section-projects) . xxx The dominant aesthetic - at least in ‘open source’, if not in ‘free-libre’ - is not communitarian, but **libertarian-autonomy** and private ownership, and tends to dictatorship. Viz Eghbal on larger communities including stadiums. > Eghbal offers a new taxonomy of communities — including newer phenomena such as “stadiums” of open source developers, other creators, and really, *influencers* — who are performing their work in massive spaces where the work is public (and not necessarily participatory). So what lessons of open source communities do and don’t apply to the [passion economy and creator communities](https://a16z.com/tag/creator-economies/)? How does the evolution of online communities — really, social networks — shift the focus to reputation and [status as a service](https://www.eugenewei.com/blog/2019/2/19/status-as-a-service)? And what if working in public is also about sharing in private, given the “[dark forest theory of the internet”](https://onezero.medium.com/the-dark-forest-theory-of-the-internet-7dc3e68a7cb1), the growing desire for more “high-shared context” groups and spaces (including even podcasts and newsletters)? All this and more in this episode. > > From [podcast](https://a16z.com/2020/08/01/working-in-public-communities-open-source-creator-economy-passion-economy/): Sonal Chokshi interviews Nadia Eghbal, August 2020 xxx xxx Nathan Schneider (2020) has a decolonial critique of governance in software stacks aka digital infrastructures aka commons of running code: [*Vanguard Stacks: Self-Governing against Digital Colonialism*](https://osf.io/pqwka/?view_only=09431d47da2542d1a9a88f9f615d455c). Also a 2021 feminist critique of the mythical openness of free software: [*The Tyranny of Openness: What Happened to Peer Production?*](https://osf.io/hnerp/?view_only=44b5c10772d5470892b701dfe4b2c833) xxx money: Eghbal on “Open source’s complicated relationship with money” > Money has been a taboo topic for open source projects since the early days of the free software movement, which arose in direct response to the practice of commercial, proprietary software.. xxx But livelihood is a core issue for meet.coop. Maintaining a platform and servicing actual living users and communities isn’t o be expected on love alone. See [Political economy](/handbook-trial/2-political-economy/political-economy.md). Also, licensing - mediates the relationships between code, commons and markets. A complicated area - create a topic on \[Licensing]? xxx meet.coop infrastructure - **running code** (a platform and the whole ecology of devices and apps) is not **code**. Also, meet.coop has other spaces in addition to the **platform spaces**: *media spaces* & *venue* spaces - which are not in any major way determined by code. Overall: maintenance of code infrastructure can’t be the model - code commons are only a small part of the commons of meet.coop, and *the majority of the commons* are of a different kind.