Building Products with FreeBSD

This document would be of interest to the following broad groups of people:

After reading this article you should have:

The rest of the article is structured as follows:

Here are a few ways organizations have used FreeBSD:

There are a large number of technologies supported by the FreeBSD project. A selection of these are listed below:

FreeBSD's organizational structure is non-hierarchical.

There are essentially two kinds of contributors to FreeBSD, general users of FreeBSD, and developers with write access (known as committers in the jargon) to the source base.

There are many thousands of contributors in the first group; the vast majority of contributions to FreeBSD come from individuals in this group. Commit rights (write access) to the repository are granted to individuals who contribute consistently to the project. Commit rights come with additional responsibilities, and new committers are assigned mentors to help them learn the ropes.

Figure 1. FreeBSD Organization

Conflict resolution is performed by a nine member “Core Team” that is elected from the group of committers.

FreeBSD does not have “corporate” committers. Individual committers are required to take responsibility for the changes they introduce to the code. The FreeBSD Committer's guide [ComGuide] documents the rules and responsibilities for committers.

FreeBSD's project model is examined in detail in [Nik2005].

FreeBSD's release engineering processes play a major role in ensuring that its released versions are of a high quality. At any point of time, FreeBSD's volunteers support multiple code lines (Figure 2, “FreeBSD Release Branches”):

Figure 2. FreeBSD Release Branches

Code lines are kept alive for as long as there is user and developer interest in them.

Machine architectures are grouped into “tiers”; Tier 1 architectures are fully supported by the project's release engineering and security teams, Tier 2 architectures are supported on a best effort basis, and experimental architectures comprise Tier 3. The list of supported architectures is part of the FreeBSD documentation collection.

The release engineering team publishes a road map for future releases of FreeBSD on the project's web site. The dates laid down in the road map are not deadlines; FreeBSD is released when its code and documentation are ready.

FreeBSD's release engineering processes are described in [RelEngDoc].

To be able to work effectively with the FreeBSD project, you need to understand the project's culture.

Volunteer driven projects operate under different rules than for-profit corporates. A common mistake that companies make when venturing into the open-source world is that of underplaying these differences.

Motivation. Most contributions to FreeBSD are done voluntarily without monetary rewards entering the picture. The factors that motivate individuals are complex, ranging from altruism, to an interest in solving the kinds of problems that FreeBSD attempts to solve. In this environment, “elegance is never optional” [Nor1993].

The Long Term View. FreeBSD traces its roots back nearly twenty years to the work of the Computer Science Research Group at the University of California Berkeley.^[1] A number of the original CSRG developers remain associated with the project.

The project values long-term perspectives [Nor2001]. A frequent acronym encountered in the project is DTRT, which stands for “Do The Right Thing”.

Development Processes. Computer programs are tools for communication: at one level programmers communicate their intentions using a precise notation to a tool (a compiler) that translates their instructions to executable code. At another level, the same notation is used for communication of intent between two programmers.

Formal specifications and design documents are seldom used in the project. Clear and well-written code and well-written change logs (Figure 3, “A sample change log entry”) are used in their place. FreeBSD development happens by “rough consensus and running code” [Carp1996].

r151864 | bde | 2005-10-29 09:34:50 -0700 (Sat, 29 Oct 2005) | 13 lines
Changed paths:
   M /head/lib/msun/src/e_rem_pio2f.c

Use double precision to simplify and optimize arg reduction for small
and medium size args too: instead of conditionally subtracting a float
17+24, 17+17+24 or 17+17+17+24 bit approximation to pi/2, always
subtract a double 33+53 bit one.  The float version is now closer to
the double version than to old versions of itself -- it uses the same
33+53 bit approximation as the simplest cases in the double version,
and where the float version had to switch to the slow general case at
|x| == 2^7*pi/2, it now switches at |x| == 2^19*pi/2 the same as the
double version.

This speeds up arg reduction by a factor of 2 for |x| between 3*pi/4 and
2^7*pi/4, and by a factor of 7 for |x| between 2^7*pi/4 and 2^19*pi/4.
        

Communication between programmers is enhanced by the use of a common coding standard style(9).

Communication Channels. FreeBSD's contributors are spread across the world. Email (and to a lesser extent, IRC) is the preferred means of communication in the project.

We now look at a few best practices for making the best use of FreeBSD in product development.