FreeBSD

FreeBSD is a free, open-source, Unix-like operating system that has been developed and maintained since 1992, when it was forked from the Berkeley Software Distribution (BSD). BSD was, in turn, developed by the Computer Systems Research Group (CSRG) at the University of California, Berkeley, using the licenced source-code of AT&T's Research Unix.

FreeBSD is widely used to serve websites, databases, and streaming media. It is also used on desktop and laptop computers. Its source code is the basis for numerous operating systems and software applications.

Quotes about FreeBSD

 * The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software[,] and one that we enthusiastically support.
 * Jordan Hubbard, in
 * There was never any consideration of using the GPL. We liked the BSD license specifically because it's flexible, simple and short. It's easy for both engineers and lawyers to read and it achieves our ends, which is to limit our liability but still make the code available to as many people as possible and for any purpose. The GPL is not something we really considered to be a license so much as a political manifesto ….
 * Lots of work is going on to make FreeBSD more friendly on the desktop. Within the year, we expect to have, or be near, parity with Linux.
 * FreeBSD developer Scott Long, as quoted in
 * The FreeBSD project is organized in much the same way as the CSRG. The entire FreeBSD project, including all the source code, documentation, bug reports, mailing-list archives, and even administrative data, is maintained in a publicly readable source-code-control system. Anyone may view the source code and existing bug reports, track progress on fixing bugs, and post bug reports. Anyone may join and participate in the numerous FreeBSD mailing lists. There are three groups of people that directly work on FreeBSD: developers, committers, and the core team. There are 5000 to 6000 developers, each of whom works on some part of the system[,] such as maintaining the FreeBSD kernel, continuing development of the 1000 core FreeBSD utilities, writing FreeBSD documentation, and updating other open-source software in the FreeBSD ports collection. Developers are able to access the source-code repository, but they are not permitted to change it. Instead, they must work with a committer or file a problem report to get their changes added to the system.  There are currently 300 to 400 committers. Like the developers, most of them specialize in some part of the system. Unlike the developers, they are permitted to make changes to those parts of the source-code repository in which they have been authorized to work. All nontrivial changes should be reviewed by one or more other committers before being checked into the source tree. Most committers are doing work of their own as well as reviewing and committing the work of several developers.  The core team is composed of nine people who are elected every 2 years. The candidates for the core team come from the committers and the committers elect the core team. The core team acts as the final gatekeepers of the source code. They monitor what is being committed and resolve conflicts if two or more committers cannot agree on how to solve a particular problem. The core team also approves the advancement of developers to committers and (in rare circumstances) temporarily or permanently evicts someone from the committer group. The usual reason for departure from the committer group is inactivity (making no changes to the system for more than a year).
 * The FreeBSD project is organized in much the same way as the CSRG. The entire FreeBSD project, including all the source code, documentation, bug reports, mailing-list archives, and even administrative data, is maintained in a publicly readable source-code-control system. Anyone may view the source code and existing bug reports, track progress on fixing bugs, and post bug reports. Anyone may join and participate in the numerous FreeBSD mailing lists. There are three groups of people that directly work on FreeBSD: developers, committers, and the core team. There are 5000 to 6000 developers, each of whom works on some part of the system[,] such as maintaining the FreeBSD kernel, continuing development of the 1000 core FreeBSD utilities, writing FreeBSD documentation, and updating other open-source software in the FreeBSD ports collection. Developers are able to access the source-code repository, but they are not permitted to change it. Instead, they must work with a committer or file a problem report to get their changes added to the system.  There are currently 300 to 400 committers. Like the developers, most of them specialize in some part of the system. Unlike the developers, they are permitted to make changes to those parts of the source-code repository in which they have been authorized to work. All nontrivial changes should be reviewed by one or more other committers before being checked into the source tree. Most committers are doing work of their own as well as reviewing and committing the work of several developers.  The core team is composed of nine people who are elected every 2 years. The candidates for the core team come from the committers and the committers elect the core team. The core team acts as the final gatekeepers of the source code. They monitor what is being committed and resolve conflicts if two or more committers cannot agree on how to solve a particular problem. The core team also approves the advancement of developers to committers and (in rare circumstances) temporarily or permanently evicts someone from the committer group. The usual reason for departure from the committer group is inactivity (making no changes to the system for more than a year).