Luis,

As much as I like to disagree and get a conversation going with people, you make great points. And it is true – it all boils down to risks we take as customers and developers, and balancing them out with our objectives.

Hi Doug and Tsahi
My point of view is that it raises rather the question of contracts, terms of use, etc. when going to a cloud API.
With some exceptions, most of the API vendors you mention in your report are either startups or small sized companies. We all struggle to get customers and evangelize around WebRTC, to have customers to understand how it will bring them competitive advantages on their activities.
Addlive, although it had a nice client list, was not in a dominant position on the market, so there will be no “industrial disaster” harming the whole API providers because some customers are “stuck” with their choice.
Also, entering into business with any startup in any technology takes always some risk. And choosing the best technology isn’t always the only factor.
When negotiating contracts with larger customer companies, these startups are not really in a dominant position. This means that procurement can perfectly include terms like holding in escrow code in case the startup goes bust, or in case it’s acquired, a certain amount of money to move to another vendor, or the obligation of continuing the service for a certain period of time.
I agree with your analysis on most points, but I think it’s rather good news for Addlive customers (other than Snapchat) that their vendor grows. They can either stay for some time or as you write, there is no vacuum in tech, they will move elsewhere to another vendor. Which will be good news for other vendors.
As a conclusion, I would say, that choosing a technology holds always risk. But for me the biggest one is that the technology offer of the chosen company doesn’t evolve. Legal aspects can always be solved 🙂

Richard,

The great thing about tech is that there is no vacuum. Other vendors will come to fill in the gap. I’d also say that there are a few who offer comparative service, though they are less familiar. My report covers these players and what they provide – something I found surprising myself when I researched the topic.

If this analysis is correct and Addlive cease to provide their services to customers, it’s a serious loss – there’s no replacement for what they do, certainly not from the bulk of the WebRTC players who seem to think signalling is all you need.

Doug,

Using AWS to its fullest means using AWS APIs.
Just using it for hosting still has its own perks that can be considered as vendor lock-in – it just tends to be “nicer” to those who need to approve it in management levels.

I’ve had my share of decisions this past year in my part time employer where vendor lock-in was raised. It happens with proprietary solutions, APIs, virtualization, cloud services and open source. The flavor is different – the result is similar.

Cloud is here to stay. Smart companies will know how to make use of it properly, which at times will mean using a 3rd party API and at other times will mean relying on open source and self development only.

I get the growth of APIs. We programmers tend to be lazy…

Doing a prototype or proof of concept with a WebRTC API is fine, but you should be aware of the inherent risk of this slippery slope. There is vendor lock-in with APIs, they may say open this or that but they are really portals to a closed source service. Once you go down the path with writing to an API you have to rewrite that code to retreat. Since coding is where the bulk of the time and money will be spent on software projects why not make a choice to spend an extra half hour up front to protect your project in the long run by using open source.

I do think using AWS or any other hosting service is different than using an API. Your application code doesn’t have to change to switch to another hosting service.

Doug,

While I understand this way of thinking, I can’t say that everyone will agree with it. Using hosted API based platform can be good for many. This is why Twilio is so big these days and AWS is a lot bigger still.

These platforms has a major role to play in our small industry and the WebRTC space – it is now just a little bit harder to make a decision.

I disagree that Twillio and TokBox should automatically be the next choice. They hold the same risks as AddLive. They are API companies. Even very large companies choose to shut down programs or services that aren’t profitable or no longer fit their world view.

Using a PaaS, an API or closed source software, involves a risk. You are trading off lower cost, convenience and time to market against an increased risk that a critical piece of your system becomes unavailable. If your project is important you should not take this risk. Period.

As a developer, to control and properly protect your projects, you need to be more responsible and ensure you control the critical software components.

EasyRTC, our open source WebRTC platform, includes a lightweight signalling server and you can use the RFC 5766 TURN server (also open source) as well as the EasyRTC client side APIs.

Use EasyRTC or any other open source WebRTC platform and you will control of the code base your system is dependant on. You will be able to continue to operate in case of corporate shutdown, buyout or outage.