On software syndicalism
Abstract
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.
Upstream
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).
Forks
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.
Organisation
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].
Principles
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
project.
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.
Syndicalism
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.
Opportunities
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.
Identification
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.
Relationships
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
|
v
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.
Challenges
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.
Outlook
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.
References
-
https://web.archive.org/web/20210705123342/https://www.techradar.com/uk/news/audacity-fans-are-absolutely-furious-right-now-heres-why ↩︎
-
https://www.linuxuprising.com/2018/12/jellyfin-free-software-emby-media.html ↩︎
-
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 ↩︎ -
“Binding Chaos” by Heather Marsh - ISBN 9781989783009 ↩︎
-
GitHub - go-gitea/gitea: Git with a cup of tea, painless self-hosted git service ↩︎
-
media.ccc.de - Infrastructures in a horizontal farmers community ↩︎
-
https://blogs.oracle.com/developers/building-a-container-runtime-in-rust ↩︎