On software syndicalism

On software syndicalism


Organisations, groups, and projects under capitalism have the tendency to centralise. This is both because of monetary incentives (it might be cheaper to just have one of something than many), as well as authority incentives; it is easier to control an organisation that is structured hierarchically.

The way that we organise free software projects is impacted by this societal framework, which replicates a lot of the issues that organisations, projects, and companies under capitalism face as well. Maybe unsurprisingly our solutions to these issues are also largely similar: personality based, and hierarchical in nature.

Projects often also use the same metrics as capitalist society for success: growth, reach, and audience appeal. This replicates the phenomenon of representative democratic systems and proprietary technology creators of pandering to the majority and letting needs by minorities largely go unanswered.

In this essay we propose an organisational structure for software and technical projects that removes the notion of “upstream”, and introduces a collective ownership approach of software and technical knowledge. Freedom of ideas (the fundamental basis of free software) is a core requirement for this approach.

Furthermore we aim to put this theory into practise by creating a software syndicate around the DREAM project, a collection of p2p collaboration tools developed by a variety of people (see “Appendix A” for more).

This essay can not hope to solve all problems related to this idea, but to start a discussion about the merits and advantages of organising in small-scale, decentralised communities. Our hope is that this sparks conversation, interest, and motivation in others to form software syndicates of their own, to communally own, develop, and maintain the technologies that our lives are built upon.

Problem domain

Developing and maintaining software is a lot of work, and largely a social exercise, instead of a technical one. While certain individuals are able to create a project by themselves through obsession and dedication, it is unlikely for projects without a community to outlive the focus period of the original creator.


This relationship between creators and consumers is formalised by the concept of “upstream”. Software development is considered a river with an original source, and can branch out into different streams and brooks to adapt to its environment.

While this is an apt metaphor for how software develops from a centralised source, it does come with a lot of burdens and challenges. A poisonous source can destroy a river’s ecosystem, and similarly, a rogue upstream development team [1] [2] can doom users dependent on the downstream ecosystem of this project.

Forks will occasionally diverge completely from the original upstream, however this is a commitment that very few are able to maintain without substantial community engagement (and public backlash).


Maintaining a software fork is a lot of work. While it is difficult to get exact statistics, our assumption is that most software forks fail due to lack of community engagement [3] [4] [5]. This social dynamic puts people off forking software projects that are developing in a direction that they do not approve of, or that no longer represent their wishes and desires: while in theory it is still possible for the software or technology to be forked, the reality of the situation needs to be acknowledged that this is out of scope for
most people.


The organisational methods used by software and technical projects are often focussed around central points of authority, similar to how the code (or design files) itself is treated. This is a limitation by the nature of organisation around a single platform and is derived from how a lot of tools are built to accommodate capitalist ventures where centralisation is a desired effect.

While it is possible for a small group to make decisions very efficiently in private, it also means that not all voices in the community can be considered.

However decentralised and open decision processes have a maximum size, past which they fail due to sheer volume of feedback, trolls, or both. A prominent community that recently ran into this issue is the Rust language project, which prompted the creation of a working group in 2019 to address these issues [6] [7] [8].


This section outlines different modes of collaborating on projects, their strengths, and how they can interact and integrate with each other. These ideas form the basis on which software syndicalism is built.

The project cabal

A common organisational pattern that exists (albeit not usually with an exact name and very often hidden) is the “project cabal”. This is a group of people, often including the original author(s), who work on the core features and expansion of a project. Their knowledge and engagement drives the bulk of the project forward, and by their hands a lot of requests from both users, as well as peripheral developers get implemented.

While many projects have a cabal, few are open about this dynamic. It is not necessarily a bad dynamic, if discussed and adopted openly. Seeing communities as a collection of concentric circles outwards from the cabal allows users to be aware of the social dynamics that go into making decisions, and the path via which an idea can be adopted by the

This uses the concept of “knowledge bridges” [9], which facilitate a way for less experienced users and developers to communicate their ideas to the cabal of a project, without having to become experts in the project domain first.

Distribution and tools

While source control systems such as git are already decentralised, many organisational tools built around it are not. GitHub, Gitlab, and many other projects inspired by them [10] [11] follow the same patterns of an upstream repository, with a central place to track contributions and open issues.

Furthermore, this approach affects the way that software is being distributed to end-users as well.

