Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Live Hideout
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
Interoperability by Regulation: The Glass Half Ful...
 
Transparency Causes Performance?
 
Dreaming in Code: Going Native by the Bay?
 
Microsoft, Interoperability, and Open Source
 
Reality Is the Model
 
Trust but Demonstrate
 
Chatting with a Spacecraft
 
OOXML: Excel2007 versus IS 29500? The Fun Begins
 
ODF1.2, My Movie Plot Defanged
 
ODF 1.2, Hijacked by OO.o?

Interoperability by Regulation: The Glass Half Full

[update 2008-07-01T03:16Z Some additional updates were announced June 30.  I account for those and the trade-press activity around them already.  There is renaming to Open Specifications generally, not to be confused with the Open Specification Promise (although there is some overlap).
 update 2008-06-28T22:34Z I added additional resources noticed while reviewing material on the Microsoft Interoperability Forums threads.]

This is a very long post.  I work through the history of Microsoft compliance with the consent decree and November 2002 final judgment in the civil anti-trust suit.  I wanted to confirm how this is a continuous improvement activity with the provision of protocol specifications and licenses at center stage now that other major compliance actions have been carried out and are being monitored for continued satisfaction. 

Because there is a perception, promulgated in what passes as the trade press, that Microsoft has not delivered and is perpetually promising delivery some day, I wanted to confirm the history and progress that has been made and that is easy to confirm using official documents and the online, public downloads of the Microsoft protocol documentation.

I also wanted to affirm how much this is a journey, it may not have a decisive end point, and the work to refine and correct and respond to difficulties in use of the documentation is an ever-expanding effort for good cause.

For simplicity, I do not track the parallel events that arose in conjunction with the European Commission judgment against Microsoft.   This progression also maps to the availability of protocol documentation in compliance there also.

1. The Story So Far
    1.1 The development of protocol specifications and licenses
    1.2 The Technical Committee assessments
    1.3 Useful review
    1.4 The progressive expansion of technical documentation (long)
2. The Current Situation
3. Public Perceptions and Debate
    3.1 My appraisal
    3.2 The eternal spotlessness of lazy minds

1. The Story So Far

1.1 The Development of Protocol Specifications and Licenses

The carrying out of the final judgment and consent decree in the civil anti-trust case between Microsoft and the U.S. Department of Justice (and other plaintiffs) is over-seen by a Federal Court judge.  Part of the on-going review of the settlement involves a requirement that Microsoft document and license, under agreeable non-discriminatory terms, a variety of protocols used between separate Microsoft products.  There is overlap with similar judgments that arose in Europe.  The idea is to encourage competition by those who would employ the same protocols to also interoperate with Microsoft products and even offer competing interoperable products as substitutes and complements.

Until this year, if we were not someone involved in their development, licensed use, or review, we only knew anything of the process of delivering and improving the necessary specifications through progress reports and other communications from Microsoft, over-sight bodies, and other authorities.  It's a bit like watching a football game during a heavy, pea-soup fog without being able to see the players and even know how the game is played.  To top it off, the various announcers and commentators don't seem to be at the same game.

This year, the more-technical members of the general public are able to observe the delivery of such specifications in a direct way.  As part of the February 2008 declaration of Interoperability Principles Microsoft provided the already-delivered documentation for on-line public access.  This documentation was developed as part of the compliance effort.  The initial materials consisted of 30,000 pages of documentation.  In April, over 14,000 additional pages of drafts for additional protocols involving more-recent products were added.  There are also on-line forums for discussion of the protocols, questions about details of the specification, and so on.  [As a point of calibration, I am not an insider in this activity nor have I taken advantage of the available protocol documentation.  I do have a personal curiosity about the FrontPage extensions and the patented Microsoft extensions to WebDAV.]

Licensing for all of these protocols and their formats where Microsoft has applicable patents is also provided under reasonable and non-discriminatory (RAND) terms, but you no longer need a license to access the specifications.   Final specifications are promised as future updates in this ongoing Open Protocol Specification activity.

These are all in addition to the specifications that Microsoft has made available under the Open Specification Promise and which have been steadily growing since 2006.

• additional resources:
  
  MCPP - Microsoft Communications Protocol Program (via Interoperability Forum).   This is the program for licensing and specifications that was originated in response to the U.S. consent decree and final judgment of 2002.  In addition to covering the current support for licensees under the program, there is now a map of individual protocols against applicable patents (June 9, 2008 PDF download).
    
  WSPP - Microsoft Work Group Server Protocol Program (via Jason Perlow and Live Search).  This is the program for licensing and specifications that was originated in response to the European Commission decision of 2004.  These specifications are also available under the Open Protocol Specification activity.  As part of the available documentation, there is a map of individual protocols against US and European patents (April 29, 2008 PDF download).  There is overlap between WSPP and MCPP.
     
  Microsoft Protocol Programs (via MSDN).  [2008-06-30 update] This covers all protocol specifications that are available, including those involving the Microsoft Office System, Sharepoint Server, and Exchange Server.  There are also additional patent licenses and patent maps for the protocols of these these products and protocols of Windows Vista (including the .NET Framework), and Windows Server 2008.  The patent maps provide check marks indicating whether there are patents or patent applications applicable to each itemized protocol.  The MCPP and WSPP patent maps provide identifying numbers for patents and patent applications of those protocols on these lists that are also covered under MCPP or WSPP.
    
  Open Specifications (via Doug Mahugh).  [2008-06-30 update] This is the location for downloading of all material provided as Microsoft open specifications, including additional formats (office binary and XAML) and computer languages (VBA) not covered by industry standards.
     
  Open Specifications, MSDN Forums.  [2008-06-30 update] Forums (new location) for discussion the open specifications, using and interfacing with the related technologies, including use and implementation of the Microsoft Office binary file formats.

1.2 The Technical Committee Assessments

Meanwhile, there is a three-person Technical Committee (TC), plus one expert assigned by the "California Group" of plaintiffs, that reviews the specifications as they are released and provides feedback to Microsoft and the Department of Justice.  The TC has its own staff.  The TC has broad access to Microsoft and its technical materials.  The TC was appointed in 2003 and the TC term has been extended until November 12, 2009, the same date that already-extended portions of the final judgment will expire.  (Some elements of the final judgment expired in 2007.)  There is provision for further extension of the judgment and the work of the TC until as late as November 12, 2012.  [My intuition is that such incremental extensions will occur.]  Microsoft has declared that it will make no objection to such extensions.

The purpose of the TC includes assessing the technical availability, completeness and usability of the specifications for successful use by third parties.  These reviews lead to requests for rewrites and other improvements in the materials and their coverage.  The TC also develops tests that are usable in some degree of interoperability verification and are being made available to Microsoft for its use as well.  Findings of the TC inform the court, Microsoft, and the Department of Justice (and other plaintiffs) of the progress and status of rewriting specifications and other activities to further the support for interoperability.  Operation of the TC is part of the oversight process agreed among Microsoft, the Department of Justice, other plaintiffs, and incorporated in the final judgment. 

On June 17, 2008, the latest Joint Status Report was filed with the court.  This is the 17th such report (including interim reports as well as the twice-yearly ones required specifically by the court).  The previous one was on February 29, 2008.  The first one was on July 3, 2003.  The complete list and texts of status reports and related documents are available on the U.S. Department of Justice web page for the case.

1.3 Useful Review

To understand the scope of all effort involved in carrying out terms of the consent decree and the final judgment, it is very useful to review the first Joint Status Report of July 3, 2003.  There are far-reaching provisions that are implemented and constantly being reviewed.  With regard to the provision of communication protocol documentation, the initial materials consisted of 5,000 pages, representing 90 man-months of technical writing effort, made available in August, 2002.  At that point having the technical documentation was but a small part of the compliance activity being carried out.

It is clear from the outset that there is a valuable iterative process by which proposed compliance approaches, license structures, and resolution of received complaints are worked out.  The progression of effort is quite revealing.

1.4 The Progressive Expansion of Technical Documentation

Although there were a number of protocol licensees by the time of the third report, January 16, 2004, there was also a complaint regarding "the sufficiency and completeness of the Technical Documentation that Microsoft provides." 

