More Than Ownership

Abstract: Democratic control is fundamental to cooperative values: it's the second item of the ICA/Rochdale PrinciplesThe Rochdale Principles (1844), https://en.wikipedia.org/wiki/Rochdale_Principles, after being open to all. For most cooperatives, however, democracy means coop members can submit resolutions and vote on these at an AGM (Annual General Meeting) under the principle of one member one vote.

Much of the discussion on open source's relevance to cooperatives has focused on open, permissive licenses that represent a 'digital commons' (possibly at risk of appropriation). But debate over licensing misses an essential and unique quality of open source: its democratic toolset which is much more sophisticated than resolutions and AGM. Understanding how successful open source tools are built by vast, distributed, often volunteer teams with few or no middle managers, could help unlock a more democratic and collaborative type of organisation. The opportunity for platform cooperatives – and any democratic group - in doing this, is to not only better engage members, users and workers, but to get the best of a community's insight and skills to improve the collective’s work.

"The ultimate question of human history, as we’ll see, is not our equal access to material resources (land, calories, means of production), much though these things are obviously important, but our equal capacity to contribute to discussions on how to live together.”
~David Graeber & David Wengrow, A New History of Humanity

Comparisons between cooperatives and open source software (also known as Free (libre) Open Source Software, FOSS or FLOSS) are frequent. Yochai Benkler was earlyBenkler, Y (2006) The Wealth of Networks: How Social Production Transforms Markets And Freedom. New Haven, CT: Yale University Press. to recognise open source as a form of digital commons, a "new form of production that is not based on private property and patents, but on loose and voluntary cooperation between individuals who are connected worldwide"Benkler, Y (2017). Noreena Hertz described co-ops as the 'open source version of capitalism'Hertz, Norwena (2012) Coop Capitalism https://noreena.com/co-op-capitalism-paper-launched-with-co-operatives-uk/ (2012); while the reverse, that open source is the coop version of capitalism, could also be claimed (Wistreich, 2013)Wistreich, Nicol (2013) Open Source Capitalism, chapter in People Over Capital, New Internationalist, 2013, ISBN: 978-1-78026-161-4. At the Open Cooperative conference in 2017, Laura Hillier remarked on stage “it’s kind of amazing these two movements don’t talk to each other more”https://www.youtube.com/watch?v=kmm53tc7uvo.

While it's recognised that the "Platform Cooperative movement has close affinities with FLOSS”, (Schneider, 2016)Scheider, Nathan (2016), Platform Cooperativism as a Critique of Open-Source https://geo.coop/internet-ownership-archive/platform-cooperativism-critique-open-source, open source's removal of most intellectual property protections is criticised by some for further enriching already wealthy and powerful digital giants. For Schneider, open source has "produced valuable, low-cost raw material for corporations that are designed to produce wealth for investors, not livelihoods for commoners”Scheider, Nathan (2016), Platform Cooperativism as a Critique of Open-Source https://geo.coop/internet-ownership-archive/platform-cooperativism-critique-open-source. It's been argued that "the digital commons might be seen as its own enclosure in which web users/producers remain separated from the value of their production" (Andrejevic, 2012)Andrejevic, Mark (2012). Ubiquitous Surveillance, cited in https://www.triple-c.at/index.php/tripleC/article/download/764/881?inline=1#ref2 while Michel Bauwens declared "the more communistic the sharing license we use, the more capitalistic the practice“Bauwens, Michael https://wiki.p2pfoundation.net/Peer_Production_License#An_integrated_view.

This has led to some developers adopting more restrictive open licenses for their work. The Peer Production License was published in the Telekommunist Manifesto (Kleiner, Magyar, 2010)Kleiner, Dmytri & Magyar, John (2010), the Peer Production License, appearing in The Telekommunist Manifesto http://telekommunisten.net/the-telekommunist-manifesto/ ISBN/EAN 978-90-816021-2-9 and prevents commercial use of a work, other than for non-profits, coops and 'commonsers'. For instance, CoopCyclehttps://coopcycle.org/en/ is a federated platform coop of 69 courier coops worldwide providing them with both services and software only under a Peer Production License, making it only available to cooperatives. Other so-called 'copyfarleft'Toner, Alan (2007) Copyfarleft: An Anarchist Gema? https://knowfuture.wordpress.com/2007/11/22/copyfarleft-an-anarchist-gema/ licenses include the CopyFair licensehttps://wiki.p2pfoundation.net/CopyFair_License, which requires some kind of reciprocity for commercial exploitation; and FairSourcehttps://fair.io/?a which remains free for an organisation up to an employee count denoted by a number after the license name. However, these have been criticised for embedding capitalist values of exchange and enclosure into open source (Meretz, 2014)Meretz, Stefen (2014), Socialist Licenses? https://keimform.de/2014/socialist-licenses/, while stripping away the freedom that allows contributors to fork an open source project from the original maintainers, suggesting work under the PPL will "become parts and parcels of the capitalist economy" (Rigi, 2014)Rigi, Jakob (2014), The Coming Revolution of Peer Production and Revolutionary Cooperatives. A Response to Michel Bauwens, Vasilis Kostakis and Stefen Meretz https://www.triple-c.at/index.php/tripleC/article/download/486/555.

