Open Standards vs. Open Source, Part 1: Standards

Print Friendly

Podcast of this blog entry

pdf version In my wish list for 2006 that I blogged about a couple of weeks ago, the very first item was my desire for people to have a better understanding of the difference between open standards and open source. Authors have written entire books about these topics, and more are being written even as I pen this.

We saw in some of the public hearings in Massachusetts some confusion between what a standard does and what the rules are when you go to implement it. I’ve been told secondhand that some people were even told things like “if you implement that standard, then all your software has to be given away for free.” This, of course, was wrong and confused, if it wasn’t, in fact, outright FUD (creation of Fear, Uncertainty, and Doubt).

So let’s talk about some of the basic notions about and the differences between standards and open source. In this part, I’ll focus on the former and start the discussion of software and open source in Part 2.

As I said in the wish list, a standard is like a blueprint. It provides guidance to someone when he or she actually builds something. Standards are not limited to software, but are an important part of computer hardware, telecommunications, health care, automobiles, aerospace, and many areas of manufacturing.

One of the reasons an architect produces a blueprint is that a builder, an engineer, or an inspector can look at it and say “if you build according to this plan, it will be safe and the house won’t fall down.” In the same way, some standards are for safety, especially where they involve electrical or electronic components.

A standard is more than just a blueprint, though, because it has to be something with which a lot of people agree. Something that may not have this sort of “blessing,” or common agreement, is usually called a specification. By abuse of language, we will sometimes call a standard a specification. Put another way, all standards are specifications, but not all specifications are standards.

Standards are also employed when we have to ensure that things made by different people will either work together or work in the same way. I live in the United States, and when I go to the store and buy a telephone, I know that the telephone wire will plug into the jack in my wall. I don’t need different jacks for phones made by different vendors. The design of the telephone jack and the plug are not control points for any phone vendor. I make my choice based on the features of the phone, the color, the price, whether it is wireless or not, and so on.

There are standards that describe the “blueprints” for the plugs and jacks, but the standards themselves are not the actual plugs or jacks. We separate the ideas of “a standard which may be implemented” and “something that is an implementation of a standard.”

To bring this back to software, the OpenDocument Format is a standard, a blueprint, created by a technical committee at the OASIS consortium. It is not software, but rather a description of how you should write out the information in word processing documents, spreadsheets, and presentations should you ever need to put them on disk or, say, attach them to emails. The same description also tells you that if someone gives you a document, spreadsheet, or a presentation and they tell you it is in OpenDocument Format (perhaps via the file extension), then your software applications know what to expect when they read the file.

Because it is a standard, the information can be used by anyone who builds software that complies with the standard. No one vendor can arbitrarily change it, and that provides a lot of security for people who save their documents in OpenDocument Format.

Another important standard is HTML, the rules by which you format pages for the World Wide Web. Although there were vendor differences in HTML in the mid 90s, most people no longer think that it is reasonable to allow vendors to break interoperability by implementing too little of the standard or doing their own special things. We don’t need different browsers to view web pages from different people, though some browsers like Firefox and Opera are known to adhere to the web standards, essentially the blueprints for the web, better than other browsers.

To extend my earlier analogy, we know that a web page (“the plug”) will fit into the browser (“the jack”) and then I can see and interact with the page (“I can talk on the phone”).

Just as we said in the 1990s that no vendor should have a control point by having their own flavor of HTML, we are saying the same thing about document formats in the 2000s. In fact, since word processors have been with us a lot longer than the web, it’s surprisingly that standards weren’t created, if not demanded, there earlier.

So, to summarize, a standard is a blueprint or a set of plans that can be implemented. Where do standards come from?

A de facto standard is a specification that became popular because everyone just happened to use it, possibly because it was implemented in a product that had significant market acceptance. The details of this specification may or may not be available publicly without some sort of special legal arrangement.

The basic problem with a de facto standard is that it is controlled by a single vendor who can, and often does, change it whenever the vendor decides to do so. This frequently happens when a product goes from one major version to another. At that point, everyone else who is trying to interoperate with the information created in the owning vendor’s product must scramble and try to make their own software work again.

This is easier, of course, if they can actually see the new specification and there are no impediments, legal or otherwise, to implementing it. The owning vendor gets a time-to-market advantage, possibly increasing its marketshare, again.

Traditionally, it was not in the interest of the owner of a de facto standard to make the details too widely available because they didn’t want to make it easier for anyone else to move into their market space. They would say, “Why would I voluntarily let other people build products compatible with my data? They might steal away my customers!”.

To turn this around, it is not in the best interests of customers to be locked into de facto standards controlled by a single vendor. The customer might say, “I may have used your software, but it is my information, and I very much want and demand the freedom to use any application I want to process my information.” De facto standards decrease customer empowerment and choice, though they linger on.

