Avoiding Protocol Capture

Vendor capture is a persistent and fundamental danger to any standardisation process.
Avoiding Protocol Capture

What is an open standard?

To understand why there is no single agreed definition, and to let us build a canonical definition, we can start with two observations:

  1. The standardisation process is driven by two conflicting economic motives. Vendors see standards as a route to direct profits, while the market at large sees standards as a route to lower costs.
  2. As the economy has become digital, the State has become engaged in the conflict between these two interest groups.

We as open source developers must explicitly take the side of “the market at large”. We must not accept the definitions of “open standard” produced by vendor bodies. We must absolutely reject all attempts of legacy vendors to stretch “open standard” to include RAND-licensed standards.

An open standard must be aimed at creating unrestricted competition between vendors and unrestricted choice for users. Any barrier to vendor competition or user choice is incompatible with the needs of the market at large.

Vendor Capture

Looking at the standards “wars” that plagued the telecoms and media industries, we see that the fight is not over technical quality or process. The war is to capture markets through the use of standards backed by patent pools. The goal of vendors who engage in such standards processes is to become part of the cartel and to kill or capture the other cartels.

Vendor capture is thus a persistent and fundamental danger to a standardisation process. Incompetence and human error are fixable by collective processes and time, as long as standards are free to improve. Vendor capture occurs at any stage in the life-cycle of a standard, from development through to long-term use:

  • Vendors capture the standards development groups and exclude open participation in the development process. The standards which result become dumps of the vendor’s software, which gives significant advantage to vendor.
  • Vendors capture the standard specification through copyright and reduce competition from smaller competitors by making it expensive to simply acquire the text.
  • Vendors capture the market by introducing patented technology into the standard, silently or explicitly. When many vendors do this, they create franchise standards (“reasonable and non-discriminatory” at the best of times) that enable cartel-like constructions.
  • Vendors capture the market by silently extending open standards. Users who thought they were getting an open standard may instead be buying lock-in. Vendors capture the standards authorities. They do this by setting up their own (like ECMA) or lobbying existing ones (ISO) to promote and accept their advantageous standards.
  • Vendors capture existing open standards. They do this by acquiring key patents, long after the market has committed to the standard. Often, such patents were held originally to “defend” the standard.

Free and Open Standard

The term “open” itself has many degrees of meaning from a high wall with a crack in the door to a field with no walls at all. We wish to secure the terminology by adding the word “free”, in both its meanings:

  • Freedom to use, improve upon, trust, and extend a standard over time.
  • Freedom from all costs and tariffs associated with the above freedoms.

The ambition of freedom in this case is the removal of barriers, of friction, and of costs. It is also the ambition of remaining free over time, especially as the value of the market based on the standard increases.

A canonical definition

From the above analysis that the interests of established vendors diametrically oppose those of the market at large, we can make a simple canonical definition of “free and open standard” as follows:

  • A standard is a published specification.
  • It is a a free and open standard if it is immune to vendor capture at all stages in its lifecycle.

Measuring immunity

Immunity from vendor capture can be measured. This is very useful because it gives us a tool to measure how “free and open” a standard is, and to offer concrete suggestions for improving any given standards process or specification.

We look at each aspect of the standardisation life-cycle, from development to wide-spread use, ignoring quality issues, which we assume an open process will detect and improve.

The development process

In which experts agree to work together to standardise an area of technology:

  • What is the cost of entry for experts? If not very low, independent experts are excluded.
  • Do vendors form the majority of developers? If so, the standard will be rapidly captured.
  • Do all developers grant their copyrights to the standard by contract? If not, copyright and patent claims may be used later to capture the standard.
  • Can others freely fork the standard under a “share-alike” license such as the GPL or MPL? If not, a captured standard cannot be freed again (e.g. the State enforces Apple’s capture of freeBSD because it was developed under the “free-to-capture” BSD/MIT license).
  • Is the standard developed publicly with no decisions being made out-of-band? If not, external reviewers are excluded and vendors can more easily capture the standard.
  • Is the process completely transparent and open? If so, vendor capture is easier to see and correct.
  • Is there a process for accepting specification translations? If not, foreign vendors are put at a disadvantage.
  • Is the development process hosted by an unruggable platform?

While “forking a specification” may seem counter-productive, we consider this an essential freedom at this stage in the standard life-cycle. Sometimes, a standard will become “loaded” with features that favour one vendor and exclude others, and the best way forward is to fork the standard, strip-out those features, and create a competing standards process. The simple possibility of such competition forces a more honest process.

The implementation process

In which vendors - often also standards developers - take provisional specifications and use them to make products:

  • Is the specification text clear and well-engineered? Vendors often inject complexity into specifications to create barriers to competing implementations.
  • Are there reference implementations freely available? This promotes a level playing field. Copy-left implementations ensure that closed source derivatives that silently modify the standard are not possible.
  • Is the standard free to implement for any purpose? If particular license conditions apply, this is easily used to exclude competitors.
  • Can the specification be freely acquired and distributed? If not, cost can be used to create barriers for smaller competing vendors.
  • Is there a process for contributing change proposals back into the standard? If not, it is easier for vendor-developers to capture the standard.
  • Are there outstanding patent or copyright claims on the standard? If so, vendors are unable to freely implement the standard.

The certification process

In which the standards group, or other groups, help define what is a valid implementation and help the market measure and compare implementations:

  • Are there conformance tests freely available? This promotes a level playing field among vendors. We would argue that copy-left licenses are most appropriate for conformance tests.
  • Is certification done by a form of unruggable organisation that itself can be forked? If not, it is trivially captured through acquisition.
  • Are there clear rules for building subsets and extensions? If this is part of the standard specification itself, users can demand better behaviour from vendors.

The deployment process

In which users use standards-based products to construct their own business infrastructure:

  • Is there a real market of competing vendors? If not, this is a sign that the standard has been captured.
  • Is the standard mature and well-certified? If not, users can be captured by vendors who release incompatible implementations.
  • Is the standard free from patent claims? If not, users are trapped by using the standard in any way at all.

The authorisation process

In which an authority declares its support and recognition of the standard:

  • Is the authority backed by the State or vendors? Vendor-backed authorities are by definition captive, and will readily promote franchise standards as “open”.
  • Is the authority meritocratic? That is, are its decisions taken by experts with proven track records in standards recognition? If not, the authority can be easily captured by vendors.
  • Does the authority have clear, transparent rules on copyright and patent claims? If not, franchise standards can be injected, capturing users by deceit.
  • Does the authority have a clear definition of “open standard” that represents the economic interests of the market at large? If not, vendors can more easily defeat open standards with franchise standards.
No comments yet.