Cloud Computing: How today’s approach is wrong (Editorial)

I’m in the process of writing about Calligra, a relatively young project. What I’ve come to realize is that very few developers seem to understand where the world is heading, and even more importantly, where the world is at. The future is on the cloud is something people often hear, and for a reason, because the future is definitively cloud related. The Cloud offers many advantages which are unprecedented, it’s platform agnostic, it can be accessed with any computer from any internet provider from any part of the world… well, perhaps not any, but chances are you’re not trapped between the walls of The Great Firewall.

We know expect devices to be connected all the time to the web, we carry smartphones so we can know instantly when an email has arrived, we suffer from a perpetual state of data hunger, we use applications like Read it Later so we can take pieces from the web when a connection is unfeasible.

What about KDE? Is it keeping at the pace? The problem is many applications seem to be disconnected from the future, or, more plainly said, disconnected from the cloud. I’m picking document editing as an example, but what I will argue applies to most applications.

Editing in the past 


Say you and your colleagues need to write a document regarding how English is world’s de facto lingua franca. If you were to use Calligra, OpenOffice or LibreOffice, you would do the following:

Open up a chat service, or call service, or what have you, to keep in contact with the team. Then all of you would open your local document processor, and start discussing what is the job of each one of you. After a while, you would start sending emails with your share of work attached to every other member, or perhaps, just one, if you previously consented it. Then, someone will put all pieces together, but oh my, it’s clear all of you worked separated from each other, no matter how much chatting there was, so you’re forced to edit many parts to make it fit and seems like a coherent single piece instead of a colage.

Notice this somewhat natural succession of steps has one important characteristic: Users need to use tools completely unrelated to document editing to accomplish tasks related to basic document editing.

Editing in the future

You will only need open your favorite cloud application, add your colleagues, and start editing. All changes will happen in real time, discussion among writers can be held instantly, and without leaving the document editor, by either video or text. There’s no need to send any attachment or to open any specific chat service. In this future, the internet is so widespread that there are no concerns about lack of connectivity, broadband is broad enough to handle all data without hassles, and web standards are evolved enough to offer an experience as fast and as smooth as local application’s.

Another big difference between past’s, present’s and tomorrow’s way of working is that we no longer sync the content of our devices to the cloud, but the other way around, all content on our devices is nothing but a reflection of the content stored in our cloud.

Editing in the present

You have two choices, editing like we did in the past, or editing in crippled form of the future. You may think Google Drive (formerly Google Docs) has reached tomorrow’s levels, that is as powerful as local applications, but that’s simply untrue, nor it is as smooth when working with images or any relatively heavy object.

And this is the key element of this editorial, both of our current approaches are fundamentally wrong regarding the current state of affairs. We either edit like in the past, with application that completely ignore the advantages of the cloud, or with cloud apps that completely disregard the current advantages of local applications, this latter set of programs are developed under the false assumption that the point where cloud apps are as fast and smooth as local apps has come, but this is factually untrue.

How it should be

Any service most be constructed around today’s circumstances, or the circumstances of the near future. Instead of apps designed like Calligra, which adds such a marginal cloud integration to render it practically non-existent, we should be developing local applications that interact with the cloud itself. Instead of Google Drive we should be using something like Calligra but connected (if available) to a real time sync service, so all changes done in the cloud are reflected in real or quasi real time on everyone’s computer. We should be able to add colleagues to the project straight from the app, we should be able to work with local data while everything syncs in the background.

Say you’re working with a 25 MB image, you should be able to work with it without interrupting your current workflow, you work with it locally, while the image quietly syncs with the cloud, once it starts syncing other users should see a place holder where the image is going to be (while it uploads and while it downloads to other’s computers), so it keep editing as close to real time as humanly possible.

At the same time, the chatting service should be integrated into the application itself, you shouldn’t need to use a common chatting service, you should merely need to use the same editing application (and, even this, can be avoided, if we put in place a set of APIs).

Where’s KDE at?

It is mostly in the past, with too slight to matter touches of cloudiness.  There’s little to worry though, as it seems all other operating systems are stuck in the same scenario. But, then again, this is Linux’s and KDE’s opportunity to take the lead, instead of just catching up, current Desktop Environments need to adapt to the current state of affairs as well as its immediate future. As a community, we shouldn’t let our highly powerful and developed Desktop Environment and applications left behind again, as they are regarding touch-input, that said, so was everybody when the iPad and the iPhone arrived, Google has caught up, Microsoft is about to caught up, we’re trying to move faster. This our chance to make the rest play catching up, and we’ve done it before (as I argue for when I introduced package managers), it isn’t a fantasy, is there waiting to be done.

