WebRTC isn’t like Node.js or TensorFlow. Its purpose isn’t adoption in general, but rather adoption in browsers. If you believe otherwise, then there’s a problem of expectations you need to deal with.
UPDATE: What a year can do… Check out my WebRTC trends for 2021.
As we are starting 2020, with what is hopefully going to be an official spec for WebRTC 1.0, it is time for a bit of reflections. I started this off when writing about Google’s WebRTC roadmap and I’d like to continue it here about WebRTC goals and expectations.
When I explain what WebRTC is, I start off with the fact that it is two things at the same time:
- A standard specification
- An open source project
The open source project angle is interesting.
Is WebRTC an open source project?
The main codebase we have for WebRTC today is the one maintained by Google at webrtc.org. There are other open source projects that implement the spec, but none to this level of completeness and quality.
By the ecosystem and use of WebRTC, one may think that this is just another popular open source project, like Node.js or TensorFlow.
It isn’t.
If I had to depict Node.js, it would be something like this:
How would I draw a diagram of WebRTC? Probably something like this:
From an administrative point of view, WebRTC is part of Blink, Chromium’s rendering engine. Blink is part of Chromium, the open source part of Chrome. And Chromium is what Chrome uses as its browser engine.
WebRTC isn’t exactly an independent project, sitting on its own, living the life.
Need an example why? WebRTC’s version releases follow the version releases of Chrome in terms of numbering and release dates. But mobile doesn’t follow the exact same set of rules. Olivier wrote it quite eloquently just recently:
“For web developers, release notes are very good and detailed. But for IOS and Android developers… I expect the same level of information.”
There’s an expectation problem here…
WebRTC isn’t like other open source projects that stand on their own, independent from what is around them. WebRTC is a component inside Chrome. A single module.
The WebRTC team at Google are assisting developers using the codebase elsewhere. It took a few years, but we now have build scripts that can build WebRTC separately and independently from Chromium. We have official pre-compiled mobile libraries for WebRTC from Google, albeit not a 1:1 match to the official WebRTC/Chromium releases.
At the end of the day, the WebRTC team at Google are probably being measured internally at Google by how they contributed to Chrome, Google’s WebRTC-based services AND to the web as a whole. Less so to the ecosystem around their codebase. If and how WebRTC gets adopted and used in mobile first applications or inside devices and sensors is harder to count and measure – and probably interests Google management somewhat less.
Who contributes to WebRTC?
I took the liberty of checking the commit history of the WebRTC git project over the years, creating the graph below:
There were various different emails associated with the committers, but they fell into these broad categories:
- People with a webrtc.org email address. These are Google employees working directly in the WebRTC project (at least I don’t know of a non-Googler with a webrtc.org email address)
- People with a google.com email address
- Commits done with a “chromium-webrtc-autoroll@” or similar “email” address in them. I’ve categorized these as bots
- All the others
It is safe to say that the majority of committers throughout the years are Googlers, and that the ones who aren’t Googlers aren’t contributing all that much.
Is that because Google is protective about the codebase, as it goes right into Chrome which servers over a billion users? Or is it because people just don’t want to commit? Maybe the ecosystem around WebRTC is too small to support more contributors? Might there be other reasons?
One wonders how such a popular project has so little external contributors while there are many developers who enjoy it.
Is webrtc.org Google’s RTC or ours?
A few years back, Google introduced a new programming language – Go (or Golang). It is getting quite a following (and its own WebRTC implementation, though unrelated to this article).
In May 2019, quite a stir was raised due to a post published by Chris Siebenmann titled Go is Google’s language, not ours. Interestingly enough, if you replace the word “Go” with “WebRTC” in this article – it rings true in many ways.
Golang has over 2,000 lines in its CONTRIBUTORS file versus WebRTC’s 100+ AUTHORS. While Golang identify individual contributors, WebRTC uses wildcard “corporate” contributions (I wouldn’t count too many contributors in these corporates though). WebRTC is smaller, and I dare say more centralized.
The simple answer to those who complain is going to be the same – “this is an open source project, feel free to fork it”.
For WebRTC, I’d add to this that what goes into the API layer is what the W3C and IETF decide. So Google isn’t in direct control over the future of WebRTC – just of its main implementation, which needs to adhere to the specification.
Then there’s the Node.js community forks that took place over the years (latest one from 2017). These disputes, technical and political, always seem to get resolved and merged back into the main project. In hindsight, this just seems like attempts to influence the direction of the project.
Can this be done for WebRTC?
It already occurred with the introduction (and slow death) of ORTC. ORTC (Object-RTC) started and was actively pushed by Microsoft, ending with most of what they wanted to do wrapped up into WebRTC (and probably causing a lot of the delays we’ve had with reaching WebRTC 1.0).
What does that mean to you?
Should you complain about Google? Maybe, but it won’t help
For Google, it makes sense to push WebRTC into Chrome as that is its main objective. Google is improving in tooling and capabilities of using WebRTC outside of Chrome, but this objective will always be second to prioritization of Chrome’s needs and Google’s services.
As an open source project, you are free to use or not use it. You’re not paying for it, so what would you be complaining about?
Google have invested and is still investing heavily in WebRTC. It is their prerogative to do so, especially as they are the only ones doing it today.
You should make an educated decision, weighing your requirements, risks and challenges, when developing a service that makes use of WebRTC.
At the same time the WebRTC team at Google is stating they’re providing a platform for others to build on. Then they ship stuff that is half-baked at best like getDisplayMedia which is still not on-par with the extension API. “spec compliant simulcast” is not implementing what the spec says these days…
Bug reports rot without anyone taking a serious look, same goes for patches.
For me this is understandable and somewhat expected.
The project is a complicated one with too many stakeholders and consumers inside and outside of Google. It is always a challenge to develop such things.
That said, there’s always room to improve 🙂
heh, I’ve never expected more than the leftovers.
At the same time the project painted itself into a corner by making promises and then not having a plan for what to do when things like developers filing bugs happen.
The state of the projects on github is… demostrating this.
couple of corrections:
– from what I know WebRTC started inside Chrome (together with hangouts) but then someone noticed an incredible shift to mobile (and ended up paying me to analyze a couple of services to better understand that :-)). A lot of core WebRTC stuff happens outside Chrome. There is still a lot of webrtc stuff going on in Chrome, things like glue code between blink and webrtc.org or moving the audio processing to a different thread (which Olga talked about at KrankyGeek 2018)
– “We have official pre-compiled mobile libraries for WebRTC from Google”
These libraries are outdated currently (at least on ios). There has been no response (albeit a deleted email) to either https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/discuss-webrtc/yZPlPJQROOM/uX5zojoLAgAJ or https://bugs.chromium.org/p/webrtc/issues/detail?id=11234
As usual, I stand corrected.
Great article Tsahi, lots of stuff I care about here! I am really biased on this stuff, but will try my best to be fair 🙂
> Is WebRTC an open source project?
Yes. Google has provided amazing software at no cost. The spent a lot of money on GIPS, and then just gave it out that is pretty awesome. I am sure if you could quantify the amount of value WebRTC created in the world it would amaze us all. I think people want more than that though.
The OSI needs to create a new label, something like ‘viewable source’. You can’t make substantial changes or drive the project if you aren’t a Google employee. I think people find that really frustrating. For many of us this is our hobby/passion, so not being able to take part is demoralizing. This is a common pattern across many corporate projects (Android and Chromium)
I wish there was a lot more distinction between WebRTC the protocol and WebRTC the software project. I think conflating them is killing the community. If webrtc.org showed aiortc, Janus and some cool hackathon projects we could have a real community.
> Google isn’t in direct control over the future of WebRTC
I disagree. With Chromium being the dominant browser, and libwebrtc being the dominant implementation they control everything. If they release an experiment that becomes popular everyone else has to follow along, and that is just the way it is. I care deeply about WebRTC and have spent many hours making Pion WebRTC, but I am not allowed to join the IETF/W3C.
> Should you complain about Google? Maybe, but it won’t help
No. I find the WebRTC community at large very negative, and quite entitled. If people spent less time complaining and more time building solutions the world would be a better place. When I see this attitude start to leak into Pion’s ecosystem I make sure to push back quickly. I made Pion to address the complaints I heard about WebRTC, and now I hear different ones. I don’t plan on giving up until I solve all of them 🙂
At the end of the day I think the amount of people who actually care about all this can fit in one room. Most people download WebRTC, build a product and then never touch it again.
Thanks for this Sean. I think we are in agreement.
Especially in the less complaining and more doing part of it.
Hello Tsahi, I leave my 2 cents here. I agree to stop and wonder about the topic. For some time now I’ve been looking at WebRTC in the browser and node (node-webrtc) mainly about specifying and deploying in major browsers.
Complain from Google for “experimentation”, I don’t think so. In the last decade the web has gained many APIs from which Google or its contributors kicked off and continued to bet and experiment even if other players wrinkled their nose … and most of them followed them.
When I look at the discussion mailing lists or the most high-profile issues on GitHub, I see that the circle of those closest to following directions is very narrow and yes, I see few participants from other teams in the game.
I believe WebRTC will follow the next few years with no surprises, but it’s hard to keep high expectations when you don’t know what key stakeholders think for its future.
I also think that more than thinking about what we can get from WebRTC today is what we want to have from it for the near future, what do developers and entrepreneurs expect of this technology in specifying (and implementing) for years to come?
Lauro, thanks for sharing.
The challenge with the current set of experiments is that they are leashed on running services without any knowledge about them. It isn’t about trying to add a faster web (SPDY and QUIC), where Google simply added a brand new layer of transport and experimented it in front of their own services. It is about small changes and tweaks made to improve and optimize performance that are tested on third party services at large without their awareness. I understand the need to run these experiments, but I am not sure the way they are conducted is the best one.
As for the rest, I definitely agree.
Hi Tsahi,
I’m the Olivier who wrote that question on the Webrtc-group :-). Thank you for sharing that point.
Globally, I’m a huge fan of WebRTC, I develop web applications with that technology since 2012/13. But when I discovered mobile applications, I was a little bit lost.
My remark was more on giving to mobile developers the right information to succeed. Once on production with tons of users, how do you decide to update your WebRTC stack ?
Is there a risk ? Do I need to pass a complete no-regression campaign ? Is-it still compliant with my Web application, my gateway, my conference server ? And is there adaptation to my code to do ? All that tests have a cost (time, people…).
I just want to illustrate that the release notes are the only documents we have as developers to understand what to do without having to dig into the source code.
Your explanations and the ones given by Alexandre and Philipp helped me to see the full picture.
Thank you,
Olivier
Check here: https://en.wikipedia.org/wiki/VP9
Not sure which ones are also used by Chrome. discuss-webrtc might be a good place to pose this question.