Attributes of Openness in SDN

When trying to ascertain what is and isn’t open, remember that one or more of the below can help determine openness.

Open Standards: Freely and generally available specifications for hardware or software developed and maintained through a shared process, like OpenFlow

Open Source Software: Source code available for anyone to modify or enhance, like OpenStack and OpenDaylight

APIs and SDKs: Application program interfaces (APIs) act as tools for creating software applications, often dictating how software components should communicate with one another (not all APIs are open, consider Amazon Web Services APIs); software development kits (SDKs) are packages of pre-written code that minimize the amount of unique code developers have to write themselves; several SDKs are published APIs, available for anyone to write into their own applications

Open Hardware: Designs with open reference for compute and networking products, like Open Compute Project

The above gives a glimpse into why many companies and organizations can label themselves or their products as “open.” However, when contemplating what is and isn’t “open,” one must consider the degree or type of openness attributed to a certain product or company.

Foundational technologies — considered the building blocks of SDx (software-defined everything) — can be SDN/NFV products, including protocols, SDN Controllers, vSwitches, or application APIs. They are held to a higher standard than supporting technologies, which enable other technologies to interact with each other.

How to Determine a Project’s Openness

Consider these areas when trying to understand the degree of a project’s openness.

Contribution and/or Participation Requirements: Participation requirements sometimes depend on the project. The Open Networking Foundation (ONF) requires membership, while OpenDaylight allows anyone to participate, but only paying members have voting rights. An easy rule of thumb when determining a project’s openness is to pinpoint the top 10 contributors. If more come from a single company, the less likely the project is more open.

Governance: This refers to the process a project follows when accepting code contributions. While every project has its own methods and processes, it’s important to identify who holds responsibility of standards.

Intellectual Propert Protection and Licensing Rights: Free and open software (FOSS) gives users the ability to run programs for any purpose, as well as alter and redistribute them without paying royalties to the original developers. Reasonable and non-discriminatory (RAND) licensing assurance means the patent holder will not gouge the market with licensing fees once the standard is adopted. Both of these licenses reduce legal risks and point to a more open project.

Ownership and Ability to Fork: Intellectual property (IP) disputes are not few and far between, so knowing who ultimately owns the open standards or open software is important for openness. Make sure an agreement dictates who will own the TP that results from any open project. Also, be sure to ask if a final product can be “forked” — turned into a unique piece of software based on source code from someone else.

To be truly open, foundational technologies must meet the following criteria: FOSS-based licensing; a level of clearly defined IP protection to ward off patent infringement or copyright claims; an open and transparent governance model with a board that represents the entire community; and open participation requirements that offer well-established merit-based processes on how code will be accepted.

SDNCentral holds foundational technologies to a higher standard than supporting technologies, or those that enable other technologies to interact with each other. SDNCentral also believes the most truly open projects are those governed by an independent foundation.

About SDxCentral

Engage With us

This material may not be copied, reproduced, or modified in whole or in part for any purpose except with express written permission from an authorized representative of SDNCentral, LLC. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced. All Rights Reserved.