Rick Jelliffe, who’s been in the middle of lots of standards efforts, writes on the subject at Is our idea of “Open Standards” good enough? Verifiable vendor-neutrality. Worth reading, although he does make the assumption that the term “open standards” means “created by some standards organization”. Although that’s a tempting definition, and the one used by a lot of people (and the one I happen to prefer), it’s not the only definition that I’ve seen. I’ve seen three main categories of definitions of the term “open standard” when applied to some specification:
- Anyone can read the specification (usually without paying); often applied to proprietary specifications which are treated as de facto standards.
- Created in a standards organization that allows anyone to take part who has relevant expertise or can pay the appropriate dues.
- Able to be used in any open source projects (i.e., there are restrictions on the types of licenses that can be used).
Recognising that lots of people use the term “open standard” to mean different things, the Liberty Alliance recently published what that term means in the context of Liberty Alliance specifications and guidelines. It’s called the Liberty Alliance Commitment to Open Standards and it’s a very brief document outlining a set of conditions for those specifications and guidelines (yes, the document talks about technical specifications but really it applies to other types of documents as well). The top item in the list of conditions to be an open standard, to answer Rick’s main point that rather than talking “open standards†we need to be talking as much of “verifiable vendor-neutralityâ€
, is cannot be controlled by any single person or entity with any vested interests
.
I disagree with Rick when he says that only ISO is truly vendor-neutral since only national bodies vote, as those national bodies could in theory be swayed by vendors. What you really want is to balance the needs of all parties (vendors, users, governments), but that’s difficult to attain in any organization. You need not only an organization that is set up to allow for input from all those stakeholders (to produce standards that are evolved and managed in a transparent process open to all interested parties
and approved through due process by rough consensus among participants
) but you also need to have enough participants who are interested in the end result, and have the appropriate expertise. And you need a competent chair for each committee, of course.
Hi Lauren, thanks for picking this up! What is your opinion on my main point, which is that competitors ganging up on each other is just as much a violation of vendor-neutrality as when they are controlled by a single interest? (In other words, the tyranny of the numerical majority.)
On ISO, yes, certainly even ISO is fallible in this regard.
s/there are licensing restrictions/there are no licensing restrictions/
John, I’ve reworded to (hopefully) make it clearer what I meant — that only some types of licenses are allowable for this scenario, i.e., royalty-free with no other conditions that preclude implementation by open source developers.
Rick, even if people are working on behalf of a vendor, they’re still people and personalities play a large role. Often what appears to be vendors ganging up on each other is in reality based on real disagreements. If the perceived prevailing view is one that one vendor disagrees with (and this may very well be for technical reasons), it’s not unreasonable for those representatives to talk to others about whether they also share that view, so as to increase their chances of having the issue fixed. This could be perceived as “ganging up”, but it shouldn’t be necessary if the chair of the committee is doing a good job and everyone knows their views will be heard and taken into account in a reasonable way.
But the idea that people have of “open standards” is that somehow they come out of a fair process and that therefore all players should conform to them; if in fact a standard can be “open” according to all the definitions and yet members of the standardizing committee may have been systematically excluded, why doesn’t it mean that we cannot warrant that an “open” standard is not just a “mob rule” standard?
Possible ways forward:
* Users demand plurality: a market place or library of “open standards” rather than the one true standard, so that it doesn’t matter that technical traditions coalesce or evolve in different standards bodies.
* Users (i.e. governments or standards bodies) put in place verification systems, so that standards which do have complete consensus are certified as such, while contentious standards are recognized as contentious.
* Committees publish dissenting reports on standards, so that members who feel disenfranchized can explain their POV: for example, XSD would have a minority report explaining the POV of those who think it was hijacked by database and object interests.
* Committees organize their technologies into small enough modules that dissenting opinions and breakaways only cause the smallest fork possible.
The importance of the organization is in two items:
1. Transparency and regularity of the processes.
Nothing about that is easy for any organization. People will gang up, people will subvert, and people will use the processes to get an edge on their competitors. Grow up and deal. Transparency and regularity don’t guarantee good behavior. They warrant that it can be seen. People will also cooperate, convert and use the processes to ensure users of products conforming to standards benefit. One reliable test for spotting the difference between these groups is behaviors such as demonizing their opponents.
2. Legal conditions for participation.
Ignoring intellectual protections against such things as submarine patents is naive and just a bit dumb. Where market consortia (what OASIS and the W3C are) and standards organizations (ISO, ECMA) do in partnership is set conditions for participation and voting. Separating these is useful as a rough means of balancing self-interests and global interests. So take a hard look at the participation agreements of the consortia and the voting/editing processes of the standards organizations. When conducted by mutual agreement, the results can be better.
There is a difference between a standard and a specification on the timeline. This is a useful distinction. If a specification is used early in the emergence of the technology, it can be changed fast and does not obligate the contributor in the same way as a standard will. Failing to make that distinction has done more damage to the standards processes than predatory acts by contributors. We do need to make the distinctions afforded by late binding or *we* are the ones creating these messy situations.