A new and growing trend is to task the developers themselves with packaging their software [12] [13]. This is done to simplify (centralise) the publication process and reduce the lag between new features being created and users being able to use these features.

Embracing the idea of decentralised collaboration in smaller communities opens up new possibilities for ownership of the technology that we use. And while projects that aim to decentralise these collaboration tools [14] around a peer-to-peer protocol such as ActivityPub [15] are not strictly required to put any of these theories into practice, they do offer the opportunity to design new ways of collaboration that don’t mirror the existing centralised platforms.

Upstream vs Mainline

Most of the issues we face in building distributed collaboration networks are organisational - not technical - in nature. As the development process of a project scatters around different groups, it becomes important to catalogue and track changes made by different
groups that allows others to easily pull them into their own trees.

For this process to work the original source of a project (currently called “upstream”) needs to be replaced in the minds of developers and users by the idea of a reference implementation. For this reason we propose and use the term “mainline” to describe this project community.

While it is a subtle difference, language plays a huge role in how people relate to structures and processes. The term and concept is taken from the way the Linux kernel is developed. Every three months a new “mainline” kernel is released [16] into the world, ready to
be used by whoever is interested in it.

However, most people do not run the mainline kernel. This is a reference configuration aimed at pleasing a very specific target audience. Most Linux distributions apply their own patches on top of this version, remove features they deem incompatible with their ideals
(proprietary firmware as an example), and re-release this version onto their users. Projects must be aware of who their target audience is and no one project can every hope to appeal to every user in the world.


Before we can discuss how to build software syndicates we need to define what a syndicate is, and how syndicalist cooperation functions in practice. One definition of syndicalism is “a radical political movement that advocates bringing industry and government under the control of federations of labor unions by the use of direct action”[17]. The term is also often used in relation to “anarcho-syndicalism” [18] which puts this theory into praxis in different ways.

A lot of political activism is done via syndicalist structures. They offer a way for people to collaborate with each other, without having to belong to the same large-scale organisation, or following the same exact plan. Alignment with each other’s ideals and principles is foundational for this mode of collaboration to work, while avoiding many of the problems outlined in earlier sections.

Technology is inherently political in how it is created, maintained, and used, and software developers carry their own ideologies into their work, whether they are aware of this or not. Cultural barriers created by these ideologies make it harder for outsiders to the ideology to participate (for example because they have a different political background or are from a different part of the world).

Syndicalism embraces political ideology around the work that we do and asks of everybody participating in this work to reflect on their own biases, assumptions, and behaviours. This does not require political uniformity (often dubbed “unity”). It attempts to make social collaboration more transparent and easier to understand, and primes [19] developers and users to understanding their own biases and assumptions based on feedback that they get from other communities.

Different syndicates can also approach group collaboration and decision making differently, while still working on the same overall vision for a project or idea.

We use this term to invoke a feeling of belonging, community, and political awareness of the technologies we build and the work we collaborate on. Software syndicalism is the act of organising in syndicates and applying it to the development and maintenance of software.


Proximity and knowledge silos

Centralised software communities tend to recreate colonialist power-structures through the distribution of developers and choice of target audience. This creates knowledge silos [20] in these countries which is detrimental to the empowerment and autonomy of both
developers and users from different countries. There are more subtle differences (for example looking at northern vs southern, and western vs eastern Europe), but most prominent in both European and white American communities, compared to the rest of the world.

One of the opportunities of creating syndicates around the creation and maintenance of software projects is breaking this relationship. To understand how this works we also need to discuss the concept of social proximity. [21]

The communities we belong to are based on the social relationships we have with people, and vice versa. These are bi-directional feedback mechanisms. Via the internet proximity (or locality) can exist both in the physical world, and in a meta-physical sense of belonging.

Users and developers of projects can exist in different proximities to different software syndicates, which lowers the barrier of entry, and gives users and developers more choices of contact points to a software project. If the mainline syndicate around a project is considered hostile to work with outside of a certain peer group, other syndicates will allow alternative communities to spring up.

It’s important to note that none of this is impossible under the current view of development. A hostile or malicious upstream development team can be circumvented by forking the project. This however comes with a lot of unexplored social responsibilities that many people shy away from. Forking, and then maintaining a fork community, is a lot of work that is often not seen as an option.

To start a software syndicate is not necessarily easier on its own, but comes with the idea of inter-project and international solidarity built-in. No one syndicate aims to speak for the whole project, or satisfy all users. And thus collaboration is key.


