Google Apps Refresh Sets Up Deathmatch With Microsoft

Until now, most customers of Microsoft Office had a variety of good reasons to stick with the status quo, steering clear of Google Apps unless they needed it for a bargaining chip when negotiating with Microsoft. But, between Monday's launch of the new versions of Google Documents and Google Spreadsheets and Google's forthcoming plans for the recently acquired DocVerse, Google Apps should no longer be just a bargaining tool.

With new versions of Microsoft Office and SharePoint Server set for release next month and a potentially expensive upgrade cycle about to begin for many Microsoft customers, the new version of Google Apps has not only changed the rules on what is meant by "document collaboration," it has ameliorated one of the primary sticking points for many Microsoft customers considering a switch: limited interoperability with Office documents.

Make no mistake about it. Google is going for Microsoft's jugular. The deathmatch is on and, at the very least, it's for bragging rights to what we at InformationWeekare calling the "collaborative backbone." It becomes a battle that's less about Google Docs versus Microsoft Office and much more about the collaborative infrastructure behind Google Apps versus Microsoft's SharePoint and Exchange.

Given the ubiquity of Microsoft Office in the business world, switching to Google Apps for working on word processing documents, spreadsheets, and/or slide shows (presentations) has been daunting if not impossible. The problem had to do with what many call "document fidelity." Creating new nicely formatted documents in Google Documents, Spreadsheets, or Presentations wasn't the problem -- but lack of interoperation with existing documents created with Microsoft Office was.

There were major limitations to the way Google Apps worked with an organization's legacy documents or documents coming from outside the organization (partner, customer, etc.) in one of Microsoft's Office formats. Especially if those documents included complicated formatting.

In a before/after video demonstration given to me by Google Documents associate product manager Jeff Harris, it's easy to see how a résumé (a document with relatively complicated fidelity) lost all of its formatting after being imported into the old Google Documents. It's not hard to imagine how such lack of interoperability with de facto standard file formats was a deal breaker for many organizations. As recently as two weeks ago, Microsoft officials were making hay out of the fidelity issue.

You can see where this is going. Not only should power users of Office be able to work with each other, using Google Apps as their collaborative backbone, power users of Office should be able to collaborate much more easily with pure Google Apps users.

But that's probably not where the DocVerse play will end. As my colleague Thomas Claburn has reported, one of the big steps backward that the new Google Docs takes is that, starting on May 3, files can no longer be saved and edited offline through the support of Google's Gears plug-in. (Gmail and Google Calendar will continue to work offline where configured to do so.)

According to Google's Harris, between a variety of justifications, bullets, tab stops, etc., a résumé is a pretty complicated document. In the same video, Harris shows how, when the same résumé is imported into the new Google Documents, its fidelity is perfectly maintained. As vastly improved as Google Documents is, it's unlikely that Google can account and test for all the edge cases. But the good news for organizations is that it's very easy to test Google Apps for compatibility with their documents at any time.

Two other related key issues that Google had to both recognize and deal with were the Office power user and Office's integration with SharePoint.

It's no secret that Google Apps can only do about 20% of what Microsoft Office can do. Google practically brags about this point -- that less is more (which can be very true for users who must wade through all sorts of functionality to get at basics). When Microsoft uses this point as a strike against Google Apps, Google leans into the punch.

But somewhere along the line, Google realized that every organization has its power users: the ones who need some of the functionality found in the other 80%. For Office power users who needed to collaborate (or just save their work out to the collaborative backbone), Google Apps simply wasn't an option. For organizations with power users, moving some users to Google Apps while leaving the power users on Microsoft Office and SharePoint basically meant signing on to the less-than-optimal idea of running two collaborative backbones.

Then, Google took a tiny baby step. In January 2010, the company announced that Google Apps users could upload and store files of any type into their shared Google Apps storage. This was immediately interpreted by many bloggers as a potential threat to the cottage industry for Web-based storage. But that, apparently, wasn't what Google had in mind.

Google must recognize that to win organizations over to Google Apps, it needs to (a) accept that pretty much every company has power users who can't give up Office and (b) that those Office users will need to seamlessly interoperate with Google Apps as their collaborative backbone in the same way they seamlessly interoperate with SharePoint.

