Apple + Google = .Mac^2?

Update: Melo covered the XMPP/IM/VoIP angle of this in a short but sweet post. I expect other Planet Tao denizens will also take this up during the next couple of days.

Via pfig, I read the comments on this post at Om's and mulled Anvarzhon Zhurajev's comment on whether Eric Schmidt's joining the Apple board would have any impact in .Mac.

Beefier pundits (completely accidental pun sort of intended) can focus on the media aspects of the deal, and whether or not the ITMS will get a shot in its (already Hulk-like) arm.

Me, I'll sit here for a while in my little corner of the planet, take up the .Mac bit, and try to reason it out (as far as possible, given my relative state of tiredness). It's a welcome break from the other stuff I've been doing at work, and in a completely different marketplace.

Google's 500-Pound Baby Steps

Well, here's the thing - yes, Google is probably the best placed company to provide any sort of hosted service, provided (and this is a big one) that service can be adapted to run on their environment. There have been various noises about their turning their platform into a turnkey solution, but I'll rate them as fantasy until there's an actual press release.

They've already started offering Gmail for company domains, and I have a vague recollection of their Calendar bundle being hyped hysterically by the Google/Office crowd earlier in the week.

Being of a more realistic (some would say cynical) nature and having other concerns, I let it pass, but it could be Google's first step in progressively (and sustainably) tailoring their free offerings to cater for vertical markets.

And what better market (besides advertising, of course) could there be for that sort of thing (considering only their current - and rather patchy - web services offering) than providing branded versions of their services to companies? Maybe even to ISPs?

It wouldn't have been the first time such a thing happened - and last time I checked, there were enough attempts from other companies for analysts to start churning out SWOT charts and the usual (completely useless) linear-growth bar charts for the "hosted web services" market or some suchlike drivel.

.Mac's Bits and Bolts

Anyway, getting back to the point: if you dismember .Mac into its component parts, you get:

  • A user directory
  • A mail service (which is pretty cheap to set up on its own, but Google could absorb .Mac's with no effort other than providing IMAP)
  • A set of content publishing services (which are used by iWeb, iPhoto, etc.)
  • WebDAV storage (which can be mixed in with the above)

I don't think there would be any big technical issues in Google subsuming .Mac, since pretty much all of it is WebObjects - which, according to conspiracy theorists who haven't yet tacked this one to Google's cozying up to Apple, is actually going to be released as Open Source.

Of course, this doesn't mean WebObjects is runnable atop Google services, but the HTTP and XML semantics used by the client applications are, for sure (even if the corresponding web services have to be re-implemented from scratch).

So, yes, there could be a "dot MacGoogle", and it could have a virtual server farm all of its own inside Google's environment.

With a "Moof-Moof" here, a "Moof-Moof" there... Ah, nevermind.

Giving Away The .Mac Jewels?

But does Apple want to do that? Ah, well. Let's speculate for a moment, yes?

I guess it will all boil down to numbers. I don't think Apple sees .Mac as a core service - either technically or financially. Mind you, it is definitely a core part of their market proposition (which emphasizes .Mac as a sort of "enabler" for simplifying your life), and, as anyone who has been exposed to multi-national corporates will tell you, something Marketing departments will go to war for (and take no prisoners).

But any CFO would at least have someone work out the math. And Peter Oppenheimer comes through as the sort of guy who knows what he's doing, so unless .Mac is really, really cheap to run, I'm betting there will be a periodical review on how it's doing and what sort of ARPU boost it brings to the company.

Would it break someone's heart to have .Mac run by another company? Maybe.

But it wouldn't be run by another company - it would only be hosted there. Of course, if Google felt up to it (which is tricky given the comparative slowness with which they have moved into providing bundled web services), they could actually make it a bit more than "just another" hosted service.

I think it would be a win-win proposition, both technically/operationally and financially - Apple would get a world-class infra-structure to run .Mac atop of, lower OPEX on it, and Google could learn from the bits in .Mac that work beautifully.

Free as in Google?

Of course, Google has a tradition of doing its own thing for a while. But is it really that different for them if a user is using iPhoto or Picasa, as long as they're viewing ads?

Which takes us to the next step: Would "dot MacGoogle" be free?

Nah. I seriously doubt it, although e-mail and iDisk storage might. Better yet, make that e-mail and basic web pages.

iPhoto and syncing can easily be cast as "non-basic" services that people would pay for (think of Flickr accounts), and I don't see Apple (or Google) wanting the hassle of having every "free" customer uploading gigabytes of stuff to their service (yes, I know about the Gmail hacks for storage - they're dumb, and there's a bunch of reasons for their being construed as improper use of the service).

There's an obvious grey area where it regards third-party apps using .Mac services, too, which would be another reason for storage only being available for paying customers.

But if (and it's a very BIG if, about the size of a googol), it happened, I'm pretty damn sure of two things:

  • It would be way faster than current .Mac (and hopefully more secure where it regards WebDAV)
  • It would look a lot better than the current Gmail and .Mac UIs put together

As always, we'll wait and see.

I hope they hurry, though - my .Mac renewal is coming up in 46 days.

See Also: