From an Open Source Pro
Relayed by Kragen Sitaker, kragen@pobox.com, a message from Ian Lance Taylor, who wrote Taylor UUCP.Kragen says, "It's the most popular UUCP package for Unix. He currently works at Cygnus, a company that has been supporting open-source development tools, primarily for Fortune 500 companies, for about ten years."
From an Open Source Pro
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 effort.
|
This page was last built on 4/24/98; 1:26:05 PM by Dave Winer. dave@scripting.com |