LogoLogo
  • Welcome
  • Note - Draft, prototype status
  • Note - Licensing, quoting
  • Meet meet.coop
    • The online meeting coop - meet.coop
    • Contact us
  • 1 Principles
    • Principles
      • Spaces
      • The toolstack
      • Platform spaces
      • Media spaces
      • Venue spaces
      • Stack of commons
      • Privacy policy
    • Commoning
      • Spaces stewarded as commons
      • Commoning - Three moments
      • Contributing in commons - A governance hybrid
      • Classic FLOSS peer-to-peer governance
      • Classic co-op governance
      • Assemblies - Governance in ‘roots’ movement organisations
      • Full-range commoning - The contribution of care work
      • Commoning as a practice of dual power - Beyond . .
    • Principles & protocols
      • Value and value(ing)
      • Values as practices in working order
      • Coop values, DisCO
  • 2 Political economy
    • Political economy
    • Members and contributions
      • User members, user-member accounts
      • Active user members
      • Operational members
      • Register of members
      • Privileges and obligations
      • Sanctions
      • Fair use of BBB space
      • Contributions
      • Contribution accounting
        • Contribution & recognition
        • Contributions & locations of work
        • Work of valuing, and means of recording and valuing (mapping) contributions
      • Funding contributions
      • Rent
      • Contributions in kind
      • Work contributions
      • Recognition of contributions
      • Voting
    • Commons political economy
      • Ownership, assets and commons
      • Dissolving meet.coop
      • Fiat money, mutual credit, fair wage, sweat equity
      • A commons and its members - Stewarding, contributing, enjoying
      • Dependence - Livelihood, infrastructure, dual power
      • Livelihood, privilege, contribution
      • Provisioning and hosting
      • Employment, federation and voluntary contribution
      • Revenue, surplus and distribution
      • Development funding, investment
      • Value, values, value(ing) and production in-and-of commons
      • Contribution, privilege and justice - The purpose of protocols
  • 3 Social relations
    • Social relations
    • Intentions, principles
    • Actions in three landscapes
    • Dimensions of community
      • Plural community - Three sectors
      • Pluriverse
      • 1 Coop - Transformed economy, making the coop-commons
      • 2 Solidarity - Transformed silos, formación
        • Tools for conviviality
        • Formación - Learning, the dance of knowing
      • 3 Toolstack - Transformed organising capability, infrastructuring
        • Dance of knowing
        • Design justice
      • Multiple languages, plural regions, uneven development
      • Privacy
    • Seven Rs of civil-society activist commitment
      • Rescue
      • Resistance
      • Reporting, recording
      • Re-weaving the economy
      • Reparation, reconciliation, restorative justice
      • Regenerative activism
      • Regime change, revolution
  • 4 Assemblies and deliberations
    • Assemblies and deliberations
      • Circles
        • Community circle
      • Standing assembly (all-hands)
      • commons.hour
      • General assembly
      • Board of stewards
      • The forum
      • Polls
      • Protocols - Time
      • Protocols - Multiple languages
      • Protocols - Facilitation & moderation
  • 5 commons.hour
    • commons.hour - The programme
      • Basic links for commons.hour
      • commons.hour invitation
      • Programme & presenters
      • Defining what meet.coop does - A handbook and a commons
      • Prototyping and collaborating
      • Defining what meet.coop is for
      • Running list of sessions
      • Summary running list
      • Design and prototyping in commons.hour
      • commons.hour - the venue
    • commons.hour protocols
      • Session protocols
      • Session pre- and post-protocols
      • commons.hour methodology
    • Design principles
      • Design justice - note
      • Plural community
      • Coop principles
      • commons.hour ‘specials'
  • 6 Constitution
    • Constitution
      • Conventional outline of a constitution
      • A design approach to a constitution - an assemblage of protocols
      • Protocols vs rules
      • The handbook and the constitution
      • Core protocols aka principles of meet.coop
      • Draft constitution
  • 7 Code of conduct
    • Code of conduct
      • In platform spaces
      • In media spaces
      • In venue spaces
      • Operational members
      • User members
      • Making the coop-commons economy
      • Provisioning and mobilising tools and capability
      • Cultivating solidarity and mutuality
  • 8 Terminology
    • Terminology
      • BBB - Big Blue Button
      • Containers
      • Discourse
      • FLOSS - Free-libre open-source software
      • gitBook
      • Greenlight
      • Markdown
      • Matrix/Element
      • NextCloud
      • Sweat equity
      • Sysadmins aka ‘admins’
  • 9 Supporting materials
  • Supporting materials
    • meet.coop
    • Other organisations
      • Open Credit Network - Membership Agreement
Powered by GitBook
On this page

Was this helpful?

  1. 1 Principles
  2. Commoning

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.

PreviousContributing in commons - A governance hybridNextClassic co-op governance

Last updated 3 years ago

Was this helpful?

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: and here are .

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: : 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 . See also .

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.

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

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.

Commons of (static) code vs commons of running code

Here’s a scattering of further notes, perhaps to be incorporated above.

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 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.

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 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.

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 is a more helpful starting point.

xxx Include a clarification on ‘free-libre’ from Snowflake :

xxx ‘Reputation’ - see Eghbal. Reputation metrics - eg badges yuk. Is 'knowable community’ among active contributors possible in meet.coop? - 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 . How many active contributors are there in in stewarding? Probably this amounts to the size of a ‘board’ or a council? See .

xxx The labour of maintainance (and its cost) is a major feature of infrastructures. - See Eghbal, above, and .

xxx maintainance as a pivotal issue in infrastructure - See Eghbal, and . See also: OpenCollective .

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 ? How does the evolution of online communities — really, social networks — shift the focus to reputation and ? And what if working in public is also about sharing in private, given the “, the growing desire for more “high-shared context” groups and spaces (including even podcasts and newsletters)? All this and more in this episode.

From : 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: . Also a 2021 feminist critique of the mythical openness of free 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 . Also, licensing - mediates the relationships between code, commons and markets. A complicated area - create a topic on [Licensing]?

design justice
https://wiki.snowdrift.coop/about/free-libre-open
Dunbar's number
Full-range commoning
Assemblies - Roots movements
The maintainers
The maintainers
Public Digital Infrastructure Research Grant
passion economy and creator communities
status as a service
dark forest theory of the internet”
podcast
Vanguard Stacks: Self-Governing against Digital Colonialism
The Tyranny of Openness: What Happened to Peer Production?
Political economy
Governance & contribution in commons
the slides
Ford Foundation study
free software infrastructure
Toolstack
Governance - Free-libre peer-to-peer