Subject: Re: A new(?) account for why free generates quality
Date: Thu, 23 Apr 1998 20:13:31 -0400 (EDT)

In fsb (Sean Shapira) writes:

>But I would very much like to hear from those of you leading
>free software projects about how you:

> - Retain and motivate recruits who seem to have the highest 
>   potential.

> - Handle recruits who seem likely to be highly ineffective.

> - Handle those in the "vast middle" of apparent effectiveness.

I've maintained free software packages both before and during my
employment at Cygnus.  I think I've been moderately successful at
getting good work from net contributions, and I've certainly thought
about how to improve them.  My short answer is that it takes a fair
amount of work.

Motivation on a free software project is somewhat out of the
maintainer's control.  The most motivated contributors are those who
use the software regularly.  They have a real incentive to improve it.

I try to maintain motivation by providing good feedback to patches and
suggestions.  Very few patches are good enough to simply check in.  If
a patch is good enough or valuable enough, I will normally rewrite it
and check it in.  Then I will send a detailed critique to the author,
explaining how to do it better next time.  If the patch is buggy, or
not well written and also not very useful, I'll just skip straight to
the critique and encourage the contributor to send a corrected
version.  If the patch is incomprehensible, I'll just say that.

I'd say 95% of suggestions from the net are useless.  They are either
bad ideas or they are good ideas which nobody has time to implement.
I normally respond shortly, saying either ``bad idea because...'' or
``good idea, why don't you find a volunteer.''

The point is to respond.  Sending in a patch and having it be ignored
is demoralizing, and it discourages future contributions.  For a first
time contributor, getting a response back from something you've flung
out into the wild is exciting.  For a long term contributor, the
response is simply part of the working relationship.

Ideally, contributors understand my critiques, and consider them in
future patches.  Eventually they reach the point where you can just
check in their patches with no more than a few formatting changes.
Then I just send a note saying that the patch is checked in.

Writing the critiques is not trivial.  I have to take the time to
understand what the patch is trying to do, and I have to take the time
to understand whether the patch fails.  As far as I'm concerned,
that's the cost of getting good net contributions.

You ask about recruits at various levels of effectiveness, but for me
that's never been an issue.  Contributors who are ineffective don't
contribute useful code.  It's not like you have to discourage them;
eventually they give up and go away.  For mid-range contributors, as I
said, I will rewrite the patch to be acceptable, check it in, and
explain what I did.  Some people never really do get it, but if their
patches are good enough to be useful after being rewritten, that's OK.

I rarely find that asking for particular contributions does any good.
People work on what they need, and on what they are interested in.  If
somebody does volunteer to do something, I just keep track of it in
case anybody else volunteers, in which case I suggest that they get
together.  I don't bother to track down volunteers and ask whether
they have made any progress; I think there are too many good reasons
for people to not work on free software, and there's no reason to
embarrass anybody.  Of course, this implies that I never depend on a
volunteer for any crucial element.

I try to always thank people who have made significant contributions
in the release announcements.  I've used THANKS files in the past, but
I suspect that only contributors read them.

>Do any techniques have special applicability in free software
>environments?  (More generally, are there any clear "human
>resources" advantages for free software development projects?)

The most obvious one is simply getting your name in lights.  I expect
that thousands of people glanced over the list of names in the GNU
binutils 2.9 announcement.  That should be a nice ego boost for those
38 people, and it's one that is rarely available in non-free software.

Working on free software gives people a chance to talk to technically
knowledgeable people about a topic of mutual interest, something most
hackers enjoy.  While many of us get that at work anyhow, for some
people at small companies, or at non-technical companies, or in remote
countries, working on free software can be a way to communicate in a
way that is more meaningful and satisfying than posting Usenet
articles (for some people--obviously many people prefer posting Usenet
articles than doing any actual coding).  Now that I've written this, I
guess it's not necessarily an advantage of free software development
so much as an advantage of distributed development.

Free software has an advantage in that you naturally tend to get
contributions for things that people need.  There is no need to guess
what people want when trying to decide how to direct the development