With everyone in the U.S. now recovered from overeating during the Thanksgiving holidays, and me waking up from my turkey-induced hibernation, we’re now ready to announce the results of our Turkey of SDN competition. Before I go ahead and announce the winner and an honorable mention, I want to reiterate the goal of the competition: This is meant to be educational to us all and not meant as a dig at anyone. And I’m certain the submitters of the entries had that intention in mind when they put their nominees in.

So with that, here’s the moment you’ve been waiting for … drumroll … the winner of our Turkey of SDN competition is Juniper’s OpenContrail project. Here’s some snippets from the submissions to provide context: 

“Yet another single-vendor open source SDN controller project. By a company that is already a Platinum member of OpenDaylight. Completely confused messaging. Landed with a thud. ‘Community’ consisting of one organization.”

“Clearly no one else is involved in OpenContrail or interested in contributing to OpenContrail. It’s not even clear what the strategy here is”

“Announcement included a pledge to work to bring OpenContrail into OpenDaylight -- empty promise”

Looking at OpenContrail's contributor list on GitHub, most or all of them indeed are from Juniper. In Juniper’s defense though, I’m not entirely surprised, since this is an early-stage open-source initiative, and this provides perhaps a replay of the Open vswitch (OVS) discussions we had in the early days of SDN here at SDxCentral, with Nicira dominating the contributor list. In that situation though, OVS became a de facto standard by getting bundled into standard Linux distributions, and I’m not sure that’s going to happen any time soon with OpenContrail. And certainly, I don't think the submitters were necessarily knocking the Juniper Contrail solution, which I've heard good things about from customers and seen a cool demo of; criticism is focused primarily on the OpenContrail project.

And as for lessons learned here, one of our submitters had a good suggestion:

“[This could have been] easily avoided by figuring out how to bring part or all of the solution into OpenDaylight. Open Source isn't just about throwing code into the open.”

We’ve said this before: Open-source models do still need a “business model” to make them successful. Putting stuff on GitHub alone doesn’t make a successful open-source strategy.

So that OpenContrail doesn't feel too lonely on that stage, I’d like to bring in an honorable mention as well: “Automation pretending to be SDN”. For that one, we have the following supporting detail:

“When SDN was first created, it was supposed to be about centralized control and fine-grain flow controls, giving networkers a new way to program specialized and optimized behavior into the networks, replacing the antiquated and complex protocols like STP in place today. To pretend that automation even comes close to that is ridiculous, scripting the configuration of a bunch of routers and switches is not SDN.”

And also, a related view that I grudgingly have to agree with: “If SDN is automation, we already had it 15-20 years ago when we were Tcl-Expect scripting router CLIs. So what's new?”

I think that automation does have value in the SDN world, but certainly, making automation the be-all and end-all of SDN would be a big mistake.

I’d like to thank our readers for their fun submissions and take the opportunity to message to the winners that this was a competition designed to be educational for us all and not mean-spirited in any way. The intention is that we all listen carefully and respectfully to feedback from the market and address concerns appropriately—with a common goal improve SDN for all. Go SDN!

Check out more Market Trends on SDxCentral: