Stephen Walli works on the Helion converged cloud team at Hewlett-Packard where he does business strategy and evangelism.

I recently attended the Linux Foundation Collaboration Summit. There was a kick-off panel on the opening day and then a couple of days of working group style presentations around OPNFV. The work comes under the sponsorship of the Linux Foundation and hopes to establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of Network Function Virtualization. (You can also read the ETSI definition of NFV). There’s a really good description of the intended work and architecture on the OPNFV site.

The panel was moderated by OpenDaylight executive director Neela Jacques, and participants included Ericsson, 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.

Standards organizations on the other hand:

– collaborate on interface specifications to enable multiple [communicating] implementations
– by negotiating a compromise position amongst participants, and
– democratic influence is gained by diplomacy and participation.

Time frames are also 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 all about telecommunications technology 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:

– When are you going to have work done for us to review?
– Notes on <some topic> are missing from the OPNFV wiki.

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.

This article is republished with permission from Stephen Walli’s blog.