I had the opportunity last week to not only share a stage with Microsoft's Jason Matusow in Geneva, but also to enjoy dinner with him and some time to chat before that as well.  Jason is a good guy, and I enjoyed the opportunity to kick things around face to face that we've sometimes taken different positions on in our blogs.  Obviously, we have different opinions on the ODF/Open XML debate, but fewer than you might expect (and perhaps fewer than he expected). 

While we were exchanging views on open standards and open source with others at the conference, though, things were apparently falling apart in the ongoing negotiations between Microsoft and Adobe.  Frankly, although there may be more to the story that I don't know, it seems to me as if Adobe is in the wrong on this one.  Adobe wanted its Adobe Acrobat product to become the dominant product in the marketplace for saving documents in a locked format - the de facto standard for creating such documents.  In order to achieve that goal, it allowed aspects of its product to become the basis for what became an ISO/IEC adopted standard, which would involve providing licenses in a non-discriminatory fashion to whoever wanted one.  Once that happened, Adobe is under an obligation to make such a license available to everyone on substantially equivalent terms - which in this case would presumably be free, given that Apple and OpenOffice.org are bundling "save to PDF" capabilities in their offerings. 

What more could there be to the story?  One possibility is that the ISO/IEC PDF standard (what the standards world calls a "de jure" standard, or a standard "as law," because it has been adopted by a formal standards body) sits inside a larger "de facto" standard created by Adobe that the market likes.  Since only the elements that are within the ISO/IEC standard are subject to obligatory license, Adobe would be free to charge whatever it wants, and to whom, for the additional de facto elements.  Such "proprietary extensions," added by the dominant market player, are one way that a company that offers royalty-free technology for inclusion into a standard makes money.  In effect, the technology included in the de jure standard that is available under a free license is used to bait the hook for the royalty-bearing license required to implement the full de facto standard.  If this is the rest of the story, there is some irony in the fact that Microsoft has frequently been criticized for adding proprietary extensions to products it has built to a standard, thereby sometimes making them non-interoperable with other products built to the same standard.

Interestingly enough, this latest speed bump for Vista highlights a point that Jason and I had crossed blog swords over not long ago, which is my view of the importance of standards as a means of achieving interoperability over other means of achieving the same end.  Back on May 8, I posted an entry where I objected to the promotion of the idea by Microsoft of other techniques as a surrogate for, as compared to a supplement to, standards as a means to achieve and guarantee interoperability.  My starting point was a quote in an eWeek article to the following effect:

"You can achieve interoperability in a number of ways," said [Microsoft's] Robertson. Among them: joint collaboration agreements, technology licensing and interoperability pacts.

I had heard the same basic statement from another Microsoft representative, which troubled me, because while these other means can result in interoperability, they don't guarantee equality of opportunity and access the way that a standard does that has been adopted by a standards organization with an effective IPR policy - as has just been amply demonstrated by Adobe's apparently discriminatory withholding of a free PDF output license from Microsoft.

Jason is, of course right that the three other methods (besides standards) he outlined at his blog can produce interoperability.  Those methods, as described in his blog are in part as follows:

1) By Design: interop should be built into the products as a design feature. This is not a marekting ploy – it is a technical goal. Last I checked, you can connect Windows to dozens of other operating systems, tens of thousands of applications,… The point is – any of the major software vendors are building interop into their products – it is mandatory to be useful in customers’ heterogenous environments.

All of which, of course, is true.  But in order for this to work, it also requires the agreement of both sides to offer a license to the necessary proprietary information that is needed to reach that end.  If that license is withheld, then some players can achieve interoperability and others can’t.  And those that do receive a license, receive access to only so much of the interoperability keys as the IPR owner is willing to give them, and only when it chooses to give them.

2) Collaboration: this is the one that got Andy upset. Companies, at least those that stay in business, are responsive to their customers and partners. They are always seeking partnerships and/or structured relationships to improve their products’ opportunities in the market. It is not quite the nefarious spin that Andy puts on it in his blog. AOL, Yahoo, and MSN cusotmers were annoyed that there was not compatibility on IM. So the three companies came to agreement to make that work. Nokia wanted to put Microsoft’s ActiveSynch into Symbian to offer better mail solutions to their customer – so an agreement was made. Our customers also build J2 solutions and were quite pleased at the announced collaboration between JBOSS and Microsoft. All of these are examples of enhancing interop. None are nefarious. All are predicated on the desire to improve the useful life of commercial products…. 

