Archive of UserLand's first discussion group, started October 5, 1998.
Re: Thoughts on ESR and Perl
Author: Eric Kidd Posted: 8/27/1999; 11:44:39 AM Topic: Opening Up Linux Journal and O'Reilly Msg #: 10135 (In response to 10090) Prev/Next: 10134 / 10136
Who decides who's on the core Linux team? Isn't it Linus? Or does it vary with the project?It varies with project. See my other message for a description of how Linux works.
Other projects work differently. Python has Guido (who maintains the interpreter) and a bunch of SIGS which handle specific libraries. Apache has about a dozen core developers with full veto power, and large number of informal contributors. WINE has a project leader, but I can't remember his name--he keeps a very low profile, and shares responsibility. Perl has an unusual system: a committee prepares each release, and major decisions are made by the person holding the "patch pumpkin". Larry Wall acts as the Supreme Court, not as the President. If nothing goes wrong, he keeps his hands off the process.
The most interesting case is the GIMP. Theoretically speaking, the project is run by Spencer Kimball and Peter Mattis. However, neither of them has worked on the GIMP much since they graduated from college. Code is written by about 50 people (who've worked out some sort of system for not stepping on each other's toes), and the actual releases used to be made by somebody who didn't write any code at all.
In general, most projects have a small group of well-respected maintainers. These people make the decisions, and they're almost always polite to each other. If you disturb the peace, you loose your respect and get ignored. If important contributors disagree, they talk things over and come to some sort of a conclusion.
To be a major contributor to an open source project, you need three things: coding ability, good writing skills and a well-honed sense of diplomacy. If you have all three, you can become a major contributor to any project simply by introducing yourself and writing lots of good code. If you do a lot of good for a project, you'll be included in the design decisions and people will listen to you. Also, you should give credit to everybody else at every possible opportunity. This makes other contributors feel good, and it makes you look like a grown-up developer and not a random flamer.
As Dave can probably point out, there's a lot in common between successful open source teams and successful traditional teams. Most of the rules of software development still apply. It's just the context which has changed.
Cheers,
Eric
This page was archived on 6/13/2001; 4:52:13 PM.
© Copyright 1998-2001 UserLand Software, Inc.