11 minute read

We discuss how we formed the CommonsCloud project and what key technical decisions we have made so far to set in motion this cooperative cloud platform.

We’ve recently started a crowdfunding campaign at the Goteo platform, many people are asking how did we start to develop this project. Let’s take a dive into where we come from, which free software building blocks we have chosen so far and how they come together. Then we share some ideas for the near future.

how did we get here and where are we heading

CommonsCloud is an online collaborative platform, an alternative to proprietary software platforms like Google Drive, but respectful with privacy and it doesn’t commercialise your data. The ambition of the CommonsCloud project is to offer an alternative to proprietary cloud platforms, under the control of its users, replicable as free software and well documented. This is collaborative web applications to edit, store and share documents, agendas, manage projects and facilitate debate and decision-making. The way we do this is through an alliance of collectives committed to free software and digital sovereignty, building on the best web applications that are already out there and bring them together in a user-friendly environment where people help each other, enhance their awareness regarding the power of self-governance and sovereignty.

Collectives and individual users have a say in the decision-making of the CommonsCloud, through the cooperative femProcomuns. Users become co-owners of the CommonsCloud as cooperativists, paying a monthly contribution for the services needed. Users that want to try the service or contribute in other users projects, can access a free account with the basic services. Everyone can choose their contribution according to capacity and needs.

We’ve recently started a crowdfunding campaign at the Goteo platform, many people are asking how did we start to develop this project. Let’s take a dive into where we come from, which free software building blocks we have chosen so far and how they come together. Then we share some ideas for the near future.

Brief history and inspirations

We didn’t want to reinvent the wheel, or our ambition would have little chances to become real. We can say that all collectives participating in the CommonsCloud Alliance have their own experiences self-hosting their free software web applications, from wikimedia instances to taiga, RedMine or WeKan boards for kanban/agile self-management of projects. From ownclouds to NextClouds and from Asterisk (VoIP) to Etherpad or RocketChat servers. The thing with all these webapps is that if we manage them individually, our users typically need to register many different accounts and collaboration between collectives is rather limited. And there are so many web applications that keeping up to date on all of them is a job on its own, not something that one can do alone. So there’s a need to build this together, especially as the tools and networks of the corporate masters are very powerful and it isn’t easy to seduce people away from them.

There are some platforms that make the management of free software web applications very straightforward and with reduced maintenance effort. Let’s take a loot at the ones we have worked with.

Since September 2016 we have been running a self-hosted server with Sandstorm. Currently, FKI still runs that instance and we have tried it with a few dozen people and projects. It allows one-click deployment of over 40 apps and encrypts the data of the users in a personally controlled “grain” as they call it. After some time we found however that it isn’t especially easy to find back your information inside the dfferent apps, in particular if you are involved in different projects. Also the users need to get used to so many different user interfaces, one for each app - even though these are embedded into one persistent interface of the Sandstorm platform. A very interesting project, but it wasn’t exactly what we wanted.

Then we studied Cloudron and set up a few instances, spoke with the founders, ran a dozen of the applications. On this platform there’s again a one-click installation procedure, that in this case installs each app in a docker container, that requires very little maintenance effort. The offer of the Cloudron founders is a 8/month subscription fee to get maintenance updates for self-hosted instances, very decent really. Maybe this was getting nearer to what we wanted, but we felt we lacked control over the applications. Maybe this solution is designed for collectives without sysadmins…

Then a very inspiring case is the Framasoft project in France, which has put up different webservices for many of the usual applications which its users can access with one account. From spreadsheets, to videoconferencing, to notepads, to framadate (alternative to Doodle), from calendars to mindmaps, etc. One interesting feature is that their sustainability model is based primarily on donations (some 300.000 euro/year), an alliance of collectives that contribute to the development, maintenance and usage and a team of 7 people with a salary to maintain the core operation, plus 35 members and some 300.000 users. Some differences with the CommonsCloud though. After several co-creation workshops we have decided to reduce the number of userinterfaces. Instead of several dozens we are starting with three core platforms that we intent to integrate where possible, but that each one of them provides a wide range of features. One other is that we set this in motion as a platform cooperative, where the users become the owners. We love Framasoft’s “De-googlify-Internet” campaign!

So how did we start the CommonsCloud? The first meeting we had was in January 2017: we got together with 10 people from different collectives in Barcelona to lay the foundations. We have put in common the experiences as briefly reviewed above. Other interesting cloud applications that we should mention include Cloudy that our friends at Guifi.net and the UPC are developing as a GNU/Linux based cloud infrastructure and Cozy as a personal cloud solution. FKI Board member Marco Fioretti has been working over the last five years on an architecture proposal for a personal cloud or “PERcloud” that each user can have individually on his/her own machine. This vision has influenced the design decisions of the CommonsCloud architecture, even though our current architecture is focused on collective cloud solutions that are co-owned by the users. After a co-creation session at the Mobile Social Congress in Barcelona in 2017 we set up an international working group, on the FKI wiki and the CommonsCloud mailing list. From there, the work has continued on- and offline, in parallel with the set up of the femProcomuns cooperative, until now, when both are ready to take the next step: enter the production phase.

The core software architecture Keep it simple and hide the complexity.

One account for single sign-on The first thing all mentioned platforms have in common is one account server that allows users to login at all different services (single sign-on). LDAP - the Lightweight Directory Access Protocol - is the open standard to organise directories of user accounts, and most webapps have existing plugins to facilitate user accounts managed through an LDAP server.

