website: work in progress articles

infra/website/content/blog/123_software_syndicate.md

@@ -0,0 +1,532 @@
+Title: On software syndicalism
+Category: Blog
+Date: 2021-07-07
+Tags: philosophy, technology, anarchy
+Draft: true
+
+---
+
+(this essay was written as part of [THX]() and is published in the
+collection [on the theory and praxis of software syndicalism]().  This
+essay was written by me as part of this publication)
+
+## 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 practice 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 [^aud] [^emby] 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).
+
+[^aud]: https://web.archive.org/web/20210705123342/https://www.techradar.com/uk/news/audacity-fans-are-absolutely-furious-right-now-heres-why
+[^emby]: https://www.linuxuprising.com/2018/12/jellyfin-free-software-emby-media.html
+
+
+### 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 [^gli] [^wfrk] [^pfrk].  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.
+
+[^gli]: https://glimpse-editor.org/posts/a-project-on-hiatus/
+[^wfrk]: https://en.wikipedia.org/wiki/List_of_software_forks
+[^pfrk]: 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
+
+
+### Organisation
+
+The organisational methods used by software and technical projects are
+often focused 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 [^r1] [^r2] [^r3].
+
+[^r1]: https://blog.rust-lang.org/2019/04/23/roadmap.html#governance
+[^r2]: https://boats.gitlab.io/blog/post/rust-2019/
+[^r3]: https://spacekookie.de/blog/rust-2019-how-we-make-decisions/
+
+
+## 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" [^hm1], 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.
+
+[^hm1]: "Binding Chaos" by Heather Marsh - ISBN 9781989783009
+
+
+### 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 [^gt] [^sh] 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 [^flatpak] [^snap].  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 [^ff] around a peer-to-peer protocol such as
+activitypub [^ap] 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.
+
+[^gt]: https://github.com/go-gitea/gitea
+[^sh]: https://sourcehut.org
+[^flatpak]: flatpak.org
+[^snap]: https://snapcraft.io/
+[^ff]: https://forgefed.peers.community/
+[^ap]: https://activitypub.rocks
+
+
+### 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 [^kernel] 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 ever hope to appeal to every user in the
+world.
+
+[^kernel]: https://en.wikipedia.org/wiki/Linux_kernel_version_history
+
+
+## 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"*
+[^syn1].  The term is also often used in relation to
+"anarcho-syndicalism" [^syn2] which puts this theory into practice 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
+[^prime] 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.
+
+[^syn1]: https://www.wordnik.com/words/syndicalism
+[^syn2]: https://en.wikipedia.org/wiki/Anarcho-syndicalism#Theory_and_politics
+[^prime]: https://www.thefreedictionary.com/primed
+
+## 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 [^silo2] 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. [^prox]
+
+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.
+
+[^silo2]: https://en.wikipedia.org/wiki/Information_silo
+[^prox]: https://en.wikipedia.org/wiki/Proximity_principle
+
+
+### 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, should be encouraged and not
+hindered.  Large communities (as outlined in earlier sections) do not
+scale, and by keeping syndicates small and focused, 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 out in the open and instead trust 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** [^mccc].  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 [^cons] 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 all "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.
+
+[^mccc]: https://media.ccc.de/v/36c3-10858-infrastructures_in_a_horizontal_farmers_community#t=593
+[^cons]: https://en.wikipedia.org/wiki/Consensus_decision-making
+
+
+## Challenges
+
+While the previous sections outlined opportunities, that solve and
+improve on the existing problem domain, software syndicalism 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 such as Freifunk [^freifunk] that use a similar
+approach 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.
+
+[^freifunk]: https://en.wikipedia.org/wiki/Freifunk
+
+
+### Not invented here
+
+A common theme in software development is the "not invented here
+syndrome" (NIH) [^nih] 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 [^railcar].
+
+[^nih]: https://en.wikipedia.org/wiki/Not_invented_here
+[^railcar]: https://blogs.oracle.com/developers/building-a-container-runtime-in-rust
+
+
+### Political fragmentation
+
+Similarly to how technical differences in opinions may fragment a
+project, the same can be said for political ideologies.  However 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
+same 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 **resistance**, about
+**autonomy**, and **reducing the distance** between the creation and
+maintenance of software, and its users.
+
+
+## References

infra/website/content/blog/xxx_autonomous_tech.md

@@ -1,12 +1,59 @@
-Title: A movement for autonomous technology
+Title: Part 2: autonomous software and software autonomy
 Category: Blog
-Date: 2019-12-12
+Date: 2021-08-01
 Tags: culture, politics
-Status: Draft
 
-I was recently at an art event of sorts, called T/H\X and met a bunch
-of cool people working on interesting things, relating philosophy with
-technology and thinking about the implications of the things we create
-in the wider context of the world.
+In my [first essay](part-1-against-primitivism/) in this series I
+tried to convey, that any revolution needs to include technological
+liberation.  In the meantime I had plotted this article, forgotten it,
+re-plotted it partially, forgotten about it again, and finally ignored
+for the last year.
 
-During 
+Only recently was I reminded of this dangling article pointer by a
+reader sending me an e-mail (hello! :)).  At the same time I had been
+working on a very similar set of essays with some other people (which
+I will publish "soon") and so, I also started thinking about the
+matter at hand.
+
+> [...] autonomy is the capacity to make an informed, uncoerced
+> decision.
+> 
+> — <small><cite>https://en.wikipedia.org/wiki/Autonomy</cite></small>
+
+This essay has three parts.
+
+
+## Atonomous software
+
+A lot of modern technology is pitched as "smart", based on its ability
+to re-incorporate user feedback into it.
+
+This ranges from music recommendation algorithms to self driving cars.
+In some cases these technologies are being called "autonomous", for
+example in the case of cars.
+
+But this is a mischaracterisation.  These technologies are not
+actually autonomous.  Decisions are not made by an "AI", they are made
+by developers of the training set and mathematical model the "AI" is
+built on.  Decisions are then rewound and played back _by_ the "AI".
+Responsibility for the outcomes lie with the developers of the
+software, not the software itself.
+
+Terms such as "autonomous systems" are thrown around to describe these
+technologies, muddying the waters of responsibility.
+
+
+## Software autonomy
+
+The idea of "software autonomy" is the inverse to the one we just
+outlined.  The focus is on the individual, and user of the software.
+
+Software isn't just another invention, such as toasters or automated
+potato peelers.  Software is a meta-cluster invention, which has
+impacted every single industry 
+
+
+## To you, who write _software_
+
+Approach your work through this lense.  Find the politics of what
+you're doing, and revolutionise them.