Cisco just entered the WebRTC PaaS Game by Acquiring Tropo

These things happen when I have the least amount of time for them.

Why couldn't they wait until next week? Just when I go on a vacation with the family, I need to halt everything, take out my laptop and sit down to write a post. The news this time? Cisco acquires Tropo.

Tropo is one of the 19 (!) vendors I cover in my WebRTC PaaS report (more will be added later this year).

Tropo is also the 5th distinct acquisition in this space:

1. TokBox got acquired by Telefonica
2. AddLive got acquired by SnapChat - and taken off market
3. Crocodile RCS got acquired by Acision - and morphed into Forge
4. Requestec got acquired by Blackboard - and taken off market

And now Tropo gets acquired by Cisco.

Zeus Kerravala does a good job on NoJitter to explain what this means to Cisco, I'd like to touch some additional points here.

Why Tropo and no one else?

• If Cisco is serious about developers and APIs,  the it should have acquired one of the communication API platform vendors instead of building its own
• The vendors with the largest developer communities around are probably Twilio, Tropo and TokBox
• Twilio is somewhat out of reach - it just raised another $100M with a $1.1B in valuation. Probably more than Cisco would be willing to invest, and  at a time when Twilio won't be willing to sell
• TokBox belongs to Telefonica already
• Tropo was up for grab
• Tropo is playing in the service providers market, where it tries to integrate its APIs right into telcos. This fits well with Cisco's target customers
• Tropo readied its platform for SDN and NFV - both acronyms are important to Cisco in their own portfolio, and in that regard, Tropo was the only Comms API platform with such a focus

The Challenges ahead for Cisco

In recent years, Tropo has changed focus. My understanding from speaking with a past employee of Tropo, they shifted their focus somewhat, trying to appease service providers (their target customers) instead of their developer community (their suppliers/ecosystem). While I am unsure if that is correct or not, there is little to be said about the breadth and depth of WebRTC capabilities that they have introduced. Their efforts have been spent elsewhere in the past year.

Will Cisco continue with this trend, trying to focus on service providers, large enterprises and its own Spark product integration, or will it try to compete head to head with Twilio and TokBox, trying to gain a leadership position with communication APIs and WebRTC?

It will also be interesting to see what route they take with video support in Tropo. Up until now, video hasn't been Tropo's strongest asset, having no real multiparty support to speak of. This places Cisco/Tropo at a cross road:

1. Should they support multiparty video by mixing?
   • Cisco has considerable know-how and assets in that technology through its Tanberg acquisition, Telepresence systems and many years in the Enterprise Video Conferencing Market
   • Tropo partnered in the past with Dialogic to offer similar capabilities to some extent
   • It may fit well into large enterprises and Cisco's current thought processes, but it makes little sense with large scale cloud deployments, consumer services and to some extent WebRTC as a whole
2. Should they support multiparty video by routing?
   • Routing is what most other WebRTC PaaS vendors end up using
   • It is cost effective considering the alternatives
   • It is Atlassian's reason behind acquiring Jitsi
   • But it may not fit well with Cisco's DNA and thought processes

Will they even focus on video?

Will developers be attracted to Tropo or will they look for their solution elsewhere?

Was this acquisition about the technology? Was it about the existing customer base? Was it about the developer ecosystem?

Why is this important?

The communication API space is moving forward. The map of available alternatives is different than what it was a year ago. It will probably change again in a few months.

If you are planning on joining this space, then you need to consider your strategy carefully.

If you are planning on using a communication API vendor for your next service, then finding the most suitable one for your needs require a well thought vendor selection process.

Check out my report (and consulting services). I will be happy to set a call with you to see how I can help you with your strategy or vendor selection.