It’s no secret that open source is behind many budding disruptions across numerous industries. However, in the telecom industry the concept of “open source” is a loaded one. In theory, vendor interoperability from open source should be convenient — even harmonious — with innovations being shared like recipes. Unfortunately for many, the system has not lived up to this reality.

In this age, not only are operators and vendors clashing on everything from 5G to software-defined networking (SDN) to virtualization, but they are hashing out the basic tenants of open source in real-time and with a global forum. For example, the multitude of projects and plans that use OpenStack have taken twice as long (or more) to complete. OpenStack itself has admitted to an “integration problem” where, despite obvious innovation, the end-result consistently fails to reach fruition. Many in the industry blame these issues on the fact that there’s no true captain on the ship, and without a governing body to help drive the project’s roadmap, too many potential successes never materialize.

At their core, open source projects need to quickly and efficiently deal with complex, community projects with many conflicting agendas. To succeed with telcos, the participating communities need to understand the symbiotic relationship between all parties by taking a critical look at open source and reconsidering how to adapt this methodology to the industry.

Essentially, the hype around open source has created skewed expectations for what could have been an otherwise mutually-beneficial concept. Consider the fact that there are hundreds of different projects and standardization bodies, some of which are working on alternate solutions to the same issues. At this point it’s clear the expectation that open source communities will save costly resources by avoiding reinventing the wheel has not evolved. Even when carriers switch to open source for the “right reasons” these days, it’s not unusual to see complaints such as:

• There are too many open source projects in progress.
• There isn’t a single authoritative governing body for open source.
• Open source groups often have their own agendas.
• Open source projects are not standardized.
• Not enough progress is being made on key projects.
• Open source is adversely affected by vendor politics and interests.

An initial step in the right direction is to reconsider seeing open source as the “wild wild west.” Standards are necessary if carriers want to control the architecture and APIs of different projects, but we need to modernize this process. This way, projects in progress can support fast iterations and can foster a climate of innovation so that multiple projects can be developed from the same framework.

To ensure its own survival and avoid stagnation the industry needs to stop attributing characteristics to open source software that were not initially intended. Most importantly, it is not mandatory for open source to be free (in terms of cost), and the two are not interchangeable. While it undoubtedly eliminates costly proprietary software infrastructures, there are still significant operational costs to consider. For example, you still must pay engineers and developers to fix bugs and upstream features into these projects.

Other issues like how vendors will generate revenue from open-source remain largely unknown. Also, who is ultimately responsible for paying for research and development is yet to be addressed. Still, to expect community members to invest in the source code — just to be able to potentially profit from the apps enabled by this code — is unrealistic. It just encourages communities to be more invested in the apps than in the infrastructure code itself.

Few vendors can afford to build closed systems anymore, so it’s crucial modules are able to work together seamlessly. However, there is still a need to accept “closed” modules so vendors can protect the value of their work. Moreover, vendors must be increasingly strategic about how they utilize the projects made available by open source to ultimately take advantage of its purpose.

To make open source work vendors need to redirect efforts and develop new products with a service-oriented mindset that’s grounded in current market and customer demands. It’s paramount to the integrity of these projects that those involved have the resource capacity and capabilities to drive the specific business needs, all while adhering to the openness and programmability. The products and business models they develop should leverage the power of open source, but also demonstrate the value-add that comes from either refining or strengthening certain solutions, or building something on top of them.

Lastly, vendors across the industry need to realize that open source projects are not created (and never will be created) specifically for their needs. Projects are instead created to meet the needs of its founders. We simply cannot expect open source communities to solve the challenges of our modern networks in the same way that vendors did in the past.

Telecom wasn’t inherently mistaken hyping up the promise of open source; the methodology has true promise and has proven successful in certain sectors. But, if our industry continues to promote the current “flavor” of open source and how it’s being applied operationally, it will surely fail. To reap the benefits (free or otherwise) and avoid cannibalizing itself, telecoms must reframe its expectations of open source and rethink open source as we know it in order to better align with the industry’s needs moving forward.