Bertrand Delacretaz wrote:
>
> On Wednesday 15 May 2002 07:45, David Crossley wrote:
> >. . .
> > So, let us develop a procedure whereby the opensource
> > model is still employed, yet there is initial quality control.
> >. . .
>
> Following the opensource model, I think docs should be released as early as
> possible, with only minimal initial quality control but clearly flagged as
> "draft" or something. AND it must be very easy for all readers to give their
> feedback on the docs so that they can be improved.
[skipped]
I totally agree on this vision.
Release as early and as often as possible.
Diana, no, people don't go learning PHP because of mistakes in the docs.
And if they do, great, they had no way to help us anyway so it's not a
problem if they don't stick around.
I'm not being an asshole, just realistic: I'll tell you a story that
I've told the students at the University in Milano last week (Nicola and
Ugo were present).
Perfect stuff doesn't create open source communities: if you take
something, it works perfectly and doesn't give you any problem, the
community struggles: there is no refreshing, no new energy coming in.
If there were perfect cocoon docs, you wouldn't even be here. The *same*
can be said for *every* committer on this list.
Steven told me privately that he considered me a talented person, but
was kind of upset for my attitude of sparking innovation and then step
back... but then I explained the concept of 'software darwinism' and he
understood that my actions were just like a 'spark in the primordial
soup' (his words) [again, no offense for those who don't believe in
this, biological evolution is just used as a metaphore here!]
Now, you guys want more 'early on' quality control, but you *must*
understand that this is against the community dynamics: I mean: it would
be great if somebody would volunteer to perform this every day, but this
is unfeasible, it can't work. It creates bottlenecks, it doesn't humanly
scale and creates frustruation.
On the other hand, if you "let if go", people will find the bugs, the
errors, the mistakes and provide suggestions.
Sure, they will have to spend an extra half an hour against that
eventual error, but gosh, that's always a small price to pay...
... now look at the *real* picture: we are sellfish. We *MUST* be
sellfish, as individuals and as a community. Delegation is
decentralization. And decentralization is the very seed for massive
scalability (as the internet and the web show!)
How do we maximize quality control decentralization? By delegating it to
the user.
Then he has two options:
1) accepting this delegation (and take that half an hour to route
around the problem)
2) rejecting this delegation and walk away to some other technology
Now, there is *NO* way to avoid #2. No matter how perfect your docs are.
On the jserv-dev mail list (the first list I ever partecipated), we had
20 people a day leaving the community, but 21/22 entering. That makes a
400+ people/year community increase. And I'm talking about developers.
They run away? so? who cares. We are all volunteers, this is our energy,
if they don't like it, they go, their choice. And we are both happy,
actually happier if they were somewhat forced to remain.
So, what is our job as developers and community managers? plant seeds,
so that flower blossom, their colors attract new people (but some will
go away anyway), we teach them how to plant new seeds (like I'm doing
right now) and the garden keeps growing.
The intersting thing is that those who left the garden at one point,
might retain a well enough impression to "get back and take a look" at
some point. And at that point, thanks to the new seeds of those who
volunteered to help up planting this garden, they might decide to stay
and help themselves.
And the community, the garden and the fun grows.
But without that half-hour of frustration, it doesn't work, it doesn't
filter them, it doesn't give them itches to scratch, it doesn't give
them challenges to perform, it doesn't give them that extra-will to
penetrate the barrier of blatant use and start getting their hands
dirty.
Sure, commercial companies don't work this way: every new customer is a
good one. But for open source *this* is *NOT* true at all!
I agree on lowering the barrier more and more, but don't try to remove
it, not at all.
I must admit that I used to leave simple bugs *ON PURPOSE* in some
Cocoon code just so that people would find them and I *forced* them to
take a look inside Cocoon, and learn its internals.
A big publisher offered me to write a book on Cocoon on April 2000: my
response was: no way, that would attract too many users and too few
developers.
That early book would have killed my ability to 'raise developers' out
of those users that eventually happened to pass around here. But now
things are different and books are required, and books will appear.
But don't try to give better quality: follow the flow, shape it, don't
save a single user, filter them! Think at a larger scale. Delegation and
decentralization. Otherwise it doesn't work, it can't possibly work on
the longer term.
I know this is a shock for some of you: but I'm pretty sure that those
who are not shocked by this, learned this by themselves and they are
smiling now :)
For docs, just consider this: two more docs are *always* better than
one. No matter what is their quality. And even better: docs that contain
mistakes are actually *better* for this community that those who are
perfect.
I won't go as far as suggesting to make mistakes on purpose (I don't do
that anymore with code myself), but don't bother perceive quality: just
plant the seed in the right location and water rightly, the plant will
grow by itself and both you and the plant will be happy.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
