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.
> 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?)
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.