It's been a few months since the OpenDaylight Project launched. With the initial controversy having cooled off a bit, we felt it was a good time to sit with David Meyer, chairman of the OpenDaylight Technical Steering Committee (TSC), to get an update on the group's progress and direction.

What are some of the key milestones the Technical Steering Committee has achieved?

Meyer: The TSC was able to “boot up” the project in a short amount of time, and I think we did that pretty well. We wanted to achieve total openness and transparency for healthy debate and progress. Everything we do is on the mailing lists and the OpenDaylight wiki, and our weekly calls are open to the public. And not just in “listen” mode, either -- anyone can chime in and offer input. Anyone can become part of the TSC if meritocracy so dictates. If you start contributing code, writing wikis and start gaining credibility, then you can become part of the TSC and even the board of directors if that’s what you want.

Because of that, we have a growing developer community from a variety of companies as well as academia — much like you see in the Linux community, or OpenStack. We also just announced a flurry of new tech contributions ranging from network protocols to virtualization to security. It’s pretty amazing to see how much progress has happened in the past three months.

By the way, how did the hackfest in Portland go? What was significant about it?

Meyer: It was our third HackFest, and we’ve really got a rhythm going. There’s a core group of developers who attend each one, but we also see new faces each time. The last one in Portland focused on the recent tech contributions and how to dig into those, and we continued discussions we’ve been having about the distributed data consistency model and southbound plug-in framework. If you’re feeling adventurous, you can look at all past and future HackFest details on our wiki.

Have you achieved the uptake with developers that the team envisioned? Who are some developers from outside the member ecosystem that you can point to? What are they working on?

Meyer: The community has grown to hundreds of developers and includes people from member companies, non-member companies and academia. Folks like David Erickson of Stanford collaborated with Colin Dixon of IBM on the architecture for the base controller — a big undertaking early on in the project. Brent Salisbury and Evan Zeller from the University of Kentucky are very involved and in fact just contributed the Open vSwitch Database project, which is something they’re creating from scratch because they use it and know there’s an industry need. ConteXtream isn’t a member but they contributed the LISP Mapping Service.

It’s the TSC’s job to make sure that things are moving along in a both technically expedient way and in a way that’s consistent with the mission, but the fine-grained operation is really on the committers and the people writing code, and that’s the way it should be: a bottom-up process. One of our goals is to continue to diversify the committers. Anyone can propose projects and contribute in a number of ways, and even become chair of the TSC.

You've guided the TSC through some early teething pains. Particularly the very visible departure of Big Switch from the project after their proposal was not accepted. Any thoughts about how that went? Were you hoping it would have gone differently?

Meyer: The controller we’re developing doesn’t cater to any one implementation, which unfortunately didn’t mesh with Big Switch’s business model. And while I was disappointed that we couldn’t find a way to work together, the community came together to combine the best parts of both code bases in a way that will produce the best total overall result and, in addition, to create a controller that would be used by as many people and as many organizations as possible. We want to produce industry-leading technology, and we’re integrating and writing the best code to do that. I know I speak for the OpenDaylight community when I say that we welcome the opportunity to work with Big Switch again, and of course as it is an open-source software project, they can contribute and participate at any time.

Some in the community have suggested that the SAL is merely a way for Cisco to maintain its dominance — i.e. allow their onePK proprietary protocols to be plugged in on the southbound side, replacing OpenFlow. What's your response to that?

Meyer: The OpenDaylight SAL has flexibility to support protocols beyond OpenFlow. OpenFlow is getting the most attention as a protocol to be supported well by OpenDaylight. OpenDaylight supports OpenFlow 1.0 and the community is working on integrating support for OpenFlow 1.3, as well as to make it easy to support future versions of OpenFlow as they emerge. Additional southbound protocols to be supported include OVSDB, BGP, PCEP, and possibly also SNMP (a recently added proposal). The design is open to allow these types of additions. We are working on suitable abstractions and their proper representations through the northbound API so that a rich assortment of protocols can be used if needed. For situations where only OpenFlow is needed, we are striving to deliver the best controller for OpenFlow that we possibly can.

There's been a series of new contributions to the codebase from a number of vendors — congratulations on that! It still seems to be more a vendor-driven initiative than a customer-driven initiative. Do you expect that to change?

Meyer: One of the great things about open-source is that when it’s done right, there is no differentiation between a vendor and customer. There are only developers and users, and more often than not, they are the same people. For example, IBM will both help build OpenDaylight as a developer and consume/use it to build products for customers. Its customers will then become users of OpenDaylight and may or may not choose to become involved in its development. Though, if you use other open-source projects as a barometer, end users often get involved in the development of open-source projects that contribute to the products they consume. This is one of the key benefits of open-source.

When a project starts to mature is when end users start to come out of the woodwork and take a serious look at what’s happening to see how it might work in their environment. As more robust code starts to appear, the more advanced users will start giving input, and at that point we will formalize a process so they can do that — just like The Linux Foundation did for Linux.

With the numerous contributions, how do you prevent ODP from becoming the Franken-controller?

Meyer: All good open-source projects are built with modularity and extensibility in mind from the start. There are many, many examples of this; Linux, Eclipse, Apache, Firefox, and many others have many variations and extensible plugins they can be made to do whatever the user wants, and only what the user wants to do at any given time. The developers within OpenDaylight are already working hard to improve the flexibility of the core controller to easily accommodate a wide array of applications, controller services and network devices. In addition, other developers are working to add those applications, services and southbound protocols to drastically increase the functionality offered by OpenDaylight.

The most interesting innovations that the industry will realize from SDN have not even been thought of yet. OpenDaylight is built from the ground up with this notion in mind. In fact, it has been proven time and time again that the best software technologies available today come from open-source projects with a wide array of contributors with varied and even competitive interests. Linus [Torvalds] could not have imaged in 1991 that his desktop operating system would one day simultaneously run the world’s largest supercomputer while dominating the smartphone market.

I understand that under the current plan, you might be handing your chairman's role to someone else in the future, based on how voting goes within the TSC. What are your feelings about that?

Meyer: I think that will be a really positive thing for the project, because the TSC should be comprised of committers who are very active. I came on board to help get the project booted up but am not contributing code at this time. That said, there are plenty of roles for someone like me in OpenDaylight (including my current role). OpenDaylight is based on meritocracy. Membership in the TSC and board of directors should be a bottom-up process and that’s what we’re working toward.