The second kind of standard I’ll mention is something I’ll call a community standard. As you might guess, this is something created and maintained by more than one person or company. The members of the community may work for companies or governments, belong to organizations, or may be experts who are otherwise unaffiliated. The standards creation process involves negotiation, compromises, and agreement based on what it best for the community and the potential users.

It is a classic fallacy to think that this necessarily creates a “lowest common denominator” or unsatisfactory compromise. Smart people can make good decisions together, even if they don’t all work for the same company. Conversely, people who all work for the same company don’t necessarily always make smart decisions. They might, for example, produce de facto standards that have security vulnerabilities.

Community standards usually get blessed, as I termed it above, by being created or submitted to a Standards Development Organization, or SDO. While it does happen that people may get together and write a standard from scratch in an SDO, it is very likely that one or more parties will bring drafts to the table as a starting point. It is usually expected that the developing standard will change over time as more minds are directed at the problem that the standard is expected to help solve.

A standard may go through multiple versions: it is not uncommon for the first version to take one to two years and then about the same time for each of the next one or two iterations. At some point it will stabilize and either become fairly universally used or else become eclipsed by an alternative way of tackling the same general problem. For example, the new web services standards are starting to be used for distributed computing, replacing older standards, as Service Oriented Architecture becomes more broadly deployed.

I want to return to this “community” idea for a moment. If you bring something to an SDO, you take a risk that others may change the specification, perhaps in ways that interfere with your product plans. One word: tough. Working within a community does not mean walking in and saying “I’m the king (or queen) and you can’t change anything unless I say it is ok.”

The value of creating a standard in a community is that products from different sources can work together to build solutions that solve real customer problems. If you can’t compete by creating superior, higher performing, more scalable, more secure products and perhaps the services to give the customers what they need, then I would suggest you have problems beyond not controlling the creation of a standard.

What you are basically saying is “I can’t win on a level playing field.” Your customers might be interested in hearing that.

Some SDOs are de jure organizations: they have particular credentials in national or international settings. Some governments have laws that make it very difficult to use standards that do not come from de jure organizations. ANSI, ITU, and ISO are examples of de jure organizations while groups like the W3C, OASIS, and the OMG are usually just referred to as consortia.

Sometimes a standard produced by a consortium will be submitted and blessed by a de jure organization to make it more palatable for government procurements. Of course, de jure organizations, like all standards groups, must be very careful what they bless because they have reputations for quality and relevance that they hope to maintain.

The last topic on standards that I want to address is what it means for a standard to be open. I’ve spoken about this previously in the blog but, at the risk of repeating myself, let me say that I think we need to consider five aspects of standards and ask some important questions about each of them:

  • How is that standard created?
  • How is it maintained after Version 1.0?
  • What is the cost of getting a copy of the standard?
  • Are there restrictions on how I can implement the standard?
  • Can I use just a part of the standard or extend it and still claim compliance?

In answering these, we need to think in terms of transparency, community, democracy, costs, freedoms and permissions, and restrictions.

  • The more transparent the standards process is, the more open the standard is.
  • The more the community can be involved and then actually is involved, the more open the standard is.
  • The more democratic the standards process is, where the community can make significant changes even before Version 1.0, the more open the standard is.
  • The lower the standards-related cost to software developers who want to use the standard, the more open it is.
  • The lower the standards-related cost to the eventual consumer of software that happen to use the standard, the more open it is.
  • When the licensing of the standard is more generous in the freedoms and permissions it provides, the more open the standard is.
  • When the licensing of the standard is more onerous in the restrictions it imposes, the less open the standard is.

From these and perhaps other criteria, we should be able to come up with some sort of “Standards Openness Index.” In the meanwhile, use them when deciding for yourself how open a particular standard is.

At this point I hope you have a good sense of what an open standard is. I also hope you understand there is a spectrum of “goodness” for several aspects of how a standard comes into being and how it might get used. “Open” has become a standard marketing term, so make sure you ask good questions of those who are trying to convince you that they are as or more open than the other guy.

In Parts 2 and 3, I’ll talk about software development and we’ll start to ask questions about openness in terms of software implementations. Just as we saw with standards, there is a spectrum of “openness” when it comes to the creation and use of software. Open source software is a large category, but I’ll focus on some of the basic issues and how open source can be related to open standards.

One last thing to think about: near the very top of this discussion I talked about how a standard can be considered a blueprint. Do people ever freely give away things they make from blueprints? Does that make business sense? Did you ever sign up for a cellular phone service and get a free phone? Why didn’t they charge you? Do they make their money elsewhere?

Comments are closed