Gather Your Thoughts Again
In reply to Get together my thoughts on OOXML/ODF
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 beinteroperable. Any movement in this space would (rightly?) be branded Embrace, Extend, Extinguish.
Read the blog of the ODF-to-OOXML conversion plug-in. Read their list of unsupported features. The MCAN (Microsoft-Clever Age-Novell) plug-in is pretty poor in what it does. Now, Sun’s translator should be as good as the current versions of OpenOffice.org, which is fairly good for less complex documents. And da Vinci, once it comes out, should make things even better.
What you’re missing is that ODF already can represent everything known to be stored in the legacy binary formats, and that it is both evolving and extensible. It would have to be so in order to enable any currently or formerly-used format’s content (including formats of multiple vendors) to be represented. This claim that ODF is the one that isn’t interoperable is a straight-out lie.
The “bugs and features” that you’re talking about are already able to be handled. One does not have to say, “doItLikeWeDidIn1995” when the meaning is “use 1/4 inch of space above footnotes.” If one says what is intended, ODF is fully able to accurately represent it. The blogosphere has made this clear, repeatedly. It seems that you’re not listening.
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.
No, the reason the 2003 XML formats are not used is because people need to be able to exchange documents with one another. Why learn to use an unproven format that many people will not know how to open? Also, no one was really using XML tools in non-Web-related applications, so it was unneeded and unwanted at that time.
On the other hand, ODF, while not perfect, is being asked for by individuals and governments around the world. It offers the best combination of openness (as in being defined and modified in an open process instead of a smoke-filled room as well as having its goals set in a similarly open process), vendor-neutrality (which any sensible buyer wants), and re-usability (unlike OOXML, the legal status is clear: anyone can implement it in any application at any time, for any purpose, under any license, for any operating system and charge any price, without any need for permission or legally-risky reverse-engineering of “secret sauce” legacy binary formats) within or without an organization.
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.
I used to read Raymond Chen’s writing, so I am aware of backwards-compatibility issues. Conversion of formulas within file formats should be mostly handled in the file import & export process. Surely your programmers do not just pickle or serialize memory objects, so they are going to be doing this anyway. The storage format should not be the same thing as the in-memory representation, because, as every student of object-oriented programming knows, this way your internal representation can change without breaking existing uses of your output.
Users are already used to some breakage, as it even happens between versions of Microsoft’s office suite. Why do you think there are whole aisles in the bookstores full of titles like “Using Excel: Now Updated For Version 2003”? This is because the old interface is gone, and some of the features have been modified. These books always have a statement like, “We know you liked the last version, but once you get used to this one, you’ll find that it was worth the pain of learning something new.”
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.
I don’t think this is about purity versus real world. This is about vendor-neutrality versus single-vendor “standards.” It is about the end-user, the person that does not want to have to buy a two hundred dollar program just so he can send off a couple of resumes or fill out a city application for approval to build a fence around his property. It is about the agency that has files created in older versions of WordPerfect and Word, but cannot open any of those files in Word 2003, yet must keep them around for archival and legal purposes. It is about real estate buyers and lenders that went to electronic records in the early 1990s, and now cannot access anything that was not printed out and saved in “hard copy” form. It is about ownership of one’s own data, which, while it may sound idealistic, is the basis of real issues that people are dealing with today. These are also issues that those of us who support users deal with today. If you do not deal with them, maybe you are the one who is not living in the real world.
While you may not get it yet, users have troubles with each version of a software application that comes out. Little cosmetic changes, like relocating menus, hiding items that haven’t been used for a while, or—oh yes, let’s not forget—dumping menus for an entirely new way to hide the function that a user wants from him (“ribbons”)—these are the things that cause users and support techs headache after headache. The reason people endure these things is because up until now, they had little choice. Every few years, the version of the software changes, and with that comes some file incompatibilities, so if one person in a work group has the new version, they all have to change. It might be different if the changes were for the benefit of the users, but these changes appear to be mostly motivated by the cash-flow needs of the software vendor, in this case Microsoft. This is a function of vendor lock-in, as the “secret sauce” file formats keep users from switching to something that may better meet their needs.
Indeed, I am sure that one of the reasons why Microsoft Office 2007 has defaulted to OOXML is to finally uproot all of those people who are still getting by with Office 97 on Windows 98. Over time, those people will find their file format less and less supported by others, and will finally have to purchase the newer version. Now I do not know if the lack of technological usage restrictions (TUR, often euphemized as “digital rights management,” or DRM) on those older versions means that many of those using the older software have stolen it. That might motivate pushing the modern, TUR-enabled software.
I gotta tell you, buddy, if you’re going to pretend to care about the users, TUR is universally hated by honest users and technicians. Only the vendors and the thieves like it, because it is trivially easy for the thieves to break, but it keeps regular users from helping themselves—they either have to buy the legal version for hundreds of dollars, or buy a “cracked” version for a few dollars. You are pushing customers into the arms of thieves. Until you are willing to deal with the consequences there, any talk of “meeting the needs of users” is hypocritical.
Enterprise users, government agencies and corporations, do indeed want XML file formats. But they want to be able to use standard XML tools to manipulate the data. For various reasons, OOXML fails this test. These users want a firm legal foundation. According to the lawyers (and I am not one of them), the patent pledge is a quagmire of unknown depth, so once again, OOXML fails the test. Users want to be able to manipulate their own data with home-grown or independent-vendor tools without getting nasty C&D letters. Again, OOXML fails the test. Users want to be able to buy software from multiple sources (that is, different vendors’ office suites) and still be able to use the same file formats and seamlessly interchange files. OOXML fails the test. At this point, even ODF fails that test, with such major holes as the formulas and various implementation incompatibilities, but plugging those holes is in progress. Hole-plugging is not being done with OOXML right now.
Where “hacks” are likely is in the “doItTheWayWeUsedToDoItIn1997” compatibility flags. If Microsoft’s office applications write files out with these flags and another application does not know what to do with them, the other application will be thought to be “not fully compatible.” I realize that this is the whole idea behind these flags, but the days of a single-source for software are coming to a close. I could even see a couple of corporations quietly putting some resources behind the ReactOS project in order to have a second source for a Windows-compatible operating system.
Actually, I am surprised that none of you ‘softies have quoted Ben Langhinrichs examinations of ODF. He has found some legitimate issues that need to be fixed, unlike the company talking points that you’ve just recited.
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, [Microsoft O]ffice via market share and caring about backwards compatability has a huge leg up.
Unfortunately, there are legal issues, which only Microsoft can resolve. Without resolution, using OOXML in a competing office suite or even an application that manipulates data from OOXML files is legally risky. It does not mean that no one will try, but it does mean that one that does so is relying upon a forebearance that may be ended at any time without notice or reason.
Now that there is a de jure international standard, the case may be made that governments should use the standard except when there are compelling reasons not to do so. Having all the past documents in an older de facto standard doesn’t fly, because even the historic vendor is moving past those older formats. At this point, public interests become superior, and whenever that happens, single-vendor standards lose. I expect to see the move of governments around the world toward ODF (or a compatible standard, UOF) continue this year and next.
As this happens, government contractors will be forced to utilize ODF as well. Some may implement both formats, but most will go with the one that is being used by their customers. It looks like a long, slow decline is in store unless Microsoft changes its strategy.
My suggestion: go sit in the corner for a little while, have yourself a good cry, and then dump this unpalatable garbage and put full, native ODF into your products. The competition will mean you’ll lose a few more deployments and have to cut prices. You may even have to jettison some of the money losers like MSN / Live. Losing share with MBD/Office will inevitably result in losing some share with Windows/Client and having to cut pricing. You may even have to come up with versions of the office applications for Linux, BSD, PalmOS, or (gasp!) PlayStation.
In the long term, however, fair competition will improve your business and the businesses of your competitors as well. We users and support technicians will also benefit by having the best products for our uses become available to us.
Blogged with Flock