The problem now, of course, is that Microsoft’s customers want Adobe PDF output capability, but won’t be able to have it natively in Vista, although Brian Jones’ log does indicate that Microsoft may make equivalent capability available as a free download. 

In fact, anyone watching the standards space as closely as Andy does should know that there are whole classes of “standards” that are formed based upon industry collaborations. Special Interest Groups frequently refer to their work-products as ‘standards.” Industry Consortia are arenas where commercial players with the ability to invest resources in the standards-setting process can come together to find consensus on technologies. Careful – they might be collaborating in those meetings. tsk tsk

This isn’t quite right.  A specification doesn’t become a standard until it is offered to, processed within a technical committee and adopted by a standards body, which receives the binding commitments of non-discriminatory licensing from the collaborating IPR owners.  This is what was done by Microsoft, IBM and BEA with the great majority of the standards that now enable Web Services, which were given in draft form by those companies and a variable group of collaborators to standards bodies like the W3C and OASIS.  The reason that those companies donated their work to these respected standards bodies, of course, was so that the companies they hoped would commit to the Web Services model would be more likely to do so if they did not have to rely on elective collaboration or IPR-owner licensing.  It’s also why Microsoft has made the same decision again, this time by making its open XML schema available to Ecma, and hoping that ISO/IEC will adopt Open XML as well.

3) Standards: Standards are descriptions of technologies constructed in environments that encourage participation and result in the opportunity for multiple, competing implementations. One of the less constructive arguments in the doc format debates of late has been the idea that there should only be one standard of doc format now that ODF has achieved ISO standardization. VHS/Beta, 802.11a/b/g, EISA/PCI, MPEG/H.264, USB/IEEE1394…there are many, many more. My point is that there should be competition in the market – and that advocating a decrease in choice seems counter productive. Market-based solutions will ultimately win out in these scenarios. Interoperability is improved by standardization, but not solved.

As a generality, I don’t actually disagree with Jason on this point.  There are times when competition among standards is constructive, and sometimes when the opposite can be true.  I’ve written pretty extensively on this topic, most recently in the March issue of the Consortium Standards Bulletin, which focused on Standards Wars.

I had an interesting conversation with the CTO of a very large broadcast network who informed me that he has approximately 20 different types of devices that support MPEG – yet no real interoperability between them due to the feature sets offered above and beyond the standard format. So there is an element of interop – but these device manufactures weren’t building it in by design (as specified above). hmmm.

The short answer is that different standards do different things, and at different levels of detail.  A conscious decision also needs to be made each time how much to standardize on, and how much to leave “unlocked” and thus available to innovation.  Microsoft seems to be solving the CTO’s problem, by the way, by creating an extremely detailed specification for Open XML.

4) Intellectual Property Licensing: this is the method that most of our detractors don’t like to hear us talk about. Yet the one that Bob Sutor should advocate the most heavily unless he wants to say that the $1B+ in revenues earned on patent licenses is somehow unfulfilling for him. But I digress – sorry. The fact is, by making patents available for licensing you are increasing the ability for others to utilize your technologies and that improves interop. Also, by licensing copyright (source code licensing) you can improve interop. Logo programs where trademarks are made available for use improve testing and use the marketing impact of the trademark as the carrot for interop work. All goodness in the end for the customer.

Supplemental licensing is also an important tool.  But again, if it’s at the election of the IPR owner , then it’s not as useful as a standard –  because the availability of the license, and the fairness of its terms, cannot be guaranteed.

So here’s my point in summary:  standards are not perfect, and they can’t do the whole job.  If they did, they’d be straitjackets.  As a result, each of those three other methods that Jason outlined can be a helpful adjunct to the foundation that is provided by standards.  Another way of looking at it is that the “must have” pieces must be covered by standards, to be sure that everyone has equal access to them.  All the rest is fair territory for those other three methods.  Sometimes, by the way, standards are extended or supplemented by additional standards, to lessen the need for these methods.

So where I come out is that if Microsoft’s message is that collaboration, design and licensing are necessary tools to complete the job of enabling interoperability, then Jason and I are in complete agreement.  The subtlety has to do with deciding which building blocks of interoperability should be described in standards, and which can properly be achieved through these other methods.

I would submit that if people have taken to calling something a “de facto standard” – as it appears more than just the ISO/IEC standardized features of  Adobe PDF may be – then that something is a poor choice to rely on receiving access to through elective licensing rather than as a result of a binding commitment to a standards body. 

As the events of last week seem to indicate.

For further blog entries on Open Source and Open Standards, click here

subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)