[pcwalton]

In a competitive multi-vendor ecosystem like the Web, public-facing protocols that are introduced and controlled by a single vendor are proprietary, regardless of whether you can look at the source code. NaCl and Pepper, for example, are proprietary, even though they have open-source implementations.

The distinction between open-source-but-proprietary and open-standard is important for many reasons. One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility with a giant pile of C++.

[kjksf]

I don't understand this negativity towards QUIC/Dart/NaCL/Pepper etc. which are exemplary open-source efforts.

By your definition Mozilla's (your employer's) asm.js and Rust are also proprietary.

Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards.

There have been plenty of research and work even in standard bodies like IETF that try to implement a better tcp/ip-like protocol.

They all went nowhere because at this point in time, you can't just have some guys in a room to design a new transmission protocol and have it taken seriously by anyone that matters (Google/Apple/Microsoft/Mozilla).

Google is following the only realistic route: implement something, test it in a scale large enough to conclusively show an improvement and then standardize it.

This is exactly how HTTP/2 happened.

We should be cheering them on instead of spreading FUD because it doesn't live up to your impossible standard of non-proprieterness.

[magicalist]

I'm not entirely sure it's helpful to lump all of those together; there is at least some difference in kind.

I think dragonwriter's sibling comment to yours is pretty apt here. It's hard to tell the difference between something that will be submitted to standards bodies any day now and something that really will be submitted to standards bodies any day now. At a certain point (with e.g. Pepper) the statute of limitations runs out and you have to assume it's just going to be an open-source but proprietary API.

Of course, whether or not overloading "proprietary" is useful is a different discussion. Mostly it seems these conversations eventually just devolve into arguments over definitions of the word for no real insight.

[pcwalton]

> Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards.

asm.js isn't a new protocol, and so isn't proprietary according to that definition. It's a subset of JavaScript (to be specific, ES6, including such extensions such as Math.imul). You can implement asm.js by simply implementing the open, multi-vendor ES6 standard. In fact, that's exactly what some projects, like JavaScriptCore, are doing.

Rust isn't relevant, as it's not intended to be added to the Web. Adding <script type="text/rust"> to the browser would be a terrible idea for numerous reasons. Nobody has proposed it.

[tptacek]

Plenty of IETF standardization efforts can be described as "a subset of Javascript" or even just "a bunch of Javascript APIs". WebCrypto, for instance, fits that bill. What makes QUIC so different from WebCrypto?

[pcwalton]

QUIC and Web Crypto are both things that need to be standardized, so I don't know what the implication is or how to respond to that statement.

I do think there is a big difference between "a subset of JavaScript" and "a bunch of JavaScript APIs" from a standardization point of view. All engines have been implementing special optimizations for JavaScript subsets ever since the JS performance wars started. Nobody thinks we need to standardize polymorphic inline caches, for example, even though the set of JS code that is PIC-friendly is different from the set of JS code that is heavily polymorphic (and this distinction would be easy to describe formally if anyone cared to). asm.js is just an optimization writ large: the reason why it's not a protocol is that any conforming JavaScript implementation is also an asm.js implementation.

I think people are reading a lot more into my posts than was intended. I'm not calling out QUIC specifically, since I'm not involved with the details of its standardization anyway. The point is simply that open source doesn't automatically mean non-proprietary.

[tptacek]

Oh, sure. QUIC is a proprietary protocol. An IETF-standardized QUIC would not be.

[rakoo]

> Rust isn't relevant, as it's not intended to be added to the Web

"Proprietary" as used here isn't limited to the Web.

[pcwalton]

Point taken, and you're right that in a certain sense Rust is proprietary, with all of the very real downsides that that entails (for example, the risk of tight coupling of programs to rustc, as hard as we try to prevent it). But I still think it's a fairly irrelevant thing to bring up, because Rust isn't targeting a large, open, multi-vendor ecosystem (as I specified in my original post). If Rust catches on, no other vendor is going to be forced to implement anything; nobody outside the current Rust community is even asking for a seat at the design table. The only real downstream dependency that the success of Rust might impact is LLVM, and we actually have maintained a pretty good relationship with the LLVM community from the start.

[magicalist]

I think this is kind of doing disservice to the way innovation of the web has proceeded virtually everywhere. Over and over again this is how web functionality has jumped forward. And there's plenty of examples of this happening at Mozilla -- e.g. the WebAPIs, not all of which are limited to FirefoxOS, and of those that have been submitted as working drafts, many haven't been touched or discussed since submission. Which is fine. Often an email to a mailing list isn't enough and you have to just start doing something to get the other browsers to act, and sometimes a standard has to languish for a while until everyone figures out it's needed after all.

Things like the "Championed" proposals model for TC39 and (as DannyBee notes) IETF's approach to standardization are direct acknowledgements of this. In a way the Extensible Web approach is also a direct acknowledgment, insofar as it says that innovation happens at the edges, so browsers should provide minimum flexible building blocks and get out of the way. asm.js is a great example of using those building blocks (though it should be noted that as asm.js catches on, other browsers are forced to spend time on it, explicit directive prologue handling or no). Network protocols, on the other hand, are something that can't be built and tested from the tools browsers provide.

I think the better question for you would be, what's the better way to develop network protocols like this, then? Assuming that purpose, I can't think of anything to criticize here except maybe they should have limited testing to beta and dev users of Chrome. However, that limits your test data and normally that sort of thing is done to make sure web compatibility isn't broken in the future by changing standards, and given that browsers already negotiate protocols, I don't see an imminent danger there.

[pcwalton]