In this way, the discussion around open source within the cooperative, solidarity and alternative/left economy spaces tends to gravitate into a debate over licenses: how they relate to fair compensation, or risk appropriation and exploitation by big business — and rarely goes further. This may be partly driven by the monopolistic nature of data online and the search for a community-owned alternative (Pazaitis, Kostakis, Bauwens 2017)Alex Pazaitis, Vasilis Kostakis, Michel Bauwens (2017), Digital economy and the rise of open cooperativism: the case of the Enspiral Network, https://doi.org/10.1177/1024258916683865. However, the focus on open licenses and ownership misses something unique to open source development that is taken for granted by developers who use it, but little known by anyone else: how it manages itself. 

Open Source communities have developed well-established methodologies with a sophisticated toolset for bottom-up and decentralised collaboration. While many civic sectors question how to make their decision making and work processes more democratic, open source communities have long used a set of collaborative functions (issues, branches, merges, pull requests, forks and diffs) that underpin a powerful form of collaborative yet decentralised working.

Traditional corporate governance, common to many cooperatives, takes the form of resolutions submitted by members and shareholders, voted on annually at an AGM. The main innovation with cooperatives over corporations is each member has one vote; in corporations, like the Digital Autonomous Organisations (DAOs) in the blockchain world, the number of votes each co-owner has is proportional to the amount of shares or cryptographic tokens owned.

The ICA Group's model for good democratic organisational governanceAn Overview of Democratic Governance, ICA Group (2019), https://icagroup.org/wp-content/uploads/2019/04/An-Overview-of-Democratic-Governance.pdf suggests having three types of participant: member, board (including a grievance committee) and management. A coop then needs bylaws to define which issues should be handled by management, which by the board, and which by the membership; as well as paths to appeal decisions or activity by any group.

Open source offers a different democratic approach. In place of resolutions are issues and pull requests (PRs); in place of voting is consensus, upheld by maintainers and forks, and in place of two board and management layers are normally just one layer of authority*: maintainers. All of these actions take place publicly and are attributed to someone, archived and managed through a tool called githttps://git-scm.com/.

Attempts to integrate the principles of open source into organisational governance typically focus on the ethos and values, not the toolset. For example open source's transparency – where decisions and discussions are public and archived – has been championed by Transparency International and the now-closed Sunlight Foundation, as well as broader movements like Open Datahttps://en.wikipedia.org/wiki/Open_data. But "transparency is openness in only one direction" (Shirky, 2012); openness in two directions emerges with proposals such as the Open Enterprise ManifestoThe Open Enterprise Manifesto, https://www.opencompany.org/resources/whitepaper.pdf, describing an organisation that is transparent and democratic, with a 'reputation matrix' to decide whose voice is most trustworthy and 'contribution based compensation' with credits for work undertaken. Another model is Open OrganisationsOpen Organisations, (2004) https://github.com/open-organization/open-org-definition/blob/master/open-organization-definition.md, such as open.coop, focusing on five areas of 'transparency, inclusivity, adaptability, collaboration, and community'.

Neither Open Organisations or Enterprises describe specific tools or workflows to implement this increased transparency and participation, instead focusing on the general values needed for an open organisation. Some platform cooperatives have gone further. Stocksy, a photographer-owned photo licensing coop, shifted from annual member resolutions to ongoing open submission of resolutions by members in 2014, and continues to develop more sophisticated methods for members to discuss and vote on these online. Such effort is essential and not always easy: “the twin traps so many democratic firms fall into: either they have so much structure and bureaucratic procedure that members cannot actually use the power they formally have, or they have so little structure that there is no available means to make a difference." (ICA Group 2019)An Overview of Democratic Governance, ICA Group (2019), https://icagroup.org/wp-content/uploads/2019/04/An-Overview-of-Democratic-Governance.pdf.

