Cascade Cycle Calandar

One little peice of code I wrote a while back is a cascade cycle daily ride ICS file that can be used with Outlook 2007, Windows Calandar (in vista) and ICal (untested). Now that we are back into riding season I expect to start getting more use from it. Also since vista and office 2007 are out, maybe some other people might get some use from it too. It attempts to estimate how long the ride will be based on the speed and the estimated legth, but it’s only a guess. Enjoy.

Get together my thoughts on OOXML/ODF

An attempt to respond to the latest thing I’ve read and stake out my feelings on ODF/OOXML.

From what I understand of the market, you have a number of (free) add-on ODF plugins for Microsoft Office. This means that the simple requirement being able to read and write the format will be satisfied to the level of quality of the plugins and the ability of the interoperable aspects of the ODF standard to handle office semantics. I feel that the blogoshpere has made it clear that the only way ODF will be able to handle the body of existing office documents (Bugs and features) at full fidelity is for there to be a large number of extensions that would render ODF something not ODF anymore, especially from the standpoint of other ODF implementations. It might be in the vaguely “right” looking container, but it would not be interoperable. Any movement in this space would (rightly?) be branded Embrace, Extend, Extinguish.

I believe it is clear that users want something like OpenXML. We’ve seen that previous movements in this direction by office in the 2003 products are never used because of the loss of fidelity. I’m just not going to migrate my spreadsheets to ODF format if my formulas are going to break, and that is the type of user complaints that you will start to get when you tell your customers you must move over. If you don’t get how complex this type of thing gets, you should start reading Raymond Chen’s blog. It is quite obvious how hostile the ODF crowd appears to be to backwards comparability with the amount of hoopla generated around supporting the 1900 excel/lotus 123 date issues in OOXML.

Could all the the technical issues been worked out in ODF? Maybe. I think the hostile environment, the time required to work on modifications to ODF in an open way and the timeline for the politics and government mandates pretty much precluded that option for the short term. On the brightside, ODF folks can take the out there and free OOXML spec and decide how they want to absorb it for future versions of ODF. Thus somday the promised nirvana of ODF being the native interoperable format of all office suites that it’s supporters want might be realized. In the here and now, there is a pretty cool creative energy that both formats competing right now has created. In an attempt to score points in some insane “Who is Right” contest both sides are pointing out the flaws in the other, and the pragmatists will pick up the real stuff and just make thier stuff better. This is a good thing no matter how ugly the process is to get there.

In the background of this debate, It appears that their are two camps in the world when it comes to this stuff, purists who believe that future technology should be clean slates not marred with the real world and those who muck around in the complex world of user demand and prior work. I have to admit out of college I was very much in favor of the purist view of the world. This little debate is making me realize that I’ve now firmly landed in the other camp. The purist typically ends in the worst hacks and/or low adoption. There are a lot of people out there who use software and just don’t care about the religious battles. It doesn’t matter what your standard is or how you architected the code is, if it doesn’t solve the user’s needs.  Put simply, users are more important then you or I and placing requirements down that are tangential to their needs is just a speedbump for them to roll over. The coders who love and support these users are going to have to help carry forward whatever hack someone came up with to get around the artificial speedbump. The sooner one grok’s this concept the better the world might be.

If ODF solves a user’s needs, they will use it, if OOXML solves it better it will be used regardless of which of them have ISO certification. There is already ECMA certification and good IP promises for OOXML. (The inability to use without IP considerations a file embded in either format is a red herring). It appears that Microsoft is supportive of having OOXML ISO certified, which sounds great to me. If there are considerations unrelated to ODF then they should be fixed, but the notion of which sausage factory produced the 1.0 spec or that you can’t have both formats be standards seems silly to me. Both are too new on the scene to have proven that they are going to be the end all. If anything, office via market share and caring about backwards compatability has a huge leg up.

Disclaimer: I work for Microsoft but nothing to do with office.