Why only strict standards are good for the customer and how to develop them

// 14th September 2018

Imagine a lose standard X. Any company can easily claim it is conforming to it and use it as a marketing instrument to lure customers into believing they actually buy a compatible product. But in reality the customer, not knowing the standard itself in detail, will not be able to switch vendors because the standard does not ensure real compatiblity. The main flaw of such a lose standard is that it does not restrict the things that are needed in order to switch between products from different vendors both claiming to perform a similar function.

It seems clear that such a lose standard has not much (if any) value for the customer, only for the companies (claiming conformance). So how can a standards committee ensure that its standards are actually serving its face purpose?

Watch out for conflicts of interest

Look at who defines the standards. If no customers are directly involved in the standards development then their interests will not be represented. In some cases only the companies are involved who have an interest in using the standard as a marketing label and as a result the standard will become a shallow facade claiming compatiblity but allow for completely incompatible products. So in order to actually serve customers, a standard development must involve the customers directly.

Make the standard open

If a standard is a document that can not be viewed for free and by anyone (even without registration) then this is the single biggest shortcoming of it. It should be readable by anyone, for free and without registration. Actually beeing able to read it allows for real evaluation by customers.

Create an open reference implementation

This allows for a robust standard. If a standard is just a written document then there are all sorts of details and errors that are present. This is due to the fact that most standards are quite complex in terms of the functions they standardize. The only way to overcome this shortcoming and find the errors and missing details is to actually go along and try to implement the standard.

The development of a reference implementation should be done by an open community and the implementation code should be released under an open source license to allow for real collaboration and to have the maximum eyeball exposure.

Create an open test suite implementation

This allows for any customer to actually buy a specific product for trial and check the claimed compatibility themselves. There should be minimal technical hurdles for the customer to actually use the test suite.

Compare products and show incompatibilities

This is to prevent usage of the standards name without actually living up to its claim. Products that are incompatible should be clearly marked as such, especially if the vendor claims compatibility. This ensures the vendors make a real effort to conform to the standard in order to get to use the label for their marketing.

How to finance standards development

So all these things, like the standards documents themselves, the reference implementation, the testsuite and the resources needed to discuss and develop as well as release to the public: they all cost money. The main stakeholders of a standard is the (usually big) group of customers which are actually normal people or other companies (not nessessarily the vendors of the standard-conforming products). So while this group is quite large it is also quite unorganized. This is the reason why many standard efforts start with a few large product vendors getting together, because they are usually quite organized and know how to approach this sort of thing among themselves (see conflict of interest above). Asie this flawed model, the following ways of financing come to mind:

A government effort

Since a standard is most often “for the people”, the customers, a government might be the right source for financing a standardization effort. And in fact this happens a lot for example with ISO.

A community effort

A group of customers gets together and starts an effort. They could potentially use a multitude of financing channels, for example private money, investments and funds. Investments by product vendors should be looked at though, because there is a serious conflict of interest. Any financing must never influence the actual standards development.

A single person effort

Similar to open source software development this approach is taken by single people and most standard development is done in their spare time and thus financed by their income through other work. Examples are Markdown and a lot of programming languages.

Any feedback or thoughts are very welcome!

Anyone pointing to specific standards that meet the described criteria or do not meet them, is highly appreciated. Maybe we can create a list to guide customers into the right direction!

©2018 by Tom Kirchner