Ten years ago this month I wrote an issue of Standards Today in which I predicted that the traditional practice of developing standards would no longer be sufficient to provide solutions to information and communications technology (ICT) challenges. The reason I gave was that many problems demanding resolution would be too complex, too cross-sectoral, and too urgent for the old way of doing things to suffice.
The second part of my thesis was that while we should acknowledge that standards are simply tools and not an end unto themselves, it is important to recognize that the way they have traditionally been developed is extremely important. What makes standards so special is that multiple players – usually competitors – collaborate to create tools they then voluntarily use to compete with each other by creating value added goods and services on top of the standardized layer of technology.
The goal, I suggested, should therefore be to identify what is special about this process so that the same principles can be followed to create new processes capable of solving today’s more complex problems, in part by preserving the motivation for competitors to work together to voluntarily create and deploy those solutions.
Here’s how I summarized that line of reasoning ten years ago:
In point of fact, the very concept of a “standard” may be becoming outdated, or at least too limiting. Recent years have seen the evolution of new ways of achieving results that traditionally would have been reached through the development of standards. The most obvious example of such a new technique is the open source project, of which there are thousands now in process.
As a result, these days, I usually speak and think in terms of “commonalities” instead of standards when I want to describe how to get the interoperability job done. What is a “commonality?” A commonality, I would submit, is:
• Whatever tool(s) we need
• That we need to agree on
• In order to do what we agree needs to be done
Let’s look at each of these elements individually. For a given job, more than one tool may be needed (perhaps a traditional standard, or set of standards, and an open source reference instantiation). The second element is the most familiar, because consensus is still needed for all the usual, good reasons. And while the third element also has a familiar sound, it contains a subtle, new twist, because what we agree needs to be done is changing. Most obviously, new realities (such as the marriage of telecom and wide area network computing) require the interplay of scores — if not, indeed, hundreds — of interoperability standards in multiple devices in order to complete tasks that we now take for granted….
I believe that the time has come to increasingly think from the bottom up, and in terms of commonalities. The result will be a world in which collaborative efforts will better address the real needs of real people. At the same time, commercial opportunities for vendors and service providers will evolve faster, and with less risk, than through the continued development of the standards of old, using the methods of yesterday.
Last year saw the public launch of a number of efforts that convincingly illustrate the fulfillment of this prediction. One of them, called the AllSeen Alliance, is focused on making the long-heralded “Internet of Things” a reality and is already making rapid progress in pursuit of that goal. As I wrote at the time of its launch, AllSeen is an example of a new type of collaborative effort creating a very new type of deliverable:
…the mission of the AllSeen Alliance includes creating a layer of software that implements existing standards and finesses the need to create many new standards, because anyone can use the software right out of the virtual box. In other words, it is the framework, rather than a description of one – ready to go, and already interoperable by design. And because it’s open source, it can be readily and easily adapted as needed by anyone to allow their particular things to join the party….
As importantly, all this can be done very quickly, rather than through a series of sequential steps. Instead of taking a long time to create a standards framework and then try to persuade vendors to adopt that framework, the framework has already been substantially instantiated in actual software, which will become richer and multi-purpose as the effort continues.
That’s a revolutionary rather than an evolutionary step in the history of open collaboration, marrying open standards and open source in a way that hasn’t happened before.
This week, another similarly ambitious and variegated collaborative effort held its first summit, during which the relevance of standards in the context of new and complex challenges was vigorously debated. That effort is called the OpenDaylight Project, and its mission is to develop some of the key elements needed to enable software-defined network architectures [disclosure: both AllSeen and OpenDaylight are hosted by the Linux Foundation, and I provide legal representation to all three organizations] Carol Wilson reported on that debate in part at Light Reading as follows:
In general, the networking industry needs to let go of what Guru Parulkar of Stanford University and the Open Networking Lab called its “obsession” with standards, and allow the ultimate choices to be determined by what works in the real world.
“We need to standardize as little as possible,” he said. “You can’t keep the same standards process in place once you become more software-based.” …
[Dan Pitt, executive director of the Open Networking Foundation ] reminded the crowd that his board is comprised of major telecom operators, and what they are focusing on is the art of the possible, not elegant approaches to building plug and play networks.
“We have to match what is needed with what is possible,” he said. “We are working at solutions that succeed because the ultimate goal is commercial success.”
Whether standards are still relevant is beside the point (although for the record, they clearly are, depending on the problem to be solved). Similarly, we need to be careful not to forget that open source software is also only a tool, and not an end in itself.
Instead, I submit, the lesson to be learned is that we should focus on the vital importance of “commonalities.” In other words, when a new challenge is identified that requires a non-proprietary solution, the first step should be to determine:
• Whatever tool(s) we need
• That we need to agree on
• In order to do what we agree needs to be done
Whether those tools should be standards or open source software is something that should not be assumed in advance. Indeed, the right collaborative process and deliverables for the job may be something new entirely, something that has never been tried before. But unless we think in terms of commonalities, that solution may escape us entirely.
Sign up for a free subscription to Standards Today today!
Have you discovered The Alexandria Project?