Standards are rarely created for the benefit of the industry, although that can be useful by-product. More often, they direct an industry for someone’s benefit.
Standards often are seen as an industry coming together to agree upon a common solution to a common problem, but there are times when this could not be further from the truth. Having been involved in standards at all levels — from participant to chair for several standards — some were successful, some were not, some are seeing significant adoption while others are withering by the wayside, and some are being blocked by those who stand to be disadvantaged by them. The truth of the matter is that standards can be political hornet’s nests that are fashioned to divide as well as to bring together.
There are many types of standards, and the most successful ones are probably de facto standards that have been transformed into open standards. In our industry, one the biggest success stories was Verilog. Originally developed by Gateway Design Automation, it was acquired by Cadence and eventually became an open standard. Since then, it has been extended and built upon. But this only happened because it was threatened by the release of VHDL, a language defined by DARPA that started to see widespread global adoption. The threat was enough to push standardization and turn it into an open standard.
There have been other cases where a standard has been stalled to prevent one vendor having an advantage in the market. This often happens when a company has a robust piece of technology that is being offered as a standard. While the industry may agree with its merits, they want to stall ratification of the standard until they have an implementation they can announce at the same time as others. In the worst cases, they do this by inserting something in the standard that makes it difficult for the donating company to implement – given that they have to retain backward compatibility with their existing capability. In some extreme cases, this can result in the donating company actually being late to announce a fully compliant implementation.
I know of one example where there was a significant disagreement involving one detail of a standard. It turned out that one member of the standards group could not implement a specific feature. This was not revealed by that member, and thus even when a compromise solution was offered so that both alternatives could be used, the compromised vendor attempted to delay a vote on the issue. Rather than accept the outcome, they left the standards group and dropped all support for the standard and worked toward an alternative.
I also have seen examples where the creation of a standard was done to disrupt a market in which one or more companies did not have a competitive product. By partially excluding the leading market share company, it can be engineered such that they have to play catch-up and lose market share in the process. Many variants of this have happened and, in some cases, completely blindside a competitor.
Why am I writing this now? While conducting interviews for my story on UCIe, I have never done research where more people asked to be off the record. They want to show support for one standard and denigrate the other, but they don’t want their companies to be associated with those comments. This tells me there is the party line, and then there is the emotional aspect of the race between two competing standards. In some cases, it is clear they want to preserve the investment they have previously made, and they are worried about that investment being lost. In other cases, it is clear they dislike the way that vast amounts of money can buy you anything — even if the solution is not as good. Think back to the VHS-BetaMax wars of the past.
Companies do not partake in standards efforts for altruistic purposes. They do it because it will expand their market or benefit them in some way. Participating in standards is expensive, and decisions are based on the allocation of capital, just the same as any other product development. Participating in standards often requires a lot of politicking, a lot of time, a lot of patience — and, sometimes, the ability to hold one’s tongue.
A very insightful article. Many years ago, when I was bringing PCs to General Motors Powertrain industrial control standards were just beginning, but the talk of standards was used to try to slow the adoption of factory floor PCs and the flowchart language used in these systems. Fortunately, the GM manager driving the early trials of factory floor PCs and Flowpro would turn to the naysayers and simply say “the one thing about standards is, that they freeze the past”. New standards do not always win, as in my case, but standards are a good thing.