So you want to contribute something to FreeBSD? That is
great! We can always use the help, and FreeBSD is one of
those systems that relies on the
contributions of its user base in order to survive. Your
contributions are not only appreciated, they are vital to
FreeBSD's continued growth!

Contrary to what some people might also have you believe,
you do not need to be a hot-shot programmer or a close
personal friend of the FreeBSD core team in order to have
your contributions accepted. The FreeBSD Project's
development is done by a large and growing number of
international contributors whose ages and areas of
technical expertise vary greatly, and there is always more
work to be done than there are people available to do it.

Since the FreeBSD project is responsible for an entire
operating system environment (and its installation) rather
than just a kernel or a few scattered utilities, our TODO list also spans a very wide
range of tasks, from documentation, beta testing and
presentation to highly specialized types of kernel
development. No matter what your skill level, there is
almost certainly something you can do to help the project!

Commercial entities engaged in FreeBSD-related enterprises
are also encouraged to contact us. Need a special extension
to make your product work? You will find us receptive to
your requests, given that they are not too outlandish.
Working on a value-added product? Please let us know! We
may be able to work cooperatively on some aspect of it. The
free software world is challenging a lot of existing
assumptions about how software is developed, sold, and
maintained throughout its life cycle, and we urge you to at
least give it a second look.

The following list of tasks and sub-projects represents
something of an amalgam of the various core team TODO lists and user requests we
have collected over the last couple of months. Where
possible, tasks have been ranked by degree of urgency. If
you are interested in working on one of the tasks you see
here, send mail to the coordinator listed by clicking on
their names. If no coordinator has been appointed, maybe
you would like to volunteer?

Build something like Tripwire(TM) into the
kernel, with a remote and local part. There are
a number of cryptographic issues to getting
this right; contact the coordinator for
details. Coordinator: Eivind Eklund <eivind@FreeBSD.org>

Make the entire kernel use
suser() instead of comparing to 0. It is
presently using about half of each.
Coordinator: Eivind Eklund
<eivind@FreeBSD.org>

Split securelevels into different parts, to
allow an administrator to throw away those
privileges he can throw away. Setting the
overall securelevel needs to have the same
effect as now, obviously. Coordinator: Eivind
Eklund <eivind@FreeBSD.org>

Make it possible to upload a list of ``allowed
program'' to BPF, and then block BPF from
accepting other programs. This would allow BPF
to be used e.g. for DHCP, without allowing an
attacker to start snooping the local network.

Update the security checker script. We should
at least grab all the checks from the other BSD
derivatives, and add checks that a system with
securelevel increased also have reasonable
flags on the relevant parts. Coordinator:
Eivind Eklund <eivind@FreeBSD.org>

Add authorization infrastructure to the kernel,
to allow different authorization policies. Part
of this could be done by modifying suser(). Coordinator: Eivind
Eklund <eivind@FreeBSD.org>

Add code to the NFS layer so that you cannot
chdir("..") out of an
NFS partition. E.g.,
/usr is a UFS partition with /usr/src NFS exported. Now it
is possible to use the NFS filehandle for /usr/src to get access to
/usr.

A concerted effort at support for portable
computers. This is somewhat handled by changing
PCMCIA bridging rules and power management event
handling. But there are things like detecting
internal vs. external display and picking a
different screen resolution based on that fact, not
spinning down the disk if the machine is in dock,
and allowing dock-based cards to disappear without
affecting the machines ability to boot (same issue
for PCMCIA).

Most of the tasks listed in the previous sections
require either a considerable investment of time or an
in-depth knowledge of the FreeBSD kernel (or both).
However, there are also many useful tasks which are
suitable for "weekend hackers", or people without
programming skills.

If you run FreeBSD-current and have a good Internet
connection, there is a machine
current.FreeBSD.org which builds a full
release once a day --- every now and again, try and
install the latest release from it and report any
failures in the process.

Read the freebsd-bugs mailing list. There might be
a problem you can comment constructively on or with
patches you can test. Or you could even try to fix
one of the problems yourself.

Read through the FAQ and Handbook periodically. If
anything is badly explained, out of date or even
just completely wrong, let us know. Even better,
send us a fix (SGML is not difficult to learn, but
there is no objection to ASCII submissions).

Help translate FreeBSD documentation into your
native language (if not already available) --- just
send an email to FreeBSD documentation project
mailing list <freebsd-doc@FreeBSD.org>
asking if anyone is working on it. Note that you
are not committing yourself to translating every
single FreeBSD document by doing this --- in fact,
the documentation most in need of translation is
the installation instructions.

Read the freebsd-questions mailing list and the comp.unix.bsd.freebsd.misc newsgroup
occasionally (or even regularly). It can be very
satisfying to share your expertise and help people
solve their problems; sometimes you may even learn
something new yourself! These forums can also be a
source of ideas for things to work on.

If you know of any bugfixes which have been
successfully applied to -current but have not been
merged into -stable after a decent interval
(normally a couple of weeks), send the committer a
polite reminder.

Move contributed software to
src/contrib in the source tree.

Make sure code in
src/contrib is up to date.

Look for year 2000 bugs (and fix any you find!)

Build the source tree (or just part of it) with
extra warnings enabled and clean up the warnings.

Fix warnings for ports which do deprecated things
like using gets() or including malloc.h.

If you have contributed any ports, send your
patches back to the original author (this will make
your life easier when they bring out the next
version)

The FreeBSD PR list shows all the current
active problem reports and requests for enhancement
that have been submitted by FreeBSD users. Look through
the open PRs, and see if anything there takes your
interest. Some of these might be very simple tasks,
that just need an extra pair of eyes to look over them
and confirm that the fix in the PR is a good one.
Others might be much more complex.

Start with the PRs that have not been assigned to
anyone else, but if one them is assigned to someone
else, but it looks like something you can handle,
e-mail the person it is assigned to and ask if you can
work on it---they might already have a patch ready to
be tested, or further ideas that you can discuss with
them.