We designed the LDAP Directory Information Tree in such a way to accomodate for other collectives to join the alliance and share the LDAP account server (we consider it a mutualised account server). Each user can be part of multiple groups (Organisational Units, OU) and each OU can have multiple services and ACL groups. We all know how important user onboarding is. Given the increasing challenge to keep spam under control, we bring human validation of accounts back into the game. Remember your wiki getting full of SPAM and closing automatic user registrations? We have seen it in different contexts. Instead we designed an onboarding process that goes as follows:

  • people register and indicate a primary collective, and validate their email address
  • the admins of the primary collective validate the user and activate the account
  • the user sets her/his password and s/he is up and running on the services that are available for everyone (public services) plus the ones from the primary collective.

From here on, the user can manage his/her profile and request or be invited to become part of other collectives and access the corresponding services. Our man Chris has been developing the webinterface that facilitates this process. Still much UI work is to be done to make the experience better.

Phabricator - as the community PROJECTS self-management platform Based on user demand we prioritised three main areas of applications with a “winner” in each area that we considered as the most solid and strategic choice for that area. Phabricator is a platform to manage projects, that allows open/closed, volunteer/professional teams and communities to organise their work with agile methodologies and Kanban workboards (like Trello, Wekan, Kanboard) with a few dozens of complementary applications that one can integrate easily within a group if so desired. It also ofers a locker to store passwords and other secrets, a hierarchical wiki and a documentation engine, a survey tool, notepad, badges, blogs, etc Members of the Barcelona: Free Software association (part of the alliance) shared the experience of the global KDE community who uses Phabricator to manage software development with its code repository toolset; the Wikipedia community also runs its own Phabricator instance. As you can appreciate, Phabricator is not just for code development (like github) but provides an extensive toolset for non-technical teams to self-manage their community production work.

NextCloud as the core online OFFICE platform NextCloud is the community fork of ownCloud and many consider it the best of online cloud platforms, where one can store and share files, calendars, and contacts. With the appropriate plugins, online editing of office documents can be integrated. This we consider the killerapp that our users need to migrate from Google’s Drive. There are several options here to edit online documents. At this moment we have integrated the CollaboraOffice online LibreOffice server for that purpose. There are also other options, such as Only Office, that can do that job. We are collectively exploring what’s the best solution on this front. We know for sure that many of our users need to collaboratively edit online office documents, or Google Drive will remain their “friend”. NextCloud has recently incorporated the so called “Circles”, which allow users to define and self-manage usergroups whith whom they can quickly share documents. At the same time we are exploring the Groups option that we manage through the LDAP directory, where users of a certain collective can automatically have access to the collective’s file share, calendar and group contacts. While it is true that NextCloud has lots of other apps that can be added through plugins, right now we haven’t activated them. We first want to have the pioneering userbase to get used to the three core platforms and then sit together to see which features and apps we think are best to have and in what ways.

One of the most wonderful things of NextCloud is its synchronisation of files, calendars and contacts between the server and one’s mobile, tablet, laptop and desktop. When editing a document online, one may decide to continue through one’s local LibreOffice installation, synch the files automatically and continue on any of the synched devices, automatically the whole team has access to the latest version of any shared document, without additional human intervention.

Discourse as the AGORA, the platform for online debate and collective decisionmaking Online discussion needs a good platform to convince people with so many different experiences. Some are fans of online forums, others of mailing lists. Discourse combines them both into a flexible and userfriendly environment. We found it a very decent complement to the other core platforms.

Some aspects of the User Experience The first thing we already mentioned was the decision to limit the number of user interfaces, of different plaforms. Right now we have three: Phabricator, NextCloud and Discourse, plus the webinterface for the onboarding process to register and manage users in the LDAP directory server. We will try to choose new applications within these existing platforms, but there will for sure be some more platforms that we will add in the near future. For example the OdooCoop economic self-management platform for the social and solidarity economy that we are developing with another alliance around the femProcomuns coop. And possibly other, depending on the demand of the users and the proposals of the developers.

A second aspect is the onboarding process itself. Based on previous experience, the fully automatic user validation isn’t our preferred route, due to the risks for SPAM. On the other hand a fully centralised human validation process could slow down the onboarding of new people. Instead we choose a path in between, where new users choose a “primary collective” where they belong to, and the admins of this collective get then notified and can validate the new user accounts.

A third aspect is the combination with public CommonsCloud services, such as the three mentioned services explained here, and private instances for collectives participating in the CommonsCloud. A user can have access to the public NextCloud instance but also to the private one of his collective. The user interface will need to combine these options neatly into a humanly understandable and easy to user interface.

Modes of production The way we produce the services as explained here is as much as possible building on the motivation of the shared mission. We can distinguish three levels of engagement:

  • Driving team, of developers, sysadmins, designers, comunicators etc: they take the initiative to make it happen, and are the first ones to get paid when income is generated; income is distributed depending on real work done;
  • Alliance members: they share knowledge on the R&D level, participate in the strategic decisions and want this initiative to exist;
  • Endusers: they are aware of the need to build the alternatives to corporate clouds collectively as a commons and contribute according their needs and capacities to make this happen. Endusers can be either individuals and collectives who want a dedicated instance of some or all of the services offered. In a next post we will share the governance model that we are developing to guide and organise our work.

Many details need still to be defined, but we are working along these lines to take the leap. Join us and contribute to the CommonsCloud.

You may also enjoy