There's a lot of talk about this topic of "the web we want," and a lot of it has focused around WebRTC lately.
I have been working with WebRTC since mid-2012, both in the Chrome and Firefox browsers, as well as the native webrtc.org library. So far I have filed more than sixty issues in the WebRTC project issue tracker and the Chrome bugtracker. I'm especially proud that I've crashed the production version of Chrome eight times.
I am among the top non-Google people to file WebRTC issues. And I managed to get quite a few of them fixed, too. I visited Google's Stockholm office in September and had a conversation with the team there about how I use the issue tracker and how that process works. Full disclosure: I got a t-shirt (even though it turned out to be too large). And I even started reviewing the Chrome WebRTC release notes before they're sent out.
Justin Uberti's description of WebRTC as a "project to bring realtime communication to the open web platform" is still the vision I cling to.
There are some amazing people working on Google's WebRTC team and I like working with them.
The same holds true for some of the Mozilla folks.
One of the first bugs I reported got fixed in less than 24 hours. I started to hang out regularly in the #media channel on the Mozilla IRC and got my bugs fixed even faster. Also, the Mozilla team is currently working on multistream support with the Jitsi team, which is going to be quite important for the next version of Talky as well. It is very good to see "coming soon" for both this and renegotiation on these slides.
But yesterday Mozilla CTO Andreas Gal wrote a blog post entitled "It takes many to build the Web we want." In describing the WebRTC Competency Center that Mozilla is starting with the help of telcos, he makes an interesting statement:
The goal of this new center is to implement WebRTC with a broad, neutral vision that captures the technology needs of many, not just the technology needs of individual browser vendors.
There are other points in the blog post I strongly disagree with, but let me pick on this one. Basically he accuses another browser vendor of only fulfilling its own technical needs. Since there is just one other browser vendor which does WebRTC currently, this must be aimed at Google and its Hangouts service.
A while back, Google enabled "WebRTC" for Hangouts, which only works in Chrome. I wrote a quite lengthy technical explanation for webrtcHacks that explains why it only works with Chrome. Andreas Gal used the phrase "the web we want" in a tweet back then.
I am very unhappy about this new statement. I do agree that Google ensured that Hangouts works with Chrome (see the webrtcHacks article). What annoys me about this statement is the accusation that Google does not care about "the technology needs of many." This is absolutely not my experience working with Google's WebRTC team.
Here's a particular example. TURN support is very integral for WebRTC, since it ensures connectivity between browsers in certain circumstances. Chrome now has excellent TURN support, even though it took quite a while (almost two years) to get there. I have filed a number of issues and they got fixed. Debugging those issues was not an easy task, and I am sure a lot of engineering time was spent by the WebRTC team at Google.
When Hangouts was released, one thing surprised me: it does not use TURN. Instead, it uses ICE-TCP for falling back to port 443 on restricted networks. Which explains why those TURN bugs were not found earlier; Google simply did not use this in production. And yet, they fixed my bugs. Because supporting the broader WebRTC community is important to them—regardless of Hangouts.
From our perspective, both the Chrome and Mozilla WebRTC dev teams have been great to work with. And they both care, as we do, about making realtime communication technologies friendly for web developers. So the comment from Andreas Gal about "the web we want" is a bit confusing.
At &yet, the web we want applies open web principles to realtime communication. It's that simple.
We'll be exploring what that means more deeply in upcoming blog posts.