Thinking back & looking forward: 20 years of TM Forum open source programs

The first lesson: Crisis promotes change.

It was 2004, the telecoms bubble had burst, and the telecoms industry was still in shock with more than 500,000 layoffs and $2 trillion of value wiped out. This didn't seem a particularly auspicious time to launch a new project, but I had just started doctoral research at Southampton University and wanted to investigate open source in the telecoms industry. Nervously, I proposed an open source "Birds Of a Feather" session at TMW Nice 2004. Today it's difficult to believe how controversial the proposal was. When the TM Forum began to see this as a possible new strand to increase the value of participation from a cash-strapped membership, some members branded us the "open source pirates" and complained to the board. Fortunately, other industry players were willing to consider the open source option as the industry desperately looked for opportunities to de-risk R&D and reduce overall IT costs. Advocates included BT, Agilent, and Sun (now Oracle). Our early efforts led to open source becoming central to all subsequent interface programs.

The second lesson: Software is a fashion industry.

Every new technology's popularity waxes and wanes. All TM Forum initiatives are eventually superseded by new tech, as was the case with the OSS/J and TIP API programs. So it's important to invest enough to track changes, but not bet the farm on technology until industry adoption is proven. Several companies learned the hard way through the TIP program—which focused on WSDL, which was retired in favour of REST / JSON technologies. The trick, particularly for a small company, is to put in enough investment to signal interest and show thought leadership, but be prepared to move on quickly if the work isn't driving business. If customer demand materializes then the early open source experiments can be productised quickly.

The third lesson: Though they are free, open source tools need sustaining revenue.

Previous interface programs like TIP and OSS/J created their own tooling, but it was difficult to build enough adoption to maintain. It appears that the latest interface program has learned that lesson and adopted OpenAPI tooling—widely accepted outside of the TM Forum. The tools are maintained and used by a community to which the TM Forum contribute—rather than own. The TM Forum employs a small sustaining team and facilitates occasional contributors (the majority of members) to make contributions that are merged and sustained within the wider codebase.

My worry is that the interface program could be in danger of trying to do too much for the sustaining efforts to be effective. The first interfaces from this program were pretty much hand-crafted and weren't necessarily consistent in data types or interaction patterns. A more consistent core entity model and newer HATEOAS -based design patterns have been introduced. Additionally, there are plans to provide AsyncAPI -based implementations of some of these same interfaces. Consequently, there are now more than 50 interfaces which need sustaining effort to migrate to the same level of compliance, fix bugs, or add necessary enhancements. This adds uncertainty to adoption.

The fourth lesson: Education, examples, & documentation are critical.

Technology creators need to promote the network effects of adoption—the more people who use a technology the more valuable it becomes. In particular, it's important that potential adopters can evaluate new technology quickly and determine the effort required to use it properly. Insufficient documentation sends a bad message.

Although the current interface program is doing a much better job than its predecessors, I believe there's room for improvement. Even though the interfaces are now published on GitHub, it's difficult to understand how they are to be used without access to material only available to TM Forum members. I've tried to use TM Forum interface assets to teach DevOps to computing students (winning a TM Forum Hackathon). However, the student feedback was that information is hard to find and not very well organised, even if you have a TM Forum account. While much of the tooling and interfaces are now published on GitHub, documentation and communications are still restricted to TM Forum members. I believe this significantly restricts the reach and uptake of the interface work and prevents outside expert contributions. An outsider might perceive this as suggesting that the TM Forum still has an ambivalent attitude towards open source, possibly driven by the desire to sustain the membership revenue stream. On the other hand, the TM Forum have made a move in the right direction in the last two years by establishing a wholly owned legal entity, first used for the ODA Component Accelerator[vi], which can accept Apache 2 licenced open source contributions unencumbered by the TMForum by-laws. So I think they are definitely trying to do a better job to encourage open source contributions but they still need to do some work to encourage wider community adoption.

I like to think I've made useful open source contributions over 20 years in the TM Forum. Although I've outlined some challenges, I think the direction is good and hope that OpenNMS will be able to continue to make tangible contributions toward API development and adoption in the coming years.