Subject: Re: Applying TDD to Open Standards Requirements
From: Simon Phipps <webmink@sun.com>
Date: Tue, 05 Sep 2006 18:01:52 +0100


On Sep 5, 2006, at 17:36, Sanjiva Weerawarana wrote:

> On Mon, 2006-09-04 at 21:52 +0100, Simon Phipps wrote:
>>>>
>>>> I would like to see you both apologize so we can go back to  
>>>> defining
>>>>
>>>> an Open Standard!
>>>>
>>>> Ironic on how the conversation to standardize an Open Standard is
>>>> being conducted.
>>>
>>> +1
>>
>> +1.  I understand and agree with Sam's points about the importance of
>> the openness of the development and maintenance processes and have
>> spoken with many of you about it.
>
> I wonder whether we're all off the track a bit: the OSR is *not* about
> defining what an open standard is  at all. We don't care whether the
> standard is defined by a bona fide "standards organization" (whatever
> that means), by a single person or by a smokefilled room full of  
> friends
> and family of one company.

While I agree with you to a degree, I regard the transparency of the  
process by which a "standard" evolves as important.

> What matters is that if something is to be a
> bona fide open standard as far as open source is concerned, then it  
> must
> meet the OSR. What we're trying to agree on is the OSR, not what an  
> open
> standard is or the process for defining an open standard.

With respect, that's a circular argument. We are discussing the OSR  
and fitting it to a purpose, which is creating a list of requirements  
that identify which "standards" are "safe" for open source developers  
to implement. What I am asserting is that the "safety" of a standard  
includes its origin and its maintenance as well as the IPR  
provenance. I realise some members of the OSI's committee don't agree  
but I remain firm in the view that both are at least relevant to the  
issue.

> Before my head gets bitten off, I'd like to point out that there are
> successful "open standards" which have been defined by each of the  
> means
> listed above (and more) as well as there are plenty of unsuccessful
> "open standards" which have been defined similarly.

Indeed, some "standards" "succeed" in spite of how unsafe they are  
for developers!

If the decision-making process behind a "standard" is opaque then it  
is much harder for a programmer to understand how safe the "standard"  
is as a foundation for development. In just the same way as open  
source communities frown upon large contributions, "standards"  
presented finished on initiation and with an opaque history rely on  
high levels of expertise (or faith in the originator) to develop trust.

If a "standard" is not 'fixed' on completion, one can never be sure  
that an implementation is accurate. A final version against which to  
implement is essential if a developer is to be confident that  
interoperability is possible.

If the process by which the next version of a "standard" could arise  
is not clear, a developer can and should fear that an entity with  
market power could hijack the standard or sideline it.

> Our interest is not
> in identifying the winning combination of features to make something a
> standard, but rather in identifying what it must enable.

That's deliciously vague :-)  The OSD provided a means by which a  
developer could know that it was safe to create a derivative work  
from a body of source code without engaging a lawyer to analyse the  
license. It seems to me that the OSR should play the same role for  
standards, providing a developer with a basis to know that a  
particular standard is safe to implement without the need to engage a  
standards specialist.

>
> Is the contentious point between Sam & Russ the "No Secrets" criteria?
> If so Sam, can you offer a patch?

I've no idea if the views I have mentioned above resonate with Sam's,  
but I believe it's beyond a simple "patch" to the existing language  
as the OSR currently neglects the transparency of the evolution of  
the "standard".

S.