• 07/18/2014
    7:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Open Source Vs. Open Enough

Open source networking is a hot trend, but its success hinges on organizations making a real commitment to open source technology.

There's a big drive in networking towards open source with OpenDaylight and other initiatives. But enterprises aiming for open networking must make a decision: Either settle for "open enough" options from vendors that may not be truly open source but offer the interoperability and support they need, or commit to the ideals and development of true open source technology.

While IT buyers may design strategies based on open source technologies, many typically end up opening their checkbooks to a vendor that provides a solution that's "open enough." What "open" really means is open APIs (hopefully an open standard API, and not a vendor-specific open API) and some level of interoperability in order to create solutions. The openness should allow an organization to integrate a technology into an environment and then easily add new capabilities to that environment.

Do these buyers really care if the technology is open source? Or do they just care that it works, is supported, and is open enough to fit into their current world (and maybe their future world) and drive new levels of productivity for the business?

So what does this mean for the networking world? Open Daylight (run by the Linux Foundation) enables organizations to download an "open source networking platform" to run their networks. This is the Hydrogen release, which comes in basic, virtualization, and service provider editions. I'm sure there have been a lot of downloads to test the software and to play with it in an IT sandbox, but I have not heard of anyone using it in production (but would be happy to talk to anyone who is).

For now, I expect most organizations will still purchase products from incumbent vendors or even innovative startups. There is a lot of brain power working on the Open Daylight project, but it's still way too early to tell if it will become "Linux for networking."

It appears that many of the network and technology vendors participating in ODL want to leverage the open source code to deliver a hardened, and perhaps even differentiated, version for their customers. The question becomes: Is that "open" enough for those organizations that have made it a long-term strategy to leverage open source software and industry-standard hardware for their network?

Innovative and disruptive startups with open source initiatives like Big Switch (Floodlight, Indigo), Cumulus (Linux OS), Pluribus Networks (Linux, Illumos, and BSD communities), and Vello Systems (Open Source Optical Forum) want to promote open source ideals and benefits to help accelerate new technology adoption in a fully supported manner.

Simultaneously, networking players like Arista, Brocade, Cisco, Dell, Extreme, HP, IBM, Juniper, and Plexxi have either joined an open source community like ODL or developed their own version of an open solution, either by developing new industry standards (Cisco OpFlex) or by partnering with a startup (Dell with Big Switch and Cumulus). All this activity makes for great discussion, but where does it leave companies that have to make a decision today?

Organizations with long-term strategies to deploy open source solutions to build cost-effective networks should closely follow the developments of ODL and those companies participating in the project.

Any networking decisions today should be balanced with a clear understanding of a vendor's roadmap and commitment to open source, or at least openness. This should also be aligned with the breadth and depth of solutions, either developed internally or via a robust ecosystem of partners that can take advantage of open APIs.

The momentum for open source networking solutions requires customers that will do more than just pay lip service to open source and begin to assert these requirements more aggressively with vendors and open source projects, as well as continue to test and deploy open source solutions.

However, that's easier said than done when your job is on the line and your company's ability to produce a product hangs in the balance. So the question remains: Will you select open source or open your checkbook to buy a fully supported solution that is open enough?



"Open" is used so often in the context of software-defined networking that it takes a concerted effort to dissect what a vendor or organization really means when they use it. Ethan Banks wrote about this in April in "50 Shades of Open SDN."

Re: Open

@Marcia, good point, the term "Open" means different things, in different areas of specialization. For example, when I first heard the term "Open Internet", I was expecting to find a framework relating to open and free markets -- the type in which demand and supply determines prices and was not expecting to find ideas relating to regulate the internet in order to make the internet resemble a utility.

In B2B interaction, most businesses would like to solely own a technology. However, due to the need to focus on core competencies and make the business profitable and the nature of some support functions that requires huge capital, infrastructure and scale -- tradeoffs come into play and open vs. Open enough vs. the dangers of vendor lock-in becomes an important consideration.

The problem with "open"

Bob, I see a couple different issues here. First there is the vendor offering a semi-open solution that is misleading the customer, and none of us want to see that happening. But when it comes to straight-up open source vs. simply interoperable, I wonder what the difference is, as long as it does what is required for the organization in question. What are the drivers for companies to want to commit to strict open source solutions over the long term -- is that a realistic goal when it comes to networking?

Re: The problem with "open"

If we talk about open source SDN then it comes to Open flow which not many OEMs support on majority of their devices. Juniper's SDN story is taking complete different path outside open flow.

I agree to Susan, for customers open enough with interoperabilty does the trick then why strictly open source?

Re: The problem with "open"

