Saturday, April 25, 2009

Rejecting the Cloud

Maybe this seems radical to you, and maybe it doesn't. To understand the reason the Cloud is a bad idea, we need to look at the short history of the web since the late 90's. The best example to look at is e-mail, but the same arguments apply to most Cloud applications. In those days, you got email access through POP and later IMAP. The service you were paying for was just a reliable email server and an account on it. Some free sites generated ad revenue by injecting text ads into the bottom of your emails (some still do). Since then, various web clients have come about. The main reason for the exodus to web clients was not that the web email clients had a better user-interface but because users could have the same user interface at any computer terminal. This is incredibly attractive to many users who do not care that much about their email client's features.

There are a number of problems with "Cloud" applications.

First, is that you cannot access the service unless you're online. You may argue that you're almost always online, but this is hardly true for mobile users. The fact is that a user should be able to access their data even when offline. This is the reason Google has their Gears project. There is another implication: you don't posses and own the data. You don't actually know if it's safe, being sold, or even managed securely. You just have to take it on faith that the service provider is doing their job. In some cases you may not even be able to extract your work or data in a usable way. What if the provider goes under, what if they are bought and the service is canceled? Not completely owning and possessing your work should be a major concern for users.

Second, the user gets an augmented version of the service. By this I mean that the service starts to be branded and enhanced by the provider. It gets integrated with the providers other features and starts delivering unique features. At first this seems like a good thing, a result of competition between providers. The reality is that this results in broken APIs and interoperability issues. These enhancements make it difficult for a user to leave a provider or to integrate a provider's features with their other work.

Third, the browser is a bad platform for these kinds of applications. The browser was never designed to be a host for dynamic applications of this complexity. Their are numerous development and usability issues in web development. Almost all web work involves hacks and workarounds to accommodate situations where browsers don't adhere to the web standards. The browser has been contorted to fill a role that your computer environment should have filled all along.

No comments: