Standards, APIs, and the Lessons of the WAC

Warning: Those who read my blog often will recognize the following material as a real "rant."
I've been watching a handful of related items slip off the rails recently and its been bugging me.
I need to get this out there, so... strap in.

GigaOM ran
one piece today
and
another last week, both of which opine on the demise
of the Wholesale Application Community
(WAC) after little more than two years on
the scene. Both writers complain that something like the WAC effort is needed and
both writers suggest, given the nature of the industry and the players involved,
it's not likely to happen. However, what they fail to notice is that, while in
this case the telco carriers are faced w/ a common problem, the attempted solution
was way off the mark.

"The Wholesale Application Community (WAC) will go down in mobile history as one
of the most ambitious, but failed, attempts at collaboration by our dear telco friends."

- Rip Gerber, Locaid

"What happens when you get four-dozen carriers in a single room? Apparently nothing.
The organization tasked with creating common carrier APIs, the Wholesale Application
Community, revealed on Tuesday it is dissolving, selling off its technology to Apigee
and folding its development efforts into the GSM Association."

- Kevin Fitchard, GigaOm

Its not the effort that fell flat, it is the very prescription itself which did
them in. And they're not alone, either. I see more of this kind of failure on the
near horizon unless folks change their POV and face some fundamental truths about
distributed networks.

Standardize Messages, not APIs

The key failure in the case of WAC was an attempt to standardize the wrong thing:
the programming interface. This is a common problem and one that is, apparently
difficult to learn since I've seen it before. For example, GigaOm readers may
recall another example of industry-level standards going astray summarized in
the "Cloudstack-Openstack Dustup" piece from April of 2012. I suspect several
readers can call to mind similar train wrecks in the not too distant past. They
usually share a common theme: disagreement on the details of the API.

All too often well-intentioned, intelligent committee members work diligently and
doggedly to identify the problem and then mistakenly apply the wrong solution.
While it's true (especially with regards to industry-level standards) that the
problem can be defined by reviewing the data and actions taken by various players,
it's a serious mistake to attempt to corral all the players into agreeing on the
same set of data points and actions for all members. This almost always ends up
in one of two ways: 1) a generic standard so hobbled that no member wants to use
it; or 2) no standard at all since all members cannot agree on a generic
standard to endorse.

The solution is right at hand, but few see it. The right way to go is to standardize
the way messages are designed and shared, not the data points and actions themselves.
In other words, the key to successful shared standardization is through media-types
and protocols. This is especially true for any communication over HTTP, but it also
holds true for standards operating at a lower level (i.e. TCP/IP).

The Success of VoiceXML

We don't need to look too far to see an example of an industry-led standardization
success.
VoiceXML
was started by AT&T, IBM, Lucent, and Motorola as a way to standardize
interactive voice system communications. Not long after defining the first markup
in 1999 (it took only a matter of months), the standard was turned over to the
W3C
for continued growth and refinement.

The goals of VoiceXML were strikingly similar in nature to the WAC and Cloudstack/Openstack
efforts: defining an interoperable standard that can be used across an industry group.
The difference in the case of VoiceXML is that the VoiceXML committee focused on message design
and domain-specific details shared by all players. They did not attempt to document
all the data elements, function calls, and workflows to be used in lockstep by everyone.

This is standardizing the manner in which parties communicate, not the actual information
they send back and forth. This is standardization that not only works, but can be agreed
upon without jeopardizing market efficiency or industry position.

The Future is Ours

If past is prologue, the WAC melt-down is not the last one we'll see. In fact, in
the last few weeks I've had the opportunity to scan two efforts, each from substantial
industry sectors, where the same mistake has been made; attempts to standardize the
actual API calls themselves instead of the message design used to communicate between
parties. I can predict with a high degree of certainty that the work will either be
abandoned before it is ever put into place or languish mostly unused due to it's
ineffective generic design.

This is not the inevitable result of competing interests in the global marketplace.
This is the doings of well-meaning people aiming at the wrong target, using inappropriate
solutions for real problems. We can do better. We can learn from successful interface
designs from both industry and open standards (i.e. HTML, Atom, VoiceXML, and others).
We can focus on making it possible to consistently communicate a wide range of information
freely between parties instead of attempting to narrowly constrain systems to a
single set of possible interactions.

The future of an effective Web, a growing and vibrant distributed network, rests
in the hands of those who would take on the task of writing the vital standards
which make it work. I, for one, am not looking forward to seeing the same mistakes
repeated over and over again. On the other hand, I am optimistic that there are
enough dedicated and talented individuals, ones committed to the future of open
communications, ready to join standards committees, ready to ask hard questions,
ready to teach and to learn, and ready to meet the challenges that lie ahead.