English Chinese (Traditional) (zh_TW)
Simon L. Nielsen mailto:simon@freebsd.org[simon@freebsd.org]
A project model is a means to reduce the communications overhead in a project. As shown by [<<brooks, Brooks, 1995>>], increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project.
During the Core elections in 2002, Mark Murray stated "I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs." [<<bsd-election2002, FreeBSD, 2002B>>]. This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works.
The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper [<<jorgensen2001, Jørgensen, 2001>>], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers.
After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project.
[<<freebsd-developer-handbook, FreeBSD, 2002A>>] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project. The vision is "To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability." The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project
An "activity" is an element of work performed during the course of a project [<<ref-pmbok, PMI, 2000>>]. It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery.
A "process" is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design.
A "hat" is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project.
An "outcome" is the final output of the process. This is synonymous with deliverable, that is defined as "any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer" by [<<ref-pmbok, PMI, 2000>>]. Examples of outcomes are a piece of software, a decision made or a report written.
When saying "FreeBSD" we will mean the BSD derivative UNIX-like operating system FreeBSD, whereas when saying "the FreeBSD Project" we will mean the project organisation.
Organisational structure
While no-one takes ownership of FreeBSD, the FreeBSD organisation is divided into core, committers and contributors and is part of the FreeBSD community that lives around it.