Once More unto the Breach

IBM Joins OpenOffice.org (The Quick Analysis)

It's official — IBM has joined the OpenOffice.org project. [There's good reporting and analysis from Andy Updegrove and Redmonk's Stephen O'Grady.  Update (12 Sep): Here's Andy's interview with IBM's Doug Heintzman, Director of Strategy for the Lotus division.] 

Here's the back of the envelop analysis.

From the OpenOffice.org community perspective, I'm guessing Louis Suarez-Potts (OO.o Community Manager) is feeling good to get a new injection of code/energy.  This is great for the community.  The OpenOffice suite keeps getting better and better, but new blood with new code could provide a much needed boost.

Overall Sun Microsystems is probably [very] happy IBM is supporting OpenOffice.org directly.  This is a much better situation than IBM building some form of ODF development platform inside Eclipse.org to enable ODF over OOXML, with OpenOffice.org hit as collateral damage.  [This would be sort of ironic since Eclipse helped to pull the Java centre-of-gravity away from Sun, and Visual Studio was collateral damage (or icing depending upon one's perspective).]  Collaboration is the much stronger market play here for Sun and IBM, and most importantly OO.o users and customers.

From the IBM perspective, this is brilliant business as usual.  ODF is the global leverage they need to crack open the Microsoft Office marketplace.  (I've written ad nauseam that ODF and Microsoft Office is just another example of Christensen economics in motion.  Microsoft has over-delivered on Office.  They mistakenly think more innovation faster is the answer.  Let the chips fall where they may.)  IBM will likely use OpenOffice to front-end Lotus and the Domino server product lines, and anchor their business messages to their customers's needs around standards and open source software, much the same as they do with Eclipse and the Websphere developer world.  Their claims are that much stronger with this announcement.

Sun gave Gnome a huge leg up about four years ago when they contributed a wealth of their accessibility technology R+D.  IBM will now contribute the same into OpenOffice.org.  It means they can easily manage their way through U.S. government procurement regulation in this space.  Once again brilliant IP management from IBM, and good for OO.o users and customers.  [For those that have heard me present, this is exactly what I mean about having a mature intellectual asset strategy, and being generous exactly in order to play to win.]

A strengthened OpenOffice.org will help Novell immeasurably to keep their distance with Microsoft on the desktop.  Novell has done a lot of work with OO.o in the past.  They have a great desktop Linux product.  They can simply take a ride on this one and eat the benefits.  There's really nothing Microsoft can say here.  Regardless of any agreements around OOXML that Novell may have with Microsoft, Novell comes out clean on the ODF front as customers demand it.

I noticed the press release includes a quote from Beijing's Redflag Chinese 2000 Software Co., Ltd., the makers of Redflag Linux and RedOffice.  This is significant.  Apparently last November I was one of the first people to blog about the document format work in China that led to a Chinese national standard (UOF).  Redflag Chinese 2000 was implementing UOF in Red Office (the Chinese packaging of OO.o).  There is work afoot to harmonize ODF and UOF.  And clearly Redflag Chinese 2000 remains committed to the OO.o effort.

So despite the bluff and bluster, the OOXML camp inside Microsoft should not be sleeping well at this point. 

"Don't blink.  Blink and you're dead.  Don't turn your back.  Don't look away.  And don't blink.  Good luck!" — the Doctor

Office Open XML Conformance (A Lesson in Claiming Standards Conformance)

So I'm a naive user of technology.  (No.  Really I am.  Ask anyone that's worked with me.) I am definitely not an expert in modern XML document standards.  (I have actually hacked troff escapes in a document production chain to insert commands in the PostScript output stream that would be recognized by the PDF generator to produce a hyper-linked document, so I know a little bit about the concepts involved, but that was also 10 years ago now.)

I am a [marvelously happy] Mac user for the past two years.  That means I already have iWork 2008 loaded with the new improved Pages '08 (the Apple word processor).  On the Apple web site, if I search for "office open xml" then I end up on this page (31 Aug, 2007), which tells me all about Pages '08:

Widely compatible.

Pages ‘08 supports industry-standard formats, so you can easily open documents created in other word processing applications and share documents with others. Whether they’re using a Mac or a PC.

Open for business.

Import your Microsoft Word documents into Pages ’08 with ease. Whether they’re Microsoft Office 2007 (Office Open XML) or earlier Word files, Pages will open them. Pages imports not only the text, but also the styles, tables, inline and floating objects, charts, footnotes, endnotes, bookmarks, hyperlinks, lists, sections, change tracking, and other elements of your original Word document.

COOL!  I'm in!  This is awesome.  I want to see how well I can read interesting docx files.  As it happens, ECMA International makes the Office Open XML standard available as both PDF and as docx files.  Clever — it's a document format standard see, and so they've provided it in its own format.  Perfect.   

So I download the .docx version of ECMA-376.  All 5 parts of it.  And I open "Part 1 - Fundamentals" and immediately get told some warnings occurred:   

I choose to review and get:

The file mostly looks good, but not quite as clean as the PDF image with the other font (Consolas?).  And clicking on the first warning (about the unsupported field) gives me NO additional information to understand what/where the error might be.  Now this is what we in the standards industry call "a quality of implementation issue".  Clearly Apple has not done a good job.   Get used to hearing this phrase a lot in the press — I'm predicting Microsoft will be forced to apply it liberally to their partners that helped them win votes and helped with the marketing message. 

Then I notice the paging problem.  I have no idea why, but there seems to be page drift between the PDF and .docx versions.  [More on THAT little problem in a minute.]  The paging problem does NOT mean there's necessarily a problem with the standard itself but rather the document production machine ECMA was using — we don't know what the definitive source and tool chain was that produced the PDF.  (Serious document production is the same as serious software production, something most word processor users fortunately don't get to experience.) Oh, and there are line numbers in the PDF that don't appear in the .docx as opened by Pages '08. 

Ignoring the document version skew problem, I decide to see what happens when I throw an even bigger docx file at Pages '08.  So I open "Part 3 - Primer"  and ...

    

A few more "warnings" to deal with here. More missing font problems.  Things were "removed".  No helpful information as to what or how. 

I asked a friend with Office 2007 to download and open the two .docx files.  You guessed it — no warnings.  So we're now on the slippery slope.  Apparently I can create files in Office 2007 that Microsoft marketing claims are "standard" Office Open XML that may (or may not) use proprietary extensions.  Or maybe Apple did a really bad job.  How would a government customer interested in preserving documents know?  But it gets worse.  The Office 2007 pagination perfectly matched the PDF version.  And there are line numbers in the Office 2007 version just like the PDF version. 

Ooops.

I'm betting the average business or government office person saving a file won't think twice about it.  You see Office 2007 gives you no way to save something as "strict" Office Open XML.  Not even not by default, but not at all.  Microsoft's definition of "Office Open XML" appears to be .docx itself. 

Indeed, even Apple's Pages '08 will only EXPORT to old Microsoft Office format (.doc) and not the standard Office Open XML (.docx) format.  So I appear to have no way to generate a OOXML file from Pages '08.  [Yes, yes, yes — Microsoft will again point out it's a quality of implementation problem.  Or they'll point out that Pages '08 is a "consumer" of OOXML only, which is allowed by the standard.  I get it.  It's not Microsoft's fault.  I'm beginning, however, to wonder at the quality of implementation on the Novell platform.  There's a business partnership under duress.]

So as an adjudicated monopoly of desktop operating systems, supplying an office productivity suite with 95+% market share, they will be able to claim instant victory for the adoption of their international standard because .docx files equal Office Open XML standard files.  Oh, wait — that's what was essentially done in the IDC study published this week that was "sponsored by Microsoft".

[Now we're about to get a wee bit tedious and exact as standards wonks are prone to be.  I'm going to try to explain the conformance game.  It can be subtle.  Apologies in advance for perhaps getting too ... well boring.  If you're not interested in standards mechanics, you can safely stop reading.]

So OOXML defines a couple of types of conformance.  There is Document Conformance, and Application Conformance.  And conforming applications can be producers (i.e. OOXML document writers) or consumers (i.e. OOXML document readers) or both.  Here's the text from the standard [Part 1, PDF edition, p. 3, lines 8-30]:

2.3 What this Standard Specifies
To address the issues listed above, this Standard constrains both syntax and semantics, but it is not intended to predefine application behavior. Therefore, it includes, among others, the following three types of information:

1. Schemas and an associated validation procedure for validating document syntax against those schemas.  (The validation procedure includes un-zipping, locating files, processing the extensibility elements and attributes, and XML Schema validation.)
2. Additional syntax constraints in written form, wherever these constraints cannot feasibly be expressed in the schema language.
3. Descriptions of element semantics. The semantics of an element refers to its intended interpretation by a human being.

2.4 Document Conformance
Document conformance is purely syntactic; it involves only Items 1 and 2 in §2.3 above.

• A conforming document shall conform to the schema (Item 1) and any additional syntax constraints (Item 2).
• The document character set shall conform to the Unicode Standard and ISO/IEC 10646-1, with either the UTF-8 or UTF-16 encoding form, as required by the XML 1.0 standard.
• Any XML element or attribute not explicitly included in this Standard shall use the extensibility mechanisms described by Parts 4 and 5 of this Standard.

2.5 Application Conformance
Application conformance is purely syntactic; it also involves only Items 1 and 2 in §2.3 above.

• A conforming consumer shall not reject any conforming documents of the document type (§4) expected by that application.
• A conforming producer shall be able to produce conforming documents.

This is the traditional way things are done with programming languages standards as well.  The concept of a strictly conforming C-language program is defined in the ISO/ANSI C standard so as then to define conformance of an actual implementation (i.e. C-language compilers).  In the OOXML standard, document conformance exists to be able to talk about implementation conformance, i.e. what readers/writers need to produce or accept if they conform to the standard. 

For completeness sake, the "document type" reference in 2.5 above is described in section §4 as [Part 1, PDF Edition, p. 6, lines 16-26]:

document type — One of the three types of Office Open XML documents: Wordprocessing, Spreadsheet, and Presentation, defined as follows:

• A document whose package-relationship item contains a relationship to a Main Document part (§11.3.10) is a document of type Wordprocessing.
• A document whose package-relationship item contains a relationship to a Workbook part (§12.3.23) is a document of type Spreadsheet.
• A document whose package-relationship item contains a relationship to a Presentation part (§13.3.6) is a document of type Presentation.

An Office Open XML document can contain one or more embedded Office Open XML packages (§15.2.10) with each embedded package having any of the three document types. However, the presence of these embedded packages does not change the type of the document.

Now there is no statement of conformance to Office Open XML on the Apple web site beyond the above statement of "support".  A search in Pages '08 Help for "office open xml" finds no reference at all.  So Apple appears not to actually claim conformance to the OOXML standard anywhere.  They simply "support" it.  So they're not really guilty of not reading a conforming OOXML document. 

But the Microsoft standards and marketing machines are claiming "support" for their standard with the assured tones that "support" = "conformance".  Aside from the successful "adoption" claims in the aforementioned IDC report (where Office 2007 market share apparently equates to Office Open XML adoption) we have Tom Robertson (Microsoft General Manager of Standards and Interoperability) "citing support in products from Novell, Corel, Apple and others."    Disingenuous at best.

Jason Matusow points out on his blog:

A real litmus test for the viability of the ISO/IEC DIS (draft international standard) 29500 (Open XML) is whether or not there are independent implementations. The answer to this question for Open XML is an unequivocal yes. There are independent Open XML implementations based on the existing specification in applications that run on Linux, Mac, Palm OS, iPhone, and Windows. 

Again note the complete lack of reference to actual conformance per the definitions in the standard they have driven through the process.  These are the people that are responsible for standards management and messaging at Microsoft.  They are by definition the folks that should be defending the strict conformance of the standards in which they participate, and not merely suggesting that partial implementations are a "great start".

So where does this leave the government customer that thought they were buying an open document format for document exchange and interop?   It is indeed finally time to roll out the certification machine — for everybody.  Let the games continue.

Microsoft's Failures with the OOXML Standard

The ISO "fast track" vote on approval of Microsoft's OOXML document specification happens next Monday (2 Sep.), and news is breaking fast and furious as various countries report out early.  An interesting bit of technical experimentation was published in the past week in the shadow of the vote.  It shows something more pragmatically damning than all of Rob Weir's hard work digging through faults in the OOXML specification. 

The work is published as a set of experiments.  The first experiment takes a trivial spread sheet created with Microsoft Excel 2007.  The next step is to unpack the Excel generated "standard OOXML" and make a trivial edit to it and repack it.  Excel then complains violently about the result (i.e. to the point of not reading the document). 

This is a catastrophic failure on two fronts for Microsoft's "standard": 

• It means Microsoft Office DOESN'T ACCEPT WELL FORMED OOXML documents not produced by Microsoft Office.  This would be very bad for all those customers that believe the marketing and think they're buying a product implementing a "standard" that will [someday maybe] be supported by multiple implementations.
• It means the Microsoft OOXML specification has sufficient problems in what it isn't saying in that implementors can't implement it.  (Changing a one character field in human readable XML with an editor is about as basic as it gets for implementation.)

Game over.  A standard that can't be implemented is WORSE THAN USELESS.  It really demonstrates that this standard they rammed through ECMA is nothing more than a vendor's product specification.   The rest of the experiments are equally telling in terms of the apparent use of product features outside the specification, etc.

This is not to say that Microsoft won't keep the steam roller crashing right along.  From Mary Jo Foley this week we see that Microsoft is still "buying research" from IDC in a study declaring great uptake for OOXML.  [I'm not linking to it because frankly it deserves to be buried.  I won't even give it the small link credit this blog engenders.]  While the IDC folks try to avoid complicity in the biased survey by openly declaring under the title that it was "Sponsored by Microsoft", we know the Microsoft marketing machine will happily be using the numbers and graphs in slides, attributing it all to an IDC study and failing to mention they paid for the "opinions".  Too bad for the credibility of the IDC researchers when this one comes home to roost. 

The incredible adoption for "OOXML" is likely a measure of market share on Office 2007 since it would be the only product claiming to implement the standard.  The way the "study" keeps conflating PDF with ODF/OOXML is broken as well.  So WHEN customers discover the truth of the implementation difficulties and continued lock-in of their document world, they'll respond the way customers always do when a vendor pulls a fast one on them.

Perhaps the most disheartening failure however is the way Microsoft has abused the machine that is the world's standards development organizations.  Andy Updegrove has a brilliant if painful read on the damage that Microsoft has caused in its "race to win."  Standards are needed and important.  In the days of film cameras, you wouldn't have been able to grab a roll of 35mm ASA 400 film from any store anywhere on the planet (produced by multiple different companies with their own value added services and technologies) and have it just work in your camera without such standards from such organizations. 

Microsoft is pushing organizational rules to the breaking point, ballot stuffing and buying its way to a win at ISO.  They have complained from the beginning of the process that they're doing nothing different than the likes of their competitors who are "aligned against them."  But this shows as much ignorance and naivete as the quality and implementability of their specification.  Companies like IBM and Sun have invested deep and long and globally in their standards participation activities.  They don't need to stuff the ballot box in a sudden end game -- they're invested in the long term infrastructure itself.   They absolutely play to win and sometimes surprise one in their creative use of the rules and organizational structures.  But they win because of a long term commitment to the machine itself, not to winning a particular battle at all costs. 

Standards at Microsoft has been run by lawyers instead of technology standards practitioners for too long.  It's been demonstrated time and again from the very beginning of the ODF working group formation in a succession of tactical and strategic failures by Microsoft.  To those lawyers that have never actually participated in standards working groups, or the standards management process, or implemented to the specification, or designed a certification process to demonstrate conformance, this is just one more battle to win and hang the consequences.  (Indeed, if we can "win" we can use it as precedent to "win" again!)

The sad part is that even if the ISO vote actually goes in Microsoft's favour, it still won't matter.  It buys them a few years of market ignorance at best.  This entire two year event is one for the standards text books on how not to respond to a business threatening standard.    In the end, Microsoft will need to implement ODF natively.  They don't know it yet, nor do they understand why, but it is just a matter of time.

Microsoft Continued Standards Abuse, PDF and the XML Paper Specification

Andy Updegrove and Bob Sutor have both well covered the announcement that Microsoft is now going to submit its PDF competitive "XML Paper Specification" to ECMA for standardization, which means they'll no doubt run it to ISO after ECMA so as to claim an international standard. 

The economic point of standards is to encourage and enable multiple implementations of the thing specified providing choice and risk mitigation to customers.  A "standard" with one implementation is a vendor specification regardless of standards body imprimatur -- the economics benefits the vendor by enabling an ecosystem around their product.  So a successful standard needs to have multiple implementations.   

But there is another quality shared by successful standards.  Successful standards are based on existing practice and experience across a technology area.  There is a richness of trials, product successes and failures, over a period of years that feeds into the development of the specification that gets standardized once the right level of abstraction begins to become apparent.  You don't standardize new things because they need the ability to change and evolve.  You don't standardize a new product, because while standards invariably have mistakes, you don't deliberately want to standardize a new product's bugs. 

As Andy points out, Adobe's handling of PDF was indeed heavy handed.  But by the time PDF was launched by Adobe 10+ years ago, there was a wealth of broad industry experience in document formats, markup languages, page description languages, printer description languages and the appropriate levels of separation between them.  The format has stood the test of time with little change.  There are multiple readers and writers in the marketplace.  With the completion (finally) of the ISO standard, one can claim PDF is a successful standard. 

For Microsoft (or anyone else) to introduce a new and potentially innovative technology in the space should be encouraged.  Just because there is an accepted standard way of doing things should not mean society (through the marketplace) should ignore the opportunity to evolve a technology space and solve new related problems.   To publish the specification to encourage an ecosystem to explore and evolve the space (to the developing vendor's advantage) is also to be encouraged because that's good business practice, AND it provides the real-world economic test of the marketplace.  It also allows the vendor to reap the economic rewards of solving a new problem space for customers.    

But that's as far as something new should go.

Once again we have Microsoft dumping its new product specification into ECMA, with a scope that says the standard must align with the product.  They originally presented the format as their PDF killer as if that was somehow a feature customers need, so we also  understand they're not evolving anything, they're just competing with an accepted standard. 

I'm a big fan of Heinlein's (or Hanlon's) Razor, but regardless of whether this is malice or stupidity on Microsoft's part, it's very wrong from a standards perspective. 

We need just to say "no".

Ari Jaaksi on Nokia and Open Source and the N770

Ari Jaaksi is head of open source software operations at Nokia, and is responsible for Nokia's N770/N800 and maemo.org initiatives.  When Nokia developed the software platform for the N770 internet tablet, they determined early on to use as much open source software as was feasible to deliver the device.  In a white paper on Ari's blog, he details the early learnings at Nokia around open source and product delivery.   

The concise 10 pages is stunning and worth the read in its entirety.  Nokia worked with a Debian 2.6 kernel, GNOME, the Hildon framework, and D-Bus to name a few open source components. Here's just a sampling of some of the observations:

On working in communities:

We used existing open sourced components such as the gnuchess chess game engine, bzip2 data compressor, id3lib for manipulating ID3v1 and ID3v2 tags in digital audio files, and many more as such, whenever that was possible. The bigger the component or subsystem was, the better. When possible, we reused an entire subsystem and subsystem architectures, such as GNOME [GNOME 2006] and Debian [Debian 2006]. Instead of separate components we reused architectural blocks that already integrate several independent components.

In several cases we sponsored the development of existing components, such as the Linux kernel, DBUS, GNOME-VFS, GTK+, GStreamer, and OBEX to make them better meet our requirements. The additional work was needed especially in the areas of UI and usability, power management, performance, and memory management. Our engineers worked directly with communities participating development projects. We also hired and asked developers within the communities to enhance components based on our needs.

On cost savings:

The biggest cost savings came from the utilization of already available components. We utilized several free components and subsystems as such, with no modifications.

We also improved several components to better meet our requirements. Such improvement is cheaper than creating the needed functionality from scratch.

Some 2/3 of the code of the Nokia 770 is licensed under an open source license. These components made it possible for us to build the software cheaper than we could have done using closed and proprietary technologies.

On code quality:

If we compare the code from open source to the code developed by us, our conclusion is that open source is of better quality. We have more bugs and problems in the Nokia developed code. This is only natural because the majority of the Nokia code is build from scratch and is thus very young. Open source code, on the other hand, has mostly been used by others already. They have fixed the most severe errors already before we started to use the code.

If we compare open source code to commercial components used on our platform, the quality difference is not that obvious. The commercial components have typically been used by others, too. That has improved their quality.

On engineering flexibility:

Open source is flexible when we needed to fix a problem or change functionality. We often requested bug fixes or modifications to the commercial closed components on our platform. If the vendors didn’t have the capacity or will to fix the problem on time, we had few options. We could not fix problems  ourselves because the companies using closed source didn’t want us to access their source code. With open source components, though, we fixed bugs yourself, hired somebody else to fix them, or worked with the communities for the modifications. We thus had many options available, and in most cases we managed to fix the problems at hand. The free access to the code and to the  developers improved the quality of open source originated components within the final product.

On software licensing:

Software licensing is often a complicated and time consuming process. It requires a lot of negotiations between the licenser and the licensee. Based on our experience, an average in-licensing process for a software component takes 6 – 12 months. It is only then when you know if you can really use the component in your project or whether you need to find other solutions.

Licensing is simpler with open source. The licensor has already done the most of the due diligence work in advance. In most cases, the licensor keeps the copyright, doesn’t give any exclusivity, and gives the licenser full right to use the component any way needed. At the financial side, licenser has decided that the code is free, but the licenser may offer support or engineering services for money. Nothing prevents the licensor to go elsewhere for help, if so needed.

All the source code is available for the licensor to study and evaluate. The licensor can assess the community, companies, and available hackers supporting the technology in question. Also, the licensor can talk to others without worrying about trade secrets.

Open source simplifies and accelerates software licensing, and reduces  technology and quality risks. Instead of negotiation for months, the technical work can start immediately.

On confidentiality and the open source community: 

We worked intensively with communities already before we announced the Nokia 770 Internet Tablet. Open source approach requires openness and information sharing during development. A high publicity launch, on the other hand, is the way to introduce consumer products to the public and you do not want to reveal the products before the launch date. There is thus a potential conflict between the open source openness and product launch secrecy.

The credentials, work, and history of open source hackers are open for everybody to see. The hackers typically want to work with interesting things also in the future. Therefore, they don’t want to become famous for jeopardizing somebody else’s project and misusing their trust. Thus, openness and open source can actually be much stronger bond than any NDA or monetary sanction one can put on an individual or a company.

Based on our experiences, we can combine open communication and product confidentiality. We had no information leakage prior to the commercial product announcements, although we had had tens of developers working on the software with us. For some of the developers, we had told very detailed information about the forthcoming product. Developing products in open source and yet maintain the confidentiality of the product plans and roadmaps was possible for us.

He further outlines some of the challenges of working in communities, managing the licenses, and where new costs showed up in the project, but summarizes:

Our experiences demonstrate that open source technologies and development model suit very well for such devices. We created the product in shorter time and with lesser resources that we have managed to develop other products utilizing proprietary software. In essence, open source offers time and cost savings in a form of readily available components and subsystems, available developers, and effective development model.

The one interesting thing he doesn't mention: the lack of royalties paid to a Microsoft or Symbian, but then this is a paper about open source software.  As the Asian markets open up, a billion handsets in China won't translate into a billion royalty payments for the OS vendors.  When that amount of money is at stake, experiments like this one are critical to getting the open source engineering model right to save Nokia billions of dollars long term. 

I've thought the Nokia 770 was cool since Mikko handed me his to explore.  The slides to Ari's original presentation on the N770 development are here.  Ari's paper is a fabulous contribution describing how a large company can engage in open source communities.  Ari maintains a blog that is also well worth tracking.

Enjoy!

Openness, ODF, and OOXML from Sam Hiser

Sam Hiser has put together a comprehensive essay comparing the Open Document Format (ODF) standard and Microsoft's Office Open XML (OOXML) standard.  Sam is vice-president and director of business affairs for the OpenDocument Foundation, so has an obvious bias.  It is, however, a timely and very useful document considering the amount of government lobbying Microsoft is doing.  Sam compares the two standards based on:

• Specification development practices
• Usefulness of the specification from an implementors perspective
• Clarity of IPR rights
• Breadth of implementations (many ODF implementations on many platforms versus one partial OOXML implementation)

The document is an excellent summary.

Microsoft Discusses Open Standards (versus Open Source Software)

Matt Asay discusses today's Wall Street Journal article on Microsoft's battles with State governments over ODF.  [Here's the link to the article source from Market Watch lest the WSJ archive go into pay mode.] 

I find this all sort of funny.  Five years ago as governments explored open source software preference legislation, Microsoft's rhetoric machine went into overdrive to lobby people to prefer technology based on open standards regardless of implementation methodology and licensing.  And this IS the right solution for governments.  But based on current rhetoric I thought it would be funny to see what Microsoft had to say for itself.  Unfortunately the Wayback Machine wasn't as helpful this time, and Google search results are jammed with the "Men in Black" story about Microsoft's hired bullies lobbyists. 

I was, however, able to find a document from that period on Microsoft.com.  [Microsoft.com is a sufficiently large site to have a life of its own.  While pages change, downloads often remain.]  A search on Microsoft.com for "standards open source" returned a huge number of links, but a download called "Key Messages" on the first page looked promising.   

So here are some "Key Messages" from Microsoft's standards team circa 2003 (doing battle with the Australian parliament no doubt) [Emphasis added]:

• An open standard is a publicly available specification which details certain technical functionality that may be implemented in different products and services.  It is adopted in an open, consensus-based process and must satisfy other criteria for transparency, ease of access, and broad implementation as described below.
• Open standards exist to facilitate interoperability and data exchange across various products and services in a marketplace of multiple, competing implementations, while ensuring that certain minimum requirements are met.
• Other types of standards (e.g., “proprietary standards”) and market-based mechanisms exist and are currently used to facilitate interoperability.  However, open standards ensure the highest level of interoperability across the widest range of competing products and services.

You can read the rest but you get the idea.  Sooooo ... ODF versus Microsoft Open XML.  I guess we should judge each based on the number of implementations of each.   

Microsoft Whining for Sympathy about OOXML

So what's the real message with Microsoft's open letter whining about IBM and ISO and the Microsoft driven OOXML standard? 

• IBM is out performing us? 
• We need sympathy after our record quarter? 
• People should ignore our anti-ODF lobbying in Massachusetts because that was just business as usual? 

This is professionally embarrassing.  It is certainly not the company for which I used to work.  (CNet article is here.)

Vendor-Speak: Microsoft and OOXML

Peter Galli well covers the current news surrounding proposed ODF adoption in Texas and Minnesota, and the ISO vote on OOXML in its first phase in this article.  There are two quotes in particular that leap out, both from Tom Robertson, Microsoft General Manager of Standards.  Let's look at the latter one first:

But the company supports customer choice and interoperability and urges governments to also support these, he said.

"In that vein, we encourage them to adopt neutral technology procurement practices so that they have the greatest choice among available technologies, and so encourage competition in the marketplace and get the maximum value out of their IT investments," he said. "Mandating a specific document format for government use reduces a government's ability to communicate with its constituents, make the best use of available technology, and promote competition and innovation in the marketplace."

A lawyer's oeuvre, as is a journalist's, is defined by language.  Tom is a lawyer.  There is a wonderful shift in meaning of "a specific document format" as Tom slides through the paragraph.  He is a consummate linguistic professional.

Tom hopes that customers will confuse the standard for a format, a specification in its own right, but one that encourages multiple competing implementations per the customer's goal, with a format for which there is but one implementation, choking off competition.  The statement's irony is indeed rich.  Well done, Tom, but your government customers aren't so easily confused.   

The earlier quote is simply funny in its own right:

Tom Robertson, general manager for interoperability and standards at Microsoft, told eWEEK that there is a competitive situation in the marketplace, with ODF supporters actively trying to stop even the consideration of Open XML as a standard under the ISO's rules. "This is a pure competitive play on the part of ODF supporters like IBM," he said.

This one wins Obvious-Statement-of-the-Week.  Standards happen when a technology space matures to the point that customers are over-served and want choice to encourage competition.  Customers complaining about price is the market signal. Competitors know they can collectively chase the incumbent vendor with a standard at this point, if they pick the right level of collective abstraction to standardize.  This is how standards work in the marketplace.  (I would hope the GM for standards at Microsoft knew this.) 

A sympathy play isn't going to work here.  Customers WANT the standard that encourages multiple implementations.  True Microsoft support for ODF in their Office product suite would have been listening to customers.   Complaining that the marketplace is competitive while shoving your own product specification through a standards forum is naive at best and arrogant in the extreme at worst. 

 

OOXML and ISO: Round 1

Andy Updegrove covers the news (and it's significance) on this first phase of the fast track process for Ecma International's submission of Open Office XML (OOXML) to ISO. 

As Andy observes, there has been a lot of controversial discussion about defining "contradiction" and what might constitute such a thing.  This is what happens when we allow Microsoft lawyers to debate standards, rather than engineers who will need to implement them.  I hear echoes of, "It depends on what the meaning of the words 'is' is."  Not liking the rule, we'll attack the definitions.

With 19 countries offering contradictions to be resolved, it will indeed be fascinating to see how Ecma International handles it all.  The midnight oil will burn brightly in Redmond, which is only fair considering how many countries worked hard to get through the 6000+ page specification by the deadline.  The clock is counting down to 28 February.

I would offer, however, that a contradiction should not be defined as a simple overlap with another standard.  This is economically a poor yardstick to use.  We all saw this coming last Spring.  At the time I observed:

While ISO certainly doesn't like to encourage competing or overlapping standards, they will not necessarily prevent them.  They are a standards development organization in place to ensure that the rules of development are transparent and followed.  It is not their role (nor do you ever want it to be) to manage the marketplace through determining the economic viability of a standard.

By all means send the Ecma International specification back for some of the egregious internal conflicts, and ugly artifacts like date redefinitions.  But let the market decide which standard has the best value proposition to solve customer problems with the most implementations.  [We already know which will win.]  Consider the IEEE 802 standards family.  If they didn't allow standards that overlap in functionality, we would still be living on star LANs.

Copyright javabell, all rights reserved.  Used with permission.