Proximity and community are about belonging and identification. This requires self-identification of users and developers, exploring existing communities. Human beings are complex, both individually, and in terms of the relationships with each other. Labels of identification are an important tool in this regard, but must not be used to bikeshed definitions.

Much like anything else that humans have created language for, identity labels are vague and have a certain amount of flexibility. A software syndicate might exists for a user group with specific needs, or for a group of developers (and thus users) based in a different country, operating in a different language.

Syndicates must self regulate their membership, but at the same time identification with the target audience of a syndicate should be enough for someone to belong to this syndicate’s user group.

Forming new syndicates based on existing ones if the need for more granular identification becomes apparent this should be encouraged and not hindered. Large communities (as outlined in earlier sections) do not scale, and by keeping syndicates small and focussed, a lot of these issues can be avoided.


While the user and developer audience of a syndicate is up to each member of the syndicate and how they identify with the syndicate, relationships between syndicates should aim to be more formalised. Syndicalist cooperation is based on solidarity.

Fragmentation is a real concern in this regard and demands cross-collaboration between syndicates in terms of basic specs, core components, and design choices. This is to ensure that software made and maintained by different syndicates remains as compatibly with other versions as possible.

However, just as with identification of syndicate belonging, diverging projects should not be hindered if this serves the need of different user groups. Neither software not its user base is monolithic and projects may diverge from each other if their goals no longer align.
An effort should be made to allow for future cross-collaboration, but there is no point in spending energy on drama and conflicts if developers and users would be happier with two separate projects rather than one.

This space offers a lot of opportunities in terms of designing tools for cross-collaboration. Syndicates might be able to publish change sets that provide metadata for git patch sets that can easily be included by other syndicates, or individual users that want a custom version of a piece of software that is configured and compiled just for them, based on a mainline version and patches that are maintained by different syndicates.

Decision models

Decision making processes may differ between syndicates which offers a choice to both developers and users in terms of how they want to engage with the software they use.

Casual users of a software might choose a syndicate which does not make decisions based on user feedback and instead trusting the cabal to guide the development and maintenance of their tool. On the other hand “power users” of a software may want to be able to be more involved in the decision making process without having to gain the technical knowledge and experience to join the core cabal.

By diverging communities into smaller syndicates it is possible for these communities to organise themselves differently while allowing for cross-collaboration on important features.

Decision models can be aligned on two axes: knowledge and trust [22]. Knowledge relationships are based on agreement on technical ideas and what is commonly used currently in “meritocratic” systems. Trust relationships are based on mutual understanding of the principles that go into making a decision and developing a software.
These two relationships can interact in interesting ways.

                              high trust
        CONSENSUS           |          UNANIMITY
                            |               high agreement
 low agreement              |
                            |          TECHNICAL
         DISSENT            |           AGREEMENT
                   low trust

Collaboration is possible in three of these quadrants, although only two of them are ideal. When two groups agree on the details of a solution but do not trust each other, a technical relationship can be formed. This usually involves a specification that is then honoured by both groups (and others that join into the relationship at a later point in time).

On the other hand, when two groups have a strong trust relationship this allows for collaboration via consensus. Consensus decision making [23] means taking every individuals point of view into account and coming to a decision based on this information. This means that individuals can disagree with specifics but find some common ground that they can both “live with”. This means that decisions are based on the comfort edges of all participants. There is no voting as this would enforce a majorities view over any minority and every stakeholder in a system can exercise a veto right to stop a decision.

These processes only work in small groups, which is why syndicates are also encouraged to form pure technical relationships.

The quadrants “UNANIMITY” and “DISSENT” should be avoided as they either result in an echo-chamber effect in terms of decision making, or don’t allow for effective collaboration at all.


While the previous sections outlined opportunities solve (and improve on) the existing problem domain, this idea is not without its own challenges. This essay attempted to propose solutions for some of these, but can of course not hope to be comprehensive.

Technical fragmentation

Existing projects that use a similar approach [24] can suffer from “fragmentation” or “fracturisation” (commonly also called “balkanisation”). This is the process by which communities diverge so significantly that they are no longer compatible with each other. In
the case of Freifunk this means that the core software is still developed communally between all “chapters”, but configuration and network setups vary so widely that moving between networks requires fundamentally re-configuring infrastructure devices.

