WG Openness - Ian Hickson, Google Inc.
--------------------------------------

The public at large is tactless and blunt. When they're in a small
group, people will tend to be polite, but when they have the
protective barrier of the crowd, people become very direct and won't
hesitate to rudely point out flaws in anything from a comic strip to
the latest foreign policy.

We can use this to our advantage to improve the quality of our
specs. By having a truly open working group, we can get continuous
feedback from a broad range of enthusiasts, and regular reality checks
from the wisdom of the crowd.  If your spec is a useless pile of junk,
people will either ignore you or bluntly tell you -- and you'll know
you have to stop and reevaluate your problem or target market, and
probably change direction, before you have too much momentum and
before having spent millions of dollars on a flawed premise.

On the other hand, if your specification is useful, people will be
enthusiastic, and will review it, advocate it, help write tests, write
test implementations, document it, and more.

What's a truly open working group? It's actually a community. You have to 
run your specification like a fully fledged open project, with a single 
coherent community. You can't run it like a traditional W3C working group 
and have the same sense of community, and without the sense of community, 
you don't get the benefits.

That means treating everyone with respect, and being tough on people who 
troll or aren't friendly. For example, it means baning someone for a week 
if they ignore a request to be more polite. It means trusting your 
community: give everyone wiki access and blog posting access. Let anyone 
be a member of your community, even if they're new. Foster a mindset of 
"ask for forgiveness, not permission". Take risks.

Have an open wiki, an open blog, an open IRC channel, an open forum, open 
mailing lists for spec discussion, for implementors, for authors. Have a 
FAQ anyone can contribute to. For each of these, have someone who is 
responsible for keeping the spammers out, for responding to requests from 
other members of the community, etc.

A key part in all this is not distinguishing corporate participation from 
individual participation. You can't have a private W3C member-only mailing 
list. You can't have working group meetings which are only attended by a 
small subset of members -- in fact, any face-to-face meetings you have 
will probably have to be informal meetings, or very small focused sessions 
(e.g. 2 or 3 people working on one issue). You can't have teleconferences, 
since having an entire community on a phone call simply doesn't work.

Doing all this actually turns out to not be that much work, especially
when compared to the overhead of working in the W3C. Much of the
infrastructure can be hosted on cheap hosting providers and farmed out
to members of the community for maintenance; for example the WHATWG
site, along with most of its infrastructure, is hosted on Dreamhost
for just $6 a month (which I personally pay out of pocket); and the
various services -- blog, forums, etc -- are managed by
volunteers. (This turns out to be at least as reliable as being hosted
by the W3C, with much less administrative overhead!)

The only danger is that you won't be quite open enough. If you don't
go all the way, if there's any aspect of your community that isn't
completely open, or if there's anything where you don't trust the
community as a whole, you will end up with a disfunctional group. If
you have a blog but only you can post to it, or if you have an issue
tracking system but not everyone can contribute to it, or if you have
teleconferences where you make decisions instead of doing everything
in the open (meeting minutes don't feel open when you have a community
for some reason), people in the community will feel disenfranchised,
and they will quickly turn on you.

There are certain differences you have to be aware of if you decide to
go this route. One is that assuming you work is important, you will
get a _lot_ of feedback, possibly far more than you expected. For
example, we have over 3000 open issues on the HTML5 work. That's a
good thing if you want a high-quality spec, but if you want a mediocre
spec and not to spend much time on it, then you'll be overwhelmed.

You also have to be aware that you can't play any dirty tricks. If you
try to play process shenanigans in the W3C, you'll have a few W3C
members annoyed at you. If you try to play process shenanigans in
public, you'll have an entire community turn on you, and they _can_
sink your ship if they want to. Don't underestimate the power of the
crowds.

So in conclusion: if your goals are noble and honest, and you truly
want a high quality set of specifications, I strongly recommend using
a community-based development model. It's hard to go wrong if you
trust the wisdom of the crowds. But you can't do this
half-heartedly. Half open is worse than not open at all.