There’s more to WebRTC than the obvious.
I’ve said it before and I’ll say it again: WebRTC is a technology and not a solution.
Want to build a service with WebRTC? By all means, do your own solution.
I am writing this after seeing this tweet on my way back home from vacation:
@macwind @jbradleybush @WhatsApp @tsahil What does it matter if it remains a walled garden? Guest access should be the litmus test
— Aswath Rao (@aswath) July 12, 2014
So litmus test for a service using WebRTC should be guest access? Without it, it doesn’t matter if it uses WebRTC?
I beg to differ.
WebRTC has two sides to its story – one dealing with developers and the other dealing with end users.
End Users
For end users, WebRTC is all about reduction of friction.
If I, as a user, don’t need to download anything, then there is one less decision to make. One less friction point between me and the service I am about to use.
This can be translated by services to allowing guest access (hey – you can now use a service without downloading an app for it), but that’s just one of many advantages of it.
For many use cases, this fact is just irrelevant or unimportant – especially in a world gone mobile-first and app-centric.
Developers
For developers, WebRTC has two advantages to it:
- Being free means it reduces barrier of entry for developers
- Being targeted at web developers means a larger target audience of developers
These two traits means it makes the technology available to a larger audience of developers – a good thing.
The litmus test in my view is understanding what made a developer pick and choose WebRTC over other VoIP technologies available to him.
Why is this important?
WebRTC is many things to many people.
Each one views it from a different angle, seeing a different thing. This type of analysis limits the end result in one of two ways, both dangerous:
- Seeing only what you want to see, which translates to entrenched vendors deciding to use WebRTC only as an access point to existing services. The ramifications in doing this without understanding barrier of entry and friction implications are numerous
- Missing other angles of WebRTC that can be more advantageous to a service, such as vendors catering carriers whoare adamant that IMS will save WebRTC from its weaknesses
Each and every business case needs to be analyzed on its own from multiple directions when it comes to WebRTC. There’s no single litmus test here that can say when the use of WebRTC is important or impactful.
I hope you had an enjoyable vacation. I m sorry that the first thing you had to do was to field my tweet. But I am afraid the brevity of thought in that tweet has given room for misinterpretation.
Take the specific example of Whatsapp. Since it will continue to require installation of an app, reduced friction afforded by WebRTC goes away. Again if you look at Whatsapp as a developer specifically, the benefits you identify are not that important. So what is left is facilitating communication from users’ friends who have not yet become a registered user. This is where WebRTC shows its strength.
Now my comment is that for whatever reason they insist on a walled garden, they are abandoning one showcase advantage of WebRTC. Given that, I for one find it not compelling use of WebRTC. Of course others are just as rightful to their opinions.
Aswath, the vacation was great, and coming back to my country and its current predicament, your tweet wasn’t the first thing on my mind. That said, it was there and it itched.
I think you are marginalizing the effect of WebRTC on developers. Vonage has decided to use it even though it had other technical options it could use (and their service is “closed”). The strength you see in WebRTC is indeed there, but it is one of many – which as I state – simply depends on what you are looking to gain from WebRTC.
The litmus test in my view is whether it’s an (web) _application_ developer picking webrtc.
There can not be a litmus test when we have started using WebRTC as a marketing buzzword instead of something technical.
The initial litmus test was RTC without plugins in the browser. Now anything can be WebRTC if you have enough imagination.