OpenDaylight today introduced Helium, a major upgrade to its open source SDN controller. Helium is focused on building in the security, scalability, and stability needed for production environments.

Hydrogen, the first version of the SDN controller released in February, "proved that this thing had legs, that we could get the right people working with each other," says Neela Jacques, executive director, OpenDaylight . "Expectations are higher now."

For Helium, OpenDaylight is focused on hardening the software, as well as adding features, says Colin Dixon, committer-at-large on the OpenDaylight Technical Steering Committee and principal engineer at Brocade.

New features include:

Helium "can work on reasonably large networks, can run on clusters of controllers, and can run without worrying your services will be exposed," Dixon says. These measures are necessary to make OpenDaylight a "salable, deployable solution" -- technology that vendors can sell and network operators can deploy.

The next major version, Lithium, is due in about six months. In Lithium, OpenDaylight will begin to standardize on components for which it now offers multiple options. This includes OpenFlow -- HP Inc. (NYSE: HPQ) and others have their own implementations of OpenFlow, and the community will need to decide whether to have a single version.

Lithium will include still more Layer 4-7 capabilities not included in Helium, including additional security.

One thing Helium won't resolve is how policy will be handled -- that remains an ongoing discussion within OpenDaylight's policy project. Networks need to support the ability to prioritize some applications over others -- for example, business VoIP calls over Netflix video, Jacques says. And it's not just networks: Applications need to be prioritized for storage, compute and virtual machines. OpenDaylight is working with other standards bodies and vendors to be sure everything cooperates together.

But how that is done, and whether it is group-based policy and whether it requires smart hardware on which to run, are still issues under debate. Jacques and Dixon both say they want to see more industry voices involved in that debate.

In particular, OpenDaylight is prioritizing working on making sure its controller meets OpenStack's needs, Jacques says. OpenDaylight is looking to encourage participation from the group developing Congress, a policy standard for OpenStack, led by VMware Inc. (NYSE: VMW), with participation from Dell Technologies (Nasdaq: DELL) and HP, Dixon says.

Also, the OpenDaylight Group Based Policy project supports southbound interfaces for OpenFlow and Cisco Systems Inc. (Nasdaq: CSCO)'s OpFlex protocol, Dixon says. (See: Goin' South: Cisco Offers 'OpFlex' as Alternative to OpenFlow .)

OpenDaylight is working fast. Hydrogen came out just 10 months after the group's founding. The controller has won support from vendors including Brocade Communications Systems Inc. (Nasdaq: BRCD), Cisco Systems Inc. (Nasdaq: CSCO), IBM Corp. (NYSE: IBM), ConteXtream , Ciena Corp. (NYSE: CIEN) and Oracle Corp. (Nasdaq: ORCL). (See OpenDaylight Project Founded, Cisco Sees Daylight for SDN and OpenDaylight Unveils Open-Source SDN Controller.)

Prior to OpenDaylight, SDN solutions were proprietary, but since then we've seen several vendors base their software on OpenDaylight's open source offering, Jacques says. OpenDaylight scored a significant win this month, when Brocade Communications Systems Inc. (Nasdaq: BRCD) announced the Vyatta Controller, its only SDN controller, based on OpenDaylight.

Brocade is moving in the direction the industry is going, Jacques says. "People want open source at the core but with vendor support," he says.

One danger to OpenDaylight, or any big open source project, is that vendors will fork the code and take it proprietary. "Open is a spectrum. There is definitely a risk to people who don't go all in," Jacques says.

Vendors with legacy businesses face pressure to implement proprietary solutions, where they might, for example, support both an open source and their own proprietary software, but invest future development in the proprietary controller. Or they might use the open source software as a foundation and add capabilities in proprietary wrappers and not give back to the community.

"What is going to keep vendors taking the right, open path is customers saying, 'This is what I want,'" Jacques says. "If customers shrug and say, 'I just want a solution that works,' you'll see people go the easier path, which is proprietary."

— Mitch Wagner, , West Coast Bureau Chief, Light Reading. Got a tip about SDN or NFV? Send it to [email protected].