May 13

The Cloud is the App is the Cloud.

During the last week, I have had an incredible number of conversations about Office 365 with press, customers, and peers. It’s apparent that with version 3.0 of their hosted services, as Microsoft has done many times before at v3.0, this is the one that could put some points on the board, if not take a lead in the game.

But one thing has been painfully clear to me for quite some time, and the last week only serves to reinforce it. As I’ve mentioned before, there’s not only confusion about Microsoft’s on-premises and hosted offerings, but simply confusion about what Office 365 is. The definitions are squishy, and Microsoft isn’t doing a great job of really enunciating what Office 365 brings to the table. Many assume that Office 365 is primarily about the Office client applications (when in fact only the premium business editions of Office 365 even include the desktop suite! Many others assume that Office 365 is only hosted services, and Web-based applications, along the lines of Google Apps for Business.

The truth is, there’s a medley of Office 365 editions among the 4 Office 365 “families” (Small Business, Midsize Business, Enterprise/Academic/Government, and Home Premium). But one thing is true – Office 365 is about hosted services (Exchange Online/Lync Online/SharePoint Online for businesses, or Outlook.com/Skype/SkyDrive for consumers), and – predominantly – the Office desktop application suite.

I bring this up because many people point at native applications and Web applications and say that there is a chasm growing… an unending rift that threatens to tear apart the ecosystem. I disagree. I think it is quite the opposite. Web apps (“cloud apps” if you like) and native apps (“apps”) are colliding at high speed. Even today it isn’t really that easy to tell them apart, and it’s only going to get harder.

When Adobe announced their Cloud Connect service last week, some people said there wasn’t much “cloud” about it. In general, I agree. To that same end, one can point a finger at Office 365 and say, “that’s not cloud either” because to deliver the most full-featured experience, it relies upon a so-called “fat client” locally installed on each endpoint, even though for a business, a huge amount of the value, and a large amount of the cost, is coming from the cloud services that those apps connect to.

To me, this is much ado about nothing. While it’s true that one can’t call Office 365 (or Cloud Connect) a 100% cloud solution, at least in the case of Office, each version of Microsoft’s hosted services has come closer than the one before to delivering much of the value of a cloud service, it continues to rely on these local bits, rather than running the entire application through a Web browser. With Office, this is quite intended. The day Office runs equally well on the Web as it does on Windows is the day that Microsoft announces they’re shutting down the Windows division.

But what’s interesting is that as we discuss/debate whether Microsoft and Adobe’s offerings are indeed “cloudy enough”, as they strive to provide more thick apps as a service, Google is working on the opposite, applications that run in the browser, but exploit more local resources. When we look at the high-speed collision of Android into ChromeOS, as well as Microsoft’s convergence of Web development into the WinRT application framework, this all begins to – as a goal – make sense.

In 1995, as the Web was dawning, it wasn’t about applications. It was about sites. It gradually became about applications and APIs – about getting things done, with the Web, not our new local networks, as the sole communication medium. Conversely, even the iPhone began with a very finite suite of actions that a user could perform. One screen of apps that Apple provided, and extensibility only by pinning Websites to the Home screen. Nothing that actually exploited the native power and functionality of the phone to help users complete tasks more readily. Apple eventually provided the full SDK that enabled native, local applications, which would still often connect out to the Internet to perform their role – when the Internet was available.

Windows has largely always been about “fat client” applications, even going so far as to have the now quite old – but once new and novel – Remote Desktop Protocol to enable fat clients to become light-ish weight, as long as a network connection back to the server (or eventually desktop) running the application was available.

I bring these examples up because the idea  of “cloud applications” or cloud services is, as I noted, becoming squishy and hard to explicitly define, though I have to personally consider whether I really care that deeply about when applications are or are not cloudy (or are partly cloudy?).

Users buy (or use) applications because they have a specific task they need to complete. Users don’t care what framework the application is written in, what languages were used, what operating system any back-end of the application is running on, or what Web server it is connecting to.

What users do care about is getting the task done that led them to that application to begin with. Importantly, they need productivity wherever it can be available. With applications that are cloud-only, when you have a slow, or nonexistent Internet connection, you are… dead. You have no productivity. Flying on a plane but editing a Word document? You need a fat client. Whether it’s Google Apps for Business running on a Chromebook (with caching), QuickOffice on an iPad, or Office 2013 Pro Plus running on a Windows 7 laptop, without some local logic and file caching, you’re SOL at 39,000 feet without an Internet connection.

Conversely, if you are solely using Microsoft Office (or Pages), and you’re editing that important doc at an airport that happens to have WiFi before a flight that does not have WiFi, you might be SOL if you don’t sync the document to the Web if you accidentally leave your laptop on board the flight afterwards, never to be seen again. Once upon a time, productivity meant storing files locally only, or hand-pushing files to the Web. Both Office 2013 and Apple’s iWork (through iCloud) offer great synchronization.

The point is that there is value to having a thicker client:

  • Can take advantage of local hardware, data, and services.
  • Can perform some level of role offline.

But there is value to taking advantage of the Web:

  • Saved state from application can be recovered from any other device with the application and correct credentials.
  • Can hook into other services and APIs available over the Web, pull in additional data sources, and collaborate with additional users inside or outside the organization.

But I believe that the merit of both mean that the future is in applications that are both local and cloudy – across the board. Many people are bullish that Chromebooks are the future. Many people think Chromebooks are bull. I think the truth is somewhere in the middle. As desktop productivity evolves, it will have deeper and deeper tentacles out to the Web – for storage and backup, for extensibility, and more. Conversely, as purely Web-based productivity evolves, expect the opposite. It will continue to have greater local storage and more ability to exploit local device capabilities, as we’re seeing Chrome and ChromeOS do.

Office 365 isn’t a cloud-only service in most tiers. Nor do I ever really expect it to be. Frankly, though, Google Apps isn’t really a cloud-only service today – and I don’t expect it to go any direction except towards a more offline capable story as well. Web apps and native apps aren’t a binary switch. We won’t have one or the other in the future. Before too long, most Web apps will have a local component, and most local applications will have a Web component. The best part is that when we reach this point, “cloud” will mean even less than it means today.




Dec 10

Android and Chrome OS – Really a two horse race?

This Tuesday, Google revealed more about Chrome OS, though it remains likely at least 6 months away from anything available commercially. For now, it’s prototype and beta testing time.

One of the most common questions I’ve heard about Chrome OS is, “Why? Google already has an OS. It’s Android.”

Recall Google’s mission statement:

To organize the world’s information and make it universally accessible and useful.

Noble goal, and seemingly altruistic. But at the end of the day, Google makes revenue not from web searches, but through advertising displayed on the results of those searches. In short, every moment of face time you give Google or one of their web properties is an opportunity for ad revenue for them. In addition to being smart about search results, Google is smart in that ads are only served to you if they stand some chance of being relevant (cynically, one could say, “some chance of monetization” instead).

The more time you spend online, ideally having something to do with Google’s properties, the happier Google is (because they have a better chance of monetizing you). People expected that Google would have a hissyfit because telcos are bastardizing Android instead of shipping it in the “pure” form offered by Google in the form(s) of the Nexus One and Nexus S. Google hasn’t. Why would they? Unlike Apple and Microsoft, their imperative isn’t the purity of the platform. It’s that more users are online, and more often than not, by being connected directly to Google’s services. Apple will only sell you their mobile OS if you buy their device, Microsoft requires manufacturers to pay royalties for Windows Phone 7, as they did with Windows Mobile. Google? Android is completely free for manufacturers to use. Because that’s not where Google sees, or gets, value in the transaction.

Think for a second – effectively every product Google makes is dedicated to getting you, or keeping you, on the Internet. The Chrome browser isn’t setting speed records because Google cares about you in a deep, meaningful way. It’s to make the time you use on the web, and on your computer, so painless and effortless that it becomes the way you always do things. Google’s true mission statement could to some degree actually be reduced down to:

To become your conduit and guide to everything, via the Internet.

Though both based upon a Linux kernel, Android and Chrome OS are totally different. Android uses packaged binaries and some web applications. Android is a great mobile platform, and I think it will wind up adapting well to be a strong tablet competitor to the iPad, and continue to pull ahead of the iPhone in net sales, if Google’s partners realize that that is what their competition is. Google doesn’t care. It’s not about devices in hands. It’s about traffic coming from those devices. It’s about more people using their Android or iPhone on the road. Android is mobile devices, today. It’s the here and now, optimized for mobile devices.

Early in 2009, Google first mentioned Chrome OS – immediate confusion set in. Why? What is this? What about Android? How can you beat Microsoft at the desktop game? Cynics abound when it comes to Chrome OS – and frankly I’m still on the fence – Google has a lot of really gory technical work, and some huge barriers of entry. But Chrome OS isn’t about now, about displacing Windows immediately. Chrome OS is tomorrow, it’s tabula rasa. It’s about 3 years. It’s about 5 years.

Chrome OS takes the huge bet that everything you need to do can be done in the web browser – and for a lot of consumers and some knowledge workers, that’s true today, even if you have to include Flash to do it. Don’t believe me? Watch this (rather pedantic) Google video “introducing” Chrome OS. It’s about appealing to the cadres of consumers who use Windows to connect to the Internet, search the Web, send email, print documents and pictures, and get directions to the new restaurant. It’s about doing the same thing to the home computer that Apple and Google have done to the phone – turning it into an always-on appliance that just so happens to really, really want you to spend all of your time in Google’s browser, connecting to their services. Odds are, if you’re reading this post, you’re potentially not a logical customer for Chrome OS, unless you’re already “all-in” Google’s cloud (or other Internet-only services) with little or no dependency on local software. Geeks everywhere note that Chrome OS won’t be able to play their legacy games or run Photoshop. That is true – but it’s also a red herring. Not every consumer runs hardcore games (if they did, everything Dell sells would look like a gaming rig) and not every consumer edits (let alone digitally stores) their own photos. Note that if you think Chrome OS is insane in it’s approach, you should consider the RIM PlayBook and it’s AIR-based UX insane too – it’s got the same long race to run in order to win (realistically the iPhone and iPad did too – they started with no apps or extensibility at all).

Success with Chrome OS to Google looks like more and more consumers having an always-on connection, straight to Google, and enterprises where Google gets revenue by providing cloud services that also keep users always on the Internet, always in a browser. Some have even theorized that Google might subsidize Chrome OS systems (especially to consumers) in order to build a market. It might be an interesting loss leader, but it would be a huge gamble – but they’ve done that before. Google also has considerable work left before next year to add device support, so consumers can plug in some level of peripheral devices (cameras, etc) and use them in concert with the device. Like many pundits, I believe this is one of the largest challenges that Google will face with Chrome OS, and it’s significant.

So is it a two horse race? Sure it is! Because Google doesn’t care which horse wins. They’re not even in that race, but they’ve bet on almost every horse in it – they get revenue regardless, unless someone can beat them at search. It’s the same reason why Google has free food and snacks all over campus, and almost any employee at an Apple store can serve as your cashier – anything that keeps you from breaking out of the thread you’re in keeps you on that thread driving it to completion, and in Google’s case, usually drives regular monetization.

Take a look at the timeline below, including some gratuitous guesses (in gray) I’ve taken as to when I see future major versions of Chrome OS and Android shipping (I see minor updates in between the major versions of each released in 2011 and 2012, of course):

Many have said that the iPad killed the netbook, and there’s no market left for Chrome OS – they can’t – they don’t even know the price yet. If Google delivers a device under $250, it’s in a totally different market than the iPad, with reliability and affordability that Google on Tuesday seemed to say Windows netbooks can’t deliver, and with better usability and extensibility than I believe Linux netbooks can deliver. Chrome OS is in it’s own market – and unless Apple retains and drops the price of the current iPad, they’ll continue to be in different markets. The Chrome Web Store delivers “apps” that will work in Chrome – whether it’s in Chrome OS or Chrome on a Windows or Mac system. Over time, expect a growing number of “applications” (rich web pages in HTML 5 or Flash) that work in Chrome. I would be surprised if Google does not deliver apps for Chrome on Android with “Honeycomb” (3.0) anticipated in early 2011 (rumored to be more Tablet-friendly than Android to date). With that, convergence of some sorts begins.

In time, Chrome OS will have to extend some local functionality – but nobody, including Google, knows how much. In the meantime, it’s a starting point, while Android can provide for a different market, and will likely grow more and more “Web app” friendly. I don’t see 1:1 parity (with one “horse” going away) anytime soon, or perhaps ever, but if “application” (web app) developers step up to the plate and build applications for Chrome OS and then Android, it makes both platforms stronger. Android is such an immense platform that, if Google does tablet-optimize it and create a Web app store as well, they create a great network effect that will pull app vendors into extending Chrome OS as well.