The panel was moderated by OpenDaylight exec director Neela Jacques, and participants included Eriksson, Red Hat, Cumulus Networks, and the community manager from Openstack. I tracked the OPNFV work for its first half day of the follow-on workshop and spot checked the work for much of a second day. OPNFV started last Autumn. To develop a "reference platform" for NFV activities, the group wants to integrate the work across other open source projects (OpenDaylight, OpenVSwitch, Openstack, etc.), determining what is needed and working with the relevant upstream groups to contribute to each project community appropriately.

What’s most interesting to me is the very different cultures that are exposed in the room. Successful open source communities:

build the one true implementation

by collaborating through contributions upstream, and

meritocratic influence is driven by the contribution of code, infrastructure, and effort.

Time frames are also different very different between such technical collaborations. Successful open source communities are building in real time, and larger complex projects have begun scheduling themselves around agile six month delivery cycles. Standards documents often need to support complex externally driven procurement and certification needs and are carefully [sometimes deliberately slowly] developed to ensure participants can meet those needs, and once agreed, change relatively carefully i.e. slowly and with rightly conservative process. (For the moment we’ll assume the open source project is mature enough to be hosted inside a foundation so IP management is understood, and that the IP management of the standard is equally well managed in the standards development organization.)

NFV is a telecommunications thing and the telco world was historically driven by standards with large internationally-focused organizations (ISO/IEC, ETSI, etc.) at their core. Linux as a vibrant open source community has demonstrated its ability to deliver vendor-collaborative engineering value this past 25 years. Openstack is attempting to replicate that success and is the hub for much of the present Infrastructure-as-a-Service (IaaS) cloud work. As explorations of software defined networking (SDN) have begun in the open source community, projects such as OpenDaylight (also under the auspices of the Linux Foundation) and now OPNFV have begun. The telco community wants to invest in driving this sort of open source collaborative work forward to reap the benefits of reduced costs and delivery agility. They just don't necessarily know they need to participate differently.

The OPNFV working group provided a stark example of this lack of understanding. Dave Neary (Red Hat) gave an excellent presentation on open source collaboration to the room. Chris Wright (also Red Hat) led a number of discussions. But many of the comments from the telco audience participants tended to be of the nature:

Many of the standards-centric telco participants seem to not understand that work happens in an open source community WHEN they participate and by their very participation.

Chris Price (Ericsson) is a primary technical leader for OPNFV. He too is working hard to understand the sort of coordination and participation that will be required. The coordination efforts across the collection of projects is enormous. Chris Wright made reference to one piece of work he tried to negotiate that required changes to OpenDaylight, Openstack, OpenVSwitch, libvirt/qemu and a couple of other projects and how trying to communicate requirements and priorities across such diverse projects is difficult. Just because he had a coordinated set of patches for each project doesn't mean there's interest to accept such contributions "from a stranger" into a project focused on different priorities. It’s not simply about drive-by contributions. One needs to participate enough to be heard.

Likewise, using terms like "reference platform" in a standards-centric audience is often an invitation (indeed a command) to fork code. There is an enormous engineering cost to living on a fork, and to not aggressively contributing small changes regularly, and it often takes vendors unfamiliar with open source participation a while to come to grips with this learning curve.

Ultimately, the work is very important going forward. There are many vendors in the room (including HP where I work) with a wealth of open source experience. Hopefully, any initial confusion is sorted quickly and the work will move forward accordingly.

Comments

One of the problems with OpenStack is that too many of the "participating" companies are just standing there waiting for someone else to do work, while complaining that some feature that they want does not exist or is not mature yet, without they themselves doing any real work themselves on it it. I fear OpenNFV will be even worse at this.

Mark, thank you for taking time and articulating the cultural challenges associated with Telecom and IT coming together to shape the new play ground for the converged industries. Do you see any differences now 4 months later compared to when you wrote this article? How do you see the open source community engage with the Telecom world to secure the best of both worlds come together? Do you see any activities to improve the business model for the integration and life cycle management cost for the OPNFV initiative, compared to classic open source inititives you have bern involved with?