Amit, thanks for your response. You bring up a good point with Juniper Contrail -- in some cases the most appropriate technology for your purposes may not be "open" at all, for whatever reason (although there is an open source version of Contrail, it's completely different, right?)

You also need to factor in the maintentance and support required for open source and whether you have the staff and expertise in house. If not, you may be better off with a vendor that packages up the technology in a product that's easier to use.

Re: The problem with "open"

When Juniper announced Contrail last fall, executives described the open-source version as providing everything necessary to create a network overlay, like the commercial version.

Re: The problem with "open"

@Susan, this is an excellent thought provoking question. The lighting industry is moving from fluorescent to LED based technologies, one of the benefits of LEDs are that they offer greater efficiency in terms of power utilization. LED efficiencies can further be increased if they are used in a PoE network. Since both the lighting industry and the PoE switch manufacturing industry would need to operate in an open and collaborative environment, competition would need to be on the bases of manufacturing cost rather than technological ownership. 

Long term, if a business does not feel secure in its ability to incorporate other devices onto their PoE network and the availably of LED blubs that can attach to PoE networks is questionable -- a business might skip investment and implementation, even if ROI makes sense at the time, I feel this is one reason why companies will need to formulate a strict Open-Source roadmaps.

Another reason is that businesses would be wary of manufacturers that simply provide interoperability, because interoperability alone does not protect against a manufacture placing a premium for utilizing a technology.  

Re: The problem with "open"

Brian, that's an interesting point about the lighting industry. Do you think we can make a comparison between LED lighting and say, OpenFlow switching? Switching seems a lot more complex to me (but then again, I don't know very much about lighting).

Re: The problem with "open"

Susan, you are right, switching has had a long time to evolve to meet the needs of the industry -- creating an environment with multiple vendors, all with their own protocols, interfaces and languages. OpenFlow has made things are little simpler by allowing for management from a single location. However, switching still remains more complicated then LED lighting.

I feel as lighting moves onto the network and has some time to evolve, creating for example, power management capabilities, visible light communication (Li-Fi) and services that are not possible with lighting being off the network, etc., lighting will also become complex.

If the lighting industry can take into account lessons learnt from the IT industry and avoid the circumstances that lead to unnecessary complications, then the possibilities are limitless.  

Re: The problem with "open"

Thanks Brian, that's very illuminating (bad pun intended)! I hadn't even realized there was such a thing as Li-Fi and the potential for lighting on the network. But what you say is so true. We surely need to work out a lot of the complexity issues if we think about what our future networks could possibly transmit.

I clearly need to do more reading in these emerging areas -- can you recommend any resources?

Re: The problem with "open"

Most of the good comments below , any idea what experiasphere project is all about.

Re: The problem with "open"

I'm not familiar with the ExperiaSphere project, but it looks like a pretty active community. Are you hearing much about it?

Re: The problem with "open"

@Marcia, same here, all I can recall is that the project aimed to bring together business like Facebook, Google, etc., and data providers like AT&T, Verizon using SDN/NFV. 

On the one hand, I think, projects such as Facebook's and Google's project loon are great. Because, the internet is a valuable resource that provides the most valuable resource of them all: information. Information can be used to kick start an economy into productivity, or increase the efficiency of an economy, create new business models, and so many things.

On the other hand, Facebook and Google would like 7 billion people connected to the internet, their business model requires scale. And infrastructure is expensive -- connecting 7 billion people is not going to happen unless the economics is right.

Re: The problem with "open"

Yes i am reading and hearing about this project but i have very limited information available with me, that was the reason i tried asking experts on this site.

Re: The problem with "open"

Aditya, I am part of the Experiasphere Google group and Tom Nolle, its founder, is an old acquaintance of mine. However, exactly what he is working on has been a bit of a mystery to me and I have not had the time to investigate and try to understand it fully. From what I can tell, it is a an open source service delivery and orchestration platform that runs concurrently with SDN and/or NVF. There is a powerpoint tutorial you can download on this page, and Tom is working on a video version of the tutorial as well:

I'll see if I can grab Tom for an interview and get some more details. 

Re: The problem with "open"
Thank You Susan, sounds interesting in fact a good learning on my way to understand how open is this open source service delivery.
Re: The problem with "open"

You're welcome, Aditya -- glad to help. I'll let you know if I come across any other simple explanations of the project :)

Re: The problem with "open"

@Susan, well placed pun!

Keith Dawson has a good article on this topic on a sister site. Interestingly, the article deals with APIs, PoE, LEDs and Economics, newer technologies rely a lot on its ability to provide saving, hybrid cars are a good example -- the engine is combined with batteries and the differences in miles per gallon by a hybrid car vs. a normal car becomes a strong selling point. 

I feel, LEDs are the same, one could say that on average newer LEDs deliver 110lumen/watt, while on average fluorescent bulbs deliver 60lumen/watt, that comes to almost 55 percent better performance. However, due to LEDs being more expensive at the moment, around 8 times the cost of fluorescent bulbs, calculating the breakeven point for ROI becomes important -- an LED over a work desk might breakeven in 3 years' time and the subsequent years providing real savings while, an LED in a supply closet that is only switched on for 10-minutes a day would take decades to break even. To gain an accurate calculation the networks seems like a great place to attach lighting for it to be metered.

Like the hybrid car that combines an engine with batteries, creates an extra layer of complications, so will LEDs on networks create an extra layer of complication. But, if businesses are to be delivered a high level of service -- extra work will be required.

Re: The problem with "open"

@Susan, here is another resource that deals with the case for lighting to be on the network.

Open source challenge: maintaining frequently changing code

Open source code and networking are relatively new to each other compared to open source and server-side computing. Open source has a good track record for both quality and security in the long run but it takes a big upfront commitment by the adopter to track changes and update open source modules and check constantly for compatibility. For the next ten years, commercial networking software will still be the dominant model... but the presence of open source will slowly grow.