When I came over to Si2 after 20+ years in the semiconductor industry, I was critical of how many standard specifications were created and approved, but then poorly adopted. My main point was, and remains, that there is no commercial value to a standard until widely adopted, so the industry needed process improvement applied to how we go about ensuring our investments are not wasted. Part of that process is clarity and alignment of need for a proposed standard – who needs it, and when it must be ready. Too early and it has no market; too late, and the concrete of “incompatibility chaos” has set and dried. Another aspect is supporting the life cycle needs of a standard through adoption – what is required to remove barriers that prevent rapid and consistent adoption across industry?

Creation of a specification is one thing, but adoption is another, often more difficult, challenge. Adoption aids for a standard may include education, training, test cases, labs, parsers, header files, or even a full “reference implementation” or “reference flow”. Sometimes, supporting software may provide useful bindings to popular scripting languages, enable translation among other formats and APIs, and might include value-added utilities to aid integration testing, debugging, and data inspection / analysis. Website support for adoption should consider offering on-line discussion forums, bug trackers, and new feature requests. In addition, new contributions of technical requirements, data models, or code implementations may require appropriate licenses, “certificates of authenticity”, and legal protections for all other participating members. Finally, effective standards development needs to work acceptably well in a global context – which may mean multiple languages and widely-varying time zones.

Not all standards require such heavy lifting. For example, Si2’s ECSM Noise standard is a mere 31 pages, describing straightforward file format syntax. By contrast, OpenAccess includes nearly 700 C++ classes, dozens of information model diagrams, plus over 1100 pages that define the API standard. This standard is supported by over 1.5 million lines of code, updated multiple times each year (along with training, labs, etc). OpenAccess could not have succeeded without this strong and consistent support.

Most standards will fall somewhere in between those extremes. The key point: plan for adoption as part of the development of the standard to avoid wasting resources. This does not mean that success of a standard is assured – many external variables come into play, just as with any product introduced into a market. One of the ways to improve the odds is through a large and broad set of active stakeholders working together on the open standard, with equal rights and equal opportunities.

At Si2, another way we help the odds is by defining specific adoption success metrics each year, for accountability to results and incentive to find ways around adoption barriers. These metrics are approved by Si2’s Board of Directors, as are the end-of-year ratings. I would like to encourage all standards development bodies to similarly define adoption metrics — and be held accountable for achieving them.

In a subsequent blog, I will explain more about how certain kinds of supporting adoption aids can open up new standardization possibilities in creating compatibility, even when the concrete has set on any number of competing existing formats. Stay tuned.