This level of member participation has been made more widely available to any democratic entity, through the open source tool Loomiohttps://loomio.com, developed by cooperative Enspiral, and used by thousands of groups to support community democracy. Group and coop members submit proposals and resolutions online, then discuss, and vote on them, with the votes and discussion archived.

Loomio stands out as having implemented in tools some of the principles of open source governance – ongoing proposals and discussion, with a transparent archive – and made them available to any kind of organisation. However, there are qualitative differences. Open source doesn't use voting, but a form of consensus, while the decision makers and workers aren't acting in separate spaces. A software repository acts like a virtual factory floor and discussion takes place there, along with contributions and management decisions. In open source it would be very unusual for a message to be handed down to developers from a virtual meeting space: "we've voted to scrap feature X, or add feature Y, please implement this".

Powering open source's 'factory floor', and at the heart of most modern open source is git, with a set of functions - commits, merges, pushes, pulls, etc - that shapes the rules and culture common to all active open source communities. Git is a decentralised, hash-based system developed by Linus Torvalds to help him maintain contributions to Linux. Unlike previous 'version control systems' which tracked changes to software over time through a pyramidal hierarchy, Git creates a unique hash (a unique identifier) for changes made locally on each contributor's computer, so that it can be compared with the original – or other contributions – which allows for the first time (Shirky, 2012) 'cooperation without coordination'Shirky, Clay (2012) How the Internet will (one day) transform government. https://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform_government.

Looking at git's functions of merges, commits, PRs, branches and forks in more detail, I will reference CiviCRMhttps://civicrm.org, the not-for-profit open source CRM (contact relationship manager) for non-profits, political groups, coops and NGOs, whose community I am a member of, and where I concluded that the most underexplored radical part of Open Source is its governance toolset.

As shareholders and coop members can make resolutions for potential changes, anyone in the world is able to report an issue on an open source repository, which could be a bug, idea or feature request. At time of writing listed herehttps://lab.civicrm.org/dev/core/-/issues are over 1400 issues for CiviCRM. 

Anyone can then respond to an issue or propose a fix to a bug or create a new feature by making a pull request or PR (as in "please pull my contribution into the main repository"). At time of writing there are 82 open PRs for CiviCRMhttps://github.com/civicrm/civicrm-core/pulls, and 23,387 closed ones. 

