The “innovation policy” community has a touching faith in the power of an “open standard”, a technology protocol that is not controlled by a single player in the ecosystem but is the result of a — more or less — open process involving any interested party. And there’s a lot to be said for openness.
Sadly, not all open standards spur innovation, and not all innovative standards are open. As an example of the former, consider the original Web Services protocols, which were open but mind-numbingly difficult to implement. Web services didn’t start to take off until the REST-ful variant (a much simpler “lightweight” protocol) gained traction. As an example of the latter, consider the standards connected with writing, publishing, and monetizing apps in the iPhone/iPad ecosystem: tightly controlled by Apple (a consideration which vexes the app developer community considerably) but nonetheless spurring explosive innovation.
In sizing up the innovative potential of a standard, I prefer the idea of a “disruptive standard”, by analogy with Clay Christensen’s “disruptive technology”.
A disruptive technology is an inferior technology which is, however, “good enough” for its marketplace, and, because it is cheaper or easier than the dominant technology, it gradually gains share until it edges out the “superior” one.
A disruptive standard has the same character. The REST protocols for Web Services were much much simpler than the original Web Services stack, and (to hear the XML-erati talk about it) much inferior. Nonetheless, the ease of implementing this standard edged out the more complex one, and thereby spurred a “revolution” in service-oriented architectures.
Consider also HTML and HTTP, two technically crummy standards which together essentially enabled the World Wide Web.
A disruptive standard needs two key elements to succeed:
A cheaper and/or easier approach to the design problem than the incumbent, so that a bigger and bigger class of problems can be solved using it
Extensibility in some “democratic” sense (it’s easy for the community to extend it without an oppressive central authority) so that the standard can evolve organically as new use cases come up.
2) probably trumps 1) in terms of importance. In the case of the Apple iPhone/iPad ecosystem, for example, the iOS development environment and deployment through the AppStore fits 1) but not 2). Although it’s a bit harder to develop an Android app, the standards involved can evolve with some Steve Jobs approving of them, and therefore Android is pulling ahead in the mobile client wars. But both aspects are important.
Look for disruptive standards to jumpstart innovation, not just open ones.