Wobbly is a workplace organising platform, being designed and prototyped by a small voluntary team of developers. It’s a communication and coordination tool, with structures and processes modelled on the IWW’s organising style (hence the name, coming from the IWW nickname). We’re creating a space for energetic, powerful, and democratic unions to win struggles, grow.

Three summers ago I was walking around an Edinburgh suburb, posting residents leaflets on discount dentistry. I stopped and asked myself, what can I do to stop this from happening to anyone else? We are getting dropped off by a van in the middle of nowhere with a map and a stack of leaflets, so how are we supposed to build any kind of collectivity? I suppose we’ve all got these phones, could that be the start of something?

I borrowed a book on Java from a friend studying physics. I started going to Lean Agile and programming language meetups, in order to meet like-minded developers and get to know how the industry worked.

In that time I have also worked as a rider for Deliveroo, which is much larger than the leaflet delivery company but not free from the same problem: the workers the service relies on are divided and atomised. I’ve come to understand this as a system-wide phenomenon in most jobs in the UK. And with Deliveroo in particular, having an unquestionable algorithm as your boss is not a pleasant way to work.

I have been working on some variety of union app ever since.

The Problem

When I worked at Deliveroo, I found that the company divided the city into zones, and riders apply for shifts within those zones a week or two ahead of their work days (using a shitty piece of software called Staffomatic). Ideally, you would work in the zone you live in, so that you can leave your home with your bike, turn on the app, and instantly be available to do a delivery. You know the area better, meaning you do not have to resort to looking at the map on your phone as often, so you have a safer experience on the road and complete deliveries faster. And when your shift ends, you are closer to home.

At any moment however, the deliveroo algorithm can decide to move riders from zone to zone, whether because the latter zone is too busy, or the previous is not busy enough, and the riders have no say in the matter. The alerts that come up are phrased as if the rider has a choice, however the only option they have in the app is ‘OK’, and they cannot take deliveries until they have moved to a zone they didn’t choose. The riders are not asked if they want to move, they are just ordered to.

A simple fix for this is all riders in the “overpopulated” zone could be offered the chance to move, and possibly a reward for doing so. However, deliveroo has no incentive to pay their programmers to add this functionality, and likely does not want to anyway, as my guess is they are ordering the riders with the highest rider rating (which is only visible to management) to move zones first.

This is just an example of an improvement of working conditions only attainable with the pressure of collective power. And the way to build that power is through traditional organising, enhanced with a powerful set of digital tools.

Those tools, at the moment, don’t exist. Organisers are forced to use a combination of email, WhatsApp conversations, or Facebook groups, which are hard to use for organising at scale. Using the corporatist tools is like trying to write a novel with a crayon. It’s technically possible to do it, but no reasonable person would do so if they had the choice of something better.

It’s pretty easy to infiltrate a whatsapp conversation, as some deliveroo organisers have found. It’s difficult to manage once they get above ~100 members, and co-ordinating between different groups across multiple localites is not a feature the whatsapp dev team have considered at all. And this is what Wobbly aims to address.

The vision for Wobbly

Wobbly differs from other chat applications by building federated organisation in from the start. Every user enters the app by joining or creating a local node, what might be called a branch in traditional organising. They do this by searching for their workplace when they open the app for the first time. The nodes are named after their workplace, and can be geotagged to make them easier to find.

The local node is the base unit of the system, used to represent workers who regularly meet face-to-face at least a little bit (or have the potential to be able to). An example would be all the workers at the McDonald’s on Princes Street in Edinburgh. The size of the node is such that the current members should be able to independently verify that a prospective member is who they say they are, and should be a member of the node. Basically, in a local node the members should know each other (or be able to know each other) without the app.

In each node there are three parts: First, encrypted communication that allows workers to talk to each other. Second, a way to raise funds, either through an integrated service from another app, or instructions to follow for using something else. Third, and this is the part that no one else is working on, a way to communicate with other nodes: Group-to-Group Communication.

If workers at McDonald’s Princes Street want to talk to workers at McDonald’s London Road, the Princes Street McDonald’s node sends a communication request, the McDonald’s London Road node accepts, and then they have an open channel.

