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: 11nov2021This 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 and here are the slides.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: 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 . See also Toolstack.
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
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 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 infrastructure, 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.
Here’s a scattering of further notes, perhaps to be incorporated above.
xxx Include a clarification on ‘free-libre’ from Snowflake : https://wiki.snowdrift.coop/about/free-libre-open
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 - 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. 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.
xxx The labour of maintainance (and its cost) is a major feature of infrastructures. - See Eghbal, above, and The maintainers.
xxx maintainance as a pivotal issue in infrastructure - See Eghbal, and The maintainers. See also: OpenCollective Public Digital Infrastructure Research Grant .
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? How does the evolution of online communities — really, social networks — shift the focus to reputation and status as a service? And what if working in public is also about sharing in private, given the “dark forest theory of the internet”, the growing desire for more “high-shared context” groups and spaces (including even podcasts and newsletters)? All this and more in this episode.
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. Also a 2021 feminist critique of the mythical openness of free software: The Tyranny of Openness: What Happened to Peer Production?
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. 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.
Last modified 1yr ago