By the April 14, 2004 interim status, the plaintiffs concluded that "the technical documentation needs substantial revision in order to ensure that it is usable by licensees across a broad range of implementations ... ."  In its response, Microsoft recognized "that there is (and likely always will be) room for improvement given the scale and complexity of the undertaking. Microsoft anticipates that modifications and enhancements to the technical documentation will be an on-going process as Microsoft and the licensees gain more experience in working with the documentation, new versions of protocols are released, related technical information resources that Microsoft makes available are modified, and so forth."

According to the July 9, 2004 status, development of measures for completeness and a plan to revise the documentation by Fall, 2004 were underway.   By the October 10, 2004 status, revised documents were being placed in beta release for review and concerns over the format of the documents were being addressed. 

On January 25, 2005, it was reported that revised documentation had been made available in December, 2004. "Plaintiffs believed that the revised documentation represented a significant improvement over the original documentation. Plaintiffs nevertheless remained concerned that further work on the documentation was needed to provide confidence that licensees would be able to implement the relevant protocols."  At this time, there was a significant expansion of technical developments to be used in verifying the protocol documentation:

"The TC's prototype implementation project and Microsoft's parser development project are designed to capture different types of potential issues with the technical documentation. The two projects will therefore proceed on parallel tracks. Plaintiffs and Microsoft believe that the two projects, combined, provide a realistic mechanism to ensure the overall completeness and accuracy of the documentation. Given the substantial scope of these projects, we propose to complete them in approximately one year. Licensees, however, should realize benefits from the projects well before their completion. As issues with the documentation are discovered during the projects, Microsoft will make the appropriate changes to the documentation and release updated versions of the documentation to MCPP licensees on a regular basis. Accordingly, the documentation available to licensees will improve in quality and accuracy throughout the course of the project work. Plaintiffs believe that this plan will provide an expeditious and effective way to improve the technical documentation."

According to the October 19, 2005 status, the TC projected that the prototype implementation would not be complete until July 2007.  The extension was required by ramp-up delays, recognition of greater effort required, and finding more difficulties than expected with the available specifications.   Microsoft offered these supplementary comments to what it agreed was a successful process:

"As Microsoft indicated at the outset of the process, creating from scratch technical documentation of the magnitude, scope, and complexity that [the final judgment] requires would be a substantial—and ongoing—undertaking. At the time the technical documentation was created, and still today, Microsoft has been confident in its accuracy and usability. To date, Microsoft is unaware of any existing or potential licensee that has been unable to use any Communication Protocol because of flaws in the technical documentation. Nonetheless, as Microsoft has consistently advised the Court, Microsoft also expected and understood that the documentation would not be perfect, which is why the license agreements include the Correction Assistance provisions to address just such imperfections.

"Additionally, in every case of which Microsoft is aware, use of new documentation will inevitably uncover 'bugs' and only through experience can those bugs be corrected and the documentation improved. The Prototype Implementation Project undertaken by the Technical Committee, with the participation of Mr. Hunt, is designed to expedite the process of uncovering and correcting bugs. As indicated by Plaintiffs, the project seems to be a success in that regard. Moreover, by establishing that software developers using the documentation can develop implementations of the Communications Protocols, the project has served to verify the usefulness of the documentation."

The Microsoft protocol parser project was having serious difficulties and was being re-planned and redirected to provide useful results using alternative approaches, leading to a November 18, 2005 Microsoft Supplemental Report to the court.  A January 23, 2006 Plaintiff Report added that there was a serious situation in the drop-off of responsiveness in handling of technical documentation issues.  There were also difficulties around the setup and configuration of a test center in India.

