Developer Ecosystem Acquisitions Makes Build vs Buy Decisions Harder

March 10, 2016

Who do you go to with your WebRTC needs?

That moment you realized you selected the wrong vendor
That moment you realized you selected the wrong vendor

There are now over 20 vendors out there offering WebRTC APIs in the cloud.


How the hell do you decide which one to pick for your service?

This question was rather “simple” to answer, but it is getting harder.

Two months ago, Facebook decided to shutdown Parse. This is something that should not be taken lightly.

In 2013, Facebook acquired Parse. Parse was a MBaaS(mobile backend as a service platform). If you want to build a mobile app, you’ll be needing some backend in high probability – a place to store account information, maybe sync data between users, etc. MBaaS does exactly that, and in this domain, Parse was one of the bigger platforms. They had around 60,000 applications on their platform at the time of acquisition – not something to take lightly.

Facebook didn’t acquire Parse for its great technology but rather for its developer ecosystem – for its popularity. In the two years since, Facebook invested more in the platform – just so it can close it.

In the context of communication API platforms with WebRTC capabilities, what we’ve seen so far are two kinds of acquisitions:


  1. Acquiring a technologySnapchat acquiring AddLive, Requestec getting acquired by Blackboard are such examples. So is Crocodile RCS acqisition by Acision and then Acision wrapped into Xuar
  2. Acquiring a developer ecosystemTokBox’s acquisition by Telefonica and the recent Cisco acquisition of Tropo

Will Cisco decide in a year or two to shutter down Tropo if it doesn’t bring the traction it wants or if it serves its purpose of getting enterprises to adopt Cisco Spark?

Would Telefonica stop investing in TokBox? Highly unlikely after 3 years, but who knows? I wouldn’t have bet on Facebook shedding Parse.

The thing about Parse is that Facebook didn’t even spun it off again – or sold it. It just closed the service. More akin to how Snapchat treated its own acquisition of AddLive.

Kin Lane explains nicely the false expectations people had from Facebook and Parse:

There is no basis for believing a platform or API will ALWAYS be there, no matter what you are promised. Companies go out of business, get acquired, and in this fast paced tech climate, companies are always looking to deliver the latest product, and features. Everything in the space points to disruption, change, and evolution, where the hell did we get the idea these services shouldn’t go away?

What can we deduce?

  1. Platforms with large ecosystems aren’t impervious to being taken off market. TokBox may get shuttered. Twilio might get acquired
  2. In the build vs buy decision of WebRTC, using a platform doesn’t mean write once and forget. You may need to update your code, switch vendors, etc. – be ready for it

As I start working on another update for my Choosing a WebRTC API Platform report, I will take the time to research the reasons for vendors selecting the less popular API platforms – what makes them take that plunge. If you are such a vendor – contact me.

Until this new update gets released (April-May timeframe), there’s a $700 USD discount on the report (which includes a 1-year update period).

You may also like

WebRTC predictions for 2023

WebRTC predictions for 2023

Your email address will not be published. Required fields are marked

  1. I’m in the situation of evaluating WebRTC PaaS providers and their APIs right now. The recommendation I made to my client was to pick a service, clone its API, and proxy to it. If they then needed to switch provider, this would insulate their client-side code (especially mobile apps) to some degree, and they would then be left to adapt the proxy.

    1. Robert,

      It is a solid recommendation, but there are two tweaks I’d do to it:

      1. Still pick the best PaaS provider for the job
      2. Build that adaptor for my needs and not necessarily based exactly on the API I am using
  2. My strategy is not to be taken in by the hottest new thing and snappy PowerPoint presentation. Don’t ride the bleeding edge, be patient, look for teams with a long track record ( a business cycles at least ). Have a plan A, B, and C. Hooe for the best and plan for the worse.

    Remember you comp. sci. lessons, encapsulation, modularity, late coupling and abstraction.

    Btw, thanks for the info on Parse, one year ago I planned to learn Parse in conjunction with Twilio, luckily I procrastinated and saved myself from learning something now defunct.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}