Friday, April 14, 2006

Google Calendar: why did it take so long?

It could not have been technical issues that had this project delayed for so long... How long exactly, I'm not even sure. Year and a half ago, when I actively interviewed for a new job, I had a contact with Google's GMail hiring person and in that conversation I was trying to sell my experience in building an online calendaring application (can be checked out by anybody willing to, web registration was always free), and (although not immediately visible) providing APIs for mobile calendaring client. Nothing extremely fancy or unusual, but a working, scaleable web app with proper backend and covering over 90% of types of recurring (or reoccurring, for those who like this spelling more) events as compared to MS Outlook. At that time, I suggested that GMail needs a tight integration with Calendaring application (since your contacts are already there), and also needs to integrate with freshly acquired Google Earth to have addresses mapped easiliy. Now, it would be silly to think that this suggestion was a revelation and that it affected Google's PIM (for Personal Information Manager) product roadmap... These ideas are pretty much laying on the surface.

Anyway, recognition of addresses in emails was implemented much sooner than Calendaring application, even though work on Calendaring application was already ongoing at the time my phone screen interview has occured (which I did not pass, by the way, failing question on algorythms; Google's hiring process is sometimes as rigid and as random as the one I'm participating in at my current place: good people get turned down frequently). At Xpherix, we had Calendaring app working (and integrated with synchronization software) in around 6 months. What took Big G 2 years? I'd guess, the so-called "due diligence" big corporations have to pay respect to. See, the PIM territory is a minefield of patents. All underlying technologies involving data storage, transmission, representation, and synchronization are claimed as somebody's IP. If RIM's troubles seem not directly linked, recent motion by Visto to sue an estabilished data synchronization company are much closer to home. And all this aqcuisition activity: Intellisync, etc.

Problem is, there are only so many ways to solve those kinds of issues (not counting stupid ways, which BTW live in products by big names; say, Sun's calendaring sever, AFAIK, stores regular instances of recurring calendar events as separate records, which forces them to cap the "event horizon" at few tens of yesrs from start date. Ours was smarter: one record for all recurring events, plus two records for each exception, coupled with a scary-ugly SQL to do initial filtering. That was good stuff actually. Should we have patented this? :) ). I should stop here to not to launch into the usual software patents debate. No point, it's all business as usual. But if it took Big G, speculatively, one full extra year to clarify issues, what chance does a smaller company have? There's just one chance: do it and hope your company is small enough to slide under a radar of litigious types, yet just big enough to make a living off of your products. Afraid this means only one-person-strong companies can live in this world. IP carriers, huh?

Update: Big G has taken the same "stupid" route I mentioned above. For recurring events, they put a cap on number of occurrences. To see for yourself, create an event that repeats every weekday and set no end date. Then, navigate into the future: sometime in 2008 your event will no longer register... I don't believe they're just stupid, it must be that a more elegant approach is barred by a patent. I wonder who holds it... Hmm, could be some company that participated in IETF's iCal standard development and so put a stake over there as well? You guessed it right: Microsoft (United States Patent 7016909, and may be others). Still too big for Google to take on, yet.

According to http://googleblog.blogspot.com/2006/04/its-about-time.html, Google Calendar is compliant with iCalendar standard. Hmm, haven't seen anything there saying recurring calendar event definition with no end date should generate events for under 400 instances. BTW, why so many, exactly? And how many, exactly? Is it simply 365? Is it 21 months worth of data? Wonder, how much it costs to license Microsoft's portfolio of patents on Calendaring and Scheduling. Do they even allow anybody to license it, or do they just keep it between them and IBM?

Another update: just double-checked Yahoo's Calendar. It does not have this problem. Apparently, Yahoo has cross-licensing agreement with other "haves" to use this efficient algorythm. So, why hasn't Google?

1 Comments:

Anonymous Anonymous said...

That's rather sad. We can only hope for patent reform and/or the elimination of software patents before all innovation is crushed.

4/23/2006 5:11 PM  

Post a Comment

<< Home