> I think the better question for you would be, what's the better way to develop network protocols like this, then? Assuming that purpose, I can't think of anything to criticize here except maybe they should have limited testing to beta and dev users of Chrome. However, that limits your test data and normally that sort of thing is done to make sure web compatibility isn't broken in the future by changing standards, and given that browsers already negotiate protocols, I don't see an imminent danger there.

As I mentioned in my reply to tptacek, I'm not intending to call out QUIC specifically here; the point is simply that open source and open standards are not equivalent. Shipping implementations is fine as long as there are effective safeguards to prevent lock-in.

What we have to make sure we avoid is something like the -webkit CSS prefix situation, where the fact that WebKit was open source did nothing to prevent the mobile Web from very nearly coming to depend on all the quirks of a big pile of C++. (That situation is also an example of standardization leading to better outcomes—remember how bad the WebKit-specific "-webkit-gradient(linear, color-stop(foo), ...)" syntax was?)

[dragonwriter]

> One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility

I think there is a distinction to be made between closed spec protocols and protocols developed prior to being submitting for standardization; while its hard to tell them apart prior to the latter actually being submitted for standardization outside of potentially misleading forward-looking statements of intent, the latter is a reasonable way of cleaning up something and getting some solid real-world feedback and proving utility before submitting something as the basis for standards work while the former carries the problem you describe.

[tatterdemalion]

> One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility with a giant pile of C++.

I love Mozilla, but this seems like an apt description of "JavaScript." (sure, they're not so much bugs as misfeatures, but..)

[pcwalton]

The existence of the weird corner case semantics in JS proves my point! Compare the strange semantics of JavaScript 1.0 with modern JavaScript—ES6. ES6 follows the open, multi-vendor standardization process, and as a result its features are extremely well-designed and interoperable.

[DannyBee]

You can't sanely standardize that does not already exist. IETF believes in "rough consensus and running code". That is what they standardize.

By the definitions of proprietary floated here, every open protocol standardized as IETF proposal started out as proprietary.

The only thing that wouldn't seems to be "stuff designed in the open by committee". A process that has worked so well, it brought us things like C++ and POSIX.

[tptacek]

The IETF does not generally practice what they preach in this regard, Google's contributions being a rare bright spot. The fiasco of trying to get Curve25519 standardized for TLS is a pretty good example of the way IETF tends to work.

[pcwalton]

> You can't sanely standardize that does not already exist. IETF believes in "rough consensus and running code". That is what they standardize.

I fully agree, but it has to be counterbalanced with not shipping random single-vendor features to the entire Web. The proven model here, which is a policy shared by both Blink and Gecko, is developer and beta channels and feature flags.

> The only thing that wouldn't seems to be "stuff designed in the open by committee". A process that has worked so well, it brought us things like C++ and POSIX.

It also brought us things like CSS 2.1 (which everyone loves to hate, but it's much better than the nightmare of pre-CSS layout) and ES6 (which is extremely well-designed). Even the standard versions of C++ aren't really badly designed, especially if you limit yourself to C++{11,14}: there were a few notable standardization blunders, like the STL allocator API, but by and large it's hard to find things in C++11 and C++14 that were clearly mistakes at the time.

CORBA and XHTML 2.0 would be better examples, but the failure modes there were being unimplementable and impracticality of dropping backwards compatibility respectively, both of which the developer channel/feature flag approach address.

[DannyBee]

" fully agree, but it has to be counterbalanced with not shipping random single-vendor features to the entire Web. The proven model here, which is a policy shared by both Blink and Gecko, is developer and beta channels and feature flags." I don't disagree, but I'm also not sure what this has to do with proprietary vs open :)

Is it unrelated, or is your argument that if they do it this way, it's somehow now "open" and not "proprietary"? Because if so, i struggle to see why that would be the case :)

"Even the standard versions of C++ aren't really badly designed, especially if you limit yourself to C++{11,14}: there were a few notable standardization blunders, like the STL allocator API, but by and large it's hard to find things in C++11 and C++14 that were clearly mistakes at the time."

I'm just going to go with "C++ committee members i have easy access to" (IE sit 10 feet from me) disagree :)

Now, that's not to say it's a complete and utter disaster, but ...

[pcwalton]

> Is it unrelated, or is your argument that if they do it this way, it's somehow now "open" and not "proprietary"? Because if so, i struggle to see why that would be the case :)

Absolutely. If the goal is to create a open, multi-vendor implementation of some feature, then the right way to go about it is to (a) implement it behind a feature flag; (b) present it for standardization; (c) take feedback into account during the process, making changes as necessary; (d) ship it to stable and remove the flag once consensus emerges. Even better if multiple vendors do (a) at the same time, but it's not strictly necessary.

The reason why the flag in step (a) is so important is that it makes step (c) possible. Otherwise, there's a very real risk that content will come to depend on the quirks of your first implementation, making it impossible to take other parties' feedback into account. If you just ship to stable right away, you're running the risk of making the platform depend on a proprietary feature.

The reason why doing (a) before (b) is important is that it prevents unimplementable features and mistakes that only become apparent once implementation happens from being standardized. It also allows users of the feature, not just the folks who implement the platform, to take part in the process.

This process is really the only one I know of for popular multi-vendor platforms that both prevents proprietary features from being locked in and avoids the problems of design-by-committee. That's why both Blink and Gecko have adopted it (and Blink is definitely to be commended for following it).

[brighteyes]

I think the point made by 2 or more people here is that this non-standard feature has been shipped to half of Chrome users. That feels much closer to shipping to them all, than to shipping to say just Canary or Dev or even Beta users.

To some extent this might be a matter of appearance. Does Google have a firm rule against shipping a proprietary protocol to over 50% - is that why you stopped there? If so, that would be reassuring to hear.

[tatterdemalion]

I agree, I was japing. :)