If workers in nodes want to do things like pool funds, make shared resolutions, strike together, organise shared events, they can form a supernode. To take the previous example, the McDonald’s Princes Street node and the McDonald’s London Road node create a proposal to form a supernode called McDonald’s Edinburgh. The members of the local node vote on the proposal, and if it’s successful, a new supernode is created that the other branches of McDonald’s within Edinburgh can also join. Then, using mandated recallable delegates (or some other democratic system) to communicate, the supernode can coordinate the local nodes that constitute it, and direct the shared resources towards their chosen ends.

The form this supernode communication takes is not yet determined, and this is what most excites me about the project. We have ideas, possibly around using visible strands, that can split and merge at will rhizomatically, you could say.

Or maybe it might involve visualising the conversation in a virtual 3D Space, similar to this one created by one of our developers - the link is best viewed on a phone so you can move it around.

To take things to another level, perhaps we need to leave euclidean space entirely. We’ve toyed with the idea of a meeting taking place in a space where there are more than 360 degrees in a circle, like this, as explored in this video. If organisers need space to talk, will a 36 sided cube do?

To get back to reality, we probably will not need to build a hyperbolic meeting chamber, but the fact that it’s a possibility excites me. These are capabilities the labour movement has never had, and to see what people will come up with is incredibly energising.

Our plan is that multiple supernodes will be able to come together to make supernodes of their own - an ultranode. The relationship of a supernode to an ultranode is the same as the relationship between a local node and its supernode. It uses the same democratic system that links the local nodes and supernodes, this time with the supernodes selecting delegates to put forward mandates for the ultranode.

So, to continue our example, McDonald’s Edinburgh and McDonald’s Glasgow could form an ultranode called McDonald’s Scotland. Because the democratic systems are ultimately derived from the local nodes, like McDonald’s Princes Street and McDonald’s London Road, the ultranode remains controlled by the workers themselves, minimising their reliance on a hierarchical union leadership to take struggles forward.

A Wobbly road-map

To get to the exciting supernode stuff, we’ve set a 3 month goal: to make a tool that is preferable to WhatsApp for organising precarious workers like Uber and Deliveroo drivers.

In practice this requires only a couple of additional features: allowing users to communicate anonymously within groups and a few security options like an invitation tree, and different levels of visibility, e.g. groups appearing in searches vs needing to scan a QR code on a comrades phone to see it.

From that point, we’ll be aiming to get enough users that we can begin trialling more ambitious features and getting ideas on what those might be. The first part of building an app is creating a team and a communication structure that knows exactly how to modify the code to alter and add features. In other words creating the links, in the shape of coders, between the software and the users. And this is another advantage of using a specialist tool: a 10 person union cannot contact the developers of whatsapp and say “we would like the app to have colour coded messages for different topics”. But you’ll be able to do that with Wobbly, because we’re building it convocationally.

How to build a tool

Most of the difficult part of software development isn’t trying to work out technical solutions, but deciding on what it is actually worthwhile to develop technical solutions for. Features, and the form those features take, are the key. Convocational development is a new term that means creating a community of software development. It requires an open-source codebase, explained below, and a social system to enable maximum participation of the users (who mostly do not speak the language of the codebase).

Open source software is the act of making the code of your software publicly available and with a non-restrictive intellectual property license. It offers three main benefits.The first is increase security over a closed-source application. To use common security terminology, a white hat (benevolent hacker) is not going to spend a long time trying to figure out what your source-code is in order to improve it, because the effort is not worth the reward. Whereas, a black hat (malicious hacker) will, because once they find a vulnerability, they intend to either sell it, or exploit it. The good news is that there are more white hats around, and if you make it easy for them to audit your system, they are happy to oblige. This reason alone is enough to use open source software for this project.

The second is a phenomenon in open source called forking. Any open source project can be forked, that is, copied and developed in a different direction than the original. Anyone can make their own version of Wobbly if they truly believe they can do it better than us. Or just try out experimental ideas that aren’t ready for mainstream release yet. This creates a release valve that deters the project from deviating from the needs of the users.

The third is that the open source resources available for developers are truly staggering. Everything, from our language that we write the app in, to the design frameworks, to the software we use to write that language is provided, for free, by a massive community of developers. From ECMAscript, to React, to GitHub, we can call on millions of hours of labour for free to build our emancipatory world.

This is a massive digital commons that I had a very limited idea existed before I started learning to code. I was aware that open source software was out there, in terms of Linux and a few tools I would use occasionally, but the scale of it was only clear once I started developing myself.

We are aiming to use what I call accessible open source, which aims to address the technical barrier (illustrated above) using documentation and structural links between participants in the creation of the app.

