The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: chapter/para
Context English State
The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper <citation><xref linkend="jorgensen2001"/></citation>, 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.
<citation><xref linkend="freebsd-developer-handbook"/>, Section 1.2 and 1.3</citation> give the vision and the architectural guidelines for the project. The vision is <quote>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.</quote> The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project
An <quote>activity</quote> is an element of work performed during the course of a project <citation><xref linkend="ref-pmbok"/></citation>. 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 <quote>process</quote> 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 <quote>hat</quote> 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 <quote>outcome</quote> is the final output of the process. This is synonymous with deliverable, that is defined as <quote>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</quote> by <citation><xref linkend="ref-pmbok"/></citation>. Examples of outcomes are a piece of software, a decision made or a report written.
When saying <quote>FreeBSD</quote> we will mean the BSD derivative UNIX-like operating system FreeBSD, whereas when saying <quote>the FreeBSD Project</quote> 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.
Number of people
Core members
The FreeBSD Project's structure (in order of descending authority) <_:informaltable-1/>
Number of committers has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004 and contributors by going through the list of contributions and problem reports.
The main resource in the FreeBSD community is its developers: the committers and contributors. It is with their contributions that the project can move forward. Regular developers are referred to as contributors. As of January 1st, 2003, there are an estimated 5500 contributors on the project.
Committers are developers with the privilege of being able to commit changes. These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. They are also the developers who elect the core team, and they have access to closed discussions.
The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. The four parts are kernel development, userland development, ports and documentation. When referring to the base system, both kernel and userland is meant.
This split changes our table to look like this:


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: chapter/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/dev-model.pot, string 53