7 ms·

The Chromium implementation of QUIC is released as Open Source, so I'm not sure how "proprietary" the protocol actually is.

pcwalton 11y ago
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++.
- deleted 11y ago
  [deleted]
- dragonwriter 11y ago
  > 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.
- kjksf 11y ago
  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 11y ago
    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 11y ago
    > 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.
    - rakoo 11y ago
      > 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 11y ago
        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.
- tatterdemalion 11y ago
  > 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 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
        > 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.
dragonwriter 11y ago
There's two different distinctions in software for which "proprietary" is commonly used: 1. proprietary vs. Free / Open Source (code released under an F/OSS license), and 2. proprietary vs. Open Standards (an implementation of a standard governed by an independent standards body and freely implementable.) QUIC is not proprietary by F/OSS on the first axis, and currently proprietary rather than based on an open standards on the second axis, with a stated intent of becoming the basis for open standards works in the future. There is, I think, a pretty good case that this is a good way to get to new open standards that are actually useful for solving real world problems.
- thrownaway2424 11y ago
  Almost all software fails 2 because hardly any software is an implementation of an open standard. That doesn't seem like a useful definition.
  - dragonwriter 11y ago
    > Almost all software fails 2 because hardly any software is an implementation of an open standard. Very few applications are only an implementation of an open standard, but things like the QUIC implementation or other communications protocol implementations aren't applications, but lower level components.
  - Zigurd 11y ago
    Moreover, I think it abuses the meaning of "proprietary" to claim QUIC is proprietary. There is no exclusivity, nor secrecy, nor any other element of control by one party here.
    - sophacles 11y ago
      In usage 2, QUIC is proprietary, following conventions older than me.
    - wtallis 11y ago
      Who other than Google currently has a vote on what constitutes the definition of QUIC? Merely being open to suggestions for changes isn't a relinquishment of control, and protocols can't be forked the way software can.

pcwalton 11y ago

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

deleted 11y ago
[deleted]
dragonwriter 11y ago
> 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.
kjksf 11y ago
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 11y ago
  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 11y ago
  > 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.
  - rakoo 11y ago
    > 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 11y ago
      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.
tatterdemalion 11y ago
> 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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
      > 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.

dragonwriter 11y ago

There's two different distinctions in software for which "proprietary" is commonly used: 1. proprietary vs. Free / Open Source (code released under an F/OSS license), and 2. proprietary vs. Open Standards (an implementation of a standard governed by an independent standards body and freely implementable.) QUIC is not proprietary by F/OSS on the first axis, and currently proprietary rather than based on an open standards on the second axis, with a stated intent of becoming the basis for open standards works in the future. There is, I think, a pretty good case that this is a good way to get to new open standards that are actually useful for solving real world problems.

thrownaway2424 11y ago
Almost all software fails 2 because hardly any software is an implementation of an open standard. That doesn't seem like a useful definition.
- dragonwriter 11y ago
  > Almost all software fails 2 because hardly any software is an implementation of an open standard. Very few applications are only an implementation of an open standard, but things like the QUIC implementation or other communications protocol implementations aren't applications, but lower level components.
- Zigurd 11y ago
  Moreover, I think it abuses the meaning of "proprietary" to claim QUIC is proprietary. There is no exclusivity, nor secrecy, nor any other element of control by one party here.
  - sophacles 11y ago
    In usage 2, QUIC is proprietary, following conventions older than me.
  - wtallis 11y ago
    Who other than Google currently has a vote on what constitutes the definition of QUIC? Merely being open to suggestions for changes isn't a relinquishment of control, and protocols can't be forked the way software can.