Contribution, Collaboration, & Implementation – Standards Need Balance

Over the past few months, my passport has received more than its fair-share of stamps. I have spoken with people representing a broad swath of interests about standards and interoperability. A few of these meetings have touched on the role of “openness” in standards.

I think the discussion of openness is hugely important, but incredibly challenged. That magical word comes loaded with so many misconceptions that it should have a warning label attached to it.

In the world of interoperability standards, there is an order of operations. In horrifyingly simple terms, the most common steps are.

1. Someone comes up with a technology that they want to use as the basis for a standard. They contribute the technology to a specific working group in a standards organization.
2. The working group will have certain rules of the road so that the many parties involved consider the contribution as part of a specification, and collaborate on the details until there is a written specification. (Important – this is not the technology itself, it is a description of the technology.)
3. Following the publication of the specification, individuals and organizations who would like to build the standard use the specification to implement it. This one requires a few secondary statements. A) sometimes implementations are done on drafts of the spec vs. final versions. B) Some implementations are partial, others are whole, others still may extend beyond the spec. C) There is generally no mandate as to the method used to create the implementation – just that the end result behaves in the manner detailed by the specification.

So why the standards 101 discussion? Because if you are going to have any debates on what makes an “open standard,” or whether or not a given standards organization is open, or what the role of OSS is in standards, or….well you get the picture. Then we should all be talking about the same basic things.

More importantly, when anyone is considering the implications of their desire to see “openness” in a specific direction – then they need to take into consideration all three steps. This is too often lost in the conversation.

Standards have been so important to the software industry because there has been balance between the needs of contributors, collaborators, and implementers. Because there has been competitive pressures on each that both spur on new activity and keep unwanted activity in check.

After years of working on standards issues daily, it is clear that little happens due to legal mandate. Rather most things work because of the industry "norms” of behavior which are reinforced by the legal framework that supports standards work.

So my point for today – let’s keep all three elements in balance as we consider what “open” should be. The idea that “open” = no IP in a standard is an overbalance in favor of implementers just as the idea that a single party has unequal say in a working group can overbalance in favor of a contributor.

Balance may well be a harder concept than openness.