Great post yesterday about ODF and distributed team-working by Stephen.
Taking advantage of the time zone differential between Denver and London, James processed the document in the morning his time, and when I opened my laptop first thing this morning I was delighted to see a reply from him with a revised and updated attachment (I would have used Writely, but I wrote most of it on planes over the weekend). Because RedMonk’s a cross-platform shop (I’m on Linux, Cote’s on OS X, and James is on Windows XP), the Open Document Format makes the most sense for us – for offline pubs, anyway. This deliverable was no exception, and the version I’d created was ODF and that’s what he returned to me.
Unfortunately, his version of Star Office / Open Office somehow corrupted the file on save. The edited version that he sent me this morning would not open, returning me the message pictured. When I first pinged him, I was holding out hope that it was simply a transmission error in email, or some other error on my side, but he quickly reported back that his version of the file was no more readable than mine.
Stephen quickly found the fix for corrupted OpenOffice files, which was goodness.
Obviously we wouldn’t recommend that most smaller companies pursue a multiplatform strategy by design. A de jure interoperability first approach makes a great deal of sense for us though because we’re an analyst firm covering multiple platforms.
Cote is thinking through some related issues, concerning time zone and event scheduling.
A constant problem for us at RedMonk is scheduling meetings. We each have different OS’s, but more importantly, 99% of our scheduling is with people outside of our organization. so you can imagine that the Exchange/Outlook approach doesn’t work too well.
Now, you can imagine that we could put a calendar on a web page that showed when we were free and busy: it might even say what we were doing at the time, contain links to relevant things (like follow-up blog posts)…you know, the Web 2.0 calendaring wet dream ;> Upcoming, eventful, and others are good initial cuts at a UI for a calendar (the next steps are integrating with more applications and services, like Exchange and iCal, or dodgeball.).
What gets tricky is if some application — say Outlook — wants to use that calendar web page to help someone schedule time with RedMonk. Good luck with that. At best you’d have to screen-scrape and someone hook up with Outlook
RedMonk: We’re loosely-coupled. With ODF we can maintain content across multiple platforms across multiple time zones, without worrying if the specific ODF implementation we’re using at a given time crashes. Its a good feeling, the confidence gained through multiple implementions of a content spec. Here is