Google’s WebRTC goals – a problem of expectations

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:

1. A standard specification
2. 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:

TensorFlow?

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:

1. 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)
2. People with a google.com email address
3. Commits done with a “chromium-webrtc-autoroll@” or similar “email” address in them. I’ve categorized these as bots
4. 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.