'Graceful machines' by Faith Holland from the Internet Gardening collection by Trav Fryer (are.na/trav-fryer).

The Co-op Cloud Public Beta

May 30, 2022

Reading time: 12 minutes

We’re delighted to announce that the public beta of Co-op Cloud is here at last! There has never been a better time to get involved in Co-op Cloud because the software kinda actually maybe works now 😆 Read on to see what we’ve been up to for the last 2 years…

Alpha 👉 Beta

Before we dive in, if you’re new to the project, you’ll probably want to start with our project launch post on autonomic.zone, and if you’re still curious, follow along on our (sometimes) monthly blog posts to get the full context.

So, what does “alpha” and “beta” quality software even mean?

Alpha meant that the project could fundamentally change at any time! Things were still super experimental and we were trying to find out how to make things work. Beta means things won’t fundamentally change! We’re pretty confident that we have a stable base now, the moving parts of the project fit well together and things are relatively easy to maintain as we bring in new changes.

Despite the experimental nature of the project so far, we’ve seen a lot of people picking up Co-op Cloud, setting up deployments and getting rad with us. Folks are reporting back that it is helping them get their work done, and fits their needs. It makes daily work convenient, and is relatively easy to learn.

To everyone who took the risk of getting involved in the alpha and even pre-alpha stages of this project: you are amazing and we couldn’t have done it without you ❤️

The beta bikemap in review

At the start of all this, we laid our goals out in a document we called the beta bikemap (because roads are usually for cars, and bikes > cars). While we believe we did not yet fully address 3 of the goals (Continuous integration testing for apps, Payments and billing, Pen Testing/security), we think we did a good job with the 12 others!

In retrospect, it was quite an ambitious plan. Here is the breakdown of the bikemap and an overview of what we achieved on each point.

Command-line tool sustainability

In the early days, we started off with a Bash implementation of abra, our command-line tool for administrating Co-op Cloud deployments. One of our more galaxy brain ideas was to re-implement this Bash script in a programming language which would help us work with data structures, formats and 3rd party APIs in a more manageable way.

We’ve since implemented abra in the Go programming language! There were some serious doubts along the way about whether we were just getting lost in a second system syndrome (yes, our Bash implementation was “small, elegant, and successful” 😄) but we managed! Here’s to 16,766 lines of Go code 🍻.

Some of the improvements include:

  • abra is now distributed as a statically compiled single binary which is simple to install and start using. The binary works for several popular platforms, and we’ve seen a reduction in reports for installation problems.

  • The Go implementation has feature parity with the Bash implementation but also gained new special powers! For example, the scripts interface, cloud server/DNS integration and recipe catalogue generation.

  • Improvements to the abra test-suite-of-sorts, release automation & management, and fairly comprehensive documentation.

  • abra no longer relies on having Docker installed on your local work machine. We’ve managed to make it a fully compatible Docker daemon client which can interact via the remote HTTP API. This makes us more resilient, reducing our reliance on corporate tools for our community needs.

Versioning and deploy stability

A core goal for Co-op Cloud is stability. We want things to run smoothly when we maintain and upgrade our deployments. We’ve been working hard on this one and have managed to come up with several moving parts which we think help make Co-op Cloud deployments more reliable.

  • Recipes can be versioned & published with abra to our recipe catalogue. Each recipe uses a variation of semantic versioning which helps maintainers communicate what kind of changes are coming in the new version.

  • We’ve documented ways to work with and maintain recipes so that anyone can join in and help.

  • We’ve implemented commands in abra so that operators can easily control the deployment state of their apps (e.g. deploy/upgrade/rollback). We’ve set up a system for release notes so that operators can leave helpful notes for other operators when doing deployments. These notes are shown at deploy-time, so operators will be warned and hopefully avoid any heartbreak.

  • abra is able to parse all recipe repositories in order to generate a JSON recipe catalogue listing. This catalogue is then consumed by abra in order to reason about deployment state and determine available versions.

Backup and restore

Standardising the way backup/restore is done was always seen as a boon for time-saving and re-use. Being able to back up and restore app data is often seen as one of the main ways a regular deployment turns into a “production deployment”.

We struggled to arrive at a single “works for everyone” solution. Instead, we aimed for a general solution which is flexible and also open to other approaches. We’ve heard from several groups who do backups very differently, so we had to have something that was customisable.

We developed two approaches to doing backup/restore. One using abra (e.g. abra app backup / abra app restore) and another using a run-time bot. We documented both of these methods and have seen several operators making use of them.

The core of our approach was to use Docker object labels to mark backup/restore commands inside the recipe configuration. This suits our approach of maintaining the entire production state of the deployment inside the recipe. Tools like abra and backup-bot-two can then read these labels at run-time and do backup/restore work.

Co-op Cloud “The Organisation”

Co-op Cloud isn’t just about digital infrastructure and libre software. We also wanted to develop sustainable and democratic governance around our digital configuration commons.

We’ve been regularly astounded (to the point of questioning reality) by the amount of wonderful folks who have turned up and started organising in & around Co-op Cloud.

To formalise Co-op Cloud as a shared resource, we’ve proposed to form a federation of participating members that will democratically manage the project. The proposal is still out for review and feedback and we’re working on concretising our next steps with groups who are engaging with it.

Beyond this, we’d like to give a huge shout-out to the folks who are using Co-op Cloud & those who are maintaining recipes, operating deployments and generally enthusiastic about the project.

Lists are always incomplete but we’ll try anyway! Here is the cast of Co-op Cloud Comrades so far:

(PS. sorry if we forgot you! Please let us know and we’ll add you in 🤞)

Compensating contributors

We didn’t want to be another project which asks people to do free work them. Instead, we set up an Open Collective, wrote clear documentation and simply paid people for their contributions!

We’re proud to report that we paid out around 2,000 euros worth of funding for work done by external contributors. It was a pleasure to open up space for people to actually get paid for their free software work and to re-distribute the available funding to other individuals, groups and projects.

We think more libre software projects should be thinking about how to use money for building collective power. In the (slightly edited) words of LURK:

Big tech and an abusive misunderstanding of free and open source software practices have led us to believe that software production, server maintenance and on-line services should be free as in gratis. However there is no such things as a free lunch and software does not exist in a vacuum. If we want sustainable alternatives, these alternatives and the humans behind them, need to be supported.

Wider libre apps selection

We wanted to expand the choice of libre software apps that operators could deploy so that different needs could be met. Certainly, we’ve seen that a lot of experimentation and testing needs to happen in order to understand if a libre software is a good pick.

We now currently have 90+ libre software apps packaged under our git.coopcloud.tech/coop-cloud/... repository listing. Most of those appear also under the recipe catalogue listing or will begin to appear once maintainers bring them into the catalogue.

Also, we wanted to make it easy to package new apps for Co-op Cloud. We expanded the recipe documentation in order to make it clear how to work with recipes in Co-op Cloud. We’ve since seen several new folks jump in and start packaging libre software without much help or guidance from us.

Documentation

docs.coopcloud.tech has been heavily revamped and redesigned from the ground up!

We expanded the idea of “roles” in the project, such as “operators” and “maintainers” and made sure to document all the recipe packaging tips, tricks & hacks.

Writing solid documentation has been our focus and will continue to be.

UI / UX testing

We have been doing extensive interface design and end-user experience testing since the pre-alpha stages of the project. This is mainly due to the “dog fooding” approach we’ve been taking.

We have been using abra extensively in our own deployments and projects for the entire period. We’ve encouraged other collectives to join us in this process and raise issues when they run into problems.

The results can be seen in 263 closed reports on our shared issue tracker.

Portability testing (software/hardware)

We wanted Co-op Cloud deployments to run on new and old hardware and of course be compatible with current cloud providers.

abra can be cross-compiled to support several mainstream platforms: GNU/Linux, ARM (several versions) and MacOS. All versions can be seen on our abra release page.

We set up release automation for automagic cross-platform builds and also see space for supporting new platforms as the needs arise.

Cloud provisioning portability

A fact of life today is that a lot of democratic tech collectives are in a position of only being able to use corporate cloud server providers. This is due to a lot of reasons (and we’re also working on changing that) but we didn’t want to ignore this and not have some form of support for it.

abra now supports the creation of servers through integrations with Servers.coop and Hetzner via the abra server new command interface. We support one co-op provider and one corporate provider.

Also, it’s possible to work with cloud-based DNS providers via abra via the abra record command interface. Creating, editing and removing DNS records via Gandi is currently supported.

We are happy to have these implementations to show what is possible.

Design and aesthetics

We established branding and aesthetics through conversation about our values and how we want the project to be represented.

This design brief was then implemented across all our public sites such as coopcloud.tech, docs.coopcloud.tech & recipes.coopcloud.tech.

Public communications

Beyond organising the project internally, we also wanted to communicate clearly to two groups: a general public and democratic tech collectives.

We wanted to build up an online community infrastructure, so that we could invite people to join the discussion and stay informed.

We’ve managed to run our public communication through several mediums:

Beta 👉 ❓

As the public beta is now in effect, we are generally interested in the following focuses:

  • Making time to welcome new folks into the project.

  • Working with collectives to concretise how our federation might work in practice. Our proposal is still open for feedback and constructive critique. We want to try to make small steps in co-operation to realise this federation as a well functioning governance body.

  • Stabilising how we maintain recipes between several collectives.

  • Fixing bugs & delivering new features in abra.

  • Getting the documentation and website translated.

  • Looking for new public funding.

Public Money, Public Power

We’d like to say a HUGE thanks to the ECF who funded this work towards the public beta. We couldn’t have gotten this far without their support and understanding during this process.

We feel it is important to emphasise that funding democratic technology collectives with public money delivers democratic outcomes!

All our work is copyleft licensed and made open and available as a digital configuration commons for others to re-use and build upon. “Code paid by the people should be available to the people!”

Furthermore, our governance and organising models are open & for voluntary participation, following the spirit of the co-operative principles. So we also focus on building our social and political commons.

As members of Autonomic, the idea of Co-op Cloud was rooted in our practical needs. We needed a democratically organised digital infrastructure project we could rely on. However, more than that, the project was also conceived as a way to put into practice our anti-capitalist politics. We still see Co-op Cloud as a way other collectives can organise to dismantle “Big Tech” today.

Get Radical with us

We’d love to see more folks get involved 🎉

If you’re thinking about setting up a technology co-op, you have a software stack sitting around waiting for you to pick up now. We have the technology. It’s built by tech co-ops for tech co-ops. If you’re curious but don’t know where to start, get in touch anyway!

We even have these amazing flyers now (massive thanks to @analuisa)! Print, distribute, share, spread the word 🎺

✌️