You are here

The First 60 Days

Collaboration Moving Fast on OpenDaylight

OpenDaylight launched with a high level of interest and contribution commitments, but the real proof of the work is in what the growing OpenDaylight developer community has been able to achieve with the codebase. There were even multiple controller codebases the technical community could choose from as a base for OpenDaylight. The community looked at the code, weighed the merits of various parts and in typical open source fashion picked the best pieces from multiple codebases to build the base controller. In the open source software world, that’s positive forward progress.

The community should also collectively congratulate David Erickson of Stanford and Colin Dixon from IBM, who teamed up and together created a proposal to merge two code bases.  If you’ve been following the mailing list discussions or joining the TSC calls, you’ve heard the plan referred to as the “Dixon-Erickson Proposal” (or “D-E Proposal” in short form). This proposal has been accepted and the TSC is working with the community to engage and enlist action owners willing to contribute to making the integration of codebases and creation of new pieces come together.

Let us report on an update of where we are after 60 days and how we got here…

Best of the Best Code Integrated to Form OpenDaylight Architecture

There are many ways to start an open source project.  For OpenDaylight, the participants wanted to start with a common framework and code base that they could all use and leverage.

The first question for the OpenDaylight technical community came in the form of deciding which codebase to start from between two contributed core controllers; one contributed by Cisco, and the other contributed by Big Switch Networks.  A community bringing forward multiple options and approaches to the same functionality happens all the time in open source communities, and the OpenDaylight community worked together to surface the best of the best code to address the needed controller functionality.

An interesting aspect about how the community came to a solution was that two parties not involved as owners of the contributions sat down, went through the code of both controllers, and made their own proposal to the community on how to merge the code taking the best components of each.

The result is David Erickson of Stanford and Colin Dixon of IBM’s joint “D-E proposal” that the community largely hailed as the right path forward.

This proposal uses the Service Abstraction Layer (SAL) and the OSGi framework that is at the heart of the Cisco “controller” contribution and marries it to the host-tracking, tunnel management,  and other robust features contained within Big Switch Networks’ “net-virt” contribution.  See the attached graphic for more information and click here to see the complete proposal [LINK: https://wiki.opendaylight.org/view/Dixon-Erickson_OpenDaylight_Merged_Co...

The D-E proposal has been viewed by the technical community at large as a great framework for merging the core controller code bases with work now being done to flesh out the specifics of each set of components to be merged.  Indeed, most of the activity planned for the Hackfest coming up at the end of this week is focused on furthering the D-E proposal.

Having a large number of technically savvy, and diverse opinions available for debate is probably the biggest strength of open source projects and OpenDaylight is already flexing its muscles on this point. Debate and strongly held opinions inform important decisions. Not everyone gets everything they want all the time, but the process ensures the best ideas percolate to the top over time.

Removing company boundaries, engaging academic talent and allowing the best and brightest to collaborate, debate, compromise, and inspire each other is why code written in open source communities is of higher quality and doesn’t degrade in quality over time when compared to other software development models.

We encourage you to come join the fun.  OpenDaylight is off to an outstanding start with the talent, effort, processes, and open source culture to succeed quickly at drastically improving the impact and acceleration of SDN.