First some definitions. Let’s define an “open standard” as one that is: 1) freely available, 2) developed in an open process and 3) freely implementable, e.g., is royalty free. Clearly there are
First some definitions. Let’s define an “open standard” as one that is: 1) freely available, 2) developed in an open process and 3) freely implementable, e.g., is royalty free. Clearly there are interests out there that attempt to soften these criteria, but that only demonstrates the competitive power presented by truly open standards. We see similar “dumbing down” pressures on other popular marks of distinction, such as the constant pressure by “big agriculture” to allow more permissive use of pesticides in organic/biologique food. It is almost a law of nature that any item of relative scarcity and value will be counterfeited. Dumbing down definitions is just one way to counterfeit an open standard.
At the same time there is clearly a spectrum of openness, from proprietary, trade-secret technology at one extreme, progressing through proprietary non-RAND specifications, proprietary RAND specifications, RAND standards to RF standards. But for sake of argument, let’s draw the line for open standards at these three criteria: freely available, open process, and freely implementable.
So how do you make an open standard? In the industry we have a number of years experience creating open standards. We know what works and what doesn’t. We’ve learned from experience and especially from failure, the harshest of teachers, e.g., Rambus and OOXML. At a high level, this experience has led to the following recipe for open standards, a recipe practiced by several notable standards consortia today:
- Publish your standards on the web for free download and use. This seemingly simple step has enormous repercussions for a standards organization, since it eliminates an entire business model, that of selling standards. So an organization that produces open standards must have an alternative source of income to fund its operations, for example, membership fees, corporate or government sponsorship, etc.
- Define and enforce an open process for the development of standards. Much has been written and said about the further qualities that define an open process, but generally they focus on openness, balance, lack of domination, broad-based public review, consensus, due process, right to appeal, etc. ANSI’s Essential Requirements [PDF] is an excellent outline of the minimum process requirements for ANSI, the organization that accredits US standardizers.
- Have a clearly-defined, enforceable IPR policy that ensures that implementors of the standard have royalty free (RF) access to all rights needed to implement the standard. This area evolved quite a bit, especially post-Rambus, and the best practices now include: defining obligations of members with regard to patents they may control that read on the standard, defining obligations of 3rd parties who submit comments or proposals related to a standard, ensuring copyright assignment from contributors, defined 3rd party patent disclosure obligations, etc. The complexities of rights given during the drafting of the standard, durable obligations of members who leave, and how rights transfer to future maintenance releases of a published standard — all these are concerns of standards organizations that strive to produce open standards. For reference, note the IPR policies of OASIS and the W3C. (Now there may be some of you thinking, “IPR wouldn’t matter if we would just eliminate software patents”. But it is not so easy. First, we need to consider copyright as well. And second, remember that not all standards involve only software. Many relevant techn