The idea of standards stretches back many years. While competition is good, competition around basic attributes of products in mature markets can obstruct customers. When they work–standard electricity voltages, standard railway gauges being two examples–society benefits greatly from them. Quality standards in particular prevent vendors messing with the attributes of products in ways that could be harmful.
When there’s a lapse–for example, the oxymoron of recognizing multiple standards in a space where there should just be one, as Japan did to its detriment in electricity generation–the consequences can be serious. But identifying just one standard you can trust for a given task can be difficult, not least because the economic consequences of such a choice make interested parties push the limits of ethics in order to influence the choice.
Software standards
In software, the way standards arise is still evolving, with a tendency to premature standardization, which arises from the exceptional pace of change in the industry. James Gosling has an interesting discussion of this which arises from his multiple experiences of standardization. He says:
Standards are regularly created and adopted before anyone has performed the experiments necessary to determine if they are sensible. Even worse, standards are getting accepted before they are even written, which is a truly ridiculous situation.
How this arises is clear: standards are increasingly being viewed as competitive weapons rather than as technological stabilizers. Companies use standards as a way to inhibit their competition from developing advantageous technology. As soon as technical activity is observed by political/economic forces, their interest rises dramatically because they see a possible threat that must be countered before it gains strength.
A counter to this trend over the decade or so since James wrote that has been to aim for not just standards, but open standards. To create open standards, multiple parties legitimately combine their interests and experience in a fair, transparent, accessible process resulting in a freely usable description that has multiple interoperable implementations.
The devil, of course, is in the details. For those who want to specify in procurement rules that they will only buy software that implements open standards, that makes it especially challenging. We’ve repeatedly seen that when government procurement in particular decides to define open standards, there’s either a career limiting backlash or there’s a weak definition that will probably do more harm than good in the long run.
Defining open standards
How can we tell if an open standard is actually open? One way is to come up with a definition of “open standards” and evaluate against it. Many have tried this, and there are a wide array of definitions of varying quality and complexity. The Wikipedia entry on Open Standards shows extensive variation on the definition. The fact there are so many attempts at defining the term suggests it’s a problem to start with.
But even if we could perfectly define “open standards,” it is only a matter of time before some suitably motivated party games the system. In fact, just defining a system of rules is enough to guarantee it will happen. Every system of rules contains within it the game that plays it and ultimately subverts it. Just looking at the definitions in the Wikipedia article hints at the many experiences (or in some cases intentions) of gaming by their authors. The most frequent issues appear to be vendor control of the process and patent licensing rules for the results.
Consequently, creating a universally-accepted definition of open standards has been controversial to date, and in my view will prove impossible in the future. Any definition strong enough to satisfy end-users and buyers will be rejected by vendors because it invalidates their games. Any definition already compromised by vendor games will be rejected by buyers as inadequate. And any definition that lays between those two end-points will be gamed and invalidated sooner or later.
Openness sentinels
I believe there is another solution. Instead of trying to define the term, how about instead looking at something that requires a standard to be open in order to survive? This is the sentinel principle–monitor an independent sentinel rather than the topic itself. Animal sentinels have been used for environmental monitoring (such as literal “canaries in coal mines”) because they respond in a structured way to many different factors on different scales rather than measuring a single factor. Whereas a set of prescriptive rules can be gamed, it is much harder to construct a game that falsifies a diagnostic sentinel.
In the case of a software standard, we ideally want to evaluate whether a standard is both mature enough to be ready for standardization (per Gosling) and also defined safely for use (in terms of patent licensing, open process, platform independence and so on). There are many different factors that need evaluating, and big corporations have experts whose only role is to make sure they meet the letter of any rules, regardless of the spirit.
The best sentinel would be a diverse community of experienced and intelligent software developers, all individually sensitive to different health indicators for a standard and collectively needing each others’ endorsement in order to proceed. Fortunately, it exists.
Open source as sentinel
That’s a pretty good description of a healthy and functional open-by-rule open source community. When a standard has a questionable character, the first place it’s likely to be identified is in an open source community that’s devoted to a technology in its subject area. If there’s no open source implementation of a standard, or if the only implementation you can find gets a low open-by-rule score, there’s a strong chance there’s a problem. It may be too new, too dominated by a single vendor, patent encumbered, dependent on a specific closed technology or faulty in many other ways.
That’s why, apart from all the other software freedom benefits of using open source, I tend to recommend to the authors of procurement policies that their rules prefer open standards which have open source implementations with open source co-development communities around them. A standard with no open source community implementing may well not be an open standard.
The open source projects don’t have to be mandatory to use; they just have to exist and act as a sentinel of openness. The open source project also plays a second role, assuming your procurement policy permits it. It ensures there is always a procurement alternative to whatever proprietary solution may be offered, which in turn places pressure on your suppliers to stay competitive because you always have a choice.
So even if it’s not politically appropriate for you to mandate a preference for purchasing open source solutions, at least specify they must exist to validate the open standards you’re specifying. It may be the canary song that saves you.
[posted at webmink.com]
Comments are closed.