The yardstick we’re using is that it should be plausible that a user, without any low-level knowledge of how coding works, could think of a way to improve the app, suggest it to the development community, flesh out the proposal to include it, and maybe even, with the proper guidance and links to resources, write the code that is then committed to the codebase of the app itself.

Most likely, that scenario will be a rare one in its entirety, but allowing for the possibility means that development becomes a better experience for the people at every level of the process. The key idea is frictionless movement between users, designers and coders.

Techno-Syndicalism

Techno-syndicalism is the name given to the political thought undergirding our emerging form of practise. That is, using computers and network technology to lay the groundwork for an industrial democracy. Creating a space for workers to meet each other and relate to each other as a class, and then to organise production on lines other than profit. It means creating self-sufficient communities that produce everything they need in an ecologically sound manner, while recognising the multiplicities of wealth other than financial that have been perpetually discounted for the past 40 years.

From this perspective, any plans to structurally reform the economy away from private industries to cooperatives and public companies will not succeed, without a nascent worker’s democracy already in existence. Creating workers councils from above cannot work, because the formation of a democratic system is a complex task, not a complicated one. It has to be approached experimentally, rather than relying on expertise. For more on the distinction between complicatedness and complexity, check out this video on Cynefin.

Wobbly is optimised for the organising model of union action: the patterns of interaction that we aim to make easiest are the actions that create workplaces with 90% union membership, that have strong presences in the community and feel as if they are the property of the members, not distant officials.

Organisation is the path of indefinite strikes and transparent negotiations and requires building supermajorities of workers through a series of structural tests of the union. This is a deep unionising model where workers are responsible for their own activity, and the union belongs to them. The other levels of action like mobilisation (one day strikes, an A to B march, a petition, paid union officials making speeches on TV) and advocacy (hiring a lawyer to issue a legal challenge to a company, funding political parties to make changes through new law) are de-emphasised.

So, where are we now?

We’ve selected our technologies, and are nearly finished building the prototype. We’re making a progressive web app, that is, a website that acts like an app, using React, with plans to use React Native to deliver Wobbly to the Android and iOS app stores. We’re using a system called Atomic Design that divides components into Atoms, Molecules and Organisms to build up a pattern library so that it is easy for people who want to add new features to jump right into making them.
This technique is fairly new, so we’re also building a tutorial for developers that join the project, that guides them through creating a simple component to more advanced features. We’re currently working on the front-end design, and finalising the GraphQL API that delivers data from the user to the server. Our back-end uses a combination of Prisma, Apollo and PostgreSQL servers.

At the moment, besides myself, there’s one other person doing non-code work on the project, mainly scheduling meetings and taking minutes. I write about the project and talk to people who want to contribute, and have been getting in touch with unions like the IWGB and GWU to tell them about how far along the project is, and what they want to prioritise.
There are three people who’ve contributed code so far, and five more who are ready to when the framework exists to do so. We’re expecting that to increase, and we will start to need people who can help with coordination of coders and interactions between them and the users.

Most of those coders have been coming from ProgCode, a group that has been really helpful for this project. ProgCode is a hub for progressive coders (and non-coders) from all around the world and I recommend anyone remotely interested in technology join. They are in need of people-skilled people to help their community of ~1500 to build powerful tools for social movements. Even if you don’t have time to help out, they’re plugged in to the cutting edge of counterpower. There’s even an anarcho-communism app called Guttersnipe.

In the next couple of months Wobbly will be at a point where we need facilitators to assist developers and start finding potential users, and promoting the app in general.

Wobbly’s main input is people’s time. The free tiers of online hosting services (e.g. Heroku) are most likely enough to get us to a point where our users can start contributing financially.

Most of all, we need people to join the project. At the moment our biggest need is for developers, but in the next couple of months, that will shift to needing users, and people who can fill the gaps between users and programmers, like designers, researchers, theorists, facilitators, writers, artists, lawyers etc. It’s going to take a large collective intelligence to build this, so any help at all, even a tweet sharing this article, is really appreciated.

If you have any interest in Wobbly, go to our website [wobbly.app] and sign up for our mailing list, or if you want to contribute to making it, join the discord here, and have a chat with (@KingMob) in our #welcome channel. Or send me a message on twitter. Or email me ( john.software.evans(at)gmail.com ). Check out the project’s current progress on GitHub.