Apparently today was Document Freedom Day. Next year we shall have to actually celebrate it.

At work, one of the company's key objectives is to promote open standards like ODF. We are lucky to have an developer in-house (a rare commodity, especially outside of Sun or Novell), and I've had the opportunity to work on supporting from time to time. The biggest difficulty is the sheer size - the built source tree needs 15GB, so it's pretty difficult to search through, for instance.

Then there's the long compile times; if you're writing a patch for OO.o, it is important to get your debug cycle as short as possible. If you can limit the patch to just one module, then that can be rebuilt individually... and then you can symlink the relevant libraries from your installed copy to point directly into your build tree. If it sounds ugly, that's because it is - but you can get the compile/testing phase down to a minute or so.

My most memorable encounter with OO.o so far has been tracking down an issue with hidden text - it turns out OO.o 2.x writes the opposite value to the ODF standard for the hidden text property. A conversion routine had been put into OO.o 3.0 to import documents written by 2.x correctly, but passing documents from 3.x (or AbiWord, or KOffice) users to OO.o 2.x users is prone to trouble. Last I checked, we were trying to persuade Sun that a 2.4.3 release would be a good idea.