From Pirate to Proven: 20 Years in Open-Source Network Management pt. 3

Thinking back and looking forwards, what have we learned from the last twenty years of involvement in TM Forum programs and push for open-source network management solutions?

As in the early 2000's when the telecoms bust opened the door to the possibility of open-source solutions, today we are seeing a renewed interest in open source as pressure on margins and competition from Hyperscale cloud providers are forcing service providers to look for more cost-effective solutions.

It seems that new technologies wax and wane in popularity. You can put your heart and soul into a project only to have it marginalized to irrelevance. Every interface initiative has eventually been eclipsed by a new technology so it is important to invest just enough to track changes but not bet the farm on a technology which might be replaced in a couple of years. Several companies learnt that lesson the hard way through the TIP program.

The trick, particularly for a small company is to put enough investment in to signal interest and show thought leadership but be prepared to move on quickly if the work isn't driving business. If, however, customers like the work then the early experiments can be productized quickly.

It appears that the latest interface program has learnt this lesson and has employed some developers to sustain the tools. A clear advantage is that the core open source OpenAPI tools are maintained and used by a community to which the TM Forum contribute rather than own. The small TM Forum sustaining team allows occasional contributors (i.e., the majority of TM Forum members) to make their contribution which is then merged and sustained in the wider code base. One can only hope that this will be a long-term commitment on the TM Forum's part.

A parallel observation would be that the interface program may be trying to do too much for the sustaining efforts to be effective. The first interfaces from this program were pretty much handcrafted and not necessarily consistent in data types or interaction patterns. Later, a more consistent core entity model and newer HATEOAS based design patterns have been introduced. Additionally, plans are afoot to provide AsyncAPI based implementations of some of these same interfaces.

Consequently, there are now over 50 interfaces, each of which need ongoing sustaining effort to migrate them all to the same level of compliance and to fix bugs or add necessary enhancements. Furthermore, these interfaces were originally developed by different expert teams which have since disbanded, and the documentation on the use cases for each interface can be patchy.

All of this potential churn adds uncertainty to adoption. Do I use the currently published version or wait for the latest tooling to be released? Do I treat these interfaces as 'good starting points' for my architecture or as a mandatory set of compliance requirements?

Other advanced initiatives such as the TM Forum canvas are complex and also need reference implementations which are widely visible to drive adoption. It would be very beneficial if the canvas program could contribute upstream to make the canvas a component which is sustained in the Kubernetes ecosystem.

This leads into my final point. Technology creators need to promote the network effects of adoption - i.e., the more people who use a technology the more valuable it becomes.

In particular, it is important that a potential adopter can evaluate a new technology quickly and determine how much effort will be required to learn how to use it properly. Insufficient documentation sends a bad message that the technology is either too difficult or that the creator does not support the technology on an ongoing basis.

While much of the tooling and many of the interfaces are now published on GitHub, the documentation and team communications are still restricted to TM Forum members. I believe this significantly hampers the reach and uptake of the interface work and also prevents contributions from experts outside of the TM Forum community.

The interfaces could have real value for the wider IT community. A more serious commitment to promoting the interfaces through open source would help.

I’ve found that TM Forum has navigated the difficult balance between being both a member trade association and a standards creator. It has managed to remain relevant to its core membership and deliver some very useful technology innovations to the wider industry.

I think the direction is positive and hope that OpenNMS will be able to continue to make tangible contributions towards API development and adoption in the coming years as open source continues to be proven out as a viable approach to open-source network monitoring standards.