1.1 Target Audience

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

• Decision makers in product companies looking at ways to improve their product quality, reduce their time to market and lower engineering costs in the long term.

• Technology consultants looking for best-practices in leveraging “open-source”.

• Industry observers interested in understanding the dynamics of open-source projects.

• Software developers seeking to use FreeBSD and looking for ways to contribute back.

1.2 Article Goals

After reading this article you should have:

• An understanding of the goals of the FreeBSD Project and its organizational structure.

• An overview of the available technology in the project.

• An understanding of its development model and release engineering processes.

• An understanding of how conventional corporate software development processes differ from that used in the FreeBSD project.

• Awareness of the communication channels used by the project and the level of transparency you can expect.

• Awareness of optimal ways of working with the project—how best to reduce engineering costs, improve time to market, manage security vulnerabilities, and preserve future compatibility with your product as the FreeBSD project evolves.

1.3 Article Structure

The rest of the article is structured as follows:

• Section 2 introduces the FreeBSD project, explores its organizational structure, key technologies and release engineering processes.

• Section 3 describes ways to collaborate with the FreeBSD project. It examines common pitfalls encountered by corporates working with voluntary projects like FreeBSD.

• Section 4 concludes.

2.1 Building with FreeBSD

Here are a few ways organizations have used FreeBSD:

• As an upstream source for tested code for libraries and utilities.

  By being “downstream” of the project, organizations leverage the new features, bug fixes and testing that the upstream code receives.

• As an embedded OS (for example, for an OEM router and firewall device). In this model, organizations use a customized FreeBSD kernel and application program set along with a proprietary management layer for their device. OEMs benefit from new hardware support being added by the FreeBSD project upstream, and from the testing that the base system receives.

  FreeBSD ships with a self-hosting development environment that allows easy creation of such configurations.

• As a Unix compatible environment for the management functions of high-end storage and networking devices, running on a separate processor “blade”.

  FreeBSD provides the tools for creating dedicated OS and application program images. Its implementation of a BSD unix API is mature and tested. FreeBSD can also provide a stable cross-development environment for the other components of the high-end device.

• As a vehicle to get widespread testing and support from a worldwide team of developers for non-critical “intellectual property”.

  In this model, organizations contribute useful infrastructural frameworks to the FreeBSD project (for example, see netgraph(3)). The widespread exposure that the code gets helps to quickly identify performance issues and bugs. The involvement of top-notch developers also leads to useful extensions to the infrastructure that the contributing organization also benefits from.

• As a development environment supporting cross-development for embedded OSes like RTEMS and eCOS.

  There are many full-fledged development environments in the 24,000-strong collection of applications ported and packaged with FreeBSD.

• As a way to support a Unix-like API in an otherwise proprietary OS, increasing its palatability for application developers.

  Here parts of FreeBSD's kernel and application programs are “ported” to run alongside other tasks in the proprietary OS. The availability of a stable and well tested Unix™ API implementation can reduce the effort needed to port popular applications to the proprietary OS. As FreeBSD ships with high-quality documentation for its internals and has effective vulnerability management and release engineering processes, the costs of keeping upto-date are kept low.

2.2 Technologies

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

• A complete system that can cross-host itself for the following architectures: alpha (up to FreeBSD version 6.X), amd64, ia64, i386, sparc64, powerpc (see build(7)).

• Support for the following technologies, protocols and standards: ATA, ATAPI, ATM, Bluetooth™, CAM, CardBus™, DHCP, DNS, EISA™, Ethernet™, FDDI, Fibre Channel, GPIB, IEEE 1394, IPv4, IPv6, IPSEC, IPX™, ISDN, MAC, NIS, NFS, OpenSSH, OPIE, PAM, PCI™, PCMCIA, POSIX™, PnP, RAID, RPC, SATA, SCSI, SMB, TCP, USB, VESA, VLAN, VLB, WebNFS™.

• A modular symmetric multiprocessing capable kernel, with loadable kernel modules and a flexible and easy to use configuration system.

• Support for emulation of Linux™ and SVR4 binaries at near machine speeds. Support for binary Windows™ (NDIS) network drivers.

• Libraries for many programming tasks: archivers, FTP and HTTP support, thread support, in addition to a full POSIX like programming environment.

• Advanced security features: Mandatory Access Control (mac(9)), jails (jail(2)), ACLs, and in-kernel cryptographic device support.

• Advanced networking features: firewall-ing, QoS management, high-performance TCP/IP networking with support for many advanced features.

  FreeBSD's in-kernel Netgraph (netgraph(4)) framework allows kernel networking modules to be connected together in flexible ways.

• Support for advanced storage technologies: Fibre Channel, SCSI, software and hardware RAID, ATA and SATA.

  FreeBSD supports a number of filesystems, and its native UFS2 filesystem supports soft updates, snapshots and very large filesystem sizes (16TB per filesystem) [McKu1999].

  FreeBSD's in-kernel GEOM (geom(4)) framework allows kernel storage modules to be composed in flexible ways.

• Over 24,000 ported applications, both commercial and open-source, managed via the FreeBSD ports collection.

2.3 Organizational Structure

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.

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].

2.4 FreeBSD Release Engineering Processes

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):

• New features and disruptive code enters on the development branch, also known as the -CURRENT branch.

• -STABLE branches are code lines that are branched from HEAD at regular intervals. Only tested code is allowed onto a -STABLE branch. New features are allowed once they have been tested and stabilized in the -CURRENT branch.

• -RELEASE branches are maintained by the FreeBSD security team. Only bug fixes for critical issues are permitted onto -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].

3.1 Understanding FreeBSD culture

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.

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

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

bde         2005-10-29 16:34:50 UTC

  FreeBSD src repository

  Modified files:
    lib/msun/src         e_rem_pio2f.c
  Log:
  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.

  Revision  Changes    Path
  1.14      +22 -97    src/lib/msun/src/e_rem_pio2f.c
       

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

3.2 Best Practices for collaborating with the FreeBSD project

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