Ken Krechmer's Adaptability Standards

By Rick Jelliffe
October 10, 2008 | Comments: 2

Ken Krechmer has been one of the leading proponents of the idea of Open Standards: his ideas are frequently cited. He made some typically interesting comments recently which I think are worth having wider currency:

Microsoft exerts control of its software APIs in many ways. One of the more significant is that Microsoft can change such APIs at any time with on-line updates. This prevents other companies, unless supported by Microsoft, from maintaining compatibility with the Microsoft APIs. So any standardization process that hopes to offer "openness" must provide a means to control such updates as part of its process. I don't think this point is addressed in the papers I have scanned.

Taking a technical approach to solving these problems has a much higher chance of success in the near term. OOXML and ODF is a sad state of affairs in the standardization world, but not for the reasons often noted. Fighting to create a single standard is an outdated standardization approach. When memory is very cheap it becomes practical to support two or more ways to implement compatibility (OOXML and ODF are both standards for document format compatibility). What is necessary is a standardized mechanism to identify, negotiate and select which way compatibility will be achieved. I term standardized mechanisms that support all three functions (identify, negotiate and select) "adaptability standards." The Fundamental Nature of Standards: Technical Perspective ( offers one lower layer approach to adaptability standards.

In internet connected systems, once adaptability standards are used it may not even be necessary to have compatibility standards.

Krechmer's Adaptive Standards pre-suppose the kind of frameworking and support for modularity that I have been banging on about for the last decade: see How to promote organic plurality on the WWW and the recent The Cathedral and the Bazaar and Standards.

As I understand it, Krechmer's Adaptive Standards approach implies that not only should you have standards organized into frameworks and modules, but that for internet frameworks, if the standard specifies how or where to down load the appropriate converter/handler module (like a codec), then you actually don't really need the standard for converter/handler. The framework is all that is necessary.

I currently cannot go nearly that far: that document standards need to have lives that outlive any particular system pretty well put the kibosh on it. However, I certainly do agree that concentrating on the adaptive standard as the bones on which to hang the flesh has to be the way forward. (This is also true of software.) And I am not sure that HTTP's mechanism for content negotiation has been any kind of success, as an example of perhaps the things Krechmer is suggesting.

The price of memory argument seems strange, unless it means that there is no reason why document formats cannot contain different components in alternative standards at the same time: this seems similar to the point I made in Can a file be ODF and Open XML at the same time (see also Harmonization by augmenting ODF with OOXML elements.)

You might also be interested in:


Microsoft are very good on maintaining compatibility of their APIs, in my experience. Of course, this is the API's that Microsoft offer to developers to use, not the cloak and dagger "secret/internal" APIs that some people fantasise about.

In our experience, we have had APIs work with no changes in our code for 10 years or more. The hardware has changed, the OS has changed but it all just still works.

Microsoft are very careful with compatibility/interoperability, which often means a lot of cruft over time. They will just add new elements to an API, which in some cases do exactly the same thing, but maybe in a better way, or offer more granular control etc. These may be given a completely different name, or contain a 2 in the name or something imaginative like that.

After a while, there may only be a few lazy folks still using the original API methods, everyone else is taking advantage of the new whizzy "2" methods, but Microsoft still take cares of it's venerable developers, rewarding the faithful with less work as they get older and more infirm.

I don't think we have much to fear from Windows Update ripping out and replacing APIs with reckless abandon. Bizarre as it may seem, Microsoft loves interoperability more than most, and probably spends more money on it than any other organization - as regards testing of 3rd party products ensuring applications and devices work with the latest OS.

They don't want thousands of mission-critical applications to stop working, so they are very bearish on changing APIs.

The entire etiquette/agent/broker/Faceman from the A-Team methodology for negotiation reminds me a little of UDDI. The problem there is of scale and "what's in it for me".

For his fax example, it's fine - every device knows it is going to be talking fax and the actors (Ricoh & the other organizations) involved are limited and focused.

Try doing the same thing for something with a much broader functional set and wider cast of actors and it falls apart in a heap.

Unless you can break down and generalize the functions of such an etiquette system so that it will work with any device and potential application, or possibly device class and application class it is merely going to be a helper app for a narrow standard or focus area.

As the classic revenue streams (paying for published standard texts) for ISO diminish, then different ways of funding may be required to allow Rick's wealth of interconnecting/interdependent micro-standards to flourish, since the "money" may not be flowing in from IBM, in the form of actual cash and expertise, nor from other companies, where these may not be as attractive from a business perspective.

If I wanted to participate in the process, then my employer would/could certainly not afford either the cash outlay for travel expenses etc, nor (and more importantly) the opportunity cost of my time.

Now if there was a nice juicy return for the company, then maybe it would be different.

Getting the enough of the right people to participate for the right reasons is certainly a conundrum.

Apologies for the rambling - constant interruptions from the epsilons (Paul Erdős' term for brats).


Another important aspect of adaptability standards - they provide the means to negotiate between public (free) and private (cost) functionality across the interface. Microsoft APIs could be public standards while specific aspects (the latest technology) are private.

In this manner the inventor (Microsoft or others) can be paid for features that users find sufficiently desirable to pay for, while the basic functionality of the API (or any interface) is available without cost.

News Topics

Recommended for You

Got a Question?