Reproducing https://pad.public.cat/software-syndicate?both to gather feedback.
full text, work in process
Software Syndicate
Purpose (of this pad)
- Outline what a software syndicate is defined in its goals, methodologies, and functions.
- Describe how different software syndicates can operate towards a shared goal, …
- Create a guide on how to start your own software syndicate
What is a syndicate?
according to Webster dictionary:
- a group organized to carry out a particular transaction or enterprise
- an association of organized criminals
- a workers managed entreprise
A syndicate is a structure where professionals/ businesses meet to facilitate their work by sharing ressources.
It is different from a union, as the later is a structure aimed at defending worker’s rights.
The choice of the syndicate structure responds to the reality that most free-software projects carry along an eutreprenarial or cooperative model.
In the third definition the term syndicate is associated to anarcho syndicalism as a method for workers in capitalist society to gain control of an economy, thus control and influence in broader society. Anarcho-syndicalism is our point of reference where different needs of society are organised locally at communal level then federated.
A communalist way of thinking about technology engages us in thinking needs at local level and looking to federate what gains can be mutualised.
Purpose (of the software syndicate)
What form can it take?
The software syndicate is a local alliance of developers and community interested in thinking the tools they use; it can take different forms both proposing both social and digital tools. There are already existing structures that we can build from, hackerspace network is one example, but other civil society structures can be a supportive base also. The software syndicate looks at transforming the decision process about software development among developers including users in the decision process.
Motivations
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.
This way of thinking has infected nearly every aspect of our society, including free software projects.
Generally projects are considered to have an “upstream”, a canonical source from which the software is created, distributed, and maintained.
This has a lot of downsides for the end-users of the software. For example, a canonical upstream puts every user of the application at the whim of its developers. If the software is changed in some way that many people dislike, the burden to fork is very high. After all each individual user (even if they have a tech background) might not be able to maintain the entire codebase by themselves, or be able (and have the connections) to build a new community around the fork.
Most forks fail [citation-needed]. There are of course exceptions (a very successful one being jellyfin forking from emby ca 2019[1]), but the rule is that forking is a quite violent act that requires a lot of strength and energy to maintain.
The idea of software syndicates (or to turn the phrasing around syndicalist software) is to remove the notion of “upstream”. Software exists in the world, and is created and maintained by different software syndicates.
Maybe one of these syndicates originally created the software, but did so in a way that was easy for another syndicate to come along, adapt, and re-distribute to its users.
In effect this creates pre-emptive “soft forks” – forks that are still compatible with each other, but that might vary slightly in their functionality.
For developers this means that software is maintained by many different smaller projects. The original authors (mainline) of the software still exist, and changes can be given to them. Maybe many syndicates would regularly pull updates from mainline, in order to get the latest features that are being worked on. But patches could also be applied to a more “local” syndicate to the developer, if the change is not deemed to be useful outside of the sydicate’s community.
For users this means that software is available by many different smaller projects. Users of Linux distributions may already be familiar with this. Packages are not usually created by the software authors, but by distribution maintainers. Users already get their software from a kind of syndicate: their distribution. The idea of a software syndicate formalises this relationship, and invites others to create other such projects, independent of (or spanning over multiple) distributions.
If the usability of one version of the software is not to the liking of the user, it is much easier to find one that is. An example of this already in practise are mastodon forks, which are all (?) still compatible with the mastodon API and activitypub spec, but that add extra features that the mastodon mainline doesn’t want to support.
What is locality
- The social proximity of people to each other, and the communities they build
- Your friend circles, their friends – this is your “local” community
- Your fediverse server is a form or “local” community
- Of course physical locality plays a part – you may meet people in your city and then meet them again on the internet
- We are using a reproduction medium/tool (computers) that has global capacity, one software doesn’t fit all but still it can have quite a large scope unrelated to its place of production.
- Computer networks allow us to take advantage of a “larger” concept of locality embeding different relations.
Oportunities
- The ability to localise the development and maintenance of software – to remove the “knowledge silo” from development in Germany, F̷̪̤̋ṟ̵͙̾͗a̷̛̩̎n̴͙͙̿́c̸̙͙̈e̵̪͒, the UK, and Netherlands, this implies looking for others elsewhere.
- Building social structures that transcend projects, giving users and developers a “closer” contact to the software they use
- Destroying the notion of personality-driven development
- More control over the software that people use, not being dependent on a single group of developers to “care about your use case”
- Rethink free software engineering around actual collective needs rather than individual developer’s itches.
Challenges
- How to deal with Not Invented Here (NIH) syndrome? I.e., how to ensure that common functionality gets to the main branch and does not end up into too many forks duplicating functionality?
- How to engage with distribution packages?
- How to avoid balkanization, e.g., such as with Freifunk?
- How to ensure processes remain common although not centralized?
- What tools are needed? E.g., ForgeFed…
- Can we extend these principles to funding (i.e., to ensure development remains funded globally)?
- Can we use Elinor Ostrom’s principles for the governance of the Commons?
- What can be localised and what can be mutualised?
Methodology
- “Automated” ways of tracking features, changes, deprecations, … between versions of a software maintained by different syndicates
- Core-minimalism: keep the core part of your project as small as possible to make it possible for other syndicates to extend the software in many different ways
- Create a forum to discuss notions, changes, and
Interlude
Excerpts from Heather Marsh’s Glossary:
Community: A group affiliated around allocation of common resources. Communities may be societies, where allocation is through social relationships, or trade economies, where allocation is through trade.
Consciousness: A subset of reality filtered through empathic networks and sometimes subjected to the laws of endoreality through an endofilter.
Concentric circle: Peer promoted voices or ideas in a transparent, permeable structure where those at the centre receive the most amplification and ideas are audited and taught to the outer circles by knowledge bridges.
Corporate feminism: Feminism which emanated from the United States in the 1960s and was heavily guided by both the CIA and corporate interests. It created an endogroup out of an exosocial struggle for liberation.
Example: The DREAM Software Syndicate
Objectives
- Create, maintain, and distribute software related to decentralised communities and networking.
- Act as a test-bed and example syndicate for others to copy, modify, and adapt – either for the same set of projects, a sub-set, or a different set of projects
Means
Governance
See below for final text…