teach people how to fish

[Ian Clatworthy]

Robert Collins wrote:
> Ian has been arguing that we need to lower the barrier to entry for bzr
> - and I totally agree.
> 
> I ran across http://denise.dreamwidth.org/23600.html today, which is an
> excellent blog post talking about the same overall goal

Thanks for the link - there are some great quotes in there.

It's my strong belief that the primary difference between community
projects that "glide" vs those that "soar" is ease of participation.
There are 3 fundamental pieces for success:

1. Architecture[1] that enables it.
2. Project policies that encourage it.
3. Documentation to guide people in how to contribute.

We're making really good progress on all 3 fronts, IMO.

On a personal level, I'm certainly thinking every day about what I
absolutely must do vs creating an environment that makes it easier for
others with equal passion to do. It's a bit like the "theory of
constraints": having limited time & energy forces one to think harder
about how to reach goals, what's mandatory vs nice-to-have, etc.

Even in areas which I consider personal strengths (like GUI design and
documentation), I'm finding over and over again that encouraging and
enabling others is delivering a better overall outcome that me tackling
challenges alone. I suspect the payoff time for core engineering (like
network tuning and file formats) is much longer than areas like GUIs and
doc though.

Ian C.

[1]
http://www.oreillynet.com/pub/a/oreilly/tim/articles/architecture_of_participation.html
is well worth reading. Here's one quote I remind myself of constantly ...

The architecture of Linux, the Internet, and the World Wide Web are such
that users pursuing their own "selfish" interests build collective value
as an automatic byproduct.