Open source seems great on the surface, but vendors commit more than time and code to a project, and that can be risky.
Customers need to understand how vendors will address shortcomings in products based on open source.
At the SDN & OpenFlow World Congress in Dusseldorf, I chaired a debate called “Building the Ecosystem for NFV, Impact of Open Source” with Brian Aherne, Director of Intel’s Network Computing Division EMEA; Ari Banerjee, Senior Director of Strategy at NEC/NetCracker; Valérie Noto, Director of the CloudBand Ecosystem, Alcatel-Lucent; Recep Ozdag, Senior Director at Ciena; Prodip Sen, Director/CTO, Network Functions Virtualization at HP; and Walter Zielinski, Senior Director, Core Network at Huawei. It was a lively debate, with everyone in agreement (despite my poking and prodding) that open source is good, everyone collaborates, and lets all hug – until Recep Ozdag, and then Ari Banerjee, made a comment at the very end to the effect that open source development doesn’t automatically mean faster or better development. A colleague pointed out they may as well have kicked a puppy. Continue reading “SDN and OpenFlow World Congress: Let’s Kick Some Puppies, or Why Open Source Poses a Business Risk”→
• The temptation to modify open source software outside of a project is often well intentioned but brings a number of significant drawbacks.
• If you’re in enterprise IT, don’t buy products based on open source projects like OpenDaylight without a guarantee that the vendor won’t fork the code in the future.
In a strong rope, lots of underlying threads share a heavy load in the very same way that strong ideas form a great movement. Over the last few weeks, I’ve picked up on a couple of threads that I believe need to be at the core of the Open Source SDN implementations to insure the strength it really needs. At the OpenDaylight Summit, I had a chance to speak with a number of vendors about the future of OpenDaylight (ODL) and my desire to see every vendor making a controller based on ODL commit to not make any changes to the distribution that doesn’t come from the project. In other words, don’t fork the code because doing so presents a number of deleterious issues such as:
• Changes from outside the project make it more difficult for vendors because those changes may conflict or introduce new bugs with the updated ODL code
• Increasing the time it takes import changes from ODL into the forked code due to increased testing and validation
• Impacting integration from other products due to unexpected changes to the controller behavior
• No improvements to the overall health or functionality of the OpenDaylight code if changes aren’t up-streamed.
Colin Dixon, Chair of OpenDaylight’s Technical Steering Committee and a Principal Engineer at Brocade; and Devlin Avery, also from Brocade, spoke at length in Best Practices and Pitfalls for Building Products Out of OpenDaylight about the discipline needed to not clone and fork the code base. Brocade is demonstrating leadership in SDN by making a public commitment to not fork the Open Daylight code at all. It’s tempting for vendors to make changes that they think can be reverted later, but in reality, doing so instills bad habits and complicates their software development lifecycle. Perhaps more importantly it will create problems as the project matures and software vendors try to maintain consistent code bases that diverge more and more. There is also no guarantee that products that integrate with ODL will work properly against a forked version.
So you’re thinking, “Well, that’s great Mike, but what can I do to change this?” The answer is to speak with your wallet. At F5’s Agility 2015 conference, General Colin Powell (Ret.) gave the keynote. He’s an entertaining speaker and draws on his experience in the military and government work. Midway through his keynote, he expressed his frustration with the gridlock in Congress and made a pointed statement that while Congress is dysfunctional, it is we, the voting public, who put our representatives there, and we can vote them out as well. Changing Congress is hard, but this principle is actually easier to implement for enterprise IT.
When it comes to support for standards and open source software, you “vote” with your wallet. I don’t think there are many networking professionals evaluating ODL today that really want to be locked into a particular vendor’s product line, but once you buy into a fork of an open source software project that’s exactly what you’ve done and you will may well have signed on to have fewer timely updates and far less seamless integration in the future. Trust me, you don’t want that. The solution is to tell your networking vendors that are shipping software based on open source software that you don’t want forked code; and if they can’t deliver project-consistent code, you’ll be shopping elsewhere.
SDN will create varying degrees of product dependencies for enterprises.
Enterprises need to plan for and create processes that support multi-vendor SDN.
It’s no secret that I think SDN Will Lock Enterprises in Tighter Than Ever because of the dependencies that are built up with software integration and I don’t think many enterprises have quite grasped the amount of stickiness software integration has.
Naturally, there is a continuum of SDN implementations, ranging from very basic integration with just enough touch to automate networking provisioning for VMs to fully automated, application-level provisioning that includes service chaining and follow-me functions for traffic monitoring and packet capture, and seamless integration of physical networking without the intervention of a human operator. Depending on where an enterprise is on that continuum the amount of stickiness will vary from “not much” to “a great deal”. Continue reading “Process is Critical for a Multi-Vendor SDN”→
The OpenDaylight project has a good start on becoming a compelling force in SDN with solid vendor support and lots of energy.
There are some hurdles the project needs to get over and some pitfalls that could derail market acceptance.
Is the OpenDaylight project going to take the networking world by storm? It’s hard to say since the project is barely ten months old and only just shipped its first revision of controller software and applications, called Hydrogen. However, if the buzz and energy at the sold-out inaugural OpenDaylight Summit are any indication, the chances for its success are very good. Continue reading “OpenDaylight Is an Exciting Start, but Success Is Not Guaranteed”→