» Patrick Durusau: Spotting ODF Supporters Spotting ODF Supporters | Open Document

The linked page has another link to a PDF document.

Mr. Durusau has quite an impressive background, including Project Editor for ODF and "chair of the committee which is responsible for the technical recommendation for the US [National Body]". I have nothing remotely comparable, and want to make that clear.
Durusau says, "Location: Usually seen on ODF committee/subcommittee discussion lists and blogs detailing how to do things with OpenDocument or with the development of the standard." In other words, those who write about reasons to choose ODF and other truly-open and vendor-neutral file formats (and avoid competing "proprietary formats in drag" such as OOXML) do not fall in the group of ODF supporters.

Whatever. There isn't room in OASIS for all of us who support ODF and other truly open, vendor-neutral formats. We are found all over the Internet, as well as in homes, schools, colleges, businesses, and government agencies. Many of us are in the IT department, but many others are merely users who believe that openness and freedom go hand in hand, while proprietarism and monopolism tend to extinguish freedom wherever they find it.

Many of us who support ODF do so because we deal with proprietary formats on a daily basis. Can you imagine supporting an office full of people who are exchanging documents with people from other organizations, sending the files in whatever file format they happen to be using, including MS Word (.doc), MS Excel (.xls), MS PowerPoint (.ppt), WordPerfect (.wpd), Quattro Pro (.qpw), MS Works (.wps), OpenDocument Format (.odt, .ods, .odp) and more, even sometimes including ancient versions of the formats? Sometimes, one can spend hours trying to find an importer of a particular format before having to give up. Sometimes, it is as simple as calling the IT department of the other organization to have them export the file to a readable format, or finding someone in the office who has software on their own computer that can open and export the document. But once that becomes a significant part of your workday, you no longer want to play format games.

I support ODF for many reasons, but one of the most important is the fact that I am the person who gets called upon to help someone open all of these formats. Often, it isn't a matter of different features, since the users really only use a few features (e.g., bold, italics, centering, underline, font, and size). It is a matter of vendors trying to lock users into their own products through the use of "secret sauce" file formats. With ODF-supporting applications, this problem goes away, leaving only the remnants that have to do with how well the format is specified and how well each implementation conforms to the specification.

I support ODF because the relevant IP releases are broad enough that nearly anyone can implement it at any time, and release their implementation under any license they choose, at any price they can realistically get in the market. Twenty years down the road, when the vendors have moved on to the next big thing, I can write tools that translate ODF files to the then-current formats without fear of violating someone's license restrictions.

I support ODF because the format is implemented in multiple products already, with many more on the way. Besides StarOffice, OpenOffice, and IBM Lotus Symphony, there is KOffice, AbiWord, TextMaker, and many more (see the list of ODF-supporting applications I maintain).

I support ODF because there are ODF-supporting applications available on the operating systems I use most, as well as other operating systems that I use less often. There are ODF-supporting applications available for the time it takes to download and install them, as well as some that require a license fee.

I support ODF because ODF is a key piece of the openness and freedom that we seek to bring to our nation and hopefully the rest of the world.

I oppose OOXML (Office Open XML) for many of those same reasons. The admitted purpose of the format is anything but vendor-neutral. As you well know, Mr. Durusau, when you intend to create something that can be used equally well by multiple parties, you do not build in specific ties to a single vendor's implementation. Instead, you use generic abstractions whose implementation can follow the internal structures of any vendor's products. Anything that is specific is fully-specified, so that all vendors can find ways to implement it.

I oppose OOXML because of the "intellectual property" issues that are associated with the format. When SFLC says that Microsoft's OSP is not good enough for FLOSS projects to rely upon, I take that seriously[HTML | PDF]. How will that pledge impact me and my business if a client engages me to provide access to documents in formats covered under this pledge? Remember, vendors regularly leave a line of business, a protocol, a product, or a file format. Many vendors change their file formats every few years. It isn't just big companies like Sun and IBM that have to evaluate its effect on them. It is little five-person shops in cities with less than 250,000 people, dealing with the technical issues for two, three, and even ten or twenty-person shops in their local areas. We cannot afford to be wrong about IP restrictions.

