Last week we discussed Cicso’s approach to Software Defined Networking (SDN) and we made the statement that Cisco is generally not one to rush to open source. Ultimately,
their true strategy in embracing SDN might be closer to “keeping your enemies closer.”
Cisco was quick to remind us last week that they were, in fact, a platinum sponsor of the OpenDaylight project, which is an open source SDN project from the Linux Foundation. In the past Cisco has also made contributions to OpenStack and to Linux where it served their business needs. On the surface, OpenDaylight is a good thing for the industry, but in pushing this new OpenDaylight strategy, how does Cisco stack up?
While it was Cisco’s opinion that we purposefully neglected to mention this, the reality is that we had considered OpenDaylight when we wrote the blog about Cisco’s SDN approach but felt that there were many questions around OpenDaylight that were still unanswered, so we decided not to include it out of fairness.
SDN is an important movement but this consortium has only been publicly active for a few months; too soon to start highlighting success or failure (the first deliverables are set for the end of the year.) The ultimate impact of Cisco’s support of OpenDaylight will not be felt until sometime next year at the earliest when people are able to take the code and start using it. A more relevant example of an SDN consortium that has a longer track record is the Open Network Foundation, where Cisco holds a decidedly smaller voice.
In the meantime we decided to dig into how OpenDaylight is structured to see how the Cisco commitment plays out.
The Cisco Contribution to OpenDaylight
From the OpenDaylight website, this is the organization’s stated goal:
“OpenDaylight’s mission is to facilitate a community-led, industry-supported open source framework, including code and architecture, to accelerate and advance a common, robust Software-Defined Networking platform.”
Cisco had contributed its ONE controller to OpenDaylight. While on the surface that sounds like a very altruistic gesture, it is just as easy to view that action cynically as the Trojan horse that allows Cisco to insert itself into OpenDaylight and SDN. If everyone engaged in this open environment is running the SDN controller that is based mainly on Cisco technology, how hard is it to upsell them into a Cisco solution down the road? To be fair, whomever’s work becomes the core of the code will stand to gain in the market; but when that company already holds the majority share, it can be limiting. In talking with people inside of OpenDaylight, the decision to mostly use Cisco’s contribution was done after a thorough code review and they feel confident that the right choice was made. Decisions from the technical steering committee are supposedly made without any influence from the board/platinum members. However there are dissenting opinions on the topic. For instance, Andrew Conry Murray was concerned back in April when he penned this discussion. And in Network World Jim Duffy wrote a skeptical blog pointing out some of the challenges with the consortium which appeared to have a strong Cisco voice that may potentially overpower some of the other work that is being done. Even other analysts have joined the discussion, including Gartner with a note entitled “OpenDaylight Project Casts Cloud Over SDN Deployments,” pointing out that the organization could actually “stifle innovation.” There were those inside the organization that feared Cisco overwhelming the group in the beginning, but they have been happy with the outcomes so far. While things seem to be manageable today, that balance may not always be the case in the future, so it is something to continue to monitor down the road.
One of the key SDN companies involved in OpenDaylight is Big Switch Networks. Then company’s Open Switch network creates a fabric that will run on both bare metal switches and on VMs that are running on x86 servers (like you’d find in any rack.) Big Switch decided to scale back their participation in OpenDaylight and key personnel have chosen Big Switch over Cisco. Much of this dispute between the members revolved around Big Switch’s belief that the Cisco SDN controller was being chosen over their far more advanced contribution, Floodlight. The issues that arose between Cisco and Big Switch were played out in a very public manner, which is never good for an organization. While there is probably enough blame to go around on all sides for the way things turned out, we’ll probably never know the whole story. The question of whether the bulk of the base SDN controller (think of it as the operating system) comes from the market leader or from a start up with disruptive technology can be argued back and forth, but ultimately on open source projects like this, there is more than just technology at play; you need a longer term view around sustainability and extensibility.
How Does a Consortium Work?
Having been involved in consortia in the past, I have some knowledge of what goes on behind closed doors. Companies join these organizations either offensively (because they see the opportunity of achieving great things by banding together with others in the industry for a common goal) or defensively (either to influence decisions or prevent competitors from gaining an advantage.) In addition, for some companies the culture of the company will dictate whether they actively engage in consortia as well.
Every consortia will have a some common structure including members, working groups and a board of directors who will make decisions on how things get done, what things are worked on, and, most importantly, what things are not worked on by the group. This is where you can see the true motivations for the group emerge. For OpenDaylight, while the technical decisions are run from the technical groups and not the board, there is always a potential for influence; this is why checks and balances are important.
When the consortium is first announced, it can be like moving into a new house. There is a flurry of activity and lots of excitement/anticipation, which is soon overtaken by the reality and the enormity of the task that is in front of them. Then the real work begins.
Looking at the lifecycle of a consortium, they tend to fall into some general patterns for excitement/activity/impact (what we will call relevancy.) With every consortium, there is an initial burst of activity as the organization forms and is announced; occasionally they will even launch with some initial work already done. But once the honeymoon is over, they tend to follow one of 3 paths:
- Standards setting, cyclical releases, constant pace. This is not necessarily ground breaking and innovative (think PCI SIG or JEDEC) but is building a foundation. Often these are multiple generations of specifications that guide an industry.
- An initial “big bang” that is followed by continued work that keeps the activity going. Over time it will never be able to recapture that initial spark, but the consortium remains relevant. Each new release is incrementally smaller as the challenge that they were focusing on becomes more refined and they have actually achieved many of their goals (think the Green Grid with PUE.)
- Lots of smoke, but little flame. There is an initial interest but the consortium either lacks the focus, the direction or the structure to allow it to make good decisions. Work essentially slows to a halt, no real impact is seen in the market and over time it dissolves. This trend line also reflects consortia that might have an initial value but then are eventually replaced (think Sony/Phillips with CD Audio – no matter how popular, it will eventually be obsolete.)
The Power Is In the Voting
In our first SDN blog we talked about the incumbents and the disrupters in relation to SDN. Think of the incumbents as those that have share to defend and probably prefer the status quo over change. Think of the disrupters as those that would challenge the status quo and are looking to gain share.
Interestingly, when you look at OpenDaylight, you see that those that have the biggest share to defend are the ones with the highest levels of sponsorship and those with the best opportunity for taking advantage of the disruption of the market are in the lowest category of sponsorship. This puts the power squarely with the incumbents, not the disrupters; this potentially limits the consortium’s ability to fundamentally change the market. Based on the dynamics of consortia, some of the lower level sponsors appear to be taking a “wait and see” attitude before jumping in. Buying in at the lowest level allows a company to have access to the inner workings and make sure that nothing goes awry. The folks at the top of the sponsorships are either interested in having control or bringing resources – or both.
The board voting does not drive the projects as much as it drives the marketing, recruitment and financial management, but it is hard to deny that those with a board seat don’t carry more weight than those without (it’s human nature.) According to the organization’s bylaws, each platinum member has a single vote, essentially each gold member has 1/3 of a vote (total # / 3, then rounded up) and all of the silvers, together share a single vote. With 8 platinum members, 2 gold members and 17 silver members you end up with 10 total votes. 80% of the votes go to the platinum members. Contrasting this to other consortia, you see a big difference in how decisions are made:
|
Consortium |
Board Voting |
| OpenDaylight | 10 total votes (today), largest 8 companies (platinum) hold 80% of the power |
| OpenCompute | 5 board votes, end customers represent 3 of the 5. Only 3 of 5 votes needed to approve measures, the 2 vendors abstain from votes where their companies are involved. |
| OpenStack | 24 board votes. 8 are from the platinum members, 8 are from the gold members and 8 are from “individual” members |
| Open Networking Foundation | 11 board votes, 10 of the 11 board seats are end customers, not manufacturers |
| The Green Grid | 11 board votes, all are the largest contributors; board representation includes end customers and multiple industry verticals |
Clearly, not every organization has a cookie-cutter structure, but there is more balance across the other organizations. Decision making can be done in a more equitable manner and there can be a focus on making sure that multiple constituencies are involved in the process.
Interestingly there are no end customers in the consortium today. I spoke to one end customer who is a large buyer of networking equipment and they relayed their belief that OpenDaylight was mainly a Cisco marketing tool so they wouldn’t be participating. In talking to people inside the consortium, they brought up two points: First, because all of these companies are talking to customers every day already they believe this brings the customer element into their work. But that only gives them input relative to their company and the customers, it does not necessarily bring input of the customers over to the consortium and it doesn’t allow customers to steer the direction. Secondly, because the project focuses on code they believe that end customers don’t develop their own code. But most large companies who are candidates for this code have a host of developers on staff today. As networking becomes more “commoditized” with things like SDN, you can expect this to grow with end customers.
How to Have a Successful Consortium
In looking at how a consortium should work, I take some hints from both those that I have worked with as well as some simple, common sense perspectives from this article:
- End customer representation – This is really critical. Creating a consortium for the good of the end customer is key. Some, like PCI SIG, are focused on the industry and in that respect, the industry becomes the end customer. The outcomes (the standards) are something that everyone follows; you don’t see a company saying “this is OUR interpretation of PCIe Gen 4…” But not having customer input directly to the organization leaves the functions one step removed.
- Balance of power and accountability – The decisions are made by the board. There needs to be a balance and accountability. Companies join a consortium to have a voice, but that voice needs to be balanced out so that nobody is dominating. Having an advisory board made up of end customers or individuals is a good way to maintain checks and balances on power.
- Meritocracy – Let the best ideas flourish; don’t let the best funded ideas dominate.
- Focus on a customer goal, not a market goal – It is important to keep the end customer in mind at all times. This should not be a “land grab,” it should be cooperative.
- Reflect real world usage models – You will not attract the market to your work if you are not reflecting what is really happening in production environments. Philosophical and theoretical are trumped by actual when it comes to customer relevancy.
- Never rely on one benchmark – It is far too easy to manipulate benchmarks, so you need multiple measurements of your organization’s effectiveness.
- Transparency – Members need to have confidence that decisions are being made in the open, not in “smoke filled rooms.”
- Look for consistency – Decisions should be consistent and expected. When a decision raises eyebrows, it begs the question of what is really going on behind the scenes. Every consortia has a charter and the decisions should always be consistent with that charter, or be accompanied with a thorough discussion for the departure.
- Keep the deliverables in mind – too often these groups will take too long to show progress. If you aren’t bringing relevant ideas or technology out in a regular manner, it is too easy to be dismissed as irrelevant.
We Are Still Holding Out
Ultimately, we still believe that OpenDaylight could have an impact on the market from a positive perspective. But until the actual deliverables start rolling out and end customer reaction is gauged it is too early to claim success or failure.
One thing is clear; we don’t believe that Cisco’s success in the market will be determined with or without OpenDaylight. In our eyes, SDN appears to be a hedged bet for Cisco, not a focused strategy. But that is not a bad thing; if we were the market leader with a majority share to defend, we would probably do the same thing.
The key underpinnings of SDN line up on both sides of the Cisco strategy. On one side Cisco is focused on the key outcomes of SDN (agility, network virtualization, better efficiency), but the other side (open source, lower cost commodity hardware, removing layers of networking) appear to be somewhat at odds with their normal direction. Time will tell whether this is a net gain for Cisco, but ultimately, if OpenDaylight can expand its membership base, add end customers to the consortium and truly deliver to the promises it has made, then there is an opportunity for some real change in networking.
John Fruehe is a guest blogger at Moor Insights & Strategy and was previously vice president at NextIO and director at AMD. John also spent nearly 15 years at Dell and Compaq in enterprise product, strategy, and marketing roles. You can find his full biography here.