Standards Best Practices Blog

If you’re reading this blog you’re probably already participating in or at least interested in standards activities. You understand the benefits of standards work, both to your employer as well as to industry and society as a whole.

But what about the companies and people who do not participate? What are the obstacles to their participating? The potential participant, whether a company or an individual

• may not know that a standards activity exists in an area that interests them;
• doesn’t understand the benefits of their participation;
• don’t understand how the standards process works;
• don’t know how to get started or doesn’t understand the rules or technical process at the standards organization;
• can’t afford the costs of joining and participating, both in membership dues as well as time and travel for participants;
• can’t afford to have the company’s top talent working on standards instead of the company’s R&D efforts; or
• doesn’t want to disclose or provide licensing for any applicable patents they have.

In addition, there may be things that the standards organization may be doing, consciously or not, to discourage participation.

• The organization’s process for joining and participating may be so complicated that only insiders or current participants understand them.
• The organization may have a closed or restricted process that limits or discourages participating in or contributing to the development of the work.
• Organizational membership dues levels may be a barrier for all but the richest companies.
• Organizational leadership may be restricted, permanently set, or tied to the highest levels of membership dues.
• Current participants may not be interested in having additional participants, i.e. increased competition, so may actively or passively hinder additional participation.

The solutions for the above problems may or may not be simple, but are do-able. Standards setting organizations need to make an effort to communicate the status of their work, make outreach efforts to bring in additional participation, make the process for joining and participating simple and easily understandable, mentor prospective and new members, make the total costs of participation within the reach of smaller companies, and have clear and participant-friendly IPR policies.

The benefits from additional participation in standards activities should be obvious: increased and broader input in the specification being developed, spreading the workload across a larger number of participants, and broader adoption of the completed work. It’s worth the effort of all parties involved to make it easier for additional companies and individuals to participate.

I’ve been on a soapbox for a few years now about the need for standards setting organizations to share information with each other. Recognizing that there’s about zero chance that all of the hundreds of SSOs worldwide will sign up to belong to a single umbrella organization in order to coordinate their work, it’s up to the individual organizations to each make an effort to coordinate with each other.

Why do we need coordination? Well, in the first place, there’s too much duplication of effort going on; different organizations are developing solutions to the same problems, usually with different results. This leads not only to confusion in the marketplace, but also wasted effort as two (or more!) organizations work to solve the same problem, oftentimes without knowing that someone else is working on the problem or perhaps has already solved it. Every SSO that I know of has finite resources, and it’s a shame to waste them by duplicating work.

Maybe that’s why the U.S. Standards Strategy recommends the principle of “…coherence to avoid overlapping and conflicting standards.” Or why the World Trade Organization, in its agreement on Technical Barriers to Trade, requires that SSOs use existing work and avoid duplication.

How do you go about avoiding duplication of work? It’s simple: Communication. If you don’t tell me what you’re working on, how will I know? And if I don’t know, how can I avoid duplicating your work?

Of course there are various ways of communicating, some better than others. Probably the most common way of doing this today is via the web, where each organization publishes on its own web page a summary of the work it is doing. That’s great, but it’s just the first step.

The problem with this solution is that every organization lists its information a bit differently – sometimes on the home page, sometimes a few levels deep, sometimes accessible only to its members, and always in a different format or syntax than any other SSO. Plus, of course, if I don’t know to look at your page I may not find it, even with the magic of Google.

The solution is for each SSO to publish their information in a standardized manner using a standard format in a single location. And the best location for that right now is the NSSN standards database at ANSI (see www.nssn.org).

NSSN isn’t a perfect solution, there are of course improvements that can be made, but it is capable of accomplishing what needs to be done, and it’s being hosted by the organization tasked with promoting and coordinating standards activities within the United States.

I see the following benefits from using a common database to publicize information about your organization’s standards activities:

1. decrease duplication of work and wasted resources
2. decrease market confusion from multiple solutions to the same problem
3. increased liaison activity between multiple organizations that are interested in working on the same problem
4. increased participation as interested parties discover work being done in a field that affects them
5. increased adoption as interested parties discover solutions to problems they have

So, give it a try. Go to NSSN and submit (and maintain!) information regarding your organization’s technical activities. Your members, prospective participants, and prospective implementers will be glad you did.

