parent
039388a127
commit
2e75561be4
@ -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 |
@ -1,12 +1,59 @@ |
|||||||
Title: A movement for autonomous technology |
Title: Part 2: autonomous software and software autonomy |
||||||
Category: Blog |
Category: Blog |
||||||
Date: 2019-12-12 |
Date: 2021-08-01 |
||||||
Tags: culture, politics |
Tags: culture, politics |
||||||
Status: Draft |
|
||||||
|
|
||||||
I was recently at an art event of sorts, called T/H\X and met a bunch |
In my [first essay](part-1-against-primitivism/) in this series I |
||||||
of cool people working on interesting things, relating philosophy with |
tried to convey, that any revolution needs to include technological |
||||||
technology and thinking about the implications of the things we create |
liberation. In the meantime I had plotted this article, forgotten it, |
||||||
in the wider context of the world. |
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. |
||||||
|
Loading…
Reference in new issue