(Links to all SDxCentral coverage from the OpenDaylight Summit can be found here.)

This week's OpenDaylight Summit served as a celebration for getting the Hydrogen release out the door, albeit two months late. Now comes the work of the next code release, Helium.

The Summit closed Wednesday with a panel discussing, among other things, how to approach Helium and what the OpenDaylight Project needs to do in order to sustain its level of development.

The Technical Steering Committee has agreed to doing code releases every six months, lumping all available candidates into one package. That puts Helium on a summer timetable.

Projects are proposed via the OpenDaylight wiki, and the successful ideas get moved to the incubation phase. Among the newest incubation entries is an application policy plug-in submitted by Cisco with help from IBM, Midokura, and Plexxi. (At press time, the wiki still lists this one as a proposal, but TSC leader David Meyer said during the panel that it's been moved into incubation.)

Several more have been proposed, including the virtual switch from Intel's data plane developer kit (DPDK) and a Python client.

And of course, many more are on the way. "In the hallways this week, there were so many projects that were proposed. It was amazing," Meyer said.

That's actually an issue for OpenDaylight. Interest in the project is running high; the final attendance figure squeezed up to 600, according to Microsoft's Rob Dolin, after being initially capped at about 500. Now, as the panel pleaded repeatedly, the trick is to get more of those people directly involved, partly so that fewer developers can pull fewer all-nighters on subsequent releases.

Testing and interoperability, in particular, have to move out of the background. Hydrogen's testing got done only because one Ericsson engineer took the lead at rallying people to do the work. By contrast, vendors can have quality assurance teams that are as large as their engineering teams. This unglamorous aspect of code development needs more love.

On similar terms, the work of maintaining previous code is going to have to fall to somebody, Meyer pointed out. That could be an unpopular chore, especially after several releases go out.

More user input, including guidance on which use cases to focus on, would help, too. "It's another way of growing the community," said Chris Wright, principal software engineer with Red Hat.

At the same time, there are places where OpenDaylight needs fewer people — meaning, there's room to automate more processes. "There are certain classes of things that you cannot trust humans to do reliably," said Ed Warnicke, a Cisco principal engineer.

A few suggestions came up regarding what else OpenDaylight might consider in Helium and beyond. One was federation — getting controllers to talk to one another. "I don't know of anyone who doesn't think that controller federation isn't important on some level," Warnicke said.

But this one isn't too urgent, because that east-west communication between controllers hasn't emerged in a big way yet, Wright said. Before aiming for a Skynet level of massive federation, the group should take the step of getting two OpenDaylight instances successfully communicating, he said.

Security came up as well. It's going to be a topic looming over OpenDaylight and every other software-defined networking (SDN) project perpetually, so we can forgive the panel for not completely solving this during their hour-long session. The one conclusion was that security has to be developed in conjunction with the rest of OpenDaylight, not as a bolt-on feature added afterward.

(Photo, from left: Dolin, Wright, Price, Warnicke, and Meyer ... and you can see their company affiliations up on the big board.)