Thursday, December 07, 2006

How ODF can beat out Microsoft Office Formats

As a business member of the ODF Alliance and a proud supporter of the concepts behind Open Document Format. I currently use OpenOffice.org for all of my business related documents, and find it to be much more helpful than Microsoft Office most of the time.

Unfortunately, I see an area that the ODF could easily dominate that I think Microsoft Office fails at currently:

File Format APIs

Could you imagine a File Format API that would allow you to quickly and easily create documents from the command line, or via PHP scripts? Possibly creating a template in your favorite ODF creator then manipulating the file later via the API.

Then, just to make things even more fun, a tool to render the ODF file and print it to a printer or to a postscript file, which would also make it infinitely easier to create a PDF from the command line.

It is not hard to manipulate XML if you know what you are doing, but that should make an API even easier to create. How many developers want to learn the schema for ODF so they can write conversion scripts and dynamically generate ODF files on the fly? (note that I am not raising my hand here)

Now, how many developers would love to write conversion scripts and dynamically generate/manipulate ODF files on the fly without needing to know how ODF works? (I am frantically waving both arms in the air at this point.)

Here's another question: How many developers would love to use their command-line linux server to generate PDF files out of ODF files and move 90% of their paper forms to an intranet application, without needing to know how ODF works, and without having to install some sort of X server or X forwarding application? (I am now waving money in the air... but only for donating to the project or spending on support, because I'm a frugal individual that wants this technology available to everyone.)

If we started treating ODF like a real file format and not just another XML file, maybe more people would see the value in using it. I'm sure moving all of our canned reports and forms to an intranet that makes use of ODF would be a big hit, and could make it much easier to switch to StarOffice or OpenOffice.org, and most of the work has already been done for projects like OpenOffice.org.

The -headless command isn't enough if I still need to run X just to install OpenOffice.org. Once we take back the command line and create PHP, ASP, Ruby, etc extensions/plugins/objects/classes/methods/functions/whatevers that can manage, manipulate, convert, and fully utilize the Open Document Format, the quicker we can move away from a forced-vendor solution.

I would also assume the first company to do this could easily be a singe-vendor-by-choice (SVBC) for many companies.

Common SVBC's might be distributors, such as CDW who sell various hardware and offer support for just about all of it. I can still switch companies anytime I want, I'm not locked into CDW, but because of their service, I'm willing to choose them over other companies when making my IT purchases. (I am not paid by CDW, but if you work for CDW and you'd like to slide a little cash my way, feel free!)

The point is, I am choosing a single-vendor because of the security, reliability, and comfort of having one company that knows everything about my IT purchases.

If CDW all of a sudden said their products and services required that I only use them, I would drop them in a heartbeat.

The only thing worse than having more than one IT vendor is being forced to use only one IT vendor. That's the whole point of ODF from my perspective.

Let's take back the office document battlefield, and let's do it by providing options and solutions that Microsoft wouldn't dream of competing with for free.

Keep in mind that an easy-to-use API would make developing your own office software infinitely easier, so we would see tons of open document office suites pop up all over the place, making it much more difficult to sell office software, but much easier to sell tools and services that work efficiently and effectively with ODF files.