- From: Brian Kardell <bkardell@gmail.com>
- Date: Thu, 7 Feb 2013 11:27:48 -0500
- To: Marcos Caceres <w3c@marcosc.com>
- Cc: Karl Dubost <karl@la-grange.net>, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <CADC=+jdPbeQq-ae2P5RmZdOoytZK=5c_1Qv5CTSfoPKQ60LG5w@mail.gmail.com>
[snip] On Thu, Feb 7, 2013 at 11:04 AM, Marcos Caceres <w3c@marcosc.com> wrote: > > > > > People say: "Oh it's an ugly API! Yeah for sure, it is designed by $ORG. > This is a proof that design by committee is bad." > > > > What I'm saying is that a spec published at $ORG is orthogonal to the > "design by committee" rant. Some will be edited by one person, some by a > group, some will be good, some will be bad. > Sure - but I don't think anyone eluded that it was the W3C's fault (just > that design by committee tends to create stuff that sucks - as opposed to > beta/usability-testing the API with real devs... This is the problem in a nutshell: The potential quality/capabilities of an API are irrelevant if it can get no uptake with real developers. For very practical reasons it has to become a common tenant of APIs that we have a means for people to try writing real apps with them, ideally ones that won't break if the API evolves or is even a complete misfire - and help make them better. Something is really only standard if it gets adoption, regardless of what we want to call it. It really has nothing to do with how many people write it, it has much more to do with how many people adopt it - it just happens to be the case that many of the committees have historically over-intellectualized things and done so with blinders on at the expense of creating an API that people won't actually adopt.
Received on Thursday, 7 February 2013 16:28:16 UTC