By now everyone on the planet with an internet connection knows about Rick Jelliffe, the blogger Microsoft offered to pay to make the Office Open XML Wikipedia page “more objective”. (It is unclear what criteria Microsoft uses to determine which bloggers are given free laptops and which ones get offered cash.) In any case, I suspect that objectivity, like love, is something that is better free than purchased.
Microsoft’s Doug Mahugh disclosed a portion of the proposal he sent to Rick, in a comment on Slashdot:
Wikipedia has an entry on Open XML that has a lot of slanted language, and we’d like for them to make it more objective but we feel that it would be best if a non-Microsoft person were the source of any corrections… Would you have any interest or availability to do some of this kind of work? Your reputation as a leading voice in the XML community would carry a lot of credibility, so your name came up in a discussion of the Wikipedia situation today.
The national coverage of what was eventually called “Wiki-gate” brought the inevitable reaction from Microsoft — IBM made us do it:
[Microsoft] Spokeswoman Catherine Brooker said she believed the articles were heavily written by people at IBM, which is a big supporter of the open-source standard — in USA Today.
So the question in my mind is this: How bad was the OOXML Wikipedia page before all the fuss started? All this Wiki-gate news hit on the 23rd, with Rick’s blog post. So let’s go back to the Wikipedia page previous to that, which would be the version of 18 January. Take a read. You can also take a look at the Talk page where the prior version was last edited on 21 September. You can read it here.
Is this something that one would say has “a lot of slanted language” and was “heavily written by people at IBM Corp”? Is this something that warranted extraordinary means to address? I’d be interested in what parts they believed were “heavily written”. What does “heavily written” even mean? This is quite an allegation.
How’s this for heavy: I’ll make you an offer you can’t refuse. I’ll do a review and fact checking of the 18 January version of the OOXML Wikipedia entry, and I’ll link to the review from the Talk page, so others can consider it and make the changes if they agree. I won’t charge you a cent. If you find this at all useful, you can donate a few dollars to the Free Software Foundation. How’s that, Doug?
- The first paragraph should say simply “Office Open XML”. It is a waste of time to argue about whether it is Microsoft Office Open XML, Ecma Office Open XML or ISO Office Open XML. At some point you may have one version in ISO while a revision is being worked on in Ecma. Just call it “Office Open XML” and it will cover all cases.
- Next sentence should say, “The specification was developed by Microsoft and others…”. You shouldn’t need to list them all here, but do list them under Standardization.
- Should say, “is the default format in Office 2007”, not just “is used”.
- “Microsoft maintains that its primary goal…” needs a reference to cite. Perhaps page 1 of the whitepaper.
- “The Microsoft Office Open XML format is Microsoft’s direct answer to the OpenDocument format” also needs a reference or should be removed.
- Standardization section would be better if written chronologically, start from the beginning and end at the end.
- Should say, “A liaison from the ISO/IEC JTC1/SC34 was appointed to help during…”
- Licensing — “There has been a lot of argument about…”. If there has been a lot, maybe someone should cite an example?
- Brian Jones is an expert in some things, but I am not aware of his legal credentials. So citing his legal analysis does not seem to be authoritative and I doubt he intended it to be taken that way. This citation should be removed.
- Overall, the Licensing section seems like it is missing what I’d consider the two most important links: Microsoft’s Open Specification Promise, and to the Baker & McKenzie analysis.
- I would move the packaging and relations text into its own article called “Open Packaging Conventions” or OPC. The basic structure here will be used in other Microsoft formats like XPS so it makes sense to centralize it in one place and reference it from here.
- Under Document Markup Languages, I’d drop the discussion of the 2003 formats. Move that to a different article if needed. Ditto for DataDiagrammingML.
- Under Criticism, there needs to be some references cited. There is no shortage of criticism and no shortage of references for that. If you want primary source material, I’d suggest GrokLaw list as the most comprehensive. It cannot simply be denied or ignored that there is a large amount of criticism out there. It will look silly for Wikipedia if OOXML is defeated in ISO and the day prior there was not even a mention of criticism on its Wikipedia page.
- Market Adoption — This section seems to be talking more about application support than adoption. I suggest it be renamed “Application Support” and “Adoption” be reserved for notable adoptions of the standard at the state or national level if/when they occur. OpenOffice’s support of WordProcessing 2003 doesn’t belong here, but Novell’s announcement that they will add OOXML should be here.
- A note throughout — this article could use some copy editing. As expected with any text written by several people over time, not all native English speakers, there are differences in levels of formality and a good number of language errors.
That’s about it. I didn’t see anything all that unusual or extreme here. If anything I found it odd that there are no links in this article to anything critical of OOXML, even though Microsoft’s stated reason for contracting with Jelliffe was to correct bias in the article. What am I missing? Where is this horrible slant? If anything, this article is living in some dream world where OOXML is not being heavily criticized for being too large, too rushed and too poorly written. If an article with no links to criticism is considered “heavily written by IBM”, I’d hate to see what Microsoft thinks an objective article reads like.
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.