I took a look at FreeBSD and Mozilla, two open-source projects that I think do a great job, and wrote down some observations. I combined them with a bunch of information from their sites and from some papers written about them.
I attached a bunch of conclusions that may be useful in figuring out some project-wide 2005 goals.
Big picture
===========
- Developers prefer more loosely controlled projects with a flat hierarchy,
relying on individual autonomy, tacit norms and self-organization rather
than commands, control and explicit rules [1].
- Projects such as FreeBSD and Mozilla are more similar to Gentoo than projects
such as Linux, which have a benevolent dictator.
- Community testing is essential for finding and removing bugs [1].
- Tinderboxes are heavily used in Mozilla, less so in FreeBSD [1]. Still,
in FreeBSD they run twice a day on three different systems. Mozilla's
tree was closed for check-ins during tinderbox runs for nearly 20% of
the
time in an arbitrarily chosen period for three weeks of October 2002.
FreeBSD does not close the tree.
- Our Web site has two primary purposes [1]:
- It _presents_ the project and the product to the outside world;
- It acts as a _portal_ for developers and everyone else to locate and
download existing information.
- For both projects, openness is a primary principle [1]:
- Everyone can download every version of every file;
- Everyone can monitor files for who made which changes;
- Test results are free for everyone to see;
- Nearly all lists are public, and few are moderated;
- Everyone can report bugs;
- People with commit rights can technically update any file.
- A key motivation factor for contributors is quickly seeing the results of
their work [2].
- The release plans are the _only_ plans in FreeBSD and Mozilla [1]. There are
no plans on more detailed levels and no timetable for the contributions
that
will eventually lead to the next release.
- Mozilla's "Seamonkey Engineering Bible" [3] talks about how to be an effective
contributor:
- Dealing with bugs
- Add value to each bug before passing it up
- Get bugs with high-quality info, and get them to the
right people
- Triage your bug list early and often
- Update bugs and give testing info when you check in
fixes
- Communicating and planning before you check in
- Get code reviews
- Send pre-check in warnings if your changes affect
others
- Communicating and planning after you check in
- Stay highly available for a few hours after any
check-in
- If your change breaks the tree:
- Acknowledge responsibility
- Estimate time to fix
- Share your experience, so others don't make
the same mistake
- Watch for feedback about your changes
- FreeBSD has a similar collection of recommendations, although looser [4]. Some
examples are:
- Discuss any significant changes _before_ committing
- When in doubt, ask for review
- Respect existing maintainers
- Do not fight in public with other committers; it looks bad
- They've got some policies that could be useful for both our QA and
devrel
teams.
- We need to keep the bureaucracy required to contribute from becoming too
complicated and time-consuming [1], or we will lose developers,
especially
if, as Raymond [5] puts it, are "self-directed egoists."
- On the other hand ... [1]
- Too few rules can easily lead to low-quality code
- Too little coordination can lead to parallel, wasted work
- Instead of counting on a large number of strict QA standards, both FreeBSD and
Mozilla chose to focus on relatively few, highly enforced rules [1].
- FreeBSD and Mozilla both rely on requesting contributors to follow rules of
conduct rather than technical control mechanisms [1].
- Mozilla has a clear policy for dealing with security bugs [6].
- It is very important for the community to be responsive to questions and
contributions of newcomers to sustain their interest and encourage their
continued participation [7]. Experienced developers should remember
they are
the learning resources for newcomers.
- When the developer and user communities diverge, when developers are viewed as
producers and users as customers, the natural system of reciprocal
benefits
falls apart [8].
- New recruits in Debian are not only encouraged to demonstrate their commitment
but also to express why they want to join and display technical
proficiency
[9]. In addition, their final test is often filled with a clean, policy-
compliant and bug-free example of the type of work the applicants
intend to
do within Debian, in addition to a series of technical questions.
- Even retiring developers have a final responsibility, as Raymond writes [5]:
"When you lose interest in a program, your last duty to it is to hand
it off
to a competent successor."
- Keeping the developer and user communities close-knit aids bug-fixing [5]:
"Given a large enough beta-tester and co-developer base, almost every
problem will be characterized quickly and the fix obvious to someone."
- Be courteous to bug reporters [5]:
"If you treat your beta-testers as if they're your most valuable
resource,
then will respond by becoming your most valuable resource."
Bibliography
============
1. Holck, Jesper, and Jorgensen, Niels. "Do not check in on red: Control meets
anarchy in two open source projects." Free/Open Source Software
Development. Ed. Stefan Koch (2004).
2. Jorgensen, N. "Putting it all in the trunk: Incremental software development
in the FreeBSD open source project." Information Systems
Journal 11: 321
(2001).
3. "The Seamonkey engineering bible." Retrieved 9 Jan., 2005, from
http://www.mozilla.org/projects/seamonkey/rules/bible.html.
4. "The FreeBSD committers' big list of rules." Retrieved 9 Jan., 2005, from
http://www.freebsd.org/doc/en/articles/committers-guide/rules.html.
5. Raymond, Eric. "The cathedral and the bazaar." Retrieved 9 Jan., 2005, from
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.
6. "Handling Mozilla security bugs." Retrieved 9 Jan., 2005, from
http://www.mozilla.org/projects/security/security-bugs-policy.html.
7. Ye, Yunwen; Nakakoji, Kumiyo; Yamamoto, Yasuhiro; and Kishida, Kouichi. "The
co-evolution of systems and communities in free and open source
software
development." Free/Open Source Software Development. Ed. Stefan
Koch
(2004).
8. Narduzzo, Alessandro and Rossi, Alessandro. "The role of modularity in free/
open source software development." Free/Open Source Software
Development. Ed. Stefan Koch (2004).
9. Coleman, E. Gabriella and Hill, Benjamin. "The social production of ethics in
Debian and free software communities: Anthropological lessons
for
vocational ethics." Free/Open Source Software Development. Ed.
Stefan
Koch (2004).
signature.asc
Description: This is a digitally signed message part
