As Brad spotted, my previous post strong-armed Google into introducing a new mail migration API. Well, there was correlation even if I’m not so sure on the causation. Looking through Google’s latest offering, it’s clearly aimed at one-way migration from other systems to Google Apps, rather than being a two-way interoperability standard that would allow a mix of Exchange and Gmail use within the same system.
To quote from the announcement, they introduced it because "some customers are reluctant to step into the future without bringing along the email from their past". I’d imagine there’s some customers who are ‘reluctant to step into the future’ if it’s a one-way trip for all their email data too, locking them into Google’s OS going forward. Email, calendars and contacts are crying out for a nice open integration layer. The information you need is comparatively well-defined and bounded, and there’s already supported standards for the components of the problem, like imap, vcard and icalendar.
Microsoft has always had a strategy with strong developer support as a priority. This is great for third-party vendors but arguably was a factor in a lot of their security and usability issues. Google doesn’t feel the same need to look after external developers, as shown by the removal of their search API. They’d much rather simplify the engineering and user-experience by avoiding the clutter of hosting third-party code within their apps.
Even though it’s ugly and COM-tastic, it’s possible with enough effort to dig deep into Exchange’s data stores and build deeply integrated tools. Moving to Google Apps (or most other SAAS apps I’ve seen) you’re losing that level of access. My hunch is that in a few years time we’ll see the same customer pressure that drove MS to open their enterprise tools to customization pushing SAAS companies to either offer APIs or lose business.