Mike Fratto
• 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.
