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