06.17.07
Open Standards: Why They Matter
Imagine if your town’s water district could not communicate with the water district in the next city, and neither of them could communicate with the sewer district. Further, imagine that they were all using the same brands of radios and the same brands of software. Could this cause loss or hardship? You know it.
Imagine if the space shuttle used 108050 kHz FM for its radios, while the space station used 98050 kHz AM, and the Russian space capsules used 102350 kHz SSB. How could they coordinate a docking maneuver? You would see a three-way collision, with all three vehicles breaking up and raining down fragments across a large swath of the globe.
This is where standards, open standards come in. Perhaps the standard will say that the local state police / highway patrol will have a channel that all other police agencies in the state must have the capability to utilize. So a chase that crosses a jurisdictional boundary is easily passed on to the proper agency, even before the news copters come overhead. Perhaps the standard will say that fire departments must use equipment (for example hydrant openings) that match specific common sizes of adapters for firehoses. Perhaps the standard will specify file formats and network protocols that emergency response agencies must use for their connections and communications between agencies. Perhaps the standard will apply to contractors and their work-product.
In any case, a standard is really best if it is set by a vendor-neutral group. For example, several years back, it was difficult to use many Web sites unless you were using the site’s chosen browser. If your chosen browser was different than their chosen browser, you sometimes got a horrid mess and sometimes got a message telling you to upgrade to the other product. (If you want a contemporary example of that, use Konqueror to visit the Yahoo home page.)
Now, at least, most sites are making some effort at working with multiple browsers. This can entail gobs of contingency code to handle compatibility, or sites can be written using Web standards such as XHTML, CSS, and JavaScript. Because no browser is 100% standards-compliant yet, even a standards-based site will needs some compatibility code, but it is lessened if the site adheres to open standards for Web development.
How would you feel if the use of a particular brand of proprietary software that did not adhere to open standards caused the IRS to reject your tax return? What if the government already knew that it needed to adopt open standards, but lobbyists for proprietary companies (with their own “secret sauce” file formats and network protocols) were able to prevent it?
The point of this is that there are potentially devastating, even deadly, consequences that come with using anything other than open, industry-standard file formats and network protocols. What if the governor sends a pardon by e-mail attachment (in a proprietary format, of course) and the warden cannot read it (because he can not open that format) before your execution? I am certain that there are not only theoretical events, but also actual events, where the lack of interoperability that happens when open and vendor-neutral standards are not used brings harm to someone.
In my opinion, an open standard needs to meet a few criteria in order to be useful:
- Open specification — the specification should be openly published and available; specifications are best when they are controlled by an independent (vendor-neutral) group within the industry.
- Clear of legal obstacles — any parties that may own relevant patents or other “intellectual property” rights that may affect the standard need to be identified and need to clearly state the criteria for usage of said rights
- Sufficiently detailed — A skilled person within the industry should be able to develop an implementation primarily from reading the specification
- Sufficiently generic — Implementers need some leeway in what they do and how they do it. If a spec is over-specified, or if there are legal obstacles for partial implementations, it becomes a problem
- Multiple implementations — in addition to a reference implementation (which generally should be open source if we are talking of software), there should be other implementers of a spec.
Beware of large vendors trying to tell you that their chosen formats and protocols are “standards”. Beware of government agencies specifying a “standard” that only one vendor can meet. If the standard is not controlled by a vendor-neutral group or if there is only one implementation of that standard, you are putting your company or your city (or county, state, or whatever) in the control of that vendor. Do you trust them? Really? Completely and totally? With the crown jewels?
I said it this way on XML.com:
Never forget the vendor-neutral part, because without it the switching cost makes choosing a vendor a high-stakes decision and subjects consumers to all sorts of abusive treatment from their suppliers (the vendors and those who distribute the products / services of the vendors)
Smaller businesses have to satisfy customers. Otherwise, those customers will quickly be gone. Larger companies have a cushion, so they can persist for years without really even trying to satisfy their customers. This is one reason why smaller companies like to base their offerings around the standards of their industries. In a larger company, customers sometimes have no choice but to pay the price and use the product, regardless of whether they like it, so those companies often use proprietary “extensions” to lock customers in.
