The good news is there has been a lot of progress establishing interoperability labs for products and services based on network function virtualization (NFV) software. The bad news is the existence of all these initiatives only highlights just how fragmented the NFV vendor community really is.

But fragmentation should not come as a surprise. Networking vendors are essentially jockeying for position before engaging in inevitable NFV standards conversations. As the industry enters 2017, there are some very big NFV deadlines imposed by telecommunications carriers. These operators are anxious to deliver 5G services, and networking vendors need to keep that in mind. Many of these operators have made an open software-defined network (SDN) capable of deploying NFVs a cornerstone of their 5G strategies.

The trouble is that most of the SDN/NFV platforms available today have deep hooks into either the underlying infrastructure or the NFV management and organization (MANO) plane used to manage them. Porting NFVs across multiple SDN/NFV environments becomes problematic for both the developer of the NFV and the customer that deploys them.

Given the current lack of progress in NFV interoperability, Patrick Filkins, an industry analyst with Technology Business Research (TBR), suggests that operator plans to deploy 5G might be extended. Instead of implementing an entirely new networking environment, many carriers may opt to deploy 5G gateways at the edge of their existing networks. They can then deploy SDN/NFV later when the technologies are more mature.

“There are a lot of hurdles,” says Filkins. “Many carriers might decide they don’t need to completely re-engineer their backend platforms to start delivering 5G at the edge.”

Those decisions could wind up putting a lot of pressure on networking vendors that are counting on carriers to serve as a catalyst for NFV software. Without demand from carriers being in place by the end of the decade, many startup networking vendors, for example, would either need to get additional rounds of funding or be forced to sell their intellectual property to more well-healed competitors.

Worse yet, given the extended timetable, the core software that NFVs are built on might be disrupted by newer technologies. Many NFV providers are already moving to make their core software available as a Docker container that present carriers and enterprise IT organization alike with a de facto set of standard application programming interfaces (APIs).

Because of these issues, networking vendors today should have a vested interest in accelerating adoption of a comprehensive set of open NFV standards. Without such an ecosystem in place, the rate of adoption of NFVs is likely be stalled.

Filkins notes that both carriers and IT organizations have made it clear that they will invest in proprietary technologies to drive a proof-of-concept. But when it comes time to deploy any technology at scale, they must have a set of open standards in place that prevents them from being locked into a single vendor.

When it comes to fostering the development of a robust SDN/NFV marketplace, the network vendor community may discover that they are their own worst enemy.