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:
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:
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.
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:
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.
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
Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.
"*" indicates required fields
