Senior Director, Interoperability Group
I’m Gregg Brown, and I work with Craig Shank and Steve Mutkoski in the Interoperability Group at Microsoft. As my colleagues pointed out, collaboration, competition and consumer trust are important to effective standards, and transparency and a commitment to technical excellence are earmarks of a process that will lead to useful standards. Of course these are just the start, in the end the marketplace decides which standards will become widely used. It would save a lot of hard work and bad coffee if we could develop just the successful standards, but unfortunately great process doesn’t guarantee great standards. In reality, the individual implementation decisions of many developers determine in aggregate what is used and what is forgotten.
Open standards are defined by standards-setting organizations and the industry as including the following fundamental elements:
- The standard is developed, approved, and maintained by a collaborative consensus-based decision-making process
- This process is transparent and open to all interested parties
- The standard is subject to RAND/FRAND Intellectual Property Right (IPR) policies that allow the IPR holder to license essential intellectual property on reasonable terms either with or without compensation
- The standard is published and available to the public under reasonable terms (including for reasonable fee or for free)
Today, developers frequently decide to implement widely-used open standards rather than design new protocols from scratch. That’s certainly the trend at Microsoft. What do developers consider when they pick a specification, and why do those considerations lead to the adoption of open standards?
The first consideration when choosing a specification is “will it do the job?” Widely-implemented open specifications are either market-tested specifications from a single vendor submitted to a standards organization for standardization, or they have gone through consensus and feedback as part of a formal process in becoming a standard. Either process makes open standards a popular design and implementation choice.
Another big enabler of open standards is that modern software design practice has moved away from the creation of unique protocols. Different interoperability scenarios require different protocols or formats of course, and at one time, developers were likely to create a new protocol to match each scenario. But as interoperability between systems and vendors became more important, developers changed how they design software to use simpler and standard protocols. It’s simply easier, less costly, and often ensures increased adoption in the marketplace to implement an existing standard. Even if the systems have unique interoperability needs, new design patterns like RESTful interfaces rely on open standards as much as possible, limiting the cost of implementation and increasing the number of supported platforms.
That brings us to the second consideration: a useful specification must be available for use on all platforms a design needs to interoperate with, now and in the future. That means it is licensed for use on all platforms you care about, is technically feasible to use on those platforms, and is as widely used as possible. While many specifications meet these characteristics, all of these needs are inherently met with open standards.
Finally, like most engineering decisions, choosing a specification is based on a set of cost tradeoffs. Direct cost for implementing a standard is rare, but implementation cost and future support costs are very real considerations. Widely-implemented open standards have an inherent support structure based on many implementations on different platforms that reduces the cost to implement them (and sometimes to test them).
Future support costs are driven by how a technology specification evolves—and unexpected changes are particularly expensive to support. A primary advantage of open standards is that the consensus process used to maintain the standard reduces the likelihood of unexpected or breaking changes, making future support cost for open standards more predictable.
As a result, widely-adopted open standards are popular with developers because they do the job they are supposed to, fit modern design practices, are implemented on platforms they need to use, and have knowable costs. All these factors are closely interrelated of course, which makes it essentially impossible to predict ahead of time if one standard will become widely adopted. That’s why a standards ecosystem based on choice, transparency and a commitment to technical excellence is critical to ensure a healthy “gene pool” for standards. But in the end, developers vote with their fingertips to pick the standard that will be implemented.