The Personal Cloud and Data Deposit Box

Last night I gave a short talk at the 3rd “Personal Clouds” meeting in San Francisco, The term “personal clouds” is a bit vague at present, but in part it describes what I had proposed in 2008 as the “data deposit box” — a means to acheive the various benefits of corporate-hosted cloud applications in computing space owned and controlled by the user. Other people are interpreting the phrase “personal clouds” to mean mechanisms for the user to host, control or monetize their own data, to control their relationships with vendors and others who will use that data, or in the simplest form, some people are using it to refer to personal resources hosted in the cloud, such as cloud disk drive services like Dropbox.

I continue to focus on the vision of providing the advantages of cloud applications closer to the user, bringing the code to the data (as was the case in the PC era) rather than bringing the data to the code (as is now the norm in cloud applications.)

Consider the many advantages of cloud applications for the developer:

  • You write and maintain your code on machines you build, configure and maintain.
    • That means none of the immense support headaches of trying to write software to run on mulitple OSs, with many versions and thousands of variations. (Instead you do have to deal with all the browsers but that’s easier.)
    • It also means you control the uptime and speed
    • Users are never running old versions of your code and facing upgrade problems
    • You can debug, monitor, log and fix all problems with access to the real data
  • You can sell the product as a service, either getting continuing revenue or advertising revenue
  • You can remove features, shut down products
  • You can control how people use the product and even what steps they may take to modify it or add plug-ins or 3rd party mods
  • You can combine data from many users to make compelling applications, particuarly in the social space
  • You can track many aspects of single and multiple user behaviour to customize services and optimize advertising, learning as you go

Some of those are disadvantages for the user of course, who has given up control. And there is one big disadvantage for the provider, namely they have to pay for all the computing resources, and that doesn’t scale — 10x users can mean paying 10x as much for computing, especially if the cloud apps run on top of a lower level cloud cluster which is sold by the minute.

But users see advantages too:

  • You can roam from device to device fairly seamlessly. Failure of one of your devices usually doesn’t mean no access.
  • Due to having land and wireless internet connections, you can often use services even if your home computer is off or disconnected (though at the same time many services become unavailable or poor when connectivity fails, such as on airplanes.)
  • You don’t have to install or maintain the software (or even much about your own device) or upgrade.
  • They back it up for you and worry about security.
  • For many compute intensive tasks, you can have access to vastly greater computer power than you have at home.
  • People seem willing to give all these resources away free or cheap. Even when they don’t, you share those high-end resources with all the other users, making your share of the costs low.
  • Social applications are cool and fun.

Many of the developer’s advantages are user disadvantages or risks — to control and privacy in particular. Using the remote computer also changes the performance equation. Cloud application performance is largely based on the resources at the cloud company and the speed and quality of your internet connection. You can’t make cloud applications much better or faster by buying a faster computer, not in the way you could for desktop applications. And the internet connection is of course also the curse; if there is no connection, you have no app. We’ve also seen cloud app companies die or shut down products. When a desktop app company does this the already installed software usually keeps running just fine for a long time.

The challenge to the personal cloud system

With cloud apps and social apps being so compelling to users, the challenge I placed before personal cloud development last night was to figure a way to be as good as, and in fact better than things like Facebook in every way. That means.

  • As easy to sign up for as Facebook (and so many people have now signed up for Facebook that it has a double advantage of zero friction here.)
  • As easy to use as Facebook — ie. as easy to do as going to a web page. Software or hardware installs are a big barrier.
  • As free as Facebook.
  • At least as profitable for developers to support as Facebook — ideally moreso.
  • More accessible to developers as Facebook — here is where an open platform has the best chance for a win.
  • As reliable as Facebook — high uptime, fast access all over the world
  • More compelling than Facebook — all the fun of social apps, and more things that can’t be done there.

This challenge is required because you won’t sell more than a small minority on privacy. Personal clouds can deliver much better privacy, and that’s good, but people don’t focus on privacy in their decisions unless they have personal experience of an invasion. Everybody wants better privacy, but the majority will not sacrifice other features to get it, because the fear is abstract, and the cool features are concrete.

Payment

I refined my thoughts on how to solve the particularly hard “as free as Facebook” problem. This is an important problem. I think ideally everybody would just already be paying for some amount of personal computing power in the cloud from some provider. This does not happen now, and is unlikely to when so many other resources are given away free, supported by advertising or other indirect methods of payment. The current model has forced websites into using methods like advertising to finance them.

This is particularly true as everybody does cloud applications and hosts on sites like Amazon Web Services. If you build a popular cloud application, your costs go up linearly with your usage. You have no choice but to have a way to pay the cloud bills. You can either have investors who pay them, hoping for revenue in the future, or you can fund them with advertising. Charging subscription fees just isn’t an option for most such services, unless there is no competition and the service is so compelling people will get over that hump.

This is different from the old PC (and current mobile) model, where people downloaded software. If you go from 1 customer to a million, your customer support costs do indeed go up, but your core costs don’t increase a millionfold.

To make that happen, you either need users to pay for their own cloud resources, or perhaps ideally to get included resources from their ISP. This happens in a sense already, in that almost all ISPs provide E-mail, and sometimes some web hosting and other services, as part of the deal. But it doesn’t happen with cloud general computing resources.

One transitional model I have described would be a micropayment token system. A site that wants to be free could provide you, with each session or page hit, a small token. These tokens, passed on to your cloud provider (such as AWS or Google AppEngine or similar) would allow the cloud provider to bill the site, in aggregate, for the resources needed to run their apps.

Tokens of this sort would probably only be usable with major cloud providers, ones who can be trusted to deal fairly here. Otherwise there might be strong incentive to game the system and overcharge the sites. Since each action would have variable cost, the tokens would need to have a range of costs they would handle. While it would be tempting to allow users to run their personal cloud on their own machine, and receive the payment from the tokens, this would be particularly risky for abuse. The amount of your own resources this would need is so small that it’s not really worth having a way for the site to pay you for it. Besides, the real goal is to move to a world where you pay for your use yourself, and sites no longer need to spend money to serve you.

In such a world, well-funded or advertising sites could say, “Use us for free with your favourite provider or your own server” and it would look just like today’s world. Smaller, startup sites could say, “You can only use us if you get an account to pay for the resources or have your own server.” Many users would install a server in their own home, or even on their own PC, and others would get accounts from those who sold them, if they found these less-well-funded applications to be compelling. Usage would be less, but poorer startups would have a chance.

The reality is that the bill for your cloud computing resources should be quite small, smaller than your ISP bill. A lot of people might tolerate it. A minority to start, but even that can be enough. Sites that get some success while making their users pay might well then raise the funding to subsidize user resources and expand their market after testing it with the minority. With luck, we would also find more and more users wanting to play in the space of apps that need resources, since there would always be cool apps on the edge — cool enough to pay for, not big enough to get investors to pay to give it all away.

If this took place, I believe we would get a richer platform of innovation, and we would see a lot more development of useful web applications which can operate without needing advertising. Advertising is great for supporting some things but terrible at others. Each funding model has its strengths and weaknesses and it’s better for the ecosystem if all the models are easy to try.

Post new comment

His name is Brad Templeton. You figure it out.
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
Personal home pages only. Posts with biz home pages get deleted and search engines ignore all links
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options