by Dave McAllister

Created

October 2, 2012

Many years ago I wrote a posting on the similarities between standards development and open source.  It seems like now would be a good time to revisit that topic, given all the activities that are blurring the barriers.

The premise still remains.  Standards are designed to stabilize a technology or interface, package or connection. Open source is driven by continual development. Standards tend to update and publish on a schedule measured in years, while open source updates and publishes in sometimes days. Standards drive the status quo. Open source  (often) drives innovation.

However, the engagement between open source and standards are creeping ever closer together. We now see significant standards developments defined by and driven by corresponding open source work. Think HTML5, CSS, even (now emerging) ECMAscript (Javascript by any other name).  We have seen significant trends to allowing the acceptable advances in open source software to define the standard.next. In short, the cycle of innovation adoption within standards is becoming significantly shorter as a reflection of the popularity of ideas expressed within open source products.

This really shouldn’t surprise anyone. Open source is the operative paradigm for development these days, whether it is within a company firewall or not. Open source underlies even the most innovative of closed software products.  Estimates from analysts state that 90% of software is a hybrid of open source and closed source code.  Open source practices help define innovative techniques, or to paraphrase “Linus’ Law” from Eric Raymond, “Given enough eyeballs, all ideas are approachable.”

Even certain of the conceptual business models of open source align with standards development. In software, revenue is often driven by scarcity. In open source, revenue is driven by ubiquity.  The more potential places to sell adjacent tools, services, and support, the more potential revenue capture.  (Yes, that’s not the only model for open source revenue.) Even in proprietary products with open source underpinnings, the more widespread the underlying package, the more potential gain from that products innovation and support in the community. Standards attempt to capture this common denominator.

Of course there are risks in this approach. Interminable “conversations” can stall progress to stabilization.  Speed of innovation can threaten the success of a defined standard. Intellectual Property concerns, in particular patents, can derail efforts in crossing the barrier between open source contributions and standards development.  Yet those risks are manageable, though the process of managing them often upsets the mindset of open source developers.  Contributor License Agreements and ownership assignments are just two of such concepts.

Adobe believes in the power of open source to allow innovation in standards. Projects like WebKit and Cordova help us demonstrate the appeal of new concepts and technologies in creating new platforms for all of us.

COMMENTS

  • By Andy Updegrove - 5:09 AM on October 8, 2012  

    Dave,

    A good essay, but I’d like to correct one point you make when you say the following:

    “Standards drive the status quo. Open source (often) drives innovation.”

    Standards do anything but drive the status quo – they enable new devices and networks to become possible that never did before the standards were agreed upon.

    In fact, standards drive radically more innovation than perhaps any other tool at our disposal. What standards “freeze” is not innovation, but base layers of technology that allow unlimited innovation above that layer. Without standards, there would be no Internet, no Web, no WiFi enabled devices, to telecommunications, and so on. The only things frozen in the Internet and Web are the protocols that allow them to exist. After that, the sky’s the limit.

    Stated another way, without interoperability standards, network-based systems couldn’t exist at all. That’s a very small tradeoff in innovation. It does mean that decisions made in setting standards should be very carefully made, since the consequences must often be lived with for a very long time (think railway gauges). But that’s where making sure that the organizations that create them have the right type of open processes comes in.

    Andy

  • By Paul Ourada - 11:19 AM on October 8, 2012  

    I didn’t think that Dave was saying that standards don’t drive innovation, because as you said Andy, standards have allowed many innovations due to creating transparency in APIs.

    However, I do think that he makes a point that it’s not easy to change standards, and open source tends to move much more quickly. Fortunately open source does move so quickly and provides much input to standards – or rather many major institutions do contribute to standards in conjunction to their open source work. However, as I think Dave is trying to state, at what point does the vacuum, or “draft”, if you will, caused by standards hamper the ever more quickly moving open source community. Or, alternatively, when will the open source community break free of standards, because standards cannot keep up.

    This is not a slight against standards (at least to me – can’t speak for Dave), but rather an examination of the current data, and a noticing of a trend which may present problems in the not-so-distant future.

    I also think that considering one issue does not necessarily invalidate what came before it. Again, I can’t speak for Dave, but that is how I read his essay.

    Paul