[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.

[cpeterso]

The 50% number is probably just to maximize the size of their A/B test population comparing QUIC vs HTTP.

[tatterdemalion]

I agree, I was japing. :)