[odf-discuss] Two interoperable and independent full implementations prior to fast-track

[marbux]

On 8/25/07, Lars Noodén <lars at umich.edu> wrote:
> The Netherlands' representatives have an interesting suggestion for the
> future:
>
>         "ISOC.nl recommends that the ISO procedures - and more
>         specific the Fast Track procedure - be adapted
>         significantly to better deal with controversial
>         standards like DIS 29500/Office Open XML in order for
>         ISO to maintain relevant. This includes demanding two
>         interoperable and independent full implementations prior
>         to accepting a submission for a Fast Track procedure."
>
>         http://isoc.nl/michiel/nodecisiononOOXML.htm
>
> The current situation, where ISO standards can be apparently purchased
> via Ecma, has made a mockery of the standards process and calls into
> question the relevance of ISO.  Requiring at least two interoperable and
> independent full implementations prior to fast-track would prevent a
> repeat of the current fiasco.


In my view, that doesn't go nearly far enough. E.g.,

* The standardization process worldwide is very heavily weighted
toward those with big bucks riding on the output of standards
developments organizations (SDO's).

* The standardization deck is stacked in favor of big vendors and
against that of independent and FOSS developers.

* The interests of those who use and consume the products are grossly
under-represented.on SDO's. E.g., the standardization process has not
yet begun to come to grips with the market requirement for
interoperability among office productivity applications. And those who
believe that "open" and "interoperable" are synonyms are just plain
wrong.

* SDOs routinely ignore the Agreement on Technical Barriers to Trade's
("TBT") fundamental requirement that standards not be ***"prepared,***
adopted or applied with a view to or with the effect of creating
unnecessary obstacles to international trade." E.g., despite the
blatant anti-competitive aspects of Ecma 376, only a single national
body raised a contradiction on grounds that Ecma 376 violated the only
restriction that the Agreement placed on the NBs in that instance. As
another example, on the OASIS ODF TC, I know from personal experience
that objections to proposals based on the TBT are met with lectures on
poor manners and fastidious avoidance of even discussing competitive
effects of proposals. And I am told by others that the situation is
much the same around the world. There is a custom in far too many SDOs
of confining discussion to technical issues only.

* The standardization process is not integrated with government fair
competition regulatory agencies, despite their overlapping
jurisdiction. E.g., if one were to attempt a Band-Aid solution to the
Ecma 376 kind of problem, in my view, one requirement would be that
standards pass review by the fair competition regulators before they
can be established.

* This is a variant of an issue mentioned earlier, but the
standardization process is not integrated with governments'
procurement processes. One idea I've kicked around with a few other
people is to restructure the standardization process around a scheme
whereby a standard's requirements would be determined by a board of
software users, e.g., government IT departments, with vendors only in
a consultant role, and confine vendors to the development role. But
that seems likely to just substitute Big User abuse for Big Vendor
abuse. And for those who trust in government to do the right thing
when it comes to riding herd on Big Vendors, you've obviously never
had the pleasure of a career spent representing little people maimed
by the partnership of Government and Big Biz.

While my thoughts on such issues are still evolving,  I don't yet see
any realistic hope that the world's international standardization
process can be substantially reformed during the remainder of my
lifetime, and scant hope at all of doing so from inside that process.
(I'll be 61 next week and have already had 3 heart attacks.) There's
incredible political inertia to overcome in the existing system, way
more than just that created by those with vested interests in software
file formats.

So I'm looking for an outside-the-box solution. I find myself more and
more interested in the idea of open community-based standards
development for software file formats and communications protocols.
I.e., the FOSS approach is rapidly displacing the proprietary software
 business model. Might file formats developed in a FOSS-type approach,
e.g., something roughly akin to the way GPLv3 was developed, fuel the
FOSS fire?

As Doc Searls once famously said, "Open source is where the demand
side has taken over their own supply." If the big vendors won't give
us interoperability, perhaps it's time to make our own.

Best regards,

Marbux