There’s an interesting trend that got introduced to our lives in 2014, which is unbundling of WebRTC PaaS.
This one is somewhat counter-intuitive. You build a WebRTC API platform for developers. The idea is that they can use your platform to develop their use case instead of building it on their own. So the whole point of this exercise is to develop and run a solid, global infrastructure – and then pack it up with high level features and capabilities.
So why are we seeing several of the WebRTC PaaS vendors trying to unbundle their services and offer lower level access? Here are some examples.
Temasys and their WebRTC plugin for Internet Explorer and Safari
In some ways, Temasys took the biggest risk with unbundling.
One of the concerns a lot of developers had was around support for Internet Explorer and Safari. To that end, there were those that ended up wrapping WebRTC as a plugin for the browser. Most WebRTC PaaS vendors had that as part of their package, with the APIs exposed from these plugins were their higher level APIs.
Temasys made the decision to offer its own WebRTC plugin for free, and later on introduced an SLA with customization services around the plugin.
The risk here? Vendors might decide to take the plugin and not the service at all. The opportunity? Position as someone with core competencies that allows them to give such a thing for free.
The challenge with such unbundling is that it defocus the vendor from its core business. Offering PaaS on a managed infrastructure is different than licensing software to developers.
Twilio’s NTS
Twilio surprised us all with their own unbundling. They have unbundled two services: TURN and SIP trunking. For WebRTC, I am interested here in their new TURN service, which they called NTS. I’ve covered this move already on how NTS affects other WebRTC PaaS players.
What Twilio did, was take a low level infrastructure capability that they already had and started offering it as a service, instead of only the higher level functionality on top of it. Same or slightly different target market, with a similar/same type of business model and dat-to-day operation.
OpenClove’s FreeMAD offering
OpenClove wanted more developers on their platform. It didn’t really unbundle, but it did offer a free service for 1:1 calls – on both the web and mobile apps. They even separated their service calling it FreeMAD.
While close to unbundling, it is slightly different, as the same service with the same APIs is offered to the same set of potential customers.
Unbundling from a service down to a WebRTC PaaS vendor
There’s also a similar trend going on, where past players with a running service on their home-grown infrastructure are starting to offer developer access:
- ooVoo, an OTT VoIP player, now offers a WebRTC API platform for developers
- Rebtel spun out its infrastructure as Sinch – an API platform for developers
- Bistri, an early WebRTC social network service veering towards the API platform for developers space
Why is this important?
This unbundling trend brings with it many interesting questions:
- Is there anything else in WebRTC PaaS that a vendor can unbundle?
- Will other WebRTC PaaS vendors follow the same route?
- Where will the new WebRTC PaaS vendors come from? Will they unbundle their infrastructure from their service or start from scratch?
How does the future look like?
Many things happened in 2014. Last week, in a webinar I spent considerable time going over the transition and change occurring in the WebRTC PaaS space – you can listen to the recording online (or just look at the deck below).
Unbundling, transitions and change are some of the new areas I am covering in my upcoming update to the Choosing a WebRTC API Platform report.
If this is of interest to you, so you might want to consider purchasing the report – once it gets published, I will be increasing its price considerably.