Day 3: Keynotes: Open Source Software Development Methodologies

For Linux, as Linus explained with humour, there is no real coordination or development model. Linus has the main tree and a few trusted people can get patches in without too many problems whereas the common user has much less of a chance to get his/her patch committed directly.
For Linux, the traffic on the linux kernel list is interesting as you find all kinds of uses. Main developers exchange ideas there, answer some questions, some other people submit patches for peer review, and after they get reviewed and sometimes improved, they eventually are submitted to Linus who puts it in the kernel if all goes well.
From time to time, people will submit a brilliant patch directly through Linus who will sometimes agree that it is indeed a great idea, and either apply the patch or rewrite it while using the same concept.

As for XFree86, there is a closed team of 650 developers with a core team of 12 people, and 3 people who are the source maintainers and handle the official releases.
Once patches are written and possibly reviewed on the mailing list, it is sent to an Email address that spools all the patches. The hard part, as Dirk explained is to reject a patch that was written by someone who possibly spent a lot of time writing it. A rejection has to be a unanimous vote among the three source maintainers.
Most of the people who work on XFree86 started contributing because they had an unsupported card, or a problem with an existing driver, and after contributing a few patches, then got hooked.

For Apache, Brian recounted that it grew out of a few people who had patches against the NCSA server. Today the core team of people has grown to 25 members.
For Apache, there is a vote system of yes and vetoes from the core team members and if there are a few yes, and no veto, the code is usually included, even if there is a problem later, because the code can then be removed.
Some core members can go an a "sabbatical" from time to time, and when release time comes, someone gets nominated to do the source release.

Chip explained that up to Perl 5.000, Larry Wall was doing all the releases, and later he started handing off work to other people on the perl5-porters mailing list as the amount of work became overwhelming. A few people take turns to be in charge and become "trusted lieutenants". Larry Wall kind of appoints a prime minister who changes from time to time.
All the patches are sent to the mailing list, even by the "pumpkin holder" (the person who is currently in charge of applying patches). Unless there is a major veto, the patch gets applied.
Chip noted that getting people to work on Perl is easier than getting them to work on the Linux kernel for instance, so it's easier to get developers.

For FreeBSD, there is a 15 member core team, and about 160 people who can commit to the main CVS tree. People can be promoted to commiters when they have interesting patches and the need arises.
With so many people in the FreeBSD team, there is a style guide, and most people agree on how to do most things. If a commiter doesn't do the right thing, he/she can easily have the commit bit removed.
Then, the core members can be dictators if needed, but it's usually not more than twice a year or so than a patch gets backed out.
As for losing people, it has happened, obviously everyone can't always be happy, but developer retention is fairly good. Then, it's an ego issue, people contribute because they'd like their name to be known.

Picture library

Back to Main Page

Next page

99/08/13 (04:50): Version 1.0