mca blog

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).

To borrow a well-worn phrase: "The medium is the message."

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.

The future is ours.