I’m having trouble getting too worked up about Google’s decision to drop Exchange ActiveSync (EAS) support for non-paying customers of Gmail et al. If this really was an attempt to slow Microsoft’s progress in mobile it was both petty and futile. The bad PR, and the less than optimal experience Google provides its customers, is likely to do more harm to Google than to Microsoft.
Let’s get the most obvious and direct part of this out-of-the-way. Microsoft isn’t going to let Google’s move keep its clients from accessing Google services. All Microsoft clients already support IMAP, so mail isn’t really the problem. Microsoft has never supported CalDAV for calendaring or CardDAV for contacts, but these are open standards that Microsoft can easily support tactically. In other words, if Microsoft cares about Google’s move it would be easy for them to add support for this technology to those products where it feels they make sense. Windows Phone would be a likely case. Microsoft would almost certainly do the minimal job necessary to satisfy consumers while leaving EAS the overwhelming choice for businesses. Not that they really need to do much. The remote management aspects of EAS make it far preferable to anything Google or anyone else besides RIM offers.
From a technical perspective one needs to keep in mind EAS’ origins and target. Unlike all the other protocols in use, only EAS was designed from the beginning as a Mobile email/groupware/management protocol. It was specifically designed to counter RIM, whose advantages in security and push-email were driving it past all other smartphone contenders. Since most of the email systems that RIM was connecting Blackberrys to were Microsoft Exchange Servers the existence of a competitive offering that allowed Smartphones to talk directly to those Exchange Servers was a big deal. While the EAS effort started in the Windows Mobile team it was soon taken over by the Exchange team.
The Exchange team, eager to protect the value of Exchange mailbox licenses, made EAS available to all mobile device manufacturers. Anyone who aspired to sell smartphones to businesses implemented EAS. Windows Mobile did the most extensive EAS implementation (even better than what Windows Phone currently offers), and rode it to (briefly) match RIM’s market share. Palm, at the time a true force in smartphones, added support for its Palm OS (and later WM, obviously) devices. Nokia, then the worldwide leader in Smartphones, supported it. EAS became ubiquitous across all (non-RIM) business oriented devices.
Then came the iPhone and the consumer Smartphone wave. Apple soon adopted EAS so iPhones/iPads could access corporate email systems. Google held off with Android, but its OEMs added the support themselves. Finally Google added EAS support to their mail app. Third-parties added EAS support to RIM’s Blackberry (and RIM is reportedly adding native support in Blackberry 10). EAS support is now nearly universal across client devices, and that has started to impact server protocol decisions.
On the business side Microsoft’s protocol story has been pretty good and consistent over the years. MAPI is the primary protocol for Exchange with EAS for mobile applications. POP3 and IMAP are supported, but most enterprises eschew them due to their poorer security attributes. But on the consumer side Microsoft has always been a mess.
I don’t even recall how the original MSN Mail communicated. Hotmail was web-focused and initially offered POP3 access for those who insisted on using a mail client. Microsoft removed POP3, then added it back for paying customers. They never supported IMAP. Mostly they focused on proprietary protocols between a Microsoft-supplied client (Outlook, Outlook Express, Windows Mail, Windows Live Mail, and a variety of mobile clients) and the Hotmail servers. In the brief period between the advent of the iPhone and Apple’s support for EAS Ray Ozzie was able to convince the Hotmail team to enable POP3 for all users so no matter the device Hotmail would be universally accessible. The story was less clear with Calendar and Contacts support, and it was only in the last few years that clients could even access the Calendar or really integrate Contacts.
With EAS achieving mobile client ubiquity the opportunity for the “Windows Live” products to clean up their act became obvious and EAS became the protocol for mail, calendar, and contacts. The new mobile-focused Windows 8 Mail application uses EAS as its primary protocol. And Outlook 2013 puts the final piece into the puzzle by adding native EAS support. While Exchange continues to offer richer functionality, Microsoft’s consumer groupware offering finally has client support that is on par with its business offering.
Other have sought to exploit EAS client ubiquity, and that includes Google. Sure Google’s support for EAS makes Microsoft’s life easier, but it mostly has been a boon to Google. In theory, by supporting EAS in its groupware products Google makes it easier for a business to replace Microsoft Exchange with limited impact on end-users. And sure enough they plan to retain that attribute for paying customers. Strategically they made a mistake in offering EAS support to non-paying customers!
Any company with business sense, and Google displays little outside the advertising arena, would have made EAS a differentiator between its free and its paid service. Go look at the history of hosted Exchange, for example, and you will see that most companies reserved EAS support for their more expensive packages. EAS was a way to differentiate between a low-price/low-margin entry-level package and the mainstream package they really wanted you to buy. When Google made EAS support part of their free offering they took away a clear incentive for small (including 1 employee) companies to go with their paid offering.
I believe Google’s dropping of EAS support in their free offerings is more about fixing their free/paid differentiation than about an attempt to slow Microsoft’s mobile efforts. The latter is a secondary benefit, but one Google knows is at best a very slight speed bump Microsoft has to go over. The timing is important though. With Microsoft holding such a small share of the mobile client market Google can make this change without enduring the wrath of too many customers. Had they waited for Windows Phone and Windows 8 market share to climb, and thus the expectation of EAS connectivity to Google’s free services to become more entrenched, they couldn’t have made the change.
So what do I expect to happen? Windows Phone will incorporate some means of syncing Google’s calendar and contacts via CalDAV and CardDAV. That may first come by way of apps, but later by way of native support. Windows 8 will ignore Google’s move for the time being since it is unlikely to impact Windows 8 adoption. All mechanisms for using Google services in Windows 7 continue to work for Windows 8. So Microsoft can simply wait for the Windows 8 user base to be large enough that Google can’t resist user demand for either Windows Store (nee Metro nee Modern) apps or reinstatement of EAS for free services. At the same time Microsoft will use Google’s treatment of EAS as a marketing tool for moving customers to outlook.com and its overall campaign of painting Google as not being customer friendly.
The only user base that is a bit in limbo in all of this are Windows RT users. They can, of course, use Google services via the web browser. But with no ability to fall back on Windows 7-compatible solutions, no EAS support, no Google-supplied Windows Store apps, and no native CalDAV/CardDAV support Windows RT will remain a second-class citizen for those committed to Google services. Actually though, maybe this is a great opportunity for third parties. Microsoft’s built-in Modern/Metro Mail etc. apps are very rudimentary to begin with and the lack of Outlook on this platform means there is no serious groupware app. Perhaps the lack of support for Google services will propel a third-party to create an awesome groupware app for Windows RT! Now wouldn’t that be an interesting unintended consequence of Google’s actions?
The bottom line here is that Google’s removal of EAS support from its free offerings present little difficulty for Microsoft. And if Microsoft plays its cards right, this will hurt Google more than it will hurt Microsoft.
