If you read Slashdot on a regular basis, you'll know the troll who keeps claiming that BSD is dying. Admittedly he's rather quiet lately, and he doesn't even go to the trouble to update his claims: the text has been pretty much the same for a number of years. A better indication would be a survey like a recent Netcraft survey which showed that nearly two million active sites run FreeBSD.
Still, you'd think that the troll would have come up with something better recently, though: Matt Dillon, an ex-FreeBSD developer, announced a new BSD variant, DragonFly BSD.
Why? We already have so many BSDs: apart from the free FreeBSD, NetBSD and OpenBSD, there's Apple's Darwin, Wind River's BSD/OS, not to mention special purpose versions like PicoBSD, TinyBSD and TrustedBSD.
An obvious reason why Matt is starting his own project is that he is no longer on the FreeBSD project: he was expelled from it a few months ago. This is not the place to discuss the matter, but it should be clear that no such decision is clear-cut. Matt is a superb technician, and I have no doubt as to his technical ability.
Still, that sounds like a bad reason to start a “branch”. And it is. That's not Matt's intention, though. The FreeBSD project made some significant design decisions for release 5 of FreeBSD, and it's still not clear that the decisions are correct. Matt asserts that there are better solutions, and he may be right. What better way to find out than start a sub-project to address the issue? Whether he's right or wrong, the results will be beneficial.
In the beginning, nobody thought of things like democracy or fairness: it was like a private club, where the most active people got together and decided the direction of the project. That's where the name “core team” or “core group” came from: they were simply the most active people.
I've already written about the early days of the free BSD projects. There were different things to do, things which were more obvious than they are now. It was easy for people to pick on a piece of work that needed to be done and do it. They could do it after work of a (presumably) less satisfying nature, and when it was done they could submit it back to the project. Little coordination was needed, little help was available, and almost by definition, if they finished the job, it was right.
As I mentioned in that article, times have changed. The result is that we need to spend more time coordinating what we're doing. We're doing so much of it that it's easy even for active project members to understand who does what, let alone why. In the FreeBSD core team recently we identified the need for describing the current state of the project, and the task fell to me. The rest of this article is a first attempt to make that definition. Don't take this version as definitive; in particular, it's my own take, and it hasn't been sanctioned by the FreeBSD core team. I'll update this article later with a pointer to the definitive URL.
The FreeBSD Foundation is relatively low-key and has little to do with the day-to-day running of the project.
Since September 2000, the FreeBSD Core team consists of nine developers, elected by the active developers (which in turn is defined as those developers who have made a “significant” contribution in the last twelve months).
The FreeBSD Documentation Project has its own managerial body, officially called the “Documentation Project Manager”, but usually referred to as docmgr after the mail address for the team.
Many people donate hardware, usually second-hand, to the FreeBSD project. A Donations Liaison Office handles these donations and tries to ensure that they are used to the best benefit of the project.
The FreeBSD Ports Collection is managed independently of the main project by the “Ports Management Team”.
As the name suggests, the FreeBSD Release Engineering team is responsible for creating new releases of FreeBSD. Read the documentation for more information on how they work.
The Security Officer Team audits software and helps maintain a secure version of the tree. It also issues security advisories as necessary.
The FreeBSD project runs a number of computers on the Internet. A large number of them are generously hosted by Yahoo!, though a number of other organizations also contribute. At the time of writing I don't have a complete list, but this page will be updated when I do.
Running computers requires systems administrators of various flavours. The FreeBSD project distinguishes between the following functions:
The Postmaster, responsible for running the mail system. The FreeBSD project distributes a large amount of mail, and the job is non-trivial.
The sources of FreeBSD are all freely available, of course, from a surprising number of different places. The master versions of the sources are maintained in CVS inside the project, and are accessible only to developers. This copy is maintained by the Source Repository Managers.
Non-developers can get the FreeBSD sources online from a number of sources. The FTP site is maintained by the systems administration team, but there is also a CVSup Mirror Site Coordinator who handles data transfer to sites external to the project.
The FreeBSD web site is run by the webmaster team in cooperation with the documentation project: a significant proportion of the content, including many of the links mentioned in this article, is derived from the FreeBSD documentation project.
Other developers are called contributors. They need to find a committer before their code can be included in the FreeBSD code base.
The vast majority of people associated with FreeBSD are the users. We saw above that Netcraft has counted about two million active Internet sites running FreeBSD. The real user base is probably much higher. Numerically, they dwarf the rest of the project.
A number of commercial organizations support FreeBSD. I've already mentioned Yahoo!. There are many others, but I won't mention them until I have permission. A number of the FreeBSD developers are employed by such companies, though.
Who's responsible for what? The core team frequently gets questions of a basic technical nature (“which direction should we be taking in the implementation of low-level kernel locking?”), which really belong to the Technical Review Board. It also gets questions relating to financial issues which should be handle by the FreeBSD Foundation. A surprising number of questions of general nature go to the FreeBSD documentation project, which has nothing to do with answering them.
Frequently such misdirected questions appear to be ignored: nothing happens. In fact, this is an issue of the volunteer nature of the project. In each such case, somebody in the respective group should answer the question. But typically questions get answered by that member of the group best suited to answering a question. Who's the best for a misdirected question?
Who's responsible to whom? This is probably the biggest question. In one case, we have a clear answer: the FreeBSD Foundation has legal obligations due to its 501(c)(3) status. That's about the only one, though. Since the democratization of the project in 2000, the core team is responsible to the developers, and the other groups, with the exception of the Foundation, are responsible to the core team. That leaves users, in particular, out in the cold.
Ethically, there is no problem with this approach. FreeBSD is developed by a group of people who do it for their own pleasure and give it away. The people who get it for free don't have any right to ask for special treatment. On the other hand, the success of FreeBSD is based on the success of the users, so it's in the project best interests to listen to the users. I suspect we're not doing enough of that, and it's not clear what mechanism would work best.
Then there's the question of employment. The FreeBSD project does not have any paid employees, but plenty of members of the project, including a large proportion of the members of the management groups, work on FreeBSD in their day job, and some are in a position to influence hiring decisions. These people might be thought to have a conflict of interest when in such decisions. In fact, I find it difficult to see any conflict of interest in such a case, but people who misunderstand the relationships might see things differently. This is one reason why it's very important to be clear about what authority such people are using. This article is a case in point: I'm a member of the FreeBSD core team, but this article is not an official FreeBSD core team statement. In a similar manner, people looking for employment shouldn't assume that membership of any FreeBSD group would change their chances in any way.