hixie on G+

I recently wrote the following in an e-mail, but it seems suitable for
a wider audience. tl;dr: I think it's more important for specs to be
technically sound than it is to get consensus on them.

Consensus (also known as "design by committee") is a terrible way to
design a language or platform. Committee design dilutes responsibility
and blame (everyone just starts saying things like "yeah, I didn't
like it, but we had to do that to get consensus") while letting
everyone take credit for everything (since their ok is necessary to
get consensus), which makes it an attractive proposition for people
who want to further their careers without really doing any work. You
also end up with people who arbitrarily disagree with things just so
their voice is heard, you get political decisions ("I'll agree to your
pet feature if you agree to mine"), you get specifications that feel
like they've been written by fifteen people all with different styles,
in short, you end up with a technology that doesn't know what it is
and doesn't do anything well.

You get much better results by putting all the blame on one person,
who then feels extremely motivated to not design something that sucks,
while diluting the credit to all the people who are contributing solid
technical information. This model pushes the people who don't want to
do real work away, improves the quality of the final product, and
provides an environment where if there are multiple completely
divergent viewpoints, they can compete rather than being forced to
ruin each other.

The other problem with "consensus" is the question of consensus among
whom? In practice in specification working groups it ends up being
consensus amongst those who bothered to show up, but this is almost
always a non-representational group. For example, in some groups (e.g.
W3C's WebApps group) implementors tend to be over-represented while
authors and users are virtually absent. In others (e.g. IETF's hybi
group) implementors of one conformance class (in this case servers)
tend to completely outweigh implementors of another whose buy-in is
actually more critical to the success of the technology (in this case
browsers — WebSockets would have gone nowhere if none of the browsers
implemented it, but would still have been a roaring success if only a
fraction of server vendors cared to support it, since anyone can
implement the server side). I've been in situations, e.g. the sXBL
fiasco, where I've represented all the browser vendors in a group
consisting of a dozen or more people, and if everyone agreed to
something but me it was considered that we had consensus, even though
in reality it meant none of the implementors were on board.

This is why "consensus" isn't a value I hold highly. Specs shouldn't
be designed to consensus, they should be designed so that they end up
solving real problems.

(Note that this does mean that there are certain stakeholders who need
to be on board -- e.g. a majority of implementors for the key
conformance class. So for example, for HTML, I need to make sure that
whatever I spec is something that the bulk of implementors want to
implement, otherwise it goes nowhere. But that's not consensus, it's
just that "we won't implement that" is highly relevant technical
feedback.)

Received on Thursday, 25 October 2012 21:55:04 UTC