I oppose OOXML because it is fully-implementable by only one company. Other implementations will necessarily be incomplete, and therefore inferior in the eyes of users. Just as I would not like a single-party governmental system, but instead would like to see three, four, or even five viable contenders for any office; I wish to see multiple vendors' products that are serious contenders in the office software space. As a user and potential customer, it is better all-around if there are multiple contenders, because it means that I can find minor differences that make one a better fit to my needs. Best of all, those differences shouldn't be in the file format, so that those that I correspond with are also free to choose the products that best meet their needs.

I oppose OOXML because only the operating systems that MS Office runs on will ever fully support OOXML. This locks out users of NetBSD, Syllable, GNU+Linux, Minix, and more. Somewhere out there, I imagine a guy with his own home-grown OS, "Three-Headed Chicken" (3HC). Because MS Office doesn't run on 3HC, that guy cannot get full use out of OOXML files, while he could write his own ODF implementation (or try to compile OOo or KOffice) to run on 3HC.

Rather than a Babel of standards without a full and accurate conversion, people such as myself wish to deal with one standard, so that the only real issue is in the faithfulness of the implementations to the standard.

OpenDocument supporters support OpenDocument. They are too busy installing OpenDocument based applications, teaching others about OpenDocument and extending and adapting it to real use cases to spend time trash talking about other standards.

Like you, Patrick, I want to see more attention focused on making sure that every use case is better served with the more open format (ODF). I was a staunch supporter of California's AB-1668 last year, which would have mandated open standard file formats and specified in the definition what would be considered an open standard. The bill did not specifically mention ODF, but OOXML still would not be able to meet the standard. The bill was squashed by your new buddies from Seattle because they saw (and continue to see) truly open, vendor-neutral file formats as a direct threat to their monopoly. Because of the anti-openness hit squads that descend upon the halls of government whenever an openness bill or policy is discussed, those of us that are pro-openness (read: true ODF advocates) have to step in and advocate against formats that promote vendor lock-in and proprietary nastiness.

There's more. I am an advocate for openness: free / libre and open source software, open standards, open formats, open protocols, open government, and privacy rights for individuals (enforceable against government agencies and corporations). Likewise, I am an advocate for smaller businesses: the very entities that have the most to gain from switching to a truly-open, vendor-neutral file format.

In a previous paper, you argued that approving OOXML as an ISO standard will give everyone a voice in helping to improve it.

Reject DIS 29500? The cost of rejection is that ordinary users, governments, smaller interests, all lose a seat at the table where the next version of the Office standard is being written.

Approve an admittedly rough DIS 29500? That gives all of us a seat at the table for the next Office standard. Granting that I wince at parts of DIS 29500, it is hard for me to argue with that rationale.

Reading reports of the Ballot Resolution Meeting, in which many proposed improvements were shut off with a we've already implemented it this way, so we aren't changing it, how can you truthfully expect that to change? Given that MS Office 2007's file format is not conformant with ISO OOXML (and may likely never conform), how do you expect ISO approval to change things?

Mr. Durusau, I respect all you've done, but you are actually harming your cause and ours by pretending that ignoring the serpent in the corner makes everything all better. Yes, we need to dramatically step up the pace of improvements, implementations, tutorials, libraries, and the like. We need more in-depth conformance testing, including a seal of approval. We need promotional materials, software distributions, and news of conversions from legacy applications to ODF-supporting applications. We need full-compliance with standards like SVG to become a built-in part of ODF. We need a canonical scripting language runtime for the format, with the ability to support other formats as well. We need ODF support to be built into Eclipse, NetBeans, Squeak, and other development environments, so that developers can hook into ODF with one or two lines or mouse clicks. But we cannot forget that we also need to make it clear to all concerned why ODF is the superior format, instead of OOXML.   No comments | ¶
Warning: include_once(/home/webconne/public_html/blogs/pv/pivot/pv_core.php) [function.include-once]: failed to open stream: No such file or directory in /home/webconne/public_html/blogs/pv/archives/archive_2008-m04.php on line 291

Warning: include_once() [function.include]: Failed opening '/home/webconne/public_html/blogs/pv/pivot/pv_core.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/webconne/public_html/blogs/pv/archives/archive_2008-m04.php on line 291

Fatal error: Call to undefined function get_editentrylink() in /home/webconne/public_html/blogs/pv/archives/archive_2008-m04.php on line 292