Somebody asked me yesterday what I thought was the pathway to open-source success in the telco space. I got involved in open-source and telco applications thereof back in about 2008, working within the TMF and the IPsphere Forum. In both these bodies I was for a time the only non-telco representative in the group, and sadly neither of these efforts came to much. Does participating in a failure qualify you as an expert on something, you might wonder. Perhaps not, but being involved with two of them gives you an insight into why something like this isn’t easy. You have to start at the beginning, with lawyers.
Telcos worldwide are highly regulated, and one aspect of regulation that is particularly plaguing to them is the anti-trust stuff. It’s hard for a highly interconnected industry like telecommunications to progress if every operator goes their own way; you need to meet in the middle of every interconnect whether you’re interconnecting devices or software. You’d think that a bunch of telcos could just form a body and hack out the requirements and specifications for doing something using open-source software. Wrong. That’s collusion, as their lawyers will tell them, and those same lawyers would pull them bodily out of any such activity.
Standards bodies or industry groups are exempt from this collusion risk providing their membership is open to all, so they don’t become a forum where telcos could engage in rampant anti-competitive activity. The NFV process, launched by telcos, was surrendered to an open body (ETSI) because of this. The problem is that open membership means that the bodies tend to become stacked with vendors, and control then passes to those vendors. Many in the SDN and NFV worlds would admit in private that this has happened to both these technologies.
The reason I’m going through all of this is that it’s the background for the current telco open-source interest. The telcos cannot build something on their own (many are also barred from manufacturing, in fact). They can’t form telco-communities to build something jointly, and their efforts to build something in open standards groups have been taken over by vendors. What’s left? Why not open-source software? At the very least, telcos could hope to contribute code of their own to a project and thus keep their own interests represented. Further, open source projects could put the vendors in the position of joining and cooperating, and by doing so devaluing their own proprietary strategies, or sulking away and leaving the task to the companies who wanted it in the first place.
The hope of an open-source solution to next-gen network technology and infrastructure has traditionally been dashed by a mixture of three factors. First, telcos have had a hard time getting funding to do coding, which leaves them at the mercy of actual contributors—usually vendors. Second, telcos have no strong history of software design and development, and often have no idea how to go about an open-source project. Third, telcos really love having scapegoats. If a commercial product fails, you can sue the vendor. Who do you sue if an open-source product failed, particularly if you were one of the contributors? Who stands behind and supports a non-commercial, community, effort?
Open source issues have been addressed and resolved before. Apache, OpenStack, Red Hat, and many other software projects and open-source companies have worked out a model for development and deployment that has been successful in many other industries. That means that to the extent that there is an answer to the “best-path-to-telco-open-source” question, the answer is likely to be based either on mimicking the practices of those past successes or simply letting one of the successful firms do the job. We could call this the “OpenStack versus Red Hat” dilemma, casting a specific company as a representative of their respective models.
OPNFV is an “OpenStack” or community approach, and I think most telcos would agree that they’d love to see this approach win. The problem that seems to be limiting the chances of that happy outcome is the fact that rather than attacking the problem of NFV from the top down, as a real software development organization would do to fulfill a generalized set of goals, they’ve elected to presume that the ETSI ISG specifications will set the software requirements. Those were not developed from the top down. Furthermore, the “community” really doesn’t have a single purpose. Some already believe others are deliberately obstructing progress, and since NFV is a threat to some big incumbents they may be right.
Red Hat isn’t currently offering an NFV solution at all, but their approach to enterprise Linux is certainly a model of success. You pick out what you believe will be a powerful, agile, and stable set of software components and you adopt them as your platform. No community to wrangle with, no compromises to be made. Doing telco software this way would work if the Red-Hat-or-imitator sponsor could be relied on to make the best choices for the telco buyers. Since open-source companies like Red Hat have no horse in the SDN or NFV race, they could very likely be expected to do just that for commercial gain alone.
I’ve done some work on mapping open-source software to SDN, NFV, and networking problems in general. Others like Overture Networks have also done that, and I think it’s clear that you could build everything you need for next-generation management, orchestration, and operationalization of next-gen networks by assembling open-source elements. So perhaps the path to an open-source telco future lies not in communities but in the hands of some open-source giant like Red Hat.
Consensus is great for a lot of things, but despite some myths of the ‘60s it doesn’t actually define reality. What telco open-source needs is some picking and culling to identify the best components already available, then an earnest effort to support whatever development remains. That’s true in the narrow area of SDN and NFV, but also in the broader area of OSS/BSS. We have to get this process moving, which I think means recognizing that consensus processes have failed us many times already. Successive approximation may now be the answer. Build suites by collecting stuff and let the best approach win.
I don’t mean to suggest Red Hat is the only player who can do this, of course. Many companies have strong open-source positions, and any of them could step up. Until they do, I think the telco open-source initiatives are all heading down the path of past initiatives—toward an inconclusive outcome at best.
