Mike Fratto
Summary Bullets:
- 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.
All the panelists have well-reasoned things to say about using open source in commercial platforms, but we know it’s not all roses. Sadly, the session came to close before we could go deeper into the problems they raised, but I caught up with Ari Banerjee afterwards and we had a lengthy discussion. His main point is that while there are benefits to using and contributing to open source projects, when a vendor commits to an open source project for a shipping product, then its development cycle, including regular and emergency software patches, is inextricably tied to the open source project’s cycle, which may not be on the same pace as the vendor’s. It could be that development hurdles in the open source project delay deployment, or there aren’t enough bodies working on a particular, perhaps less popular, feature set, which then has to be pushed off to the next release, or any other reason that results in delays of features that customers want. The vendor is on the hook to its customers if it doesn’t ship features, and the vendor can’t very well cast the blame elsewhere.
These are reasonable issues vendors face, along with ensuring the code is stable and bug-free, security issues are addressed in a timely manner, and all of the rest of the software project management details for which vendors are responsible to their customers.
For IT buyers, you really want to understand how your vendors are working with open source projects, how they are using open source software, how they are ensuring the code given to you is stable and reliable, how it ensures that bugs and security issues are addressed with or without the support of the open source project, and finally, how committed the vendor is to not forking from the open source distribution, something I discussed in “Commitment to Unified Open Source is Critical for OpenDaylight Success in Your Enterprise” back in August.
Well-run open source projects like OpenDaylight are aware of these issues; everyone from the executive director to contributors strives to resolve them in a timely manner, and they are constantly improving – all vendors share the same pain and are motivated to address them – but you have to be diligent.
