With WebRTC, the browser vendors are the only ones that count.
When I wrote my recent post about browser vendors being the only important players in WebRTC, I didn’t really know it would make such a fuss.
The post received many comments on NoJitter and in the WebRTC forum on Facebook. It seems I’ve struck a cord – or more like nagged many with my opinion.
Some complained about browsers being the wrong approach. Others focused on mobile first service. There were those who went to the extent of contemplating an utopian ecosystem (for some reason they were focus on interoperability and legacy).
Let me first iterate what I was trying to convey in that post on NoJitter:
- The future of WebRTC depends only on 4 vendors
- They call them browser vendors
- Google (Chrome), Mozilla (Firefox), Microsoft (Internet Explorer) and Apple (Safari)
- Opera doesn’t count – too small an audience, and generally speaking, a different UI on top of Chromium
To be blunt, Apple, who has no WebRTC support or known position to speak of, has a lot more impact on where WebRTC is headed than any other non-browser vendor out there.
Let’s knit-pick a bit on the comments I received, to see why they still don’t change this fact.
Issues with Browser User Experience
While I can’t say that all the use cases that require communications can be served with a browser, how does this have anything to do with the discussion?
WebRTC doesn’t live only inside a browser. Many of its use cases are in mobile, wrapped inside apps or just living as code modules taken from WebRTC to fit elsewhere altogether.
Most of these use cases still start their code by downloading WebRTC’s source code from webrtc.org. For those who are unaware – that code comes from Google and is what ends up in Chrome. If Google decides tomorrow to add or deprecate a feature, then this initial code will change with it – affecting many of the non-browser use cases.
Mobile
Mobile means apps. Apps means no browser. No browser means who cares about browser vendors.
Not so fast.
As I stated above, these apps use the same code base of WebRTC as the Chrome browser. I know about the alternative OpenWebRTC stack from Ericsson. Can you count 10 different vendors who use it on mobile? Because I can easily count more than 10 who use Google’s WebRTC code for their mobile apps.
Putting that aside, though, most mobile apps have aspirations to grow. Part of that growth means web browser support as well. And this translates back to needing to care more about what browser vendors end up implementing for WebRTC than anything else.
Just look at what TokBox announced in such a timely fashion:
A few days ago we released version 2.4.1 of our Android and iOS SDKs. This update to our SDKs were prompted by Mozilla’s implementation of a security enhancement which we fully support.
TokBox modified their iOS and Android SDKs because of a change in the implementation of Firefox. Hmm… a mobile SDK for WebRTC influenced by a browser vendor. I wonder how this came to be exactly.
To make a long story short, if you are implementing a mobile app, there are too many good arguments why you should keep track of WebRTC browser support and capabilities.
Ecosystem, Interoperability and Legacy
We have this great voice network today, so supporting it is important.
I actually agree.
I just don’t think anyone in that space of the technology matters for the future of WebRTC.
Put a gateway and be done with it. There are many gateways today already available, and none of them is making an impact on the WebRTC industry as a whole.
And that ecosystem?
Here’s some homework for my doubters:
Name 1 company that is more important than any of the 4 browser vendors when it comes to the future of WebRTC.
That’s what I found lacking in all of the comments on this subject – they were too theoretical. No one dared placing a name of a vendor that is making any real impact when it comes to WebRTC’s future.
So please. Find a WebRTC influencer who doesn’t own a popular web browser.
A word about Apple and Microsoft
Many commented that the absence Apple and Microsoft is an issue for WebRTC.
It isn’t.
It is an issue for some of the use cases of WebRTC. It seems like many vendors are happy with the current browser support that we have.
That said, having them on board is better than not and would widen the adoption of WebRTC.
Why is it important?
If you are a vendor, then please – know your place in the ecosystem. It isn’t in a leader position when it comes to WebRTC. Find a niche and rule it.
If you want to stay on top of things, make sure you follow and understand the roadmaps of the browser vendors, as they are the ones that matter the most.
I can write JS code so ugly that it makes Justin Uberti’s eyes hurt. Does that count as influencing if I get a better way of achieving what I want within a reasonable timeframe?
caveat: this strategy can backfire.
Good post Tsahi.
I’d possibly add Cisco to the list – partly because of OpenH.264, partly because of input into standards (Cullen etc) & partly because of likely impact on enterprise adoption in UC, conferencing etc. Maybe Avaya too, for similar reasons.
One other (future) possibility: WordPress, if it starts supporting WebRTC in a more homogeneous & accessible fashion, although various people do plug-ins already.
WordPress is a longshot. Most websites using WebRTC will end up being a lot more sophisticated. It also isn’t the only game in town.
As for Cisco, our opinion differ here.