What is the difference between percloud and...

Many people who read the percloud proposal stop after the first few paragraphs because they conclude that “bah, this would be just another version of “X””. This page explains why, in my humble opinion, they are wrong, looking at each of those projects. But before that, a short preface is unavoidable. For feedback, please see the bottom of the page.

“What are the differences between percloud and…

The shortest possible answer #

is that, if any of those projects were a sufficient solution to the actual problem I care about, we wouldn’t be, five years after the initial proposal, in this situation:

Short answer #

The short answer, in practically all cases, is “think to pizza”. Pizza is one of the most popular foods worldwide. If percloud were pizza, it would be the whole right side of this picture, and the other projects I know of would be somewhere in the left side:

Pizzas on the right side may be made of exactly the same ingredients in the left side. But the right side is the only way in which the great majority of people (deliberately ignoring more “sophisticated” foods!) ever demands and gets pizza.

Percloud must indeed use many of the same software applications already used or developed by existing projects. It would be dumb to do otherwise. But this is a world in which more and more Internet users only own a smartphone. And even if turned out that all is lacking to have what I call percloud is “only” a full “cooking and delivery service”, plus proper promotion, of some of those projects… those alone would be huge differences, worth a difference project, involving people (not necessarily me!) with different skills than the original developers.

So, if you are a developer of one of those projects, and find yourself thinking “duh, this is exactly what I’m already doing, just wrapped in a nice package for people who can’t bear ANY fiddling with software”… , you know what? Right now, I cannot exclude that you may even be right, eventually. But that is exactly the point. 99% of humans belong to that category.

Main technical differences between percloud and the others #

In general, the main, but crucial differences are that percloud:

  • tries to be really, immediately usable even by people without their own computer, or always-up internet connection.
  • sees quick mass adoption as more important than almost anything else. When a building is on fire, you don’t wait till you’ve built a better building to rescue the people inside. You get them out and give them an emergency blanket. All the projects belows probably are “new better buildings”, but what is needed NOW is a blanket. LOTS of blankets. The percloud is the blanket.
  • for the reason above, percloud must have built-in “connectivity” with, at least, Facebook and Twitter. Lack of that is the main reason why, to non-geeks, most of the projects below still feel “largely so underpopulated that there’s been no incentive to go back”. This is discussed at length in the proposal
  • each percloud must have its own domain name, and includes assistance to get one

Differences between percloud and… #

Let’s now look at specific projects, as they look on February 7th, 2018. None of the observations below are critics of the projects in and by themselves. They are simply the reasons why I believe that they do not solve the problem that percloud is meant to solve, that is why I am convinced that percloud is a different proposal. If I missed a project, or if you have feedback, please check out the FAQ, the complete proposal and then email me, thanks.

Cloudron #

I discussed “cloudron as a percloud” with cloudron developers in early 2017, and we found several practical obstacles in that. I’ll post details in a further version of this page.

Cozy #

Cozy has a nice user interface, and is provided as a service, but not one with its own integrated domain name, among other things. The Cozy self hosting procedure has the same limits of the scuttlebutt one, see below. Cozy also puts a lot of effort on what frankly seema niche use cases to me, that is integrating a lot of personal data and data management interfaces like: health, “quantified self” in general, Internet banking, utilities bills…. all great stuff, assuming you can use it (no bank or utility companies where I live would provide Cozy integration in the foreseable future. And I live in what still is, for better or for worse, the capital of a G8 country) but definitely not in the “blanket” category.

Diaspora #

Diaspora is “based on three key philosophies”: Decentralization, freedom and privacy. In practice, I seem to not have email and social network integration and, as far as I understand from its “choosing a pod” guide:

  • the only way to use your own domain name is to self-host your own “pod”
  • changing pod means service interruption because “your pod’s domain name will be part of your Diaspora username”
  • besides “there is currently no way to migrate a Diaspora account to a new pod”

Freedombox #

Freedombox is “a 100% free software self-hosting web server to deploy social applications on small machines”. In and by itself, the current list of Freedombox features and applications does indeed overlap a lot with the percloud one. It lacks email servers, but this wouldn’t be a big deal. However, the introduction to Freedombox explicitly notes that “the simplicity of setting up and operating a FreedomBox is similar to that of a smart phone” ONCE [Freedombox is] installed on the hardware of your choice”. This assumption alone is enough to cut off 99.99..% of the billions people who need an alternative to Facebook etc.. Besides, perclouds should be heavily optimized for the PEAAS scenario, not for running on “personal” hardware.

Indienet #

Indienet is very interesting because it aims to, among other things:

  • develop “an engine for creating federated personal web sites and apps…”
  • empower the citizens of Ghent with the option to have their own federated personal web site, at their own domain
  • above all, includes “Onboarding Scenarios that are basically identical to what I feel necessary for Percloud as a service.

Federated personal web sites at their own domain, with such an “onboarding” procedure are the right way to go. However, I don’t know enough of Indienet yet to judge if the percloud may be “only” a generalization” of that project (adding an independent email server, making sure that those personal web sites are easily movable to new servers/domains, adding FB/Twitter interfaces…). I’d like if that were the case, actually. And I’d like to receive and publish here comments on this by the Indienet developers.

Mastodon #

Mastodon is only a “microblogging” platform, promoted as “alternative to Twitter”. It does much less than what perclouds should do. Above all, Mastodon is still proposed as a platform, whereas we should go where we need no platforms instead. Check this, and the links at its end, for more.

Nextcloud/Owncloud #

Nextcloud and Owncloud can (and even that is an approximation) replace Flickr and Dropbox, but certainly not Facebook or Gmail. They have no embedded email server, just to name one of many lacking features. As a minimum, it seems to me they are missing general support for Indienet-like “Onboarding”, and full optimization (both of nextcloud/owncloud proper and the underlying Linux VPS/container) that would be needed for PEAAS.

Sandstorm #

I and other members of FKI tried to set up Sandstorm last year, for what I call “group boxes” in the proposal. It was so complicated to manage, and so far from requirements 2 and 3 of the percloud proposal that it is simply out of question. Great product, but for perclouds… it would be like killing ants with a speargun. No, thanks.

Scuttlebutt #

Scuttlebutt is a “decentralized gossip platform”. As far as I can tell from its application list, scuttlebutt includes no email or RSS aggregator, and generally seems focused on “doing stuff” only among scuttlebutt users, rather than giving them permanence and visibility/interoperability with the current Web and social networks. Besides, the “quick start” install of Scuttlebutt is this procedure:

is totally unfeasible by the average Facebook user, or person without a fixed computer, permanent Internet connection. Assuming they would remotely understand what they are supposed to do, of course.

Feedback? #

Before asking any combination of “why aren’t you DOING this yourself?” or “if you can’t, why don’t you just shut up”… please please please do read, besides the complete proposal, both this and this. After that, just email me, thanks!