What are open standards?

Open source resources
Image by:

Opensource.com

By now you probably have a good understanding of what "open source" means. (If you don't, you should read What is open source? before diving into this article.) So what do we mean when we talk about open standards?

In open source software development, open standards act as guidelines to keep technologies "open," especially for open source developers. Sounds simple enough, right? Unfortunately, debate about what qualifies as open and who gets to pick what becomes a standard makes defining what open standards are a little more complicated. Before diving into what open standards are, let's take a closer look at standards.

What are 'standards'?

ISO, the International Organization for Standardization, defines standards as "a document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose."

ISO is an independent, non-governmental international organization that develops international standards. The ISO site explains that international standards give specifications for products, services, and systems, to ensure quality, safety, and efficiency, which is instrumental in facilitating international trade.

Standards are why we are able to use a debit card from a bank in Canada to withdraw cash from a machine in South Africa, share a photo from a Samsung phone to an Apple laptop, buy light bulbs that fit reading lamps and ceiling fans, and access the Internet.

In fact, standards are such a big deal that they even get their own annual holiday on October 14, World Standards Day, an initiative of the World Standards Cooperation (WSC).

Developing standards, on the other hand, is so complicated that it has its own xkcd How Standards Proliferate comic.

How are standards developed?

Well, it's complicated. There are hundreds—perhaps thousands—of standards organizations around the world, and many of them are part of multiple larger standards organizations. And there's no one guidebook to rule them all, which is why we end up with a spectrum of standards, such as open or closed, industry or vendor standards, and so on.

Let's look at ISO, for example. ISO is a small acronym for a much bigger organization, with a membership that includes 163 national standards bodies. Because standards affect everyone, everyday, there are lots of standards developing organizations (SDOs), and not all of them are members of ISO. The SDOs specialize in particular industries or technologies (for example, the Internet), but many SDOs work together to develop specifications that cross areas of expertise and industries.

Imagine the amount of cooperation and collaboration required to develop voluntary, consensus-based international standards. For example, the WSC site explains, the World Standards Cooperation is high-level collaboration between the ISO, the IEC (International Electrotechnical Commission), and ITU (International Telecommunication Union). "Under this banner, the three organizations preserve their common interests in strengthening and advancing the voluntary consensus-based International Standards system," the site says. By working together to develop international standards, organizations from different industries are able to implement standards that benefit organizations across industries.

The WSC site also notes that international standards are an important instrument for global trade and economic development. "They provide a harmonized, stable and globally recognized framework for the dissemination and use of technologies. They encompass best practices and agreements that encourage more equitable development and promote the overall growth of the Information Society." And the same holds true when we're talking about open source code and open standards.

In his standards primer, Understanding Technology Standardization Efforts (PDF), open source advocate and software business consultant Stephen Walli explains:

Technology interoperability standards are specifications that define the boundaries between two objects that have been put through a recognized consensus process. The consensus process may be a formal de jure process supported by national standards organizations (e.g. ISO, BSI), an industry or trade organization with broad interest (e.g. IEEE, ECMA), or a consortia with a narrower focus (e.g. W3C, OASIS). The standards process is not about finding the best technical solution, and codifying it, but rather to find the best consensus driven solution with which all the participants can live.

The best interoperability standards enable multiple implementations to be delivered into the market. They benefit customers by enabling choice in a marketplace. A successful standard usually has many implementations, and the standard with the most implementations could be considered to "win" from a standards development producer's perspective.

Open standards example: The Internet

In its explanation of open Internet standards, The Internet Society (a global organization that helps drive Internet policy and technology standards) says, "The Internet is fundamentally based on the existence of open, non-proprietary standards. They are key to allowing devices, services, and applications to work together across a wide and dispersed network of networks." The page lists The Internet Engineering Task Force (IETF), The Internet Research Task Force (IRTF), and The Internet Architecture Board (IAB) as the core groups behind the development of the open Internet standards. "These organizations are all open, transparent, and rely on a bottom-up consensus-building process to develop standards. They help make sure open standards have freely accessible specifications, are unencumbered, have open development and are continuously evolving," the page explains.

To get an idea of the huge quantity of standards for the Internet, see the Internet Standard page in the RFC series that is hosted on the RFC Editor site, which has been funded by a contract with the Internet Society since 1998.

Example official Internet standards

Note that not all RFCs (Request for Comments) are standards. As the site explains, "The RFC series contains technical and organizational documents about the Internet, including the specifications and policy documents produced by four streams: the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), and Independent Submissions.

Let's look more closely at STD 3, for example, Requirements for Internet Hosts -- Communication Layers. This early Internet standard dates back to 1989.

Requirements for Internet Hosts -- Communication Layers

Figure 2 only shows the first 12 pages listed in the Table of Contents. STD 3 is more than 100 pages long.

Page 4 in the STD 3 introduction says that the standards documents—keep in mind that STD 3 is only one of many Internet standards outlined in these documents—are intended to provide guidance for vendors, implementors, and users of Internet communication software. "They represent the consensus of a large body of technical experience and wisdom, contributed by the members of the Internet research and vendor communities," it explains.

Page 5 of STD 3 introduction

Page 5 nicely illustrates a few key points about standards:

  • they are voluntary,
  • when they are developed for the marketplace matters,
  • and they evolve over time.

Standards are voluntary

"There may be valid reasons why particular vendor products that are designed for restricted contexts might choose to use different specifications," STD 3 explains. For example, in September 2016, Apple announced that its iPhone 7 and 7 Plus would ship without a 3.5mm headphone port, which has been the standard for most mobile devices, including mobile phones, music players, and laptops.

In his opinion piece on the move for Mashable, journalist Chris Taylor responded, "It has eradicated the most successful, most widespread and best-sounding audio standard in the world in favor of its own proprietary [Lightning] system."

Apple marketing chief Phil Schiller says the move was driven by "courage," but Taylor and many other journalists (and consumers) think the move has more to do with Apple's plan to profit from sales of aux-to-Lightning cable dongles and wireless headphones. Many people like the convenience of wireless headphones, but they aren't considered to be superior when it comes to sound quality. Although Apple positions the move as having a valid reason, not everyone else agrees.

Walli's primer addresses a problem with vendor specifications, like the new Lightning audio standard for the iPhone, instead of industry standards. "Vendor specifications enable the vendor's business by encouraging complements around the vendor's technology base. They benefit the vendor over the customer."

Standardization timing matters

The STD 3 introduction illustrates that the Internet was still in its infancy when the standard was developed. "Although most current implementations fail to meet these requirements in various ways, some minor and some major, this specification is the ideal towards which we need to move," it explains.

From a technology-maturity perspective, timing matters. "Many fear that standardizing too early hobbles innovation," Walli says. "Once the point of standardization happens in the market, it is clearly time to codify an aspect of the market, allowing new innovation to build around the stable ‘standardized' base," he explains. Walli points out that standardizing too early or ahead of the market is difficult, saying, "Good standards codify proved ways of accomplishing things. They are based on existing practice and experience." 

Standards evolve

The STD 3 introduction acknowledges that, as the Internet matured, the standards would evolve, and says, "These requirements are based on the current level of Internet architecture. This document will be updated as required to provide additional clarifications or to include additional information in those areas in which specifications are still evolving."

What makes a standard ‘open'?

Well, that's also complicated because different standards organizations and advocates offer different guidelines. Let's look at one open standards organization, OASIS, for an example.

Whereas ISO is an organization composed of many national standards bodies, OASIS is a nonprofit consortium that drives the development, convergence, and adoption of open standards for the global information society. Let's take a high-level look at the requirements OASIS has for developing open standards.

The OASIS site explains, "OASIS members broadly represent the marketplace of public and private sector technology leaders, users, and influencers. The consortium has more than 5,000 participants representing over 600 organizations and individual members in more than 65 countries."

Under OASIS, technical committees (TCs) develop the standards, and then for the standard be adopted by the consortium as an open standard, it must:

  • be created by domain experts (not SDO staff);
  • be developed under and internationally respected, open process (i.e., be open for public review and debate);
  • be easy to access and adopt;
  • have allowed anyone affected by the standard to contribute to the development of it;
  • not have hidden patents to scare implementers;
  • have the ability to implement the standard baked in (i.e., OASIS standards must be verified by multiple Statements of Use);
  • and be safe for governments to endorse.

(From the Starting a TC (PDF).)

OASIS is the group behind the development of the OpenDocument OASIS Standard (for example, .odt files), which was approved by ISO and IEC in 2006 (ISO/IEC 26300). As that announcement explains, "OpenDocument defines a genuinely open XML file format for office applications. Suitable for text, spreadsheets, charts, graphs, presentations, and databases, the standard frees documents from their applications-of-origin, enabling them to be exchanged, retrieved, and edited with any OpenDocument-compliant software or tool. The standard will facilitate access, search, use, integration, and development of document content in new and innovative ways."

OASIS has detailed policies and guidelines to help develop open standards, so browse their site to get a feel for the behind-the-scenes work involved with developing standards, even in "the open." For example, the site includes Antitrust Guidelines and an Intellectual Property Rights Policy, as well as policies regarding conflicts of interest and interoperability demonstrations.

But the high-level overview shows how open standards must be openly created and easy to adopt without restrictions or for use or royalties expectations.

How do other open standards advocates define 'open standards'?

Bruce Perens, creator of The Open Source Definition, outlined six criteria an open standard must satisfy:

  1. Availability: Open standards are available for all to read and implement.
  2. Maximize End-User Choice: Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer into a particular vendor or group.
  3. No Royalty: Open standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.
  4. No Discrimination: Open standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor's implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.
  5. Extension or Subset:Implementations of open standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices).
  6. Predatory Practices: Open standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open standard may not otherwise prohibit extensions.

