Standards Panel at OSBC

Back to blogging. Too easy to get wrapped up in work and home and not put in the time for the blog.

On Feb. 15 I spent an hour on a panel moderated by Andy Updegrove (Gesmer Updegrove LLP), and joined by Tim Bray (Sun), Bob Sutor (IBM), and Stephen Walli (Optaros). The topic of the panel was the relationship between open source and open standards.

Andy did a good job of setting the tone of the discussion by pointing out the fact that there is little direct commonality between open source and open standards. The amount of hyperbole on the subject is frequently not helpful in that OSS is a method for creating software and standards a process for defining specifications. Those specifications may be built as open source (ignore licensing for a moment) or under any number of other development models.

Clearly, the overlap comes in when considering licensing. There are established licensing practices in the standards world whose goal was to create an environment of "reasonable" terms that were "non-discriminatory." In other words, participants and implementers would feel safe to engage and thus the standards would meet their ultimate goal of adoption. The question that comes to the forefront is how do OSS licenses interact with the terms associated with standards licensing? 

There is no easy answer to this question, and not being a lawyer I will leave it alone for the time being. Suffice it to say that there are concerns with patents, sub-licensing of modifications, conformance and a range of other items. Yet, it is clear that standards have been implemented in OSS projects so no one is overly clear on how compatible or not the licenses are.

Back to the panel session: each panelist gave their two or three minute spiel and each was along expected lines of thought given the companies that the panelists represent. In many ways, the points of view expressed follow the business models of the various companies. I will blog further on this in the future.

One point that seems to have been a real theme during the conversation was around the idea of multiple implementations. Stephen called out the details of the discussion in his blog of the panel. Everyone on the panel but me (hmmm...familiar territory at an OSS panel) emphasized the fact that there are multiple implementations of ODF and only O12 from MS for Open XML File Format. In fact, this was echoed in Gavin Clark at the Register piece today in the Register. From Stephen's blog,

"… in his explanation I thought I heard [Jason] say that Microsoft is defining the new Microsoft Office standard indeed to encourage multiple implementations, AND to encourage developers to innovate around the Microsoft Office document formats. In the first case, it would be bad business to encourage multiple implementations of a product that is responsible for 50% of the revenue stream. In the latter case, it's just another vendor specification to benefit the vendor regardless of the standards imprimatur"

The work at ECMA on the Open XML File Format will hopefully result in an open standard enabling multiple implementations of the file format. This means that non MS-Office applications will be able to generate documents to the standard format, thus making those documents fully compatible with office. Additionally, those non-MS Office applications will be able to consume the Open XML File Format docs from MS Office for use. That is very different than this standard enabling an independent version of the MS Office product. 

The working group at ECMA working on the Open XML File Format is made up of customers, competitors, and partners of Microsoft. The rules of ECMA enable any organization (including IBM or OpenOffice.org) to participate in the process. Furthermore, the specification has already been altered based on suggestions from members of the working group. This suggests to me that there is strong interest in the future of this specification and that it is likely to be received well many customers and competitors alike. Thus, there are likely to be multiple implementations of the specification.

My best guess is that Microsoft will continue to be the only one building Microsoft Office.

 

 

.