Andy Updegrove’s ConsortiumInfo.org blog has a link to a web page for St. Isidore, the patron saint of computers and the internet. This started me wondering if there was an equivalent for standards setting activities. I’m not so familiar with the Catholic saints as with characters from mythology, but a bit of digging in my Classics books didn’t get me anywhere. Perhaps we could go with Zeus the law-giver, or any one of the “chief god” equivalents in any of a number of pantheons, but that’s too easy and probably not quite what we’re looking for – such laws were by decree rather than the product of a consensus process. What we need is a character whose responsibility is measuring or weighing things, building consensus, or maybe even running meetings. So, what do you think? Who should be the patron saint, god, muse, etc. of standards? Now accepting nominations.

Everything seems to be called “open” these days — open source, open architectures, open standards, etc. But when someone claims that something is open, what do they really mean?

As generally understood by standards setting organizations, which includes all manner of accredited and non-accredited standards organizstions, consortia, etc., “open” means that all interested and affected parties have a say in the matter.

But this has a great deal to do with perspective — not just with one’s definition of the term “open” but in where and by whom it is being used. For example, in the complete life cycle of the technology codified in a specification, which includes the following,

1. requirements gathering
2. participation in the development of the specification
3. approval of the specification as a standard
4. availability of the specification to implementors
5. availability of licensing under reasonable terms
6. availability of the implementation (product) to users
7. (start again with feedback)

“open” could apply to any or all of these steps. The term “open standard” would generally be considered to be a specification where steps #1-3 above were conducted in an open process where all interested and affected parties were allowed to participate.

But what about “open software”? Does that mean open in regards to #4 or to #6? After all, “open software” could really just be software that is available to the public. And for that matter, “open standard” could be just #4 — the specification is available to the public.

What do you think it means?

As demonstrated by the recent approval by ECMA of OOXML (Open Office XML), a Microsoft-developed specification for office documents, it is possible for a specification developed in a closed environment by a single organization for its own purposes, to be ratified by a standards body. It is probable that OOXML will eventually be ratified as an International Standard once it wends its way through the approval process.

How is it possible, one might – and should – ask, that a “closed” specification becomes approved as an International Standard, given the universal agreement among de jure organizations that Openness is a basic principle of any approved standards process?

Over the last decade or so, as international standards organizations have recognized the generally valuable work done by non-accredited standards organizations and consortia, they have added to their operating procedures the means for completed, third-party work to be submitted for de jure approval.

For example, the PAS (Publicly Available Specification) process at JTC1, the Joint Technical Committee for ISO and IEC for high technology, allows a PAS Submitter, an organization which has been pre-approved by JTC1, to submit completed work into the JTC1 approval process. The approval of a third party as a PAS Submitter is based on a review of the submitter’s process, which requires that specifications be developed under the guiding general principles of Openness, Balance, Due Process, etc. So far, so good. But, the loophole is that the PAS Submitter accreditation process doesn’t check the organization’s rules on accepting work developed outside of the organization, or whether any further – and open – development work has taken place after the submission. The approval process must be open, but it is merely assumed that development as well takes place under an open process.

In the case of OOXML, ECMA will be submitting their work by a different route, via their Class A Liaison with JTC1. Like the PAS Submitter status, a Liaison allows a third party to submit completed work, though the JTC1 Subcommittee has additional scrutiny of the work before it may be approved.

JTC1 isn’t the only organization that works this way. At OASIS, for example, where I was responsible for maintenance and administration of the technical process, it was possible for a specification developed in a closed environment by a small group of companies to be submitted to an OASIS technical committee for further work and approval. The informed reader will note that ODF started life elsewhere as a vendor spec before being submitted to OASIS; the difference is that the spec went through a few years of additional work under an open development process before finally being approved and submitted to JTC1.

Essentially, Microsoft has inserted a “closed” specification into the approval pipeline at the process’ point of entry; as the specification flows through the “open” process it gains the patina of an open spec.

This loophole poses a great danger to the credibility of the open standards process. At some point it is difficult to distinguish between work both developed and approved under an open process and work that is only approved by open voting. Some may say that it doesn’t matter, that the open approval process still guarantees that the work is of good quality. But sadly many times the approval process is merely a formality, where approval at the prior stage is “good enough”. Or the work may be technically competent, but no questions are asked regarding its single-party purpose. In any event, while such a specification may carry the “stamp of open approval” deep down inside it’s still a closed spec.