From 2e75561be4272e566aa82ab290f9c06f6724df3d Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Sat, 14 Aug 2021 18:23:36 +0200 Subject: [PATCH] website: work in progress articles --- .../content/blog/123_software_syndicate.md | 532 ++++++++++++++++++ .../content/blog/xxx_autonomous_tech.md | 63 ++- 2 files changed, 587 insertions(+), 8 deletions(-) create mode 100644 infra/website/content/blog/123_software_syndicate.md diff --git a/infra/website/content/blog/123_software_syndicate.md b/infra/website/content/blog/123_software_syndicate.md new file mode 100644 index 00000000000..3e77b40aa33 --- /dev/null +++ b/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 diff --git a/infra/website/content/blog/xxx_autonomous_tech.md b/infra/website/content/blog/xxx_autonomous_tech.md index a4c3acbd5c7..03a4abc99d6 100644 --- a/infra/website/content/blog/xxx_autonomous_tech.md +++ b/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. +> +> — https://en.wikipedia.org/wiki/Autonomy + +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.