The Free Software Foundation Europe (FSFE) collaborated with other individuals and organizations in the tech industry, politics, and community to outline a different five-point definition. According to the FSFE, an open standard refers to a format or protocol that is:

  1. subject to full public assessment and use without constraints in a manner equally available to all parties;
  2. without any components or extensions that have dependencies on formats or protocols that do not meet the definition of an Open Standard themselves;
  3. free from legal or technical clauses that limit its utilisation by any party or in any business model;
  4. managed and further developed independently of any single vendor in a process open to the equal participation of competitors and third parties;
  5. available in multiple complete implementations by competing vendors, or as a complete implementation equally available to all parties.

The Open Source Initiative (OSI), the organization responsible for reviewing and approving licenses as Open Source Definition (OSD) conformant, says "an ‘open standard' must not prohibit conforming implementations in open source software." OSI provides a list of five criteria an open standard must satisfy. "If an ‘open standard' does not meet these criteria, it will be discriminating against open source developers," the site says:

  1. No Intentional Secrets: The standard must not withhold any detail necessary for interoperable implementation. As flaws are inevitable, the standard must define a process for fixing flaws identified during implementation and interoperability testing and to incorporate said changes into a revised version or superseding version of the standard to be released under terms that do not violate the OSR.
  2. Availability: The standard must be freely and publicly available (e.g., from a stable web site) under royalty-free terms at reasonable and non-discriminatory cost.
  3. Patents: All patents essential to implementation of the standard must:
    • be licensed under royalty-free terms for unrestricted use, or
    • be covered by a promise of non-assertion when practiced by open source software
  4. No Agreements: There must not be any requirement for execution of a license agreement, NDA, grant, click-through, or any other form of paperwork to deploy conforming implementations of the standard.
  5. No OSR-Incompatible Dependencies: Implementation of the standard must not require any other technology that fails to meet the criteria of this Requirement.

How do ‘standards collaborations' differ from ‘open source collaborations'?

Standards and open source projects are different collaborations. They're different economic tools in a marketplace with different goals, outcomes, and processes. As Stephen Walli explains:

1. Standards take longer to develop and change. Whereas open source projects can develop quickly, standards encourage multiple implementations and tend to enter a market with some maturity and competition. Standards and specifications don't change quickly, so they are developed with the expectation that they'll need to last for longer periods of time. For example, moving from HTML1.0 to HTML5 standard took about 18 years, and we've had TCP since 1981 with few changes.

2. Standards are consensus-based compromises. Open source projects are driven by contribution and meritocracy.

3. Standards define useful predictable boundaries. Well-run open source projects are the building blocks of rich, varied ecosystems.

Example open standards organizations

Standards bodies

Software standards

Security standards

Benchmark standards

(Source: http://community.redhat.com/standards/)

Thanks to Stephen Walli, Rikki Endsley, Deb Bryant, and Nithya Ruff for contributing to this resource.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.