1 Comment

Summary:

As the vendor-led OpenDaylight Project reaches consensus around a code base, Big Switch disagrees with the consortium’s direction and has stepped back in its participation.

Software-defined networking
photo: Jordan Novet

Just as some people had foreseen, the participants in the OpenDaylight Project for standardizing software-defined networking (SDN) are having trouble getting along.

Big Switch Networks, an SDN player that jumped in deep with the vendor-led consortium as a top-of-the-line platinum member, implying financial and developer contributions to the project, is giving up its board seat and downgrading to a silver member, Network World reported Wednesday.

Jason Matlof, the company’s vice president of marketing, was quoted as saying that OpenDaylight is “not in the best interest of the industry or as a technical place to start.”

The news followed an OpenDaylight announcement that five more companies had gotten aboard, including Cyan, Huawei and Radware.

Big Switch CEO Guido Appenzeller explained the company’s reasoning in a Wednesday blog post, noting that, while the OpenDaylight Project had initially looked at merging code from Cisco and Big Switch’s open-source Floodlight controller to form “a clean, new repository,” the leaders of the consortium ultimately chose “to start the project with the Cisco controller as the base repository.” (David Meyer, chairman of OpenDaylight’s Technical Steering Committee and a Brocade executive, describes the proposal differently, saying it incorporates “robust features” from Big Switch in addition to Cisco code.)

The Big Switch code is more time-tested than the Cisco code, Appenzeller argued, and anyway it will be hard for Big Switch to run some of its applications atop the controller code going forward. A source told us that Big Switch had joined OpenDaylight with the hope of staving off the adoption of Cisco’s controller code, and now it appears Big Switch was outgunned.

In addition to complicating Big Switch’s efforts to push proprietary applications, Appenzeller wrote that OpenDaylight might not be doing enough to give customers with what they want:

The second, and more important reason is that our energy is better spent concentrating on the needs of the user community – not playing politics with the incumbent vendor community. Specifically, the market is clamoring for a transition toward “bare metal switches,” or “white box switches,” which provide customers an ability to rack-n-stack switches and centrally provision them just like they do with data center rack servers today.

It’s hard to say how much the OpenDaylight controller code will end up keeping Cisco customers buying from Cisco instead of more open switches, but it’s a legitimate concern as companies wonder if they might be able to implement SDN and do more with simpler — and less expensive — switches. (We’ll be talking about what use cases are possible with SDN at GigaOM’s Structure conference in San Francisco in two weeks.)

It would be nice to see some customer representation on OpenDaylight Project, Appenzeller noted. That could bring some assurance that the resulting standards will help not just vendors but many kinds of companies interested in reaping the benefits of separating the control plane from the data plane.

In the meantime, still more drama could unfold in the OpenDaylight Project, as official code is expected to ship in the third quarter of the year.

  1. [Disclaimer: I work at Plexxi, an ODP member, but I do not in any way speak on behalf of ODP or any member companies]

    I have seen a few places that have discussed this particular flare-up, with the implication being that things are not well in the land of ODP. But we have an emerging technology trend that spans a ton of markets trying to solve a lot of problems in different ways. It would be surprising to me if there was consensus – alarming maybe. Innovation happens when ideas compete.

    In this case, ideas competed. I have no idea which code is better (I am neither coder nor have I audited the code with my incapable eyes). But some decision needed to be made to move forward. The worst possible outcome would have been an indefinite stalemate.

    BSN’s subsequent moves were undoubtedly what they saw as their best interests. Faced with a choice between porting all their stuff (which would consume resources and spoil their lead) or continuing to develop so they can drive sales… no matter what they did, it was going to be tough. I would guess the two things not being discussed much publicly (burn rate and money in bank) were at least as important as any open source aspirations.

    And by the way, I don’t mean any judgment in that. They are a for-profit company and need to consider their business model when making moves.

    My point is that I think there is more than ODP dynamics at play here. The strategic discussion this is forcing, though, is fascinating to watch. It should make a good case study at HBR some day.

    Mike (@mbushong)
    Plexxi

    Share

Comments have been disabled for this post