A Week in the Valley: GData

I spent the week before Where 2.0 visiting companies between San Francisco and San Jose. I've already written about my trips to Ning and Meebo. Next is an account of a meeting with Mark Lucovsky, who was architect of the HailStorm web services product from Microsoft.

I had a great lunch with Chris DiBona and Mark Lukovsky at Google. There's a huge move within Google away from SOAP and even REST-style ad hoc APIs and towards GData instead. The big point for me was that GData is just Atom/RSS for reading, Atom Publishing for writing, and A9 stored queries for searching. They had to specify a bit of glue around sync and so on, but the whole thing is that simple.

The big thing about GData for Google is that it's extremely simple to build into the server-side, so they can offer APIs very easily. This is important as they offer APIs for lots and lots of new stuff. Atom is quietly becoming the standard for reading and writing to Google (RSS for reading as well). They're not saying that in public, but it's happening. Atom is becoming the standard RESTian web services envelope.

They're building APIs to your Google-stored data via GData, and it's all very reminiscent of HailStorm. Mark, of course, was the architect of that. So why's he coming up with more strategies to the same ends? I figure he's hoping Google won't screw it up by being greedy, the way Microsoft did. Microsoft always asks "where's the prioprietary edge?", which is a great strategy for making money but not necessarily the best nurturing technique for open APIs. I did some digging around HailStorm and found these patent applications filed in Europe at the same time as Microsoft was shopping HailStorm as "open". This is a classic proprietary grab: they point and say "look, open APIs!" and then meet with patent lawyers to figure out what bits of the schemas can be patented.

That's the strategy if you want to make money off the use of the APIs and you want to own the services. Google doesn't look at in the same way. I pushed Chris DiBona on Google's take on APIs and he said, "we just want so many developers using straightforward HTTP and XML that it's impossible for someone to introduce anything proprietary that would weaken Google". Google doesn't need the proprietary ownership of the services, they make their money when people use the Internet. The biggest threat to Google isn't that someone else will implement the same Calendar API as Google, it's that someone will make web pages uncrawlable through proprietary extensions to HTML or HTTP. They need web standards so firmly entrenched in common use that nobody can break the Internet from under them, and this pits them against proprietary evilness.

The reaction to the GData APIs for Calendar have been very positive. This is in contrast to HailStorm, of course, which was distrusted and eventually morphed its way through different product names into oblivion. Noting that Mark's trying again with the idea of open APIs to your personal data, I joked that GData should really be "GStorm". Mark deadpanned, "I wanted to call it ShitStorm but it didn't fly with marketing".