Naturally, allowing Google Apps to store files of any type was the first step. The next was acquiring DocVerse in March 2010. Today, using its own cloud as a collaborative backbone, DocVerse adds an element of real-time collaboration to users of Microsoft Office.Multiple users using Office can edit the same document at the same time and see each other's edits as they happen. With Google Apps able to store files of any type and now with DocVerse in its portfolio, it's just a question of time until Google replaces DocVerse's cloud (the collaborative backbone to which DocVerse users currently save their work) with Google Apps' cloud.

This so-called "airplane" problem is one that desktop software makers use for hoisting cloud computing on its own petard and the withdrawal of this feature will undoubtedly become a haymaker for Microsoft. But one of the benefits of running a cloud computing infrastructure with 25 million users like Google does with Google Apps is you get to see what features people are using and, as it turns out, the offline feature wasn't getting used as often as everyone thought it would. At least that's what Google officials say, nervously.

The dilemma for Google is that the very same people to whom the lack of offline access will matter, the CXOs who do a lot of travel, are the same ones whose opinions weigh heavily in major technology decisions -- for example, the decision to move to Google Apps. Officially, Google says it is "working to support an improved offline access option in the future."

According to Google engineering director Alan Warren, "Docs was dependent on Gears for offline access. But it was a sparsely used feature. So support for offline in Docs will go away for a while and users will not be able to autosync [their documents in the cloud with their PCs]. That feature will come back when we get synced up with HTML5's data caching model."

For the latest Desktop Apps news, opinion and conversation, be sure to check out InformationWeek's Special Report: Desktop Apps: Time For Change

But DocVerse will probably have a role, too. One of the other features of DocVerse is how it resyncs shared Office documents with the cloud if an Office user has worked on those documents while offline. Essentially, people who fly around or spend a predictable amount of time off the grid qualify as power users. Like the other power users, they could get a copy of Office to guarantee that no matter where they are, they can get their work done. When asked, Google officials wouldn't say if DocVerse would be free to users of Google Apps.

But history shows that when Google introduces a new interoperability technology into Google Apps (Exchange import tools, Outlook functionality, BlackBerry Enterprise Server interoperability, mobile device management, etc.), it has always been free to users of Google Apps. A Google official agreed that that pattern of adding interoperability tools at no cost isn't likely to change.

In some ways, the acquisition of DocVerse reflects Google's recognition of an important reality: The company must be prepared to support a hybrid model if it wants in with certain customers. Google Enterprise Group product management director Matt Glotzbach told InformationWeek that Google views "the Web as a platform. ... We don't view it as a companion to the desktop." But proving that Google knows it must make allowances for certain types of users, Google Enterprise Group president Dave Girouard admitted that "all companies will have Office; they just won't have as much of it. ... Office will become something like Photoshop, something that a few users need. It's not really the right tool for most people."By acknowledging this hybrid world and adjusting its strategy accordingly, Google is also shifting the focus of the deathmatch to the collaborative backbone itself. That's why the battle becomes much more about the collaborative infrastructure behind Google Apps versus Microsoft's SharePoint and Exchange. If Google can demonstrate that end users can have their cake and eat it, too (cloud-based productivity for the majority of users and Office for a handful of power users), without sacrificing collaborative or power-user capabilities -- all at palatable cost -- Google could see a breakthrough in corporate interest in Google Apps.

And while we're on the subject of sacrificing collaborative capabilities, with today's launch, the company is looking to change the rules altogether when it comes to document collaboration.

Google has a different vision of how to get people to collaborate without friction. It starts with using the Internet because that's what everyone, including mobile device users, is connected to. By relying on the Internet, you can collaborate just as easily with someone in your company as you can a customer as you can a family member.

Next comes device agnosticism. Think of how a lawyer might collaborate with a client or another lawyer on a contract. Beyond the Web, that lawyer shouldn't have to know or care what technologies the other people have access to. As collaboration crosses organizational boundaries, the Web browser becomes the most obvious universal client. It's the easiest way for two dissimilar devices to collaborate on the same document and Google is focused on making sure that a browser is all that's needed (no plug-ins either) to access Google Docs, regardless of the devices being used.

But there's one challenge. Even though most browsers (desktop, mobile, etc.) are getting more powerful in terms of their capabilities (faster JavaScript processing, better support for standards, HTML5, etc.), no two browsers are created equal. And here's where Google's engineers have been spending thousands of man-hours building what could amount to an unfair advantage for Google and Google Apps.

