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