Open Source Management

Most large OpenSource projects (like Mozilla, Apache, etc.) set up management guidelines of some sort. These guidelines define terms like committer and user, express rules for accepting committers, and (most importantly) methods to insure that development goes smoothly.

In large OpenSource projects, disagreements will invariably arise. Developer Primus wants to add feature XYZ, but Developer Secundus asserts that feature XYZ clearly belongs in a plug-in and shouldn't pollute the clean, modular codebase. Developer Primus becomes frustrated and forks the software to modify on his own. You know the story.

To deal with such decisions, a project will usually choose one of the typical VotingPatterns.

Common problems in open-source management

Voting before discussion

If a proposal is made, a vote is often included in the initial responses. For many issues like those of style, code reorganization, application of patches, etc, this isn't a serious problem. When discussion moves on to the future, or suggests major changes, however, most developers will not have considered all the implications of each possibility. For that matter, they may not have considered all of the possibilities. It can't hurt to have a short no-voting period while the plan is discussed in detail.

The Veto

The veto can be used responsibly or recklessly. Exercise caution.

The Mailing List

When every statement requires a complete message (with extensive quoting of course), communication can become tedious. Discussion about a single topic may be split among any number of apparently unrelated threads. Each topic should be clearly identified and accessible. Perhaps Wiki form would be appropriate. Failing that there's always BugZilla or just text documents in CVS.

CategoryNegotiation CategoryManagement