Just how committed are operators to open source? We see a lot of stories about their sweeping shift to open-source technology, but is that shift a real one? I did a quick survey of operators last month, and over three-quarters of them said that their current open-source deployments (beyond things like Linux and other software hosting elements) was less than 5%. Almost the same number said that it wouldn’t likely grow much until after 2020. What’s really going on?
There is no question that operators want to be more committed to open source. In that same impromptu survey, only one operator said they didn’t think open-source technology would figure in their transformation plans to any greater degree than it did today (as a hosting platform for OSS/BSS). This operator didn’t see a transformation driven by a shift to hosted features, so every operator who does see that sees open-source elements playing a big role.
What, then, is holding them up in the near term? There are three dominant issues, and all three of them could tell us a lot about how our transformed future might emerge.
The biggest problem cited by operators is the lack of a complete open-source ecosystem to fulfill requirements. About half the operators said that they couldn’t find all the pieces of transformation in open-source form, and the other half said they could find what they needed but that they were uncomfortable about the integration.
This issue seems to emerge from the counterpressures of two points. First, the industry tends to focus on narrow offerings in almost every space for the simple reason that broad technology shifts are difficult to justify. Oil the squeaky wheel. Second, though, operators need a high-level vision of what the total new infrastructure architecture would be, or they can’t fit things into it with any confidence, or build to it through their own efforts. Lifecycle management seems to be the particular focus of these points.
You can see, in initiatives like AT&T’s ECOMP (now ONAP), that there’s still a tendency to view the lifecycle management process as an “application” in a traditional sense, something that runs in a monolithic way, takes “inputs” in the form of orders, changes, and faults, and somehow makes things work. It’s been clear for the last decade, in my view, that this approach isn’t workable, but it’s still the intuitive pathway to solving the problem of automating complex services built on complex infrastructure.
Enthusiasm for ONAP, once at a level of almost 80%, has dipped to roughly 50%, and while operators don’t tend to state their reservations in software architecture terms, they do see problems with “integration”, “scalability”, and so forth.
The second problem operators list for open source is the disorderly change and release processes they find in open-source groups. A few operator planners remember the old days of telco switches and their releases, which were planned on a two-year timeline and released every six months. Most of them, while they don’t yearn for this nice structured framework, do believe that there are simply too many changes made too quickly, and that all the figures in the open-source ecosystem dance aren’t hearing the same music. A release of something fundamental can break a bunch of things because of dependency issues, and yet that release may be needed to get some other key feature supported.
There’s some truth in the view that open-source changes a lot, and with a certain lack of coordination across multiple projects. However, there’s also truth in the view that the changes are driven by market needs, and so a more orderly release process would likely compromise feature evolution, perhaps to the point where it took too long to finally implement what was really needed for a given service or feature to deploy usefully.
We have open-source companies (Red Hat, in particular), and even telecom initiatives from those companies, but so far those initiatives aren’t complete, meaning they miss the boat on the first of our issues. It might be fair to argue that unless we can resolve that first point of completeness, we’ll never get a solution to the problem of release disorder because the releases won’t solve operators’ problems. The obvious solution to this would be for Red Hat to take the lead and define/assemble a complete ecosystem. They’ve not done that, and that could be because they don’t know how (they don’t know what’s needed), because they can’t find the pieces out there, or because they haven’t tried.
The third problem is product direction, integration and support. With respect to product direction, open-source stuff is a bit like a Ouija board; it goes where consensus pushes it. With regard to integration and support, you’re back to the issue of project scope for the former, and to “community” support for the latter.
Support is perhaps the biggest point in this particular issue, and that clearly points at the open-source support-bundled community. Operators have run into integration and support issues with things like NFV, and they see the broader ecosystem they know is needed (even if that ecosystem is still a hazy picture at best) will have even more of those issues. They’re used to having somebody be responsible for everything, and it’s interesting that while operators are eager to avoid “vendor lock-in” or “proprietary” strategies, they seem to want the one-stop-shop benefits that come with those downsides.
This is where I think it’s fair to say that operators’ mindset has to be changed. As sifi writer Heinlein once said, “There’s no such thing as a free lunch”. You don’t get free support with free software, you get no support in the sense that operators have come to interpret the term. To create another whimsical phrase “You can’t back-seat drive a self-driving car.” Operators can’t expect to have a decisive role in directing a project they elect not to resource decisively.
It would be exciting to see operators really shift decisively to open source, which of course is why we see so many stories about it. The publicity isn’t helpful, though, because it hides the issues operators themselves cite, and hidden issues rarely get addressed. For the three operators cited to me, it’s going to be difficult enough to get them resolved without adding the issue of hiding them. As is often the case with operators who shy away from “vendor lock-in”, their future may end up being decided by a vendor or vendors who step up to solve the problems.
Both Red Hat and VMware seem to have specifically targeted the operator space, and this could bring about a more ecosystemic vision of operator software, but so far neither firm has covered even the most critical software spaces thoroughly. It’s hard to say whether they intend to, because in this day and age, it’s not uncommon for vendors to start something with a lot of flair, then slow-roll the hard stuff. If that happens here, we may have to wait a long time for the open-source revolution to really hit the network operators.