People stop me all the time and they ask, “Bob, what is an open standard?” And I tell them, well it depends, but if you read my blog you would have an idea of some possible answers. They then look really scared and I never see them again.
All kidding aside, I have tried to force some examination of what the word “open” means and warn against its use as a marketing term. I’ve also put forth the idea that we should consider “closed” and “open” as two ends of the spectrum. Here “closed” means “it’s mine, you can’t have it” and “open” means “here take it, do whatever you want with it.” Most standards fall somewhere in between, with very few things being all the way at one end or the other. This language is still imprecise, so let’s take some time to look at what we might really mean by this use of the word “open” in the extreme sense of “purely open.” To be clear, I’m not the only one who has looked at these types of things. In particular, my IBM colleagues Tom Glover and Chris Ferris have thought and written quite a bit about this, so I’ll attribute the really good ideas to them and save the bad ideas and mistakes for myself.
I think there are five areas we need to look at:
- Modification by Others
Let’s consider them in turn. Remember, this is meant to describe the extreme meaning of “open.” After this initial discussion I’ll return to some things to be considered when you decide how open you need a standard to be.
Development: A purely open standard is created in a manner that allows anyone who wishes to participate to do so without discrimination. All proceedings and records of proceedings are public and decisions are made by consensus. No one can prevent anything that actually happened during the development of a standard from being recorded in the minutes. There are no secret agreements. No one person or organization can veto a decision.
Maintenance: Once created, a purely open standard is maintained by a community under terms similar to that which developed the standard. In addition, the community has a responsibility to maintain backward compatibility if it decides to do so. That is, openness gives the maintaining community the right to make significant modifications, but since membership is not restricted, the community may get enlarged at times by a sizable group of people who may either want to force the changes or maintain the status quo. (This is just democracy in action: if you get more people to vote for you, you win.) So while significant changes may be made in the evolution of a standard, it is not done at the whim of a single vendor unless that vendor can garner significant independent support. As in the development of a standard, all votes or positions taken during consensus creation are recorded for all to see.
Accession: Anyone who wishes to have a copy of a purely open standard may have one at no cost. When possible, the standard is available online and the document format used to represent the specification is an open document standard (I know this is recursive, but you know what I mean).
Implementation: A purely open standard can be implemented by anyone in any way desired with no payment of royalties.
Modification by Others: A purely open standard can be mined for its good ideas and used in part or in whole in other standards. In particular, a profile can be created that states which parts of multiple standards should be used together to achieve a certain end (for example, a subset of a set of standards for use on mobile phones).
What are some of the problems with these criteria?
- Standards development organizations (SDOs) have expenses. They may need to pay for permanent staff, lawyers, websites, conferences, offices and other ongoing expenses of formal organizations. Where is this money to come from if there are no membership fees or costs for acquiring standards? Perhaps an SDO survives by accepting voluntary donations from participants with a “give if you can and want to” model. Giving more should get you no more privileges than if you give nothing. If this still doesn’t generate enough money, then the SDO may go out of business. It also begs the question: if no one is willing to support the effort, why does it exist in the first place?
- If you can’t get a copy of the standard for free, how much is too much? If it costs you $5, is that ok? How about $500? What if you have 2000 developers that need a copy? I tend to think free is really the best answer here, at least for an online version.
- Standards efforts need to be sustainable in order to maintain specifications. This brings us back to the funding question, but also makes us think about how one organization might pick up an effort when another decides to no longer pursue it. Note that because of the community nature of purely open standards creation, it is likely that some group can be found to maintain the standard, whereas a closed de facto standard might vanish if the owning vendor goes out business, gets sold, or simply decides it wants to something different.
- If membership is completely open, you have to make sure you have rules that prevent an organization from “stuffing the ballot box,” that is, sending many people to vote for or against a proposal.
- Can you really be sure that no one can put up a barrier to implementation of a standard? In a purely open standard, the creators of the standard can presumably be prevented from putting up such roadbloacks, but what about others? Do you allow legal concepts such as reciprocity and defensive termination to be in license agreements for purely open standards? Can they actually help make it purely open?
- In a purely open standard, license agreements do not have tricky or cute language that prevent open source implementations. Should a license just allow implementation of the standard or should it also allow arbitrary derivative works that go beyond the scope and intent of the standard?
- In order to maintain control of a standard it creates, an SDO may copyright the specification and so prevent subsetting or extension. However, certain permissions may be included that liberalize this. Which conditions are acceptable?
- You need to maintain some sense of an official version of a standard, so you don’t want to allow such looseness that someone claims to implement a standard if only a small subset is actually handled. You also want to prevent people from unilaterally extending a standard, thereby preventing interoperability and allowing undo advantage to one implementor. Here an open source reference implementation will help and do two things: 1) provide a test case for compatible implementations, and 2) allow people to quickly use a standard without waiting for proprietary implementations.
If you have read this and conclude “ha, we can’t really get an open standard so we’ll muddle through and do what we want”, then you have misunderstood what I am talking about. Since most standards fall between closed and this “purely open” characterization, you need to decide what is important to you. For example, a government may decide that it really cares about Maintennace, Accession, and Implementation and will try to use standards that maximize those characteristics while being willing to concede a bit on Development and Modification by Others.
For some kinds of standards efforts, it may be easy to obtain patronage for the effort that therefore allows anyone interested to join. The nature of the effort may preclude troublemakers from taking advantage of the rules. That said, you need to be careful and precise in the membership and participation rules and always think about how someone might abuse them. To paraphrase Bo Diddley when speaking of the music business: “Trust no one, except your mother. Even then, keep an eye on her.” Ideally, standards would be created in an environment of trust. You just sometimes have to legislate trust.
In practice, I think it is probably easiet to tell when a standards effort is less open than you think it should be. Here are some danger signs:
- control by a single vendor,
- overly complicated license agreements,
- license agreements that reserve certain special rights to individuals or vendors,
- license agreements that prevent some kinds of implementations,
- overly complicated procedural rules that can allow people to be less democratic than they should,
- a history of disregard for backward compatibility,
- costs of participation that exclude individuals or small organizations,
- high costs of obtaining copies of the standards,
- standard specifications not being openly available online,
- for XML-based standards, allowance for proprietary, vendor-specific extensions.
Some of these are worse than others: you will need to decide for yourself how open you need the standards you use to be. As I’ve suggested in other entries, I hope that we eventually come up with a grading system that allows us to compare two specifications side by side and see which one is more open. I hope that what I’ve written here is a start on such a system. I believe we’re getting more and more open every day. Such a grading system will help you tell whether a particular standard is more open than it was last year and whether it is on a path to be more open next year.