Skip to content

Sovereign Tech Fund

Status: rejected

Project title

Critical fixes & enhancements for Abra, the Co-op Cloud command-line interface

Describe your project in a sentence.

Abra is the flagship command-line interface for Co-op Cloud, built to support the day-to-day workflow of deployment operators and recipe (app configuration) maintainers.

Describe your project more in-depth. Why is it critical?

The core technical work of the Co-op Cloud project involves democratic tech collectives hosting open source apps on self-managed servers. These apps empower digital sovereignty for members of our own collectives, and the wider community of partners, allies and clients for whom we operate these privacy-preserving, commons-based services. This is vital at a time of increasing surveillance predation and centralisation by "Big Tech" firms – including widespread regulatory capture – but also as public awareness of these issues grows, to facilitate concrete and meaningful action.

Day-to-day operation of Co-op Cloud uses the "Abra"command-line interface to interact with the app packaging & maintenance ecosystem, run app deployments and support long-term app maintenance (backup, restore, monitoring, etc.).

Since the Beta launch of Co-op Cloud in May 2022, we've formed a federation with 10 founding members, 2 of which run large-scale deployments (100+ apps in production) managed using Abra. Each open source app requires maintaining a shared app configuration ("recipe") using Abra, collectivising the federation members' experience into the digital commons.

Abra is a critical infrastructural resource because operators and recipe maintainers rely on it to do their work, share their work and operate and maintain their Co-op Cloud deployments and recipes. Abra is increasingly being relied upon for daily operations by more democratic tech collectives as the Co-op Cloud project scales up membership.

git.coopcloud.tech/coop-cloud/abra

coopcloud.tech

Please provide a brief overview over your project’s own dependencies.

The design of Abra is based on the idea of wrapping existing APIs and interfaces to provide a more convenient and efficient workflow for operators and maintainers. In this way, Abra relies directly on integrations with core Linux tooling such as Docker, Git and SSH.

Abra relies primarily on interacting with the Docker Engine APIs using the Go programming language, in order to interact and control container runtimes on the self-managed servers. Abra speaks directly to the Docker daemon on the server using those APIs. Abra also relies on several non-public APIs from Docker and Mobdy related packages.

Abra provides library APIs for clients which are currently available for experimental use. Tools such as Kadabra consume the Abra API in order to provide server-side automation, e.g. automatic upgrades. Furthermore, cctuip, a prototype text-based user interface for operators also consumes the Abra APIs.

Both Kadabra and cctuip are being developed by members of the Co-op Cloud federation. Both tools are actively being used, tested and developed within the context of production deployments.

Abra relies on self-hosted Gitea (code hosting) & Drone (continuous integration / continuous deployment) systems to provide binary builds and release automation.

Operators and maintainers who rely on Abra for daily operations are as follows:

Which target groups does your project address (who are its users?) and how do they benefit from the funding (directly and indirectly)?

The intended public of the Co-op Cloud project are established democratic tech collectives, such as technology co-operatives, who are already involved in public service providing. This focus allows us to situate our work within the specific requirements of this community, of which we are also a member.

Collectives would immediately benefit from the funding of critical fixes and enhancements in Abra: the fixes and enhancements listed in this proposal are generated through our bug reports, discussions and proposals for change. Receiving funding to proceed with this work will bring the exact changes required to improve the day-to-day operations and maintenance of the Co-op Cloud technical community.

Collectives face issues of scale when trying to achieve financial sustainability. As a consequence of Big Tech, end-users are accustomed to receive services for free or at very little charge. Small service providers need to scale out usership to make ends meet, which brings the risk of becoming overwhelmed with maintenance tasks, e.g. responsibility to backup data correctly across several apps/servers/groups.

Tools such as Abra play a key role in reducing the maintenance burden and expanding collaboration within the responsible collectives, because it is designed to do so by the community itself. In this sense, an improved and stable Abra increases the chances that end-users receive a stable and reliable service, which in turn helps with further outreach to grow the number of users benefiting from privacy-preserving, user-friendly, and community-directed software systems.

How was the work on the project made possible so far (structurally, financially, including volunteer work)? If applicable, list others sources of funding that you applied for and/or received.

Co-op Cloud, including Abra, was initiated by members of Autonomic Co-operative – initially on a volunteer basis, and then financially compensated from Autonomic's revenue once Abra reached an initial alpha release, including nominal back-pay for the volunteer work.

Shortly afterwards, Co-op Cloud received 32,986 EUR in funding from the European Cultural Foundation to bring the project to public beta, and more widespread adoption by tech collectives. Autonomic Co-operative, who applied for the funding and continued to manage Co-op Cloud & Abra development during this period, helped distribute this funding to community members, to help avoid the frequent reliance of commons technology projects on volunteer labour.

Following the public beta launch, the project received 10,000 GBP in funding from a private donor to support the launch of the Co-op Cloud Federation, a nascent multi-stakeholder co-operative modelled after the CoopCycle model.

We also applied for the NLNet User-Operated Internet Fund for funding to work on an web-based operator interface but were unsuccesful.

Currently, the project's main sources of funding is the membership dues of 10 federation members who pay 10 GBP / month to the federation common fund, and the ~5000 EUR left over from the private donation.

What do you plan to implement with the support from STF?

The Co-op Cloud project is reaching a point where a significant number of democratic tech collectives rely on Abra for daily operations of their large scale production deployments.

This brings new technical challenges in two directions.

The first is handling the increase in bug reports. The challenge here is the increasing scale, diversity and collective triage and discussion required to fix the bugs. We're seeing that these new fixes must be nuanced in their implementation and aware of diverse needs of operators/maintainers. This can often result in democratic decision-making to achieve consensus on a fix that is agreeable to those involved.

The second is a new challenge in which we must implement larger scale enhancements in Abra. We're seeing changing workflows, new approaches to deployments and discussion which result in proposals for significant changes in Abra. These changes often risk major disruption in workflows, e.g. for the app maintainer ecosystem and require a period of consensus building and democratic decision making around a proposal. Furthermore, the deployment of these changes typically require a pre-release and early adopter testing phase before rolling them out fully in a new release of Abra.

We currently categorise these two development trajectories under the following project boards:

Abra has proven itself as a resilient toolset over 3 years of development and adoption. However, with the increase in scope of fixes and proposals for large scale changes, is at risk of falling behind and at worst, becoming an obstacle to day-to-day operations as the ecosystem of open source infrastructure management continues to change.

With the support of STF we can ensure the continued resilience of the project by implementing the fixes and changes generated by the Co-op Cloud community of operators and maintainers.

Who (maintainer, contributor, organization) would be most qualified to implement this work/receive the support and why?

Abra currently has 7 maintainers who work infrequently on Abra alongside their existing responsibilities in their own tech collectives. 2 of these developers have been involved in the first implementation of Abra, including the original Bash implementation. 4 tech collectives are represented in this development team.

We believe we have the expertise within the existing maintenance team to carry out the proposed changes in Abra. In our estimations, we expect that 2 developers can engage significantly in Abra development on a more dedicated basis over the course of 8 months.