Rendering a Word document in full fidelity in browser is, as Google software Micah Lemonik put it, nontrivial. Lemonik knows. For the new release of Google Apps, he single-handedly rewrote the underlying data model for Google Documents (the browser-based word processing app) from the ground up. Whereas before (with Google Documents), the data model and the presentation layer (in the browser) were inextricably linked, now the two are separate. This paved the way for Lemonik to worry about how things like a Microsoft Word document gets stored with all that fidelity while his fellow engineers worry about how to render that fidelity across every major browser on every major device.

To hear Google's Warren describe the difficulties in handling the differences between Firefox, Internet Explorer, Chrome, and Safari (not to mention any of mobile browsers) is to understand the degree to which Google is committed to making the Web work the same for everyone on every device. But for Google, it wasn't just about doing whatever heavy engineering had to be done to get the rendering right.

Google also decided that, with today's high-performance networks and browsers (particularly the JavaScript engines), now was the time to move to a model of real-time collaboration. This is where, regardless of what device you or they are on, the people you're sharing a word processing document with can see where exactly in the document your cursor is (you can see theirs, too) and what you're typing, character by character, second by second.

To give you some idea of what this involves: Google has written Ajax code that essentially autosaves a document every second and then replicates those saves to the browsers of everyone else who is simultaneously working with the document. And not just in one direction. Everything that everyone is typing into the document is being centrally saved and replicated out to everyone else every 1 to 2 seconds. And it does this across the four major desktop browsers (unfortunately, not Opera).

With the old version of Google Docs, this degree of synchronization usually took 10 seconds or more. Describing those 10 seconds the way the telecommunications industry used to describe the proverbial "last mile," Harris and Lemonik say it was the hardest challenge the engineers faced.

According to Lemonik, "The hard problem that we solved was the ability to have the kind of data model that is elastic and flexible and that we could make it extremely generic so that we could have any content type to sort of be represented in this elastic data model. So it was hard enough to get it to work just for one data type. But getting it to work for several different complex data types that had very little relationship with each other -- that was a truly hard problem that's taken us a number of years." Said Harris of the challenge in my interview with him, "That 10 seconds was really hard. The product you're seeing right now is a rewrite from almost the beginning."

Using Safari on a Mac, I used the new Google Documents to write columns from my home office in Northern Massachusetts. And as I tapped on my keyboard, InformationWeek editor Chris Murphy using Firefox on a Mac was only a second or two behind in reading back to me over the telephone what I was typing. Collaboratively speaking, it was like breathing pure oxygen. As I typed in one part of the document, Chris typed in others and we both watched what the other was doing, easily avoiding "stepping" on each other.

Google's real-time technology breaks through not one, but two glass ceilings. The first involves the reconciliation engines that many of today's collaborative solutions use to sync and resolve the differences between the changes that two or more people have made to a document. With collaboration happening in real time, the need for such engines, which are fallible anyway, is completely eliminated.

The second technology Google's invention impacts has to do with screen sharing. Before this version of Google Apps came along, this easiest way to share documents in real time was through screen-sharing technologies like Cisco WebEx and Microsoft NetMeeting. Well, for Office documents, Google just obliterated those, too.

So what does all this mean for you and for Microsoft?

For you, it means that Google Apps is has graduated to a must-evaluate solution, particularly if you're thinking about upgrading your existing Office-SharePoint-Exchange setup. Not only is the game-changing technology compelling enough to sample, the cost is a bargain for what you get. Whereas Google Apps costs $50 per user per year for the entire thing, you have to spend $120 per user per year just for Microsoft's collaborative backbone in the cloud. In addition to that, for users to be able to create and edit documents locally or in the cloud (using that collaborative backbone) will require a licensed copy of Microsoft Office for each user.

For Microsoft? One thing I've learned is, never count Microsoft out. As far as pricing is concerned, Microsoft can (and most likely will) reduce its price whenever it wants to. Also, Microsoft will probably have to relax one of its legal requirements, the one that makes a license to Microsoft Office 2010 a prerequisite for each user that's going to access the read/write versions of its Web apps.

In terms of technology, Microsoft, like Google, has some of the finest software engineers in the world. When Microsoft wants to, it can close pretty much any technological gap. It's just a question of whether that's what it wants to do. And if that is what it wants to do, it had better not wait too long to do it.

For the latest Desktop Apps news, opinion and conversation, be sure to check out InformationWeek's Special Report: Desktop Apps: Time For Change