Creating small syndicate communities around all sorts of software projects may suffer from the same problem if not managed accordingly. This requires collaboration platforms to grow and scale in a way that they currently don’t, or for syndicates to operate from compatible
principles, which will be hard to ensure and verify.

Not invented here

A common theme in software development is the “not invented here syndrome” (NIH) [25] which prompts companies to rewrite technical projects created by other parties because they either don’t like or don’t understand the existing (and available) solution.

Because free software developers do not exist in a bubble this affects free software projects as well. Fragmentation in communities, social and technical differences in understanding, and other factors might contribute to a rise in NIH among syndicates. This is a problem with no real solution. It can potentially be avoided with better communication.

On the other hand it is important to consider that just because something has been written once that does not mean that no alternative implementations can or should exist. It is possible to find errors in specifications through alternative implementations [26].

Political fragmentation

Similarly to how technical differences in opinions may fragment a project, the same can be said for political ideologies. It is reductionist to assume that ideology in itself is the problem (after all not believing in ideologies is itself an ideology). Labels exist in language to catalogue and describe natural and cultural things.

The importance is to recognise that different labels can exist for the ame principles, and that similar political conclusions built on the same principles are still compatible with each other.


Bringing this essay to a close, we look into the future. The way we build systems and organise ourselves in communities has grown out of the capitalist system that we aim to escape. Furthermore this is not simply about the development of software (and other technologies), but about giving users and developers autonomy over the tools that they
build and use.

It is time for an overhaul of how we organise, and to become aware of the systems that we replicate in how we develop the technologies that we hope will transform the world. This is sorely needed, as boycotting technology is not the solution to the ever growing surveillance apparatus created by capitalist systems.

Ultimately, software syndicalism is about reducing the distance between the creation and maintenance of technology and its users.


  1. https://web.archive.org/web/20210705123342/https://www.techradar.com/uk/news/audacity-fans-are-absolutely-furious-right-now-heres-why ↩︎

  2. https://www.linuxuprising.com/2018/12/jellyfin-free-software-emby-media.html ↩︎

  3. A Project On Hiatus | Glimpse ↩︎

  4. List of software forks - Wikipedia ↩︎

  5. Research exists that indicates the opposite of this statement. However survivorship bias may exists in terms of how projects are advertised, scoped, and identified. More research into the field is certainly needed
    https://sci-hub.st/10.1007/978-3-642-33442-9 ↩︎

  6. Rust's 2019 roadmap | Rust Blog ↩︎

  7. Organizational Debt ↩︎

  8. fun memory violations ↩︎

  9. “Binding Chaos” by Heather Marsh - ISBN 9781989783009 ↩︎

  10. GitHub - go-gitea/gitea: Git with a cup of tea, painless self-hosted git service ↩︎

  11. https://sourcehut.org ↩︎

  12. flatpak.org ↩︎

  13. https://snapcraft.io/ ↩︎

  14. https://forgefed.peers.community/ ↩︎

  15. https://activitypub.rocks ↩︎

  16. Linux kernel version history - Wikipedia ↩︎

  17. syndicalism - definition and meaning ↩︎

  18. Anarcho-syndicalism - Wikipedia ↩︎

  19. Primed - definition of primed by The Free Dictionary ↩︎

  20. Information silo - Wikipedia ↩︎

  21. Proximity principle - Wikipedia ↩︎

  22. media.ccc.de - Infrastructures in a horizontal farmers community ↩︎

  23. Consensus decision-making - Wikipedia ↩︎

  24. Freifunk - Wikipedia ↩︎

  25. Not invented here - Wikipedia ↩︎

  26. https://blogs.oracle.com/developers/building-a-container-runtime-in-rust ↩︎


For those who missed it in Barcelona, 2019’s RustFest closing talk by @spacekookie

1 Like

I stumbled upon https://magicstone.dev/

Ecko is a community-driven fork of Mastodon’s social network software. The idea for the fork is to optimize toward community, that is making it as easy as possible to contribute. We’re following a protocol called the Collective Code Construction Contract (C4) that says if you are addressing a valid problem, your code gets merged. Everything else follows from that.

C4 stems from the ZeroMQ development process. Were you aware of this @spacekookie?

ZeroMQ RFC 42: C4

slug: 42
title: 42/C4
name: Collective Code Construction Contract
status: stable
editor: Pieter Hintjens ph@imatix.com

