An important shift is under way that's helping bring interoperable products to market more quickly than in the past. Rather than working in isolation in their separate domains, technical standards bodies and open source communities are becoming more closely intertwined.
Customers, service providers, and equipment makers alike benefit from this collaborative approach, which is making the IT industry more competitive and reducing the barriers to entry for new participants.
The need for “open” standards
The goal of standards is to provide interoperability and data exchange across diverse products and services from multiple vendors. To achieve that goal, standards must be widely implemented.
Historically, defining a standard has been a lengthy process in which a group of stakeholders in a particular industry segment or technology area (usually vendors) determine the key behaviors and other common denominators needed for interoperability. The result of their efforts is typically a lengthy written specification that companies then have to figure out how to develop into products.
While this process has worked for decades, it has shortcomings. Too often, these printed standards are bloated with features and functions that customers and even vendors don’t need or want. In addition, standards bodies can be highly politicized. It’s not uncommon for the market leader in a given area to dominate the activity in a standards body, and even attempt to drag out the process to protect their market position. In some cases, participants in a given technical area may not be ready for a standards body approach, or they lack the time to reach consensus around a standard.
The traditional standards-making process is out of sync with the rapid pace of today’s software-driven industries and the inclusion of more open source software in products. Given the pace of our industry, standards must be open for faster development. I use the term “open” standard to refer to a type of technical standard that is not produced in a vacuum of closed membership contributors, but by a technical community that is actively engaged in open source instantiations of its standards in software.
Standards bodies need to work in concert with software developers and, ideally, should deliver both written specifications and code that enables a standard to be implemented ubiquitously.
The role of open source
Open source communities have been around for decades, successfully creating and distributing software. Their importance has risen substantially in the past few years with the advent of server and storage virtualization, containerization and orchestration packages, and integrated deployment. In addition, the introduction of software-based standards such as OpenFlow for software-defined networking (SDN) have pushed more and more functions, from networking to telecom services, into software.
With open source projects, development is a collaborative, ongoing process and source code is made freely available to the public under open source licenses. Individuals from academia, research networks, and many other organizations contribute to open source projects, often bringing a different skill set and perspective from those of corporate developers.
A key strength of the open source community is its ability to quickly incorporate new capabilities into software and to modify code in response to real-world usage. I’ve seen hardware manufacturers whose equipment passed standards-based conformance testing end up failing interoperability tests when faced with newer software versions that outpaced the written specification.
In a plugfest or appfest, the software (and the firmware in the networking equipment) can be changed in real time should the odd bug or incompatibility arise. No standards body meeting provides this level of assurance.
When the open source community works collaboratively with standards bodies, a standard can be quickly implemented, tested, and propagated throughout an industry segment. Vendors benefit from being able to bring standards-based products to market rapidly. Since they don’t need to develop all the necessary software from scratch, vendors can focus on value-added features.
Customers benefit from having more choice, including the ability to mix and match interoperable products from different vendors in the same environment. Customers also can use open source software within their organizations, and modify it to fit their particular requirements. New models of economic benefit can arise from vendors extending their service coverage to include software testing and deployment as new versions of the open source application become available.
As the primary standards development organization for OpenFlow and related SDN specifications, the Open Networking Foundation (ONF) is actively working to support a collaborative relationship with the open source community.
We’ve seen how the open source community modifies its software essentially in real time based on what its learns during the many OpenFlow interoperability fests that have been held for Open vSwitch, OpenDaylight, the Open Network Operating System (ONOS), and other SDN-related open source projects.
These developers are eager to know what’s going to be in the next version of the OpenFlow specification and how the architecture will change.. They want to offer input based on their real-world experience with implementing the specification, and be prepared for what’s coming next.
Consequently, ONF has established relationships with the Linux Foundation, ON.Lab, Open vSwitch and other communities that want to collaborate across open source projects. Rather than take a “kitchen sink” approach to new versions of the OpenFlow protocol, ONF has learned to allow the controller software developers to identify software trends that need standardization, not the other way around.
In addition, ONF is sponsoring the Open Source SDN (OSSDN) project, which is focused on producing open source software that instantiates the OpenFlow standard. OSSDN models its licensing for all open source projects on the Apache 2.0 licensing model, which allows for collaborative development but protects commercial enterprises that embed a copy of OSSDN software into a commercial product.
The world of standards making is changing -- for the better. Rather than operating in isolation, standards bodies such as the ONF are recognizing the tremendous benefits of working hand-in-hand with the open source community to ensure that standards are widely adopted.
Customers have a lot to gain from the availability of standards-based open source solutions. They can select the best products for their application, at the best price, and be assured they’ll interoperate--future proofing their purchases. Likewise, the industry as a whole benefits from a robust competitive market where standards making isn’t holding back innovation.