Product & Startup Builder

The challenge of developing Open Standards

Added on by Chris Saad.

A lifetime ago I created something called the DataPortability Project and, separately, proposed my own standard called APML. I also co-authored the Backplane standard. The first two were not very successful in achieving their mission. The latter is currently enjoying a medium amount of success.

During these experiences, and while observing other standards efforts (particularly in the social media and web space), I've come to be quite jaded about the Standards process

I still believe deeply in the vision of Open Standards. A world where independent parties can interoperate with each other without prior negotiation means that there's free and rapid iteration for the benefit of everyone.

Most of life as we know it is enabled by standards of one kind or another. From which side of the road you drive on to the shape and power coming out of your wall socket. The Internet itself is a miracle of technical standardization - from TCP/IP to HTML5.

The reality, however, is often times far messier and more frustrating than one would expect and hope. It's caused me to rethink some of my earlier, perhaps naive, points of view.

So, despite my love and admiration for the work and many of the individuals, I'd like to indulge in a post about the frustrations with standards and the standards community...

  1. The standards writing community tends to be mired in politics divided along minutia like HOW to organize yourself and WHICH technical approach is the most elegant and WHO is running what clique. You have to approach it in exactly the right way or risk offending someone (this post likely wont help).
  2. The community tends to be fairly academic resulting in commercial applications and/or ease-of-use taking a back seat.
  3. If any commercialization does happen, only the 'losers' in the market tend to participate so it never becomes dominant or particularly useful at solving the end goal (which is not openness, but interoperability). Even when big players participate they tend to send people who do not have the political capital at their company to adopt what's been developed in any meaningful way.
  4. For some reason engineers/implementers would rather create a proprietary format or protocol over an open standard just because the latter sounds like more work. Unfortunately often times they're right.
  5. it's easy to write a technical spec and propose it as a standard. The problem is getting consensus amongst the technical community and adoption by companies that matter. Unfortunately most standards efforts get stuck on the first part and never even begin to tackle the second and most important part. Adoption is far more important than getting every technical detail correct.
  6. As a result the standards often die on the vine or shortly thereafter.

As far as I can tell real standards tend to emerge only after proprietary innovation is created and commercialized by a first mover who wins big. Part of their competitive advantage is they get to control the implementation and iterate on it quickly. This forces competitors to fast-follow (read: copy) the conventions and models of that market leader.

This results in a kind of rough, market led convention that, while not open and interoperable, lasts for pretty much the entire cycle in which the particular technology is relevant, interesting or rapidly changing. This can take many, many years. Decades even.

Once that layer/component in the technology stack becomes conventional (read:boring) and the battle (read:unique value prop and lock-in) has moved up the stack, then standards groups can get together, figure out the common cases (which have now stabilized and been fully figured out), sand the edges and create true interoperability.

Said another way... you can't standardized the innovation before it's played out in the market and had a chance to run its course. Then you can retroactively write down what happened.

Let the hate mail begin :)