By the February 8, 2006 interim status, Microsoft has offered to provide Windows server source-code access at no extra charge to licensees.  This is proposed as a way to overcome the difficulties in maintaining the desired rate of responses to the technical documentation issues while the documentation effort is expanded.  [Ed. note: I am amazed that this was considered.  There are many reasons why reversion to the code as the authority is a bad idea, although it is difficult to argue with the desire to provide schedule relief.  It is important to understand that the Court's measure of whether the specifications are successful and the remedies of the final judgment are effective has to do with the arrival of substantial competitive products that employ the protocols; the judicial clock is ticking.] 

According to the May 12, 2006 status report, the availability of source code and a review of outstanding issues shows improvement, but not the high-level of resolution experienced previously.  Microsoft proposes that resolving the technical documentation issues and making revisions one-by-one is ineffective.  In considering a "reset" recommendation from Microsoft Senior Vice President Bob Muglia, the plaintiff's agree that a project to completely rewrite the documentation is preferable to the current revision approach under the conditions that "(1) the parties must agree on a specification for the new documentation; (2) the parties must agree on a project schedule for all the protocols; (3) Microsoft must rewrite the documentation for each protocol according to this schedule; and (4) the resulting new documentation must be tested and validated to ensure its completeness and accuracy. As it is clear that this project to rewrite the technical documentation will require a significant amount of time to complete, ... Plaintiffs have informed Microsoft that an extension of portions of the Final Judgments will be necessary, and Microsoft has consented to such an extension."  The extended portions were originally scheduled to expire in November, 2007. 

There is also rewriting required to satisfy the European Commission, so one could see how appealing a single, comprehensive rewrite could be.  The US plaintiff's are impressed by the samples they are shown, but the current approach must continue until it is clear that the rewrite is producing what is needed.   At this time, there is also new initiative to promote adoption of the protocols in third-party products:

"Microsoft will also move forward this year to create a new interoperability lab in which licensees can test and debug their protocols and obtain easy access to on-site Microsoft engineering assistance. The lab will provide a testing facility, training, best practices, trouble-shooting and technical support for licensees working on the implementation of protocols using the MCPP documentation. Microsoft will also sponsor 'plug-fest' events, which take place regularly in the information technology sector and at which a variety of companies can test and debug their protocol implementations with the goal of improving interoperability. Plaintiffs and Microsoft agree that these steps can promote interoperability. "

According to the August 30, 2006 interim report, the plaintiffs and the European Commission are coordinating and Microsoft is estimating that the rewriting of the protocol documentation will occur in stages with completion in mid-2007.  The plaintiffs are concerned with the estimate being so long.  There is also to be addition of protocols and APIs that will be arriving with "Longhorn Server," the successor to Windows Server 2003.  The TC and staff have grown to 40 people.  The Microsoft team has grown to 245 Microsoft employees and contingent staff.  The Microsoft Parser project has recovered and is making staged deliveries.  The TC prototype work is now dependent on availability of the new, rewritten technical documentation.

According to the November 21, 2006 status, the first rewritten documents delivered in the first of five initial-availability milestones are recognized as improvements, although there is some disagreement on the template that was agreed to.  This is worked out among the parties, along with an agreed review and correction process.  Microsoft warns that the current schedule is aggressive and contains no buffer.  The fifth milestone is targeted for May 29, 2007, with an online build of that milestone's reviewed/revised documents 90 days later.  The Microsoft staffing has grown to 260.

According to the March 6, 2007 interim status, the first three initial-availability milestones were met on schedule.  Microsoft has requested insertion of an additional "Longhorn milestone" before the original 4th and 5th milestones.  This moves the final initial-availability to July 20 2007 with online build later.  The Microsoft staffing has grown to 313.  Microsoft notes that "the number of pages of documentation that Microsoft now expects to deliver as part of the rewrite project is significantly larger -- likely thousands of pages larger -- than Microsoft originally anticipated in Fall 2006." 

"The increase in the volume of the documentation is due to two primary factors: 1) the need to document new protocols that Microsoft identified as part of an internal audit, and 2) a conclusion by Microsoft that overall quality of the documentation could be improved by providing more comprehensive and detailed descriptions for a certain number of existing protocols."

On June 19, 2007 work is continuing.  The TC decides it needs to hire some consultants for auditing Microsoft's identification of applicable protocols, following the discovery of some omitted ones.  The plaintiffs repeat, at each status report since the rewrite started, that they will not be able to determine that the rewritten documents are acceptable until the full set is available.   [Actual take-up in competing use appears to remain a shadow over the effort.]

According to the August 31, 2007 interim status, "the technical documentation project has proceeded according to schedule and Plaintiffs are encouraged by the quality of the new documents."  The TC noticed that a number of protocol elements were removed from the new documents.  The TC had expected that they would have been consulted before that was done.  Microsoft agrees to locate all removals and review them with the TC.  The online build of Milestone 5 is scheduled for September 28, 2007 [on schedule].  "Microsoft has committed to producing, at the same time, a final set of overview documents that explain how all of the protocols work together. As these documents are essential to ensure that licensees can make full use of the documentation to effectively implement all of the communications protocols, the TC will be reviewing them closely when they are produced."  The Microsoft staffing has grown to 630.

By the February 29, 2008 status, additional protocols are being documented to cover an update to Windows Server 2008 (the "Longhorn" server) and other documents are to be updated by March 14, 2008.  The protocol documents are now provided as part of Microsoft's Open Protocol Specifications under the Interoperability Principles.

"Plaintiffs are satisfied that Microsoft has maintained the overall quality of these documents through the final milestone. Microsoft will continue to improve the documents over time, based on feedback from the TC's implementation and validation projects and from Microsoft's own test suite project. This process is proceeding without major problems and is important in ensuring the overall quality of the documentation."

At this point there is disagreement on the depth and content needed in the overview documents.  The Plaintiffs and the TC assert that the quality of the overviews is critical and the scenarios need to be expanded along with other improvements.  A template and revised contents are being negotiated with Microsoft.   The Microsoft staffing has grown to 650.

2. The Current Situation

It is important to appreciate that major, extensive measures were required for compliance with the final judgment and the consent decree.  In this broader context, the development of documentation and licensing of protocols were defined in but a few paragraphs of the final judgment.

Although I have mainly traced the progression of the protocol documentation effort, its growing significance is a consequence of all of the other actions having been successfully carried out, with their ongoing review and confirmation taking on a routine quality.  There are still complaints that end up needing to be resolved and there are also many technical documentation issues being tracked.  This should be understood in the same way as bugs are identified and tracked in software:  there is no end to it, and some issues seem to persist far longer than others.  Nevertheless, a systematic process for identifying issues, agreeing on resolution, and revising the documentation is in place.

According to the plaintiffs in the latest, June 17, 2008, Joint Status Report on Microsoft's Compliance with the Final Judgment, an interim report,

"Plaintiffs' work ... and the Microsoft Communications Protocol Program ("MCPP") continues to center on efforts to improve the technical documentation provided to licensees. In particular, Plaintiffs, in conjunction with the Technical Committee ("TC") and Craig Hunt, the California Group's technical expert, are reviewing the results of Microsoft's project to rewrite the technical documentation, described in detail in previous status reports, and are providing feedback to Microsoft on what additional work is still needed.

"Since the prior Joint Status Report, Microsoft has completed producing all of the documents in the Milestone schedule, including the last group of documents that were added to cover an update to the Windows Server 2008 ("Longhorn") product. Microsoft continues to address issues in the documents that have been identified by the TC and by Microsoft itself; this work will continue over time in order to ensure the overall quality of the documentation."

The plaintiffs identify three areas of current concern:

1. "Microsoft removed a number of protocol elements that were included in previous versions of the documentation. When this same issue arose last year, Microsoft and the TC discussed that Microsoft would not remove protocol elements from the documentation without first discussing it with the TC in order to ensure that there was no substantive disagreement. ... It is important for the stability of the documentation that the TC review the proposed deletions before they occur, as Microsoft and the TC previously agreed."  [The original discrepancies and remedy were reported in the August 31, 2007, interim status.]
     
2. "TC has suggested to Microsoft that it would be extremely beneficial to the TC and licensees to create a mechanism for detailing changes between versions of the documentation. Currently, it is difficult to tell exactly what has changed when Microsoft releases a new version of the documentation. This slows down the TC in its work by making it difficult to evaluate revisions to the documentation and causes issues such as the one discussed in the previous paragraph, where it is difficult for the TC (and Microsoft itself) to determine whether protocol elements have been removed from the documentation. Licensees have also informed the TC that the absence of version-to-version change information complicates product development. Microsoft was receptive to the TC's suggestion and will work with the TC to develop an effective mechanism to track changes to the documentation."
    
3. Document revisions were moved to a quarterly release cycle.  This is found to be too long and the parties are working to provide revision updates more frequently.

These seem to be natural occurrences as part of growing experience.  The "regression" in regard to removal of protocol elements from the documents, and difficulty of identifying changes, is an important area for process improvement and better accountability.   In the context of the overall progression from the 5,000 pages of documentation provided in 2002, I see this as a sign of maturation of an ongoing, iterative process for producing something that has no ideal measure of perfection.  The practical measure is whether or not licensees and others are able to use the documentation successfully.  This is also a matter for debate, with Microsoft agreeing to produce more while asserting that the available material is sufficient.  This depends, I suppose, on the determination of licensees.  The greatest practical concern appears to be the desire for determined licensees to appear on the scene and exploration of how that can be encouraged.

In this regard, the greatest outstanding technical-documentation activity is with regard to the additional overview documents which were first introduced in September, 2007.  Following the concerns expressed in the February, 2008, status report, the plaintiffs report the planned resolution:

"Microsoft agreed to create a set of additional "system" documents which would provide more detailed information on the interaction between the protocols in a number of complex scenarios. At the end of March, Microsoft provided the TC with three pilot system documents to evaluate Microsoft's proposed template for the new system documents. The TC recently gave Microsoft feedback on the pilot documents by identifying a number of technical documentation issues; as a general matter, the TC was concerned with the overall quality of the pilot documents.  ... The TC and Microsoft will discuss over the next few weeks what ... steps should be taken to ensure that subsequent documents meet everyone's expectations in terms of quality.

"Microsoft has developed a list of nineteen system documents it plans to create and developed a rough, high-level schedule for producing these documents. As Microsoft describes in its section of this report, Microsoft plans to publish drafts of all nineteen documents by the end of March 2009 and to publish the final version of all system documents by the end of June 2009. Once Microsoft and the TC finalize the template (or templates) for the system documents, Microsoft will develop a more detailed schedule with a number of identifiable deliverables over time. As with the earlier phases of the reset project, establishing individual milestones for particular groups of system documents will allow Plaintiffs and the TC to assess the quality of the newly-created documents in a more orderly way, to provide Microsoft with timely feedback, and to monitor Microsoft's progress in meeting its schedule commitments. Plaintiffs and Microsoft will provide the Court with this detailed plan when it is available. As with the reset project itself, experience in preparing the system documents over time may result in changes to the current list of nineteen documents such as adding additional documents, combining documents, or shifting subject matter between documents."

It needs to be understood that this is new, additional work, that the need for it was identified by Microsoft in 2007, and that the TC sees its quality as being critical.  The TC also expects to see issues dealt with here that Microsoft had earlier declared would best be handled in what were then called overview (now "system") documents.  In that context, the original rewrite is considered to be complete and now in what I would call continuation and maintenance status.  It would not be unusual if the creation of the system documents led to some revision back into the protocol documents.

For its part, Microsoft reports that, as of June 1, there have been 146,000 downloads of the on-line, public documents.  Microsoft staff for development of the documentation and testing of the protocols is now at 750.

Finally, Microsoft's tracking of Technical Documentation Issues (TDIs) is reported on a per-period basis in the status reports.  In reviewing these numbers, it is important to notice that previously-closed TDIs are not accumulated.  It would be very useful to review all of those reports and see how this works as a progressive activity.  Although new TDIs are always coming in (including ones identified by Microsoft itself and by Microsoft in addressing queries from licensees), it is important to understand that this is very much like a bug tracking history.  Showing only per-period activity tends to remove important perspective on how well this is working as a progression over time.  I am curious to see if the increasing availability and visibility of the documents is also resulting in an increase in identification of TDIs.  I'm not ready to fire up Excel just yet, though.

3. Public Perceptions and Debate

3.1 My Appraisal

When I first saw the popularly-cited June 21 commentary by Matt Assay, I had not reviewed anything but the current, June 17, interim status.  That was enough for me to assert the following in a comment that same day:

This is an iterative process, including review for acceptability, requests for changes, and tightening of the process. ...

One problem with specs developed (often after the fact) by the implementers is that there is a great deal of tacit understanding that can only be caught by outside parties.

My take is that this is a mammoth undertaking, it takes great effort to shift to an interoperability-focused approach, and this is a journey, not an end point.  There may never be a time when there is a nice bow tied around everything.

What I find encouraging is that all parties seem to acknowledge the progress that is made and how course-correction is being put in at each iteration.

It is magical [thinking] to expect that this could be any different. Go look for specifications anywhere in the industry that satisfy the implicit assumption ... that there is some perfect state available. The stable ones that I know of (TCP/IP, say) all had birth and growing pains before settling down. It is natural to expect, even for Microsoft protocols that are a bit long in the tooth (but still evolving).

I should add that attempting to develop comprehensive specifications without testing by outsiders is a guarantee of wasted work.  The risk is over-explaining something that is obvious and/or irrelevant to others and overlooking those tacitly understood matters that outsiders will stub their toes on.  Finally, it is not possible to write perfect specifications, although they can be evolved to be good enough.  In this case, the "good enough" test is ensnarled with the Court's desire to see competition fostered, something that the documents can facilitate, but not cause.

Having gone deeper here, tracing through the entire history of this aspect of Microsoft compliance with the final judgment, it is clear to me how much this has been a learning experience, with several course corrections and expansions along the way. 

• The first documentation, available to licensees in 2002, consisted of 5,000 pages produced by a team of 10 technical writers working for 9 months.  This documentation was apparently written from scratch.  This is incredulous for some.  I find it unsurprising since interoperability with oneself can be accomplished by easier means, especially for process-adverse software developers (although such means do not scale and are perilous for preserving interoperability-over-time).
    
• Attempting to improve the original documentation by revision updates, initiated in 2004, broke down as unsustainable by 2006.  A parallel "reset," proposed by Microsoft, was initiated to completely rewrite the documentation and also add additional protocols and updates for newer Microsoft products (such as "Longhorn" server and updates to its release as Microsoft Server 2008).  Important efforts to provide a prototype implementation of the protocols and to introduce a protocol parser, already recognized in 2005, were continued as indispensable.
    
• The set of rewritten technical documents was completed at the end of  September 2007.  Those documents, with editorial updates, were made available as online, public downloads, in February, 2008.   The documents, now consisting of more than 41,000 pages, are now under maintenance.  These are the documents that current licenses apply to and that are the subject of discussion on on-line forums created for that purpose.
    
• In August 2007, the need to provide overview documents was also identified.   In February 2008, review of the overview documents led the TC to insist on greater quality and comprehensiveness in the overviews, leading to the current (June 2008) schedule for the expanded set of additional system documents to be completed by the end of June 2009. 
    
• [Updated 2008-06-30] Microsoft published, as promised for June, version 1.0 specifications replacing a variety of drafts first published in April 2008, involving Microsoft Office, Sharepoint Server, Exchange Server, Vista (with .NET Framework), and Windows Server 2008.  The drafts on the Microsoft Office binary formats were also updated.  This is evidence of the ongoing progressive refinement and maintenance of protocol specifications. This extends to availability of other specifications that are not available as published standards: the Office binary formats, XAML, and Visual Basic for Applications (VBA).

I wouldn't be surprised to see wider availability of tests, examples, and even tutorials before this work is considered complete.  The ability to build successful prototypes of the protocols using the specifications is a critical test.  An even more important test will be the introduction of substantial third-party products that rely on the protocols and are able to fully demonstrate achievement of interoperability.

Everything we have before us is evidence of laborious progress toward that achievement.  The glass is more than half full.

3.2 The Eternal Spotlessness of Lazy Minds

It is amazing to see the ways that the latest interim report is used as a launching pad for un-researched criticisms and complaints that have no foundation in reality.   The progression of exaggeration and taking leave from the facts is quite impressive.  I recount this particular drama to show how much even the simplest fact checking is apparently considered irrelevant to reporting on this effort and its status. 

It is indeed fortunate that the source documents produced by the U.S. Department of Justice are online for all to see and verify.  They are actually quite readable by non-lawyers, even the ones at Groklaw.

3.2.1 More-or-Less Balanced.  There are relatively straightforward accounts of the June 17 interim status, with some degree of spin in the headlines, selection of emphasis, and presumed causality.  Ars Technica led off with Jacqui Cheng's DoJ: Room for Improvement on Microsoft Antitrust Compliance, an advance over Jeremy Reimer's earlier US DOJ: Microsoft Dragging Feed on Documentation.   InternetNews.com carried the Stuart J. Johnson report, DOJ Says Microsoft Cooperating but Slow, including an unsubstantiated (and already repudiated) claim of investigations in China.  Some of these accounts seem to have the dates of various events (such as the final judgment) seriously muddled.  There is also some confusion over the process of the European Commission versus those in the United States.  [I have focused on the US-only aspects just for clarity of the timeline and the progressive expansion of the documentation activity.]  The most balanced early account is the straightforward reporting in Dawn Kawamoto's CNet News.com blog entry, Microsoft, DOJ Issue Status Report on Interoperability Compliance.
   [update 2008-06-30] With the announcement of updated documents today, delivered as promised, there is improving balance in Ars Technica Jacqui Cheng's We love interoperability: 50K-page Microsoft document dump (even though 50k is the running total, not the total delivered as new today).  I saw 2 Twitter tweets on this one.  Marshall Kirkpatrick reported Microsoft Releases Interop Docs: Is This What Data Portability Looks Like? on ReadWriteWeb.  This is a speculative piece using the announcement to leap into a discussion of Bill Gates' absence and how this might be to Microsoft's advantage., earning 9 tweets.  Elizabeth Montalbano's piece in InfoWorld, OOXML projects bolster Microsoft's interoperability efforts (which has only tangential relevance to OOXML) provides accurate coverage with some context along with speculation about what provoked the Interoperability Principles in February 2008 (good for one tweet).  Ina Fried of CNet News.com has a simple and direct Microsoft tries to live up to interop pledge (earning 7 tweets).  What's striking about this event is the greater balance and the number of Twitter tweets from various sources that announced the different articles.

3.2.2 The great Leap Out of Compliance.  When the Groklaw reporting on the June 17 interim status is cited as more comprehensive than the status report itself, it is time to wonder about veracity.  You'll notice that the Groklaw analysis, based on the same progression analyzed in section 1.4, here, completely overlooks that the 19 system documents reported in June are new work in addition to the 41,000 pages of technical documentation already delivered.  The system documents replace a smaller selection of overview documents that were produced for the first time in September, 2007. 
   This oversight is apparently seized on by Matt Assay in his June 21 CNet News.com article, Microsoft still not in compliance with DOJ interoperability order.  This is where the glass is taken from half empty to having a hole in the bottom.  Both Assay and Groklaw have the entire timeline of Microsoft's compliance efforts screwed up.  It is apparently a well-guarded secret that there is substantial documentation and related activity and you can find it online. 
   By June 23, the message is headlined as Microsoft Deleted Windows Interoperability Documents, Feds Say over Paul McDougall's InformationWeek article.  In the body of the article, the "so-called Technical Committee" is quoted accurately and then interpreted incorrectly.  I love it that Microsoft is said to have been "blasted" over the change in its publication release schedule when the biggest worry of all is the production of the system documents, not even mentioned in this breathless account.  Even so, most of the observations here are accurate.  The headline is awful, and suggesting that a pact has been broken is also a little strong.  The headline was all that the Microsoft Subnet blog required in its NetworkWorld version, Microsoft Removed Interoperability Documents, Feds Accuse.  This article, fixated on the incorrect statement in InformationWeek, reports on only the concern for removed protocol elements (not documents) and goes off on evidence for "more guile on the part of Microsoft."

3.2.3 Here Comes the Judge.  On Tuesday, June 24, the Federal Judge overseeing the Microsoft final judgment and consent decree held a meeting to review the June 17 interim status.  Ina Fried provides a balanced report in her June 24 CNet News.com article, Judge presses for more from Microsoft.  With all of the background here, it is straightforward to tie the reported remarks to the interim status and the history leading up to the system ("overview") documents that are under development.  It is not clear, here, whether on-platform integration is also meant (requiring more documentation than that already covered by published APIs), or whether attention remains strictly on the communication protocols that work between services.  This could be a confusion on the part of Judge Colleen Kollar-Kotelly or just in the coverage of the meeting.  I expect it will be resolved over time as the system-document work proceeds.

3.2.4 The Empty Glass.  Having not caught on to the fact that Microsoft's 19 system documents are new work that was found necessary beyond the current 41,000 pages of protocol technical documents, Matt Assay continues the great leap with his June 25 CNet News.com article, Microsoft promises to deliver interoperability documents by March 2009.  The Assay perspective is that no documents have been released and Microsoft is withholding material that it must have available internally.  The offered example seems to confuse API documentation (which is all fully available already) and the system documents that apply to the licensed communication protocols.  It appears that Assay has not noticed that the June 2009 documents, with drafts all completed in March 2009,  are the recently-defined additional ones. 

 
Comments:

 
Dennis,

Outstanding post. I had no knowledge about this, other than the very barebones facts.

This is an excellent summary indeed.

It's the same old, same old we saw in the Open XML bunfight.

It looks like Microsoft are making as much of an effort as anyone might be expected to do under the circumstances.

It must get to something when you essentially say "what do you want, blood? Have the source code, we're past caring"

I can see the next scoop from these ill-informed characters

"Nobel peace prize winner Mandela revealed as convicted terrorist - raised funds for paramilitary operations"

The National Enquirer beckons...

Gareth

# posted by  Gareth: 27 June, 2008 08:52

 

Post a Comment

Transparency Causes Performance?

[update 2008-06-18T15:22Z There are an unusual number of broken phrases and mangled sentences, even for me, and I must repair them.  This reflects the haste with which I completed this post.]

Some Visible Goodness of Transparency

Michael Krigsman, of ZDNet IT Project Failures, recently posted "Miracles Happen: A Transparent Government Dashboard."  Since this is my home State, I am intrigued by the transparent operation of the Washington Transportation Improvement Board.  The clearly self-promoting overview also hints at the apparent connection between going public and making measurable performance visible and understandable.

This has me wonder about the extent to which transparency causes performance.  I suspect there is some dynamic between willingness to be transparent and to perform and having the incentive that being transparent provides to performance.  My hunch is that the transparency has a positive impact provided that the there is a relentless commitment to not allowing the activity to retreat into darkness.  It appears, in the Washington TIB case, that there is a clear quality-of-results improvement and along with a cycle of increasing trustworthiness that arises as well. 

The application of dashboards to support transparency is showing remarkable results with regard to public works, especially road projects (funded by this state's 3% hit on gasoline sales).  This appears to work very well with regard to governance but there are applications in other areas, as reflected in other uses of graphics for communication on matters where public policies and open government are factors.  Although the Washington TIB effort is the most visible, the State of Washington Governor is requiring all other executive agencies to also provide this form of public accountability.  The sessions of the executive in which these initiatives are analyzed and feedback gathered are open to the public and the press as well.

Although this visibility is on management and governance, I think it also demonstrates that public works failures are generally not engineering ones.  The ones that are (the bridge or aircraft falls down) are recognized as such.  And it is the transparency and accountability of engineering conduct that allows the failure to be understood and avoided in the future. 

Helping Each Other Stay Visible

On a related topic, Jeff Atwood has posted "Don't Go Dark."  I find this similar to the transparency situation in that going dark signals some deviation of attention, performance, or focus that is ultimately destructive.  (Meanwhile, I have thoroughly gone dark on two of my public projects and must make repairs.)  What is valuable in the case that Atwood features is the introduction of a team practice that does not allow a team member to go dark.  (This is also related to flipping the bozo bit rather than working through the human dynamics to empower team-mates.)  Atwood suspects that the problem is not as much about perfectionism as it is about fear of embarrassment.  This would seem to be the behavior in many public agencies, including avoidance of criticism and being second-guessed.

Atwood points out that going dark is extremely easy to do on open-source projects, and it can obviously be a major stumbling block for those of us conducting solo nano-development operations.  It seems that what calls us forth the best is having someone care how we are doing, and caring that someone cares.  Hmm, so we can empower trustworthiness?  That's an interesting thought.  I wonder what form empowering actions might take.

And Visible Interoperability?

My attention is on interoperability these days.  It is natural for me to wonder how transparency fits in the creation of interoperability arrangements and the development of standards that support interoperability.  I suspect that development of open, public standards could benefit from earlier transparency and public review.  We now have technology that makes wide discussion and visible tracking not so difficult to accomplish.

In discussing this just now with my colleague, Bill Anderson, Bill makes an important point about measurability.  It might be important to have explicit measures and to account for them publicly.  I think that is the case, at least in terms of measuring how well one conforms to a standard and also how well a product achieves or preserves or moves toward some particular level of interoperability.  It would be great to see concrete measures on these qualities and have transparency on their achievement and confirmation.

I suppose one could even have interoperability dashboards.  The Government Management, Accountability, and Performance (GMAP) dashboards all work because there are measures.

Dreaming in Code: Going Native by the Bay?

One of the guilty pleasures of picking up Scott Rosenberg's Dreaming in Code is knowing that it mentions people that I have met, others I have heard of, and more that I could easily have bumped into unwittingly on San Francisco's Howard Street.  Although I had an unread hard-cover edition of the book, I was eager to have the paperback edition with its brief updating postscript and to settle in for a serious reading.  I've completed that, found an interesting author weblog, and noticed some unexpected side connections.

Now that my copy of Dreaming is edge-laced with little colored stickies carrying brief notes, arrows, and exclamation marks, my challenge is to organize what I sense in the work. 

One of the most infuriating aspects of the book is that it doesn't provide an answer.  I know that it would be strange if it did, because we can't know what would have made the Chandler project proceed more successfully, although I bet there are far too many groundless pet theories.   I found that I had to constantly give up trying to "fix" the project in irresistible Monday morning quarterback water-cooler style.  All through the course of the narrative, I would silently scream out something I saw the team miss, only to have it addressed or dismissed in a later passage.  This had me be very careful about what I think I know and also what I don't know about the reality for the Chandler team.  That's a good thing.

The other concern I have is the dismissiveness I see in Dreaming's treatment of software engineering.  I think the genuine progress in bringing discipline to software development is over-looked, with attention on mostly-old failures and misgivings over what "discipline" involves.  Evolving successful practice is discounted and I don't recall any report of successful cases at all.  I will dig deeper in a closer look.

Meanwhile, I wonder how much the author went native, partaking of the Silicon Valley apologetic around why software engineering is no good for our creative and innovative spirit and the need to survive in Internet time.  I find the contrast with the current Bay Bridge fiasco inapt, since the lessons to be found there are not about civil-engineering practice at all.  On the other hand, I think there might be some common lesson with the desire to "make history" with Chandler.

I fear Dreaming's characterization of software engineering is infected by the attitudes of those who claim software engineering is inapplicable or passé, probably never having practiced it successfully, meanwhile having to re-invent it, usually badly, never in the name of software engineering,  as an undertaking crashes into one wall and then the next and then the next beyond that.

Dreaming is valuable for the tension that it reveals in the struggles that projects can undergo, the seemingly chaotic and random progression that can happen in search of a conception to be wrestled into working, usable software.  I will continue to mine in the book for clues to the misapprehensions and skepticism that I see, perhaps reflecting my own more than the author's.

There is a certain literary carelessness that may be missing the larger point in some cases.  For example, Rosenberg's final chapter makes an interesting point about Frederick Brooks saying "the hard thing about building software is deciding what to say, not saying it [1: p.348]."  Unfortunately, Brooks is here talking about how speech recognition will provide at-best marginal gains in programming practice, assuming there is any value at all in speaking to a programming tool rather than writing it down [2: pp. 190-191].  How Brooks states his key message is this way:

"I believe the hard part of building software to be the specification, design, and testing of this conceptual construct [the abstract software entity], not the labor of representing it and testing the fidelity of the representation [2: p.182, emphasis in the original]."

Brooks wants us to move our attention from the accidentals (including whether we program by speaking or writing) and confront the essentials:

"We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems [2: p.182]."

Nonetheless, Rosenberg makes an interesting point of his own based on the decontextualized Brooks quotation.  It is in the deciding what to build, and how there must be far more consideration for the situation of the software as an instrument of human purpose and the difficulties that imposes.  I think Brooks would concur.

The other problem is how to actually deliver software so people can find it useful, if it is, and so the process can be corrected or abandoned if it is not.  This is indeed not how we would like major bridges to be built. but we should not confuse engineering principles with the differences that apply in different engineering situations.  We must be careful to separate the different subject matters and the context of their work from the common principles shared among the recognized engineering disciplines.  The details will differ, many of the principles do not.

Microsoft, Interoperability, and Open Source

I was startled to find an important interview on Microsoft's relationship with open-source development on Sam Dean's OSTATIC blog a few minutes ago.

Here are the four questions that Dean reports from his interview with three Microsoft representatives involved with open source at Microsoft:

1. Microsoft has, in the past, employed key open source development concepts such as modular architectures in its own products. Do you foresee more of this, including developing directly on top of existing open source platforms?
      
2. What do you think is missing in the open source community as a whole? Better marketing for commercial efforts? Better compatibility?
     
3. Does Microsoft's recently announced Live Mesh platform have implications that the open source community ought to know about?
     
4. What goals do you have for Microsoft's interoperability alliance with Novell, and what's behind the goal of converting Linux users in the Chinese market to SUSE Linux Enterprise?

I'm not going to attempt to summarize the remarkable responses to this fascinating choice of questions.  I recommend the article.

Oh, and the comments there seem to be starting off on a predictable footing.

Reality Is the Model

[cross-posted from Numbering Peano [link corrected 2008-05-2930T01:05Z].  This is at a level of abstract speculation that is more appropriate there than here.  However, I would like a broader audience, and reactions, to what strikes me as having practical importance in how we develop successful computer-based systems.]

During my regular Tuesday buddy call with colleague Bill Anderson, it suddenly occurred to me that I could account for reductionism, an error that scientists and others (software technologists and their masters, for example) make.  It is all captured in the following statement:

 Theories don't model reality; reality is the model.

I don't recall what prompted my exclamation on the subject during the call, unless it was something about how objectionable "code is the model," "code rules," and other developer slogans are, where the implementation of something becomes the specification, denying us access to any useful answer to the question "implementation of what?"

Now, it is not a new thing for Bill and I to be discussing these issues, including this view of the role of theory.   What hadn't landed so sharply was how viewing theories as models for reality is the very pitfall that engenders reductionism.

There's much more careful development required as part of arguing for the usefulness of "reality is the model."   I have been looking at that in a setting where I am conducting a theory-driven implementation of some software in the Miser Project.  Bill and I discuss this even more where it matters a lot to information technology, in contrasting What Computers Know with what Programmers Know to Do and how there is an essential gap between how computer systems are built, the requirements that those systems are meant to satisfy, and the world of opportunity in which those systems are instruments of human purpose.

For now, I want to look at the statement in the context of how we appear to arrive at theories and then apply them as given.

A word of warning: the value of "reality is the model" is not that it is "true."  The value to be found is in having a more useful and powerful way of looking at what we do with theories in contrast with the limitations of imagining our theories to be modeling reality.

Where Theories Come From

There seems little doubt that theories started out as explanations of the regularity in our experience of reality, of the world.  Some of these theories were, and still are, very pre-scientific (as theories about theorizing might be as well, and that won't stop me).

At some point in the course of the scientific revolution, say around 1600, typified by the work of Frances Bacon, there was an important move to development of scientific theories via inductive generalization from observations of nature, not deduction from some principles of cause.  The reliance on experimental confirmation and empirical observation became important.   A consistent case of contradictory results could show where the theory is inapplicable or even completely incorrect.  One risk is that expression of a generalized (abstracted) theory might be taken as an explanation of the nature of nature as in "objects at rest tend to remain at rest." 

Emergence of mathematical sciences, illustrated in the achievements of Isaac Newton, had a profound impact.  It permitted the deduction of consequences by calculation or proof, and it permitted the experimental confirmation of those deductions by natural experiments.  Notice, however, that the deduction occurs inside the theory, as it were, and the correspondence of the conclusion with reality is an empirical matter.

Theories on Their Own

The mathematical formulation of important theories, and the computational applications of those theories, are removed from reality.  Once we are operating in the formal, mathematical theory of a science, there is no reality there.  The connection to the reality is accomplished by our interpretation of the mathematical theory as being about reality.  Being about something, especially reality, is not a feature of mathematical systems.  Being about something is how we interpret results in the mathematical formulation as applying to the world in accord with a scientific thesis.  In other words, the scientific thesis part is not expressed in the mathematical formulation.  That is what we add ourselves (even though it is what led us to the formulation and why it might be of any value to us).   Some of these interpretations have been so reliable and so useful, we tend to speak of the expressions of the theories as laws (E = mc² being a popular one, force being proportional to rate of change of momentum being less familiar, although we experience its confirmation every day). 

There is a combination of deductive process (predicting via calculation, say) and inductive formulation in this approach.  We might say that (empirical) experience has shown that the interpreted deductions are reliable and that the theory is a good one in that sense.

The pitfall is to think of the theory as the truth, as somehow explaining how it is that the interpretation of findings in the theory align.  Perhaps the most current conceit of this nature has to do with confusion of what nature does as computation because computational processes have some similar characteristics.

Interpreting Theories and the Reductionism Pitfall

There is an area of mathematics called "model theory" or what, here, we might call the model-theoretic view of mathematically-expressed theories. 

In model theory, the idea is that a mathematical theory, expressed in a formal, logical way, is given an interpretation by identifying its mathematical elements with those in some other system (usually some other kind of mathematical one).  If the interpretation is such that deductions in the first theory have results that are true in the interpretation, we say that the interpretation is valid, and that the interpretation is a model of the theory.  The model satisfies the theory.  I am omitting many technicalities (and probably abusing model theory) in order to appropriate the basic idea for application to interpretations in the world in mathematical sciences.

An important feature of this view is that the theory need not account for everything in the model.  For the model to be a model everything that is true of the theory is true in the interpretation, but the model is not otherwise constrained.  The interpretation is only for that aspect of the model that corresponds to the theory.  There may many other features and aspects to the model that are simply not captured by the interpretation (and hence the theory).   Under the particular interpretation, at least, however valid (in either a mathematical or an empirical sense, as the case might be), the theory has nothing to offer about those other matters.  In particular, we are free from concluding that the theory explains the model or dictates its "working."  We are also free, in the case of the world and many mathematical and logical theories, of having quite different interpretations in reality for models of the same theory.  (Interpreting objects and phenomena as numbers is something we are able to do in innumerable ways.  I had to say that.)

The reductionist pitfall is treating the theory as the model (and therefore comprehensive), and claiming the theory to be "about" the world.  In that case, there is no way to countenance there being anything else about the world and even the obvious becomes inaccessible.  There's some other kind of pitfall in faulting a theory for not embracing all of reality in its interpretations, but I am less concerned about that, although "reality is the model" avoids that too.

Computational Manifestations of Theories

This apparently-backward way of looking at theories is about the application of theories in ways that are useful in approaching reality.  The perspective is also contrary to using computation as embodiments of theories and seeing them as somehow modeling the world.  Theories may have computational models (as interpretations).  This doesn't make the computation model a model of the world any more than the theory is, in this view.  I say that there is a computation model of the theory, and there may be an intended interpretation in the world that is a model, but that does not make the computational model a model of the world any more than the theory is.

I find this a very fruitful way to look at a variety of aspects of information technology as it is developed and used.  My continuing duty is to articulate this value in less-abstract and directly valuable terms.  One curiosity is how this view can still allow for the notion that the act of programming a computer is a case of theory building.

Trust but Demonstrate

[update 2008-05-25T15:36Z: Added a faith-based illustration and clarified that the stated insight from Solomon and Flores is not a quotation.]

Exploring Trust

I have an interest in trustworthiness of open-system software.  Open-system software is the kind of software that can be combined/connected with other components to form a functioning, integrated probably-distributed whole.  Open-system software can be open-source software.  Open-source software is not necessarily open-system software.

My interest in this motivated the TROST project: Templates for Raising Open-System Trustworthiness.  I didn't work this around to successful completion of a completed M.Sc Project Dissertation.  I am still working on the topic and I am constantly learning more about the subject.

When I described the project in March, 2005, I said this:

"Trustworthiness?  Well, that should be easy.  We all know trustworthiness when we see it, right?  Maybe not.  Starting out, I am looking at trustworthiness in terms of human arrangements for mitigation of the risks of everyday and not-so-everyday life.  There is, most of all, the risk of dealing with each other, especially at a distance.  I foresee a mapping into trustworthiness projected onto artifacts.  I am not willing, at this point, to take my eye off of the ultimately human and social nature of trust and trustworthiness."

My sense of the social nature of trustworthiness was expressed in these morsels (from 2004-12-20):

"Although there are technical arrangements that can be employed as instruments for demonstration of trustworthiness, everything I've encountered affirms (and perhaps accentuates) the centrality of mutual human trust in trustworthiness.  Establishment / preservation / restoration / improvement of software trustworthiness is the conversation I want to contribute to.  It always comes back to trusting in someone. ...

"Everything depends on trust.  It's one of the best gifts you can give someone.  [Quoting Julie Leung]

"Trust is a gift that we make to someone.  You can't demand someone's trust.  You can only treasure and protect it, once granted you.  It is a fragile thing, easily damaged and difficult to repair."

What Makes Artifacts Trustworthy?

My dissertation involved demonstration, with a small, open-source software project, of ways that a producer could demonstrate and an user/adopter could confirm the trustworthiness of delivered software.   This framing left me with a problem: it seems to remove all social arrangements from the picture.  So I had to resolve that in some way.

My first realization was that we often use "trustworthy" as "not requiring trust."  Yet in computer security and secure computing circles, trust is defined as always applying in situations where trust can be breached and we are trusting that it won't be.  The US National Security Agency (NSA) defines trusted components as ones that can break security.  Consider how this interpretation fits these expressions: "In God We Trust;" "In God We Trust, Others Pay Cash."  (There are other uses that don't fit so well, such as "Trust in God" and the assurance "Trust me."  These seem to have a different sense of trust.) 

If there is no possibility of breach, no trust is involved and, indeed, trust would be unnecessary.  Even so, I hear popular use of trustworthy and trustworthiness with regard to features that make trust unnecessary with regard to computer systems, communication protocols, and protection mechanisms.  The Trustworthy Computing Initiative smacks of this, as do efforts to enforce property rights by Digital Rights Management.  Also, these activities seem to involve mutual distrust.  Whatever is at play here, it does not seem to involve trust. 

I couldn't see how to break apart this situation and identify meaningful open-system trustworthiness in the way I'd intended.

Rather late in my researches, I encountered the 2001 book, Building Trust in Business, Politics, Relationships and Life, by Robert C. Solomon and Fernando Flores.  (My copy was purchased on June 24, 2005.)  I found a number of fertile topics in the book.  And I found a connection between artifacts (products, software, computers, etc.) and trustworthiness.  Here is what I extracted (and all misinterpretations are mine):

The trustworthiness that we place in our use of computer systems and software is tied to our recognizing, in our experience with the product, the care of the producer for those (namely, us) who adopt and use the product.

There it is.  We don't trust the product so much as we trust the producer to have been careful of us.  In particular, the greatest test of trust is when there are breakdowns with respect to the product.  How the producer then demonstrates care and provides remedy is critical in restoring and even strengthening our trust. 

After that, the TROST project was focused on ways that producers of open-system components can demonstrate care and create arrangements that build trustworthiness and act to restore it in the face of any breakdown.  The symbol of trust was formulated at that point.

What Makes Us Trustworthy?

There's a critical corollary to how trustworthiness shows up:

If the producer distrusts the adopters and users of its products, there is no room for the care that engenders trustworthiness.

We have ample evidence of the excesses we can justify when we claim the other party is untrustworthy.  Some of the most perfectly-maintained dysfunctional relationships are those in which each party considers themselves the victim of the other.  Look around.  It arises in international relations, within business firms, and in families.  Couple that with the common fear of being taken advantage of (as producer or as adopter or user), and you might wonder how we manage to cooperate in groups at all.

Here is what I see, extracted from my studies and analysis (largely based on Solomon and Flores, but all misinterpretations are mine):

1. To be trustworthy, one must first be willing to trust.  This is a position of vulnerability and discomfort.  It will take serious commitment to be willing to trust anyhow.
     
2. To be trustworthy, one must be careful to build a relationship of trust with the adopters and users of your products. 
     
3. The product and its support is designed to reflect and demonstrate that care.  It is evidence of trustworthiness.
     
4. Trustworthiness is tested not when everything works but when there is a breakdown in the product, the support, or the service.  The care provided here is where trustworthiness and a relationship of trust live or die.

Trust but Demonstrate

Ronald Reagan is known for his "trust but verify" statement.  That is certainly understandable, especially when there is a history of distrust.  But it is distrust-based and it bring with it the constant escalation of how the other must prove trustworthiness along with the tendency to do what we fear of the other as a defense pre-emptive self-defense.

I suggest "Trust but Demonstrate," even if it doesn't seem to make sense on the face of it.  It's about being willing to trust enough to demonstrate the care that being trustworthy requires.  It is the earnest offered into the building of trust.

Chatting with a Spacecraft

[update 2008-05-25T17:32Z: The landing itself will be at 16:38 PDT (2008-05-25T23:38Z) but because it takes a signal 15 minutes and 20 seconds to get here from Mars, we won't know if it succeeded until 16:53 (2008-05-25T23:53Z).  Thanks to the tweet just in from @MarsPhoenix.]

At 15:30 -0700 (that's 3:30pm PDT in North America or 2008-05-25T22:30Z globally) there will be "live" NASA coverage of the landing of Mars Phoenix on a North Polar plain of Mars.

This is a "hard landing" involving dramatic atmospheric entry and rocket-powered descent  to a frozen area expected to have water ice only inches below the surface.  The evidence for this, and guiding the choices, is the appearance of polygonal patterns in the surface.  The smoothness of the surface also influenced the choice.

How did I learn about this? Twitter.  It seems that @MarsPhoenix is tweeting the progress and as well as the excitement about a flaming entry and powered descent of this large lander (although I don't expect Twitter to be available at landing time, based on Twitter's overloading already at 07:30 -0700).  It is all accomplished by the lander.  The communication time lag (and, I suspect, interference during entry ionization) prevent any direct control.  It's all software and robotic machinery. 

I told Vicki I was tweeting a spacecraft and she asked if I needed my tin-foil antenna hat to do it.  This was particularly awkward when I claimed that Mars Phoenix answer my tweet, too.  (The twitter account is "manned" of course.)  It is a very interesting use of social networking, and drama, to bring attention to this exciting event.  It worked for me.  (For various reasons, including no newspapers or television in the household, NASA events are mainly below my threshold of attention, although I've followed the space program since the first tweeter, Sputnik, crossed the October skies in 1957.)

Vicki's next question, after we riffed on my being a tweeter, was who are the woofers?

OOXML: Excel2007 versus IS 29500? The Fun Begins

This is a hasty post.  I haven't done the research to determine whose bug this is about.  Added: I'm beginning to think it "bug" is too simple for this kind of discrepancy.

[update 2008-05-19T23:30Z: Rob Weir has been picking apart this situation, along with the benefit of having a proof copy of IS 29500.  His analysis is much deeper into the workings of Excel date-related functions and how DIS 29500final is mucked up with regard to the same functions.  His analysis is important, completely apart from his observations about the ISO and BRM processes.  My sense is that the bar has been set too low and sloppy for spreadsheet functions.  The bar must be raised and maybe the OpenFormula effort is a place to come together on that.  (My recommendation is that OpenFormula not attempt to match the Excel/IS 29500 flavors at all, avoiding even use of the same names, with rapprochement if and when IS 29500, or a sequel, are repaired.)

update 2008-05-19T22:56Z: On reflection, this is a point case of a very complex and too-subtle situation.  Here's a way to look at it apart from the details of the specific however-illuminating case:

1. There are spreadsheet functions that seem to have obvious behavior that, in practice, are non-obvious and not well-specified.
     
2. There's a terrific "me too" among spreadsheet implementation and naming of functions, although it is not clear that the implementations match and they are mostly (or more-so) under-specified.
     
3. The behavior of spreadsheet functions can change from one version of a product to the next.
     
4. Some spreadsheet functions relate to specific practices and disciplines (e.g., accounting and finance) that software developers should not be making up their own, independent definitions for.
     
5. Some of those practices might be ill-defined in their discipline of origin too.  Whether they are or not, it is not up to software developers to come up with unilateral repairs.
     
6. We're in a continuous learning and correction process when it comes to perfecting the definitions of spreadsheet functions (not to mention practically every human discipline that we attempt to computerize).
     
7. Change and correction is assured.  It takes great care and patience to work that out in a non-disruptive way in a world where digital artifacts are disseminated and preserved everywhere with no way to force migration.
     
8. The Microsoft Excel, ECMA-376, and IS 29500 (?) YEARFRAC functions provide exemplary demonstration of all of this.
     
9. We can't stand under-specified and deviating functions in an interoperable world.  We're just learning how to remedy the situation.  David Wheeler and the others working toward an OpenFormula specification are the pathfinders.

   I'd like to say much more about this.  It will have to be added to my already-mountainous backlog.]

David Wheeler, Chair of the OpenDocument TC's OpenFormula subcommittee, has noticed a breaking change between Excel 2007 and OOXML.

There's a problem, though:

1. Excel 2007 was shipped in 2007.  Office 2007 SP1 was shipped in December 2007.
     
2. Wheeler is comparing Excel behavior with "Office Open Extensible Mark-up Language (OOXML), final draft ISO/IEC 29500-1:2008(E) as of 2008-05-01" which I presume is DIS 29500final or the much-awaited proof copy of IS 29500.  This document did not exist before April, 2008, and reflects changes agreed in the DIS 29500 Ballot Resolution meeting.  There were a lot of changes around the handling of calendar dates in ECMA-376 (the original DIS 29500 basis).

To be fair, one should test Excel 2007 against the December 2006 ECMA-376 (part 4), the best specification that Excel 2007 files and functions could possibly be in conformance with. 

Unfortunately, all I can establish there is that there's a bug in ECMA-376, part 4, section 3.17.7.348 YEARFRAC, where an extraneous day-count-basis argument is listed but not used.  The function is seriously under-specified concerning the ranges and acceptable separations of parameters.  In addition, there is no identified source of authoritative definitions for the methods identified by the basis argument. 

I could find no ECMA-376 description of the basis rules to compare with the one (PDF file) Wheeler has found, but ECMA-376 has some non-normative examples that indirectly answer one of Wheeler's questions.  Excel 2007 produces the results shown in the ECMA-376 examples, but it is clear from Wheeler's better edge cases that, although the ECMA-376 examples are in accord with the IS 29500 definitions, Excel does not arrive at its results by the method defined in IS 29500.  So we appear to have a bug in Excel (that may have been there for some time), a bug in the definition added to IS 29500, or both.  [This affirms for me something that I've always felt: that the apparent lack of precision and rigor in the published definitions of Excel functions (and other people's too) is a terrible thing.  I have been grateful to the OOXML standardization effort for creating conditions where that has to be remedied.]

I'm a bit confused about the ISO/IEC 29500 document that Wheeler mentions.  First, I would like to know where it can be obtained and what its status is so I and others could check this and other matters of importance.  It may be that there is a defect in the editing of this document that should be prepared, although it doesn't sound like it.  Also, there is a serious domain-knowledge question (concerning financial practices and what the agreed definitions of those basis cases are, and there seem to be contradictory definitions around) that must be answered to figure out what the methods should be.  I understand Wheeler's haste, if there is meant to be a compatible YEARFRAC in OpenFormula.

Meanwhile, this adventure and others like it are going to provide some great examples of how breaking changes from one version of a standard to another are navigated by implementations.  Along with that, we get to see what can be responsibly done in changes from one version (standard or non-standard or out-and-out defect) of an implementation feature to another while still interoperating up-level and down-level with all of the unchanged versions out there.  It has long been impossible to throw a switch and suddenly have all programs and documents aligned with a particular version of a specification.  How standards are crafted to support this reality is important. 

As Wheeler observes in his detailed documentation (PDF file) of this problem, there are many lessons to be gained here.  Wheeler also provides further details (start with the README) on discovering what the Excel implementation is, when it changed, and what some think the correct answers are.

 
Comments:

 
You might also like (or not) to read Rob Weir's further analysis of David's findings...

# posted by  Anonymous: 19 May, 2008 15:38

 

 
Thanks. My feed reader had not picked up that post yet. I find it valuable and have added a link at the top of this post, along with some other ammendations of mine.

# posted by  orcmid: 19 May, 2008 16:41

 

Post a Comment

ODF1.2, My Movie Plot Defanged

I need to clean up some things about yesterday's post, "ODF 1.2, Hijacked by OO.o?" 

In that post, I made much over not knowing what ODF 1.2 is and what the changes are from earlier ODF specifications.  I found this disturbing when coupled with the support for ODF 1.2 advertised as part of OpenOffice.org 3.0 beta's public availability.

Thanks to a speedy comment by Rob Weir, I now know where there is a complete account of the work toward ODF 1.2, including the accepted proposals for that version, on an OpenDocument Technical Committee Wiki page.  This material is completely public.  It is also a great demonstration of the kind of open, transparent conduct that we need more of among standards-development activities.  I'm pleased to see this.

I have updated the original post.

I continue to harbor concerns about confusion around file-name extensions and that leading people to expect compatibility with OpenOffice.org or simply treating OO.o as the bona fide standard (implementation).  I think it matters, in this regard, how any (document-format) standards are crafted, although it is not entirely in the hands of standards-development organizations and their technical committees.

ODF 1.2, Hijacked by OO.o?

This is not a post that I wanted to write.  The situation has been nagging at me and I need to lay it to out to give myself some rest.  My nightmare is that the worst possible thing is happening to completely undermine the prospect for successful open document-format standards: the building of a favored implementation prior to the public availability of even a public draft specification.  No, I don't mean Microsoft Office, and I don't mean OOXML DIS 29500 final (or IS 29500).

1. Flash Back

Following the agreement on changes to ISO/IEC DIS 29500 (OOXML) at the Geneva Ballot Resolution Meeting, the ISO/IEC JTC1 SC34, meeting in Oslo on April 5-9, 2008, initiated a maintenance process for IS 29500 (the official form of the revised DIS 29500 documents).  To support its moving forward in that and related work, SC34 Resolution 8 from the meeting requests copies of DIS 29500 final, the revised material reflecting the BRM agreements:

"SC 34 requests the ITTF and the SC34 secretariat to distribute the already received final text of DIS 29500 to the SC 34 members in accordance with JTC 1 directives section 13.12 as soon as possible, but not later than May 1st 2008. Access to this document is important for the success of various ISO/IEC 29500 maintenance activities."

The following elements strike me as important:

• On April 9, 2008, the attending member of SC34 seemed to have information that the modifications to make DIS 29500 final had been made and DIS 29500 final was in the hands of ITTF and perhaps the SC34 secretariat.  Based on this, it is reasonable to surmise that the document is out of the hands of ECMA and any Microsoft contribution to the document-revision effort.
    
• It is now May 17, 2008, and there are no reports of DIS 29500 final being distributed to SC34 members or otherwise being made available. 
    
• If you go to the ISO catalog entry for IS 29500 (click "Standards under development"), you'll see that the new organization into four parts is listed but no files are available for download or purchase.  The project stage (40.99) reflects that DIS 29500 is approved.  There are other stages to have it appear in published form.

People are wondering when a final version will be available.  On May 16, Yoon-Kit Yong (no fan of OOXML) commented on a blog post that the SC34 Secretariat claims to have DIS 29500final and (as quoted by Yong):

"I was asked by ITTF not to distribute it to the SC 34 members since the availability of the slightly different version from the actually published version would be confusing.  

"ITTF informed me that the proof will be available in a few weeks and I am intending to post the proof (after confirmation by the project editor) on the SC 34 website as soon as it becomes available."

It would appear that the ITTF is marching ahead to produce the published IS 29500.  It may be a few weeks before someone manages to post the proof documents and start delighting in whatever defects are apparent.  Meanwhile, this modus operandi is providing lots of room for cynical speculation and apprehension.

2. Flash Forward

On May 4, Rob Weir commanded "Release the OOXML final DIS now!"  Waiving the JTC1 Directives in the air, Weir points out that the missing DIS 29500final is in violation of the procedures.  I don't know what is served by instructing the SC34 Secretariat in this manner.  I would think that National Body members of SC34 are the ones to act and to raise concerns about procedural issues with the SC34 Secretariat and IITF.

I'm also disappointed that the specification, wit