221 views
 owned this note
# Co-op Cloud beta bikemap ![](https://vvvvvvaria.org/~decentral1se/cc/fietsen.jpg) > We're not very fond of the word "roadmap" which is the word traditionally used to mean something like "a list of goals to achieve in a given time" :stuck_out_tongue: The following are not listed in any particular order of priority and are subject to change. We are using [these milestones](https://git.coopcloud.tech/coop-cloud/organising/milestones) to track our work on this bike map. We also have this [Project board](https://git.coopcloud.tech/coop-cloud/organising/projects/8) for coordinating our weekly work. ## Command-line tool sustainability The pre-alpha/alpha command-line tool for managing a Co-op Cloud instance (e.g. [`abra`](https://git.coopcloud.tech/coop-cloud/abra-bash)) is written in [Bash](https://www.gnu.org/software/bash/). This choice was made because we had little to no funding, no clear idea of a final design and were very much in experimentation mode. This choice served us well but we began to run into the limitations of this approach - difficulty in parsing different file formats, concurrent programming and command-line input handling. As part of the Beta release, we have decided to reimplement and extend `abra` in the [Go programming language](https://golang.org/) as it overcomes the limitations listed above and significantly improves our ability to deliver a cross-platform portable command-line tool without much fuss. We're fans of the [Dokku project](https://dokku.com) which also took [a similar approach](https://github.com/dokku/dokku/discussions/4258#discussioncomment-289670). ## Versioning and deploy stability We want to make deploying libre apps simple and reliable. This means putting work into the `abra` command-line interface and making sure `abra` understands what the container runtime is telling it (did the deployment succeed, fail, needs a rollback, etc.) and reporting clearly what is happening on the command-line. We also need to know which versions of which libre apps are available. And more importantly, which are reliable and can be deployed safely with some assurances that they will work? This involves coordinating with upstream publishing rhythms and integrating with a test suite (see below for more). ## Continuous integration testing for apps Libre app developer communities are publishing new versions of their apps all the time. However, not all versions deploy succesfully due to changes in configuration and/or bugs in the software. When this happens, we need to do some packaging work on the Co-op Cloud side to ensure things work. In order to understand when a new version requires some work before it can become available for deploying, we need to implement a test suite which will put the new version through a series of tests to ensure it works. ## Backup and restore After you deploy your app, you need to take care of it. That means backing it up and sometimes, restoring it (e.g. if you move to another server). Another case is when an upgrade fails and you want to restore to a previous version safely. We want to provide a simple way to backup/restore apps through `abra`. ## Co-op Cloud "The Organisation" One of the core goals of Co-op Cloud is to have the project run and managed by a diverse group of tech co-ops and collectives who are invested into building, maintaining and extending this digital configuraton commons. In order to open the project up we need to work on shared governance guidelines, codes of conduct, building community trust and working towards economic sustainability. ## Compensating contributors People should be compensated for the work they contribute to Co-op Cloud. This work could mean packaging new apps, fixing the tools we build, writing blog posts, giving work shops, doing user support and so on. We need to self-organise a clear process to help people understand how to get compensated for their work and in relation to other types of work. And this must be done in a sustainable way. ## Wider libre apps selection We want to have more libre apps available for end-users. We currently have over 60+ apps available but there are many more which cover different needs. This catalogue should be simple to navigate and understand what apps are available and what those apps are for. ## Payments and billing Too often, open source platforms leave the financial work to out-of-band organisational processes or altogether ignore the need, relying on unsustainable maintenance practices. Functionality and design for accepting payments from end-users and handling the administration of billing for hosters is critical to support financial sustainability of Co-op Cloud instances. ## Documentation Clear, concise and simple documentation designed for multiple publics (tech co-ops, end-users, general public) is an incredibly important goal for our Beta release. Quality documentation helps build capacity, understanding and promotes knowledge sharing across the project. In this sense, the documentation may be more important than the source code. ## UI / UX testing Intensive user interface and experience testing will take place across different user groups and with different focuses in order to discover what we're getting right, what we're getting wrong and how to prioritise development of the project. ## Portability testing (software/hardware) Modern computing takes place on many different architectures, hardware and in diverse conditions with regard to networking and power requirements. We want the Co-op Cloud to be performant, run reliably and be portable to support different needs. This means deploying and testing Co-op Cloud instances in different environments. ## Cloud provisioning portability (Hetzner, DO, Linode, etc.) Co-op Cloud should support running on different cloud environments and support 3rd party integrations with VPS and DNS providers. We are especially interested in supporting integrations with tech co-op providers such as [servers.coop](https://servers.coop). This kind of automation is expected when using corporate providers and we want to achieve this level of convenience as well. ## Pen Testing/security Security is important and we want to provide a realistic guarantee of what Co-op Cloud can and cannot offer. This means working with security communities in order to analyse how secure our system is. ## Design and aesthetics We want to develop and maintain a visual aesthetic and design presence which communicates what the project is about and the values it promotes. ## Public communications We want to have clear guidelines and processes around how we communicate the project to a wide public and how to self-organise that inside the project.