Is Open Gateway the answer to telco’s Twilio woes?

I had a monster post on LinkedIn recently, called Telco execs: Are you jealous of Twilio? And boy, did I hit a nerve.

The post was about how Twilio, the communications platform, managed to displace telcos in the communication platform-as-a-service (CPaaS) space. How’d Twilio do it? It created a growth company by giving software developers the tools they needed to easily integrate messaging (and voice and video) into their apps and services, and commoditized your network in the process.

But telcos aren’t ready to give up the fight—yet. The GSMA announced at MWC23 that the industry is attempting to create its own network application programming interfaces (APIs) with the Open Gateway initiative. There’s a lot of skepticism, but 25 mobile network operators have joined the effort, along with hyperscalers Amazon Web Services (AWS) and Microsoft Azure. They have API specifications for eight services so far, with more reportedly on the way this year.

In order for Open Gateway to work and for telco to take back revenue from Twilio, three things need to happen:

Operators need to build a developer community.
The service needs to be easy as shit to use.
The price has to be right.

Build a developer community

To monetize these CPaaS APIs, operators need to build a developer community. That’s no small task. IBM spent $34 billion on RedHat to acquire, among other things, a developer community. If you don’t buy it, you gotta build it. Here’s what it takes:

Traction: You have to attract a critical mass of enterprise software developers. Reaching them is a huge marketing challenge. Once you have their attention, you have to convince them that your way is as good or better than the Twilio way that they’re already using.
Low churn: Once you’ve brought willing developers into the fold, you have to keep them happy, engaged and invested. This means your product and service has to be GREAT. It has to be easy to use, updated regularly, bugs fixed quickly, etc.
Active community: Once you’ve built your community, you have to nurture it with things like hackathons or meetups, as well as in online spaces where developers can ask and answer questions, share code, and generally support each other.

Building a successful developer community takes time and investment. Twilio was founded in 2008 and went public eight years later, in 2016. You know how many developers were on the platform at the time? ONE MILLION. THAT’S IT! (It now has over 10 million.) Is the plan for Open Gateway that each individual telco will build its own developer community? Or will Open Gateway do it for the telcos, like TMForum has done on its OpenAPIs / ODA? Regardless, some telcos are starting to do this on their own. For example, US MNO DISH launched its Developer Xperience at AWS Re:Invent last year. Telefónica seems to have launched its own Open Gateway developer website. But both of these sites feel new and unused, and don’t give off the warm fuzzy feeling of being a vibrant community. Clearly, it’s early days for telco in building a developer community.

Make it easy to use

One of the reasons Twilio was able to steal (yes, steal) messaging enterprise revenue from telcos was that it provided a common, easy-to-use API layer, which telcos did not have at the time. Twilio enabled developers to use the same API signature to send messages, regardless of network, to anyone around the world. The effort by Open Gateway to get 25 operators to agree on using the same API signature is a step in this direction. In this way, it’s good.

But I read the spec for Open Gateway that GSMA released recently, and I still see a problem with it: the code for the APIs still needs to be written. Only the specs of the API have been defined. This means each individual telco in the Open Gateway program will still need to develop, productize and test each API for its network, on its own (it has to actually write “the guts” of the API). How long will this take? Telcos aren’t software shops. Even if they burn the midnight oil and crank out the API code, each telco will implement it with its own variances, so the behavior is not guaranteed to work exactly the same across every single telco. This is the beauty of Twilio: one API, and it doesn’t matter which network executes the SMS. It works the same whether the SMS goes to Brazil, India, or the UK. How will the Open Gateway program guarantee this experience? This is key.

But perhaps the real problem is that in order to monetize this whole thing, we’ve gotta convince 10-million developers to flip over to use our APIs. This will require all those existing customers of Twilio (your target prospects) to change working code: they will need to modify written, tested, deployed code, and swap it over to the Open Gateway APIs. Will that happen? That’s definitely a challenge.

For example, just look at the two snippets of code below.* (And I swear I’m not trying to turn you into a developer, but hang with me for a sec.) Both API calls create a one-time passcode (OTP) to send to a device. It’s one of the most basic use cases for CPaaS APIs. The first example is for Twilio, and the second is for Open Gateway. It doesn’t really matter what the code says. What matters is THAT IT’S DIFFERENT CODE. So let’s say developers join your dev community, they want to use your APIs, and they want to swap out Twilio code for Open Gateway. In every place in their code, they will have to copy, paste, recompile, and test. The commercial question is, will that happen? Maybe, but only for the right price.

Example 1: Twilio “send a one-time passcode” API via SMS:

Example 2: Open Gateway “send a one-time passcode” API via SMS:

Open Gateway one-time passcode API via SMS

The price has to be right

Back to why we are doing this in the first place: REVENUE. How will telcos monetize the APIs? On the DISH and Telefónica websites, there’s ZERO information on pricing. There are ways to request more information, but if I’m a developer itching to use awesome, telco-grade network APIs in my app, you want me to … call you? Sign an enterprise agreement before I can access it? I’m not even sure your product will work for my application, and you want me to go through the same process you go through to buy … a car? Um, no, and not even close.

Again, here’s where Twilio kicks our ass. If you go back to the Twilio’s OTP API example above (called the Verify API) and scroll down to the last item in the left-hand menu, there’s a little link for Verify API Pricing, and I can see it’s $0.05 to call this API, per use. I can read the doc, decide if it’s for me, look at the price, and say, sure, I can spend $5.00 (for 100 API calls) and test it out. Straightforward and simple.

The Empire Strikes Back

I may have taken some wind out of the sails of Open Gateway, but I still think we have a chance. I say that because the time is NOW to strike and take back what’s ours. If you haven’t read the news, Twilio is under attack. Not by telco (though it should be); but by activist investors. Its recently high-flying stock is down, its CEO is under pressure, and the activists are pushing for organizational changes and results. The founder CEO Jeff Lawson may be on the way out, and he’s slated to lose his very powerful “supervotes” at the end of this month. (He has 21.8% of the vote, even though he owns only 3.7% of the stock. When that expires, activists will have more voting power and can apply more pressure.)

This is the perfect time for telco to attack while Twilio is experiencing weakness. But what are we doing? We aren’t launching a competitive attack; instead, we are wasting time, each writing our own implementations of the APIs, which will take years. What a missed opportunity.

Thankfully, I have a telco enterprise software startup called Totogi that’s working on a plan for you. We aren’t ready to announce our plan … yet … but with TelcoDR’s recent purchase of Kandy, we may have some tech that can help telco out. If you’re an MNO looking for a way in, give me a call and let’s go after some of that SMS market share.

* For nerds like me who are curious to know more about what makes these snippets different:

Twilio requires you to configure a template and replaces “FriendlyName” and “code” in the template. So, you simply pass FriendlyName as the parameter.

OpenGateway requires you to pass in a message template and substitutes in the code. So FriendlyName = Cool App in Twilio, which should result in the same message being sent out.

Other differences:

Twilio uses basic authentication—you pass in account SID and auth token as user/password (that is the last “-u”)

OpenGateway uses OAUTH authentication, which means you exchange credentials for a token and then pass it in a header (Authorization: Bearer {token})

In OpenGateway those headers say you’re sending JSON and getting back JSON. If you want to delete those, there’s a good chance it will still work.

Recent Posts