[odf-discuss] procedure at ISO Ballot Resolution Meeting
marbux
marbux at gmail.com
Tue Sep 11 23:20:23 EDT 2007
On 9/11/07, Ian Lynch <ian.lynch at zmsl.com> wrote:
>
>
>
> > I think it's going to be a purely political battle from here on in.
> > The only way I see for Microsoft to win now is through political
> > pressure to force NBs to withdraw their comments and change their
> > votes from No with comments to Yes without comments at the Ballot
> > Resolution meeting.
>
> I'm curious as to how you could credibly change your vote if there is no
> change in the technical specs? Surely that looks like you were
> incompetent in coming to the judgement in the first place. If several
> comments all highlighted the same issue and that was not changed it
> seems even more incredible. It seems rather more logical to change from
> yes or abstain to no because someone highlighted something you hadn't
> thought of. How can the issues disappear if there are no changes to the
> spec? Furthermore, surely the changes have to actually be made rather
> than just promised. How can a spec be ratified if the detail isn't there
> so presumably this is going to take time too.
If the issue were about logic or credibility, every NB wuld have voted no
without comments and saved the bother of the Ballot Resolution process.
There are technical issues involved, but the process actually employed to
resolve issues is political rather than technical from everything I can see,
boiling down to a contest for votes.
In most of the world, the process has no real government oversight --despite
the treaty requirement -- and is susceptible to the kind of stuffing of the
ballot box we have been watching. Most nations allow private standardization
bodies to form and submit positions on behalf of the government without any
government checks and balances, and membership in the NBs tends to be biased
by membership fees. In other words, software users' interests (market
requirements) are grossly under-represented in the over-all process. Indeed,
there is a widely held view that "market requirements" means vendors'
requirements, rather than users'. It's wrong as a matter of law, but that is
how the system is working right now. Custom rather than norms like
applicable law and procedural directives seems to dominate and the customs
are severely out of synch with the norms.
The only strong check on the process is the ability for a national
government to force issues in the WTO dispute resolution process. But for
the most part, the national governments are not even aware of what is being
done in their name by the NBs, which tend toward being extremely biased by
those with vested financial interests.
I've been thinking a lot about what might be done to reform the system, but
that's an essay I'll have to save for another day because of my work
schedule (I'm behind, up to my armpits.) I have no comprehensive solution,
although I'm leaning toward leaving the existing standardization process
behind and pushing for community-developed standards, with developers and
vendors excluded from voting on market requirements to be fulfilled by the
developers and vendors. E.g., a hybrid system where government IT
departments rather than the vendors set the market requirements, exercising
the procurement power. What is happening right now in the European Community
with the PEGSCO report and the IDABC ODEF Workshop held in Berlin this
spring certainly move in that direction. I think the danger there is that it
might lead to big customer abuse in place of big big vendor abuse.
There is an interesting 1998 academic paper by Ken Krechmer of the Univesity
of Colorado's International Center for Standards Research that attempts to
identify all of the interests that must be served by an open standard. <
http://www.csrstds.com/openstds.html>. Here's the abstract:
This paper develops the argument that many Information Technology
standardization processes are in transition from being controlled by
standards creators to being controlled by standards implementers. The users
of standardized implementations also have rights that they wish addressed.
Ten basic rights of standards creators, implementers and users are
identified and quantified. Each of these ten rights represents an aspect of
Open Standards. Only when all ten rights are supported will standards be
open to all.
It builds atop an earlier work by Bruce Perens and is worth the read if
you'd like a more analytic view of various interests in the standard setting
process and where the overlap exists. It's an over-simplified model, of
course, but good food for thought and discussion.
Best regards,
BUCK "MARBUX" MARTIN
Director of Legal Affairs
OpenDocument Foundation
Contact:
<http://www.opendocumentfoundation.us/contact.htm>
-- Universal Interop Now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070911/67126ad4/attachment-0001.html
More information about the odf-discuss
mailing list