Issues and PRs make an important difference to resolutions, for in separating diagnosis (issues) from cure (PRs), the community can apply the mindset and approach appropriate to quite different functions. It's arguably easier to spot problems than solve them, with this divide there's no wait to raise a problem until a good solution has been found. Flagging and discussing an issue ('this board is too male/white/old', 'this product isn't sustainable', etc) is not limited only to those who have the answer, while those offering big changes can point to the problems their proposal addresses. Issues can be discussed for as long as needed to gain consensus, before solutions – perhaps there are several – are offered, or the issue is closed.

Maintainers have the power to decide if an issue should be closed or a Pull Request merged into the project or rejected. On the path to merging a PR, as well as reading and testing a contribution, a maintainer might:

• Discuss it. Git management tools such as Gitlab, Gitea and Codeberg have discussion threads on every issue and PR, along with emoji voting and ways to quickly tag other community members. Here's a discussionhttps://lab.civicrm.org/dev/core/-/issues/2122#current-behaviour about how to implement a seemingly simple change to add timezones for event listings in CiviEvent that runs to hundreds of comments.
• Look at the PR's 'diff'. A diff is a colour-coded guide to the changes being made (red for deletes, green for additions) similar to track-and-changes in a word processor. This is the diffhttps://github.com/civicrm/civicrm-core/pull/20476/files for a PR for the 53 changed files to implement the timezone improvement above. Unlike track changes, a diff for every merge and pull request in the history of a git-managed project is archived, so each change and signoff is attributed, and future problems can be debugged (this timezone change adjusted the times on the event listings of existing installs so a reverted version of the code was offered, which was easy to roll back to). If looking at the git archive for an employment contract, for instance, you could see who proposed to change wages and which maintainer merged (‘approved’) it. 

• Invite reviewers. Much like peer review, a maintainer can invite reviewers to look at the PR. For instance in this PRhttps://github.com/civicrm/civicrm-core/pull/23808 to improve the calendar integration in CiviCRM, a maintainer flags users who have expertise in specific areas, or are interested in seeing the feature integrated, to review the code. With enough positive peer reviews, the merge is made.

• Create a branch. Creating a branch is a quick way to copy the full code with the proposed change integrated to see how it works. Many organisations run trials or prototype an idea in a safe and ringfenced way before rolling out widely – branches are much the same. A branch groups all changes together so they can be tested, improved, forgotten or merged back if successful. If the initial issue was, for example, 'our energy bills are too high', and a PR towards this issue was 'turn off the heating for 30 minutes every hour', a branch could implement this in just one building or floor rather than the entire organisation. Another floor or building might implement another PR for 'turn heating down 20%'. Once it's established which idea works best, it can be merged back into the 'master branch'.

Despite these methods to make an informed merge of a PR, maintainers have a lot of discretionary power over the direction of a project. Because most open source projects start with one developer's 'itch' (Raymond, 1997)Raymon, Eric (1997), The Cathedral and the Bazaar, https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar#Lessons_for_creating_good_open_source_software founders often end up adopting the maintainer role, which means if successful they can significantly dominate the culture of the system (potentially extending any gender, racial, cultural biases they have).

Compared with the voting in a coop or corporate AGM resolution, this system of maintainers could appear strongly undemocratic. However open source projects can be seens as consensus-driven, with the community empowered through the potential to fork a project. A fork lets anyone copy and maintain their own copy of a project. If the project is trademarked they may need to rename it (as the Drupal fork Backdrop didBackdrop - a Drupal fork (2013), https://groups.drupal.org/node/325403), if it's under a 'copyleft' GPL-type licenseWhat is Copyleft? https://www.gnu.org/licenses/copyleft.en.html they'll need to share any modifications they make under the same license (as Trump’s Mastodon fork Truth.social didhttps://www.theverge.com/2021/10/22/22740354/trump-truth-social-network-spac-mastodon-license-software-freedom-conservancy) – but otherwise a fork has no requirements. The ability to fork is doubtless a strong motivator for developers and funders contributing to open projects, often unpaid; if the project fails, their work or investment shouldn’t be locked in or lost.

Forking underpins community governance by consensus, not the voting of coops or shareholder-governed corporations – a maintainer is trusted to do the job well and if they don't, they could lose their users and dev community who can take everything with them. As a result it's in maintainers’ interest to respond to issues and make fair judgements over PRs. Maintainers are sometimes known as Benevolent Dictators – Dictators for the power they wield; Benevolent because if their decisions don't reflect community consensus – they can be easily overthrown.

Famous forks like Joomla! and WordPress happened for different reasons: WordPressMullenweg, Matt (2003), The Blogging Software Dilemma https://ma.tt/2003/01/the-blogging-software-dilemma/ because the maintainer of the original B2 blogging software had gone quiet and wasn’t engaging with the user community any more; Joomla because owners its predecessor Mambo had introduced a governance model that favoured high-paying sponsors over everyday users and contributorsJoomla 15 years later - Founders' memories: Brian Teeman (2020), https://magazine.joomla.org/all-issues/september-2020/joomla-15-years-later-founders-memories-brian-teeman. Despite these notable forks, they happen rarely and succeed even less often: getting the codebase is one thing, but getting a community to follow requires a threshold of community frustration to be passed. There are manyhttps://en.wikipedia.org/wiki/Wikipedia:Mirrors_and_forks/ABC forks of Wikipedia but none can come close to Wikipedia's scale, popularity or institutional strength. 'One click revolutions' sound threatening but perhaps forking's main power is more to ensure maintainers stay active, engaged and respond to community consensus, a kind of digital sword of Damocles.

For cooperatives looking at open source governance, arguably the challenge is to consider not just how much of their activity could be managed through a git repo – but how the culture that comes from an open repository — of people actively finding and fixing problems and improvements — can be encouraged.

Much already sitting on a corporate or coop intranet could be put in a repo: contracts, staff handbook, press releases, branding guidelines, product specifications, forecasts, minutes, recipes or user manuals – available to be easily edited, revised, tracked and discussed. Other areas without digital assets could still use an issues queue, project maintainers and archived decisions with the same repo management tools. For example, this planning space for CiviCRM's last community summithttps://lab.civicrm.org/marketing/events/community-summit-2019 - like most of CiviCRM's marketing and community governance – uses a Gitlab repo to discuss the schedule and assign tasks. Non-developers in the CiviCRM community can be seen engaging on the public website contenthttps://lab.civicrm.org/marketing/civicrm-website/-/issues,  financial sustainabilityhttps://lab.civicrm.org/community/sustainability/-/issues, or event planninghttps://lab.civicrm.org/marketing/events Gitlab projects.

However, while the functions described above could be adopted by many projects or organisations, forking is only available when the core assets are already open and easily copy-able (ie are digital, intellectual property or non-scarce, free assets like waste). This excludes coops who, for instance, share land, machinery, a brand, labour, or other limited resources. Still, perhaps forking's 'one click revolution' is a powerful enough tool in empowering consensus-led structures that co-exist with a powerful manager class, to make it worth cooperatives who cannot easily 'fork' exploring models that could offer similar potential.

A common criticism of the biggest cooperatives is that their management has become slow-moving and stale, so as to make the organisation indistinguishable as an employee or customer experience from other big businesses. Making it easier for members to vote to replace the management, or break a big cooperative into smaller coops would approximate some of the power of forking, but, unlike digital goods it's impossible to allow both 'branches' to exist in parallel. If new management does a worse job, you can't easily revert to the old team, unlike a fork of a digital project where if it fails the original is intact and still running. Indeed a digital fork only becomes threatening to the original if it ends up better or more popular, otherwise it will be forgotten.

Another option would be to prevent coops from getting too big in the first place, seeking not scale, but federation (Disco Manifesto, 2021)The DisCo Manifesto (2019) https://disco.coop/wp-content/uploads/2019/11/DisCO_Manifesto-v.1.pdf. Federated coops, might make it easier for a part of a coop – such as a single supermarket branch, or region-specific group of couriers or drivers – to vote to join a different 'head office' and rebrand. This more decentralised approach has been also regularly discussed in relation to both Platform Coops and the Blockchain (Wistreich 2015Wistreich, Nicol (2015), What might a Coop Uber look like? (or should we be thinking bigger)? https://helloideas.com/ideas/what-might-coop-uber-look-or-should-we-be-thinking-bigger, Wachira 2020https://businessblockchainhq.com/business-blockchain-news/co-operatives-and-blockchain-a-perfect-match/, Davilla 2021https://www.dgen.org/blog/decentralisation-at-work-cooperatives-on-blockchain, Schneider 2022Schneider, Nathan (2022) Web3 Is the Opportunity We Have Had All Along: Innovation Amnesia and Economic Democracy https://osf.io/2wg6s?view_only=709f1f87528943a4b27de2b5eb0f9eef, etc) as well as cooperative run instances of the 'Activity Pub' social media 'fediverse', like social.coop (Irving, 2017)Irving, Alana (2017), Social.coop: A Cooperative Decentralized Social Network, https://medium.com/open-collective/social-coop-a-cooperative-decentralized-social-network-c10980c9ed91. Federalisation of cooperative organisations using open source assets offers considerable potential – local and regional differences can emerge while sharing cost-savings by collaborating on technology common to all.

But that's a bigger discussion. Without even including forking, or releasing all digital assets and IP under an open license, collaboration over git through issues, pull requests, maintainers and branches is still a new democratic idea. What's strange, given open projects' continued success and impact in the digital world, is that these working methods are barely known outside of programmers. For platforms seeking to offer their users and workers the most comprehensive democracy available, maybe it's time to change that.

"A momentous thing that can happen to a culture is they can acquire a new style of arguing: trial by jury, voting, peer review, now this. A new form of arguing has been invented in our lifetimes... The question for us now is, are we going to let the programmers keep it to themselves? Or are we going to try and take it and press it into service for society at large?"
~Clay Shirky, How the Internet will (one day) transform governmentShirky, Clay (2012) How the Internet will (one day) transform government. https://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform_government

*Some open source project have added more traditional democracy to their operations beyond maintainers: CiviCRM has an elected Community CouncilPlease register to vote and/or nominate yourself for the CiviCRM Community Council, https://civicrm.org/blog/artfulrobot/please-register-vote-andor-nominate-yourself-civicrm-community-council, Joomla has an elected board of 11 directorshttps://www.opensourcematters.org/organisation/directors.html, Debian Linux Operating System has an elected one-year leaderhttps://www.debian.org/devel/constitution, who can appoint their own team, selected by developers who get their voting power based on their standing in the Debian community. Governance methods vary by project, with many overseen by corporations, like Automattic for WordPress or Acquia for Drupal; or foundations, like the Apache Foundation hosting over 350 different projects, or Wikimedia Foundation for Wikipedia. What's key however, is that all open source projects offer the same collaborative features described above, whether a one-person pet project or the world's most popular operating systemhttps://gs.statcounter.com/os-market-share#monthly-202204-202204-bar.

Header image by opensourceway