[sharedaddy]

7 thoughts on “Cloud Computing: How today’s approach is wrong (Editorial)

  1. I read the opening paragraph and have to disagree. Your future may be in the could, but mine is certainly not. Anyone who understands networks and the technologies behind them would not be so foolish as to store their data on “the cloud”. Here is a recent occurrence to which shows this: http://www.theregister.co.uk/2012/05/09/atlassian_cloud_storage_outage/

    Disregarding outages, how would those without access to the Internet find could based software useful? They wouldn’t. So perhaps rather than turning a decent application into something that is only useful to always connected individuals, rather make another cloud version – much like Google does with their apps.

    It’s techno evangelists, like you, living in a bubble, that are the cause of lots of rubbish and waste. Ignorant users hear of your dream in the clouds and because they do not understand the underlying technology, and duped by your promises of computopia. My future is not in the could. It’s in reality. The very real situation that we have is, cables are cut, power goes out, bombs are dropped, and I should stop there because I think I made my point.

    I think WebDAV (or whichever is the winner amongst the variants) should be developed to the point where it is possible to use regular old software to do as you described. So creating a document would be a matter of saving it to a server that your colleges have access to. Then you could use the DAV servers versioning capabilities to handle merges. This is more of a true online/offline solution. You don’t have to be connected to the cloud, but you can if you want to. And there is nothing application specific. Any application that “speaks” DAV can make use of “the cloud” or as we use to call it “server”.

    • You didn’t make any point, unless technical points and analysis regarding the future are based on ideologies and paranoia. The world is heading to the cloud, the empirical evidence is overwhelming, of course, ideologist aren’t not going to change their mind because of empirical data.

      • Ad hominem arguments don’t help your case: http://dictionary.reference.com/browse/paranoia

        I can give you many cases of data loss caused by 3rd party cloud services where the service providers cannot be held responsible. In my line of business we take data security seriously.

        By ideologies, are you referring to standards such as DAV?

        I think there is a problem with the term “cloud”. For me and those who design “cloud services” it’s virtual servers, which for many intents are purposes are quite handy, because you can essentially discard them and create them at will.

        Contrast that to the vision that “cloud evangelists” give: A user’s data *only* in the cloud, accessible from everywhere. I feel sorry for that user, as s/he probably doesn’t understand what they were sold. There are other ways to achieve the same thing, as I outlined in my comment, but there would not be as much profit.

        • The article is outlining how the future is going to be, and how the present should be given the current state of technology, what you’re presenting is ideology because it’s about how you want it to be instead of where is heading.

          Again, the empirical data is against you, the world isn’t heading where you wish, for better or worse. The fact is cloud services are the trend.

          • You are only considering a certain set of data. Consider the corporate world. We build and run our own networks, and don’t trust 3rd parties with our data.

            In the public sector perhaps all users will eventually give up control of all their data. So you do have a point there. I see it all around me too. However, it doesn’t mean that we should build software that gives up control of data to a 3rd party. Why? Because you’ll exclude many corporate users from your user base – users who have money to sponsor open source projects, might I add. This is one of the reasons why corporations sponsor open source projects – because they don’t want to use a competitor’s product. My only point is, when building networked applications, if you leave the user firmly in control of their data, your software will more flexible and palatable to corporations and business users. Of course if your target is *only* the unwashed masses, by all means, put the data in the cloud. It’s probably safer there anyway considering most people don’t even know how a harddisk works.

  2. Oh goodness me! How did I ever get on with my daily life before this shiny new cloud came along? Please oh please faceless  profit driven corporations with questionable-character employees and grotesquely one-side, digital and personal rights restricting Terms Of Service, I can’t trust myself any longer; here, take all my data, come save me from this hell on Earth! 🙂

    If this is the view of NetRunner, guess I won’t be installing this any time soon! Ie, never. 🙂 But hopefully you guys make some good non cloudy KDE software I can play with some day! Haha.

    Cloud Computing. Lol!

  3. While the cloud has it’s place, it is not a panacea. Do you really think that law offices (the major user of word processors) will start putting their legal documents out on public servers?  What about the medical profession?  Will HIPPA even allow that?  Then there are research and design departments of numerous industries.  Will they trust their plans and trade secrets on the cloud?

    There are definate advantages to cloud computing — in the right circumstances, but companies that rely on restricting access as part of their security model, cloud computing comes with great risks.

    A more secure approach would be to store documents in an open format and allow secured access to them.  As long as the format is open, then one could use any number of local applications to work on them.

Leave a Reply