The Co-op Cloud Public Beta
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.
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:
abrais 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
abratest-suite-of-sorts, release automation & management, and fairly comprehensive documentation.
abrano 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.
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
abrato 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
abraso that operators can easily control the deployment state of their apps (e.g.
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.
abrais able to parse all recipe repositories in order to generate a JSON recipe catalogue listing. This catalogue is then consumed by
abrain order to reason about deployment state and determine available versions.
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 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
backup-bot-two can then read these labels at run-time and do backup/restore work.
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 🤞)
- Local-IT (operators, maintainers)
- Threndol Tutoring (end-users)
- ruangrupa &
- Servers Co-op (operators & end-users)
- Vermont Real Estate Co-operative (end-users)
- United Tech & Allied Workers (operators & end-users)
- Industrial Workers of the World (end-users)
- Autonomic Co-operative (operators, maintainers)
- Neuronic Games (end-users)
- Fashion Revolution (end-users)
- Biobulkbende (operators & maintainers)
- Third Sector Accountancy (end-users)
- Anarchy Rules (end-users)
- Doop Coop (design work & feedback)
- bath.social (operators & maintainers)
- Bonfire (operators & maintainers)
- Tante Wandel (end-users)
- WASHNote (operators)
- Solisoft (operators & maintainers)
- Forum voor Anarchisme (operators)
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.
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.
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.
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.
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.
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.
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.
We established branding and aesthetics through conversation about our values and how we want the project to be represented.
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:
We ran a (mostly) monthly blog post update on
coopcloud.techto give a more general status update.
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
Getting the documentation and website translated.
Looking for new public funding.
Public Money, Public Power
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 🎺