Keynote: Open Source, Open Standards & Open Vendors

This keynote compares open source versus closed source orchestration in Network Function Virtualization (NFV) deployments, arguing that the primary value of open source lies not in cost savings but in transparency and collaboration.

**Overview** The speaker explains that NFV service onboarding—consuming VNF artifacts including TOSCA scripts, testing, certification, and deployment—is an inherently complex, multi-step process. Each step incurs labor costs and time delays. The real differentiator between open and closed source orchestrators emerges during troubleshooting and vendor coordination.

**Troubleshooting Comparison: Closed Source** When issues arise with proprietary orchestrators, the escalation process involves multiple parties: the CSP (Communications Service Provider) operator, the closed source orchestrator vendor, and the VNF vendor. Because both the orchestrator and VNF are black boxes, troubleshooting requires 'triangulation' across multiple unknowns. The speaker describes these cases historically escalating to R&D, testing, and expensive off-site meetings where engineers travel to remote locations to resolve issues collaboratively. This complexity creates communication overhead, pointing of fingers between vendors, and extended timelines.

**Troubleshooting Comparison: Open Source** With open source orchestrators, when an issue is discovered, the CSP engineering team can directly engage the VNF vendor. Crucially, the VNF vendor has full access to the orchestrator source code, can test locally in their lab, and can contribute fixes directly. The VNF vendor may become a contributor or committer to the open source project. There are no black boxes, minimal escalation chains, and no exotic off-site meetings. The speaker emphasizes the substantially reduced number of communication arrows in diagrams.

**Key Takeaways** The speaker argues that while people often associate open source with cheap licensing and fast vendor switching, the true value is eliminating black boxes and enabling direct vendor collaboration. Each of the 15+ deployment steps has similar left-and-right comparisons, but transparency—knowing that each stakeholder can engage directly and without pointing fingers when issues arise—is the 'huge benefit' that demonstrates real agility.

**Q&A Insight** When asked how long upstream acceptance takes, the speaker notes fixes can be applied immediately to your own fork, while upstream integration depends on the project's release cadence (mentioning ONAP's periodic release windows as an example).