The Collective Code Construction Contract (C4) is an evolution of the github.com Fork + Pull Model, aimed at providing an optimal collaboration model for free software projects. This is revision 2 of the C4 specification and deprecates RFC 22.


Copyright (c) 2009-2016 Pieter Hintjens.

This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, see http://www.gnu.org/licenses.


C4 provides a standard process for contributing, evaluating and discussing improvements on software projects. It defines specific technical requirements for projects like a style guide, unit tests, git and similar platforms. It also establishes different personas for projects, with clear and distinct duties. C4 specifies a process for documenting and discussing issues including seeking consensus and clear descriptions, use of “pull requests” and systematic reviews.


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

1. Goals

C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:

  1. To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
  2. To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
  3. To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
  4. To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
  5. To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
  6. To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.

2. Design

2.1. Preliminaries

  1. The project SHALL use the git distributed revision control system.
  2. The project SHALL be hosted on github.com or equivalent, herein called the “Platform”.
  3. The project SHALL use the Platform issue tracker.
  4. The project SHOULD have clearly documented guidelines for code style.
  5. A “Contributor” is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
  6. A “Maintainer” is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
  7. Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
  8. Maintainers SHALL have commit access to the repository.
  9. Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.

2.2. Licensing and Ownership

  1. The project SHALL use a share-alike license such as the MPLv2, or a GPLv3 variant thereof (GPL, LGPL, AGPL).
  2. All contributions to the project source code (“patches”) SHALL use the same license as the project.
  3. All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
  4. Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.

2.3. Patch Requirements

  1. Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.
  2. A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
  3. A patch MUST adhere to the code style guidelines of the project if these are defined.
  4. A patch MUST adhere to the “Evolution of Public Contracts” guidelines defined below.
  5. A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
  6. A patch MUST compile cleanly and pass project self-tests on at least the principal target platform.
  7. A patch commit message MUST consist of a single short (less than 50 characters) line stating the problem (“Problem: …”) being solved, followed by a blank line and then the proposed solution (“Solution: …”).
  8. A “Correct Patch” is one that satisfies the above requirements.

2.4. Development Process

  1. Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
  2. To request changes, a user SHOULD log an issue on the project Platform issue tracker.
  3. The user or Contributor SHOULD write the issue by describing the problem they face or observe.
  4. The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
  5. Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
  6. Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
  7. To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
  8. To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
  9. A Contributor SHALL NOT commit changes directly to the project.
  10. If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue.
  11. To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
  12. To accept or reject a patch, a Maintainer SHALL use the Platform interface.
  13. Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
  14. Maintainers SHALL NOT make value judgments on correct patches.
  15. Maintainers SHALL merge correct patches from other Contributors rapidly.
  16. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
  17. The user who created an issue SHOULD close the issue after checking the patch is successful.
  18. Any Contributor who has value judgments on a patch SHOULD express these via their own patches.
  19. Maintainers SHOULD close user issues that are left open without action for an uncomfortable period of time.

2.5. Branches and Releases

  1. The project SHALL have one branch (“master”) that always holds the latest in-progress version and SHOULD always build.
  2. The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
  3. To make a stable release a Maintainer shall tag the repository. Stable releases SHALL always be released from the repository master.

2.6. Evolution of Public Contracts

  1. All Public Contracts (APIs or protocols) SHALL be documented.
  2. All Public Contracts SHOULD have space for extensibility and experimentation.
  3. A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
  4. A patch that introduces new features SHOULD do so using new names (a new contract).
  5. New contracts SHOULD be marked as “draft” until they are stable and used by real users.
  6. Old contracts SHOULD be deprecated in a systematic fashion by marking them as “deprecated” and replacing them with new contracts as needed.
  7. When sufficient time has passed, old deprecated contracts SHOULD be removed.
  8. Old names SHALL NOT be reused by new contracts.

2.7. Project Administration

  1. The project founders SHALL act as Administrators to manage the set of project Maintainers.
  2. The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
  3. A new Contributor who makes correct patches, who clearly understands the project goals, and the process SHOULD be invited to become a Maintainer.
  4. Administrators SHOULD remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
  5. Administrators SHOULD block or ban “bad actors” who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.

Further Reading

  • Argyris’ Models 1 and 2 - the goals of C4 are consistent with Argyris’ Model 2.

  • Toyota Kata - covering the Improvement Kata (fixing problems one at a time) and the Coaching Kata (helping others to learn the Improvement Kata).