Contributed by Jordan K. Hubbard <jkh@FreeBSD.org>.
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?
The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed:
3-stage boot issues. Overall coordination: FreeBSD technical discussions mailing list <freebsd-hackers@FreeBSD.org>
Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks.
Filesystem problems. Overall coordination: FreeBSD filesystem project mailing list <freebsd-fs@FreeBSD.org>
Clean up and document the nullfs filesystem code. Coordinator: Eivind Eklund <eivind@FreeBSD.org>
Fix the union file system. Coordinator: David Greenman <dg@FreeBSD.org>
Implement Int13 vm86 disk driver. Coordinator: FreeBSD technical discussions mailing list <freebsd-hackers@FreeBSD.org>
New bus architecture. Coordinator: New Bus Architecture mailing list <new-bus-arch@bostonradio.org>
Port existing ISA drivers to new architecture.
Move all interrupt-management code to appropriate parts of the bus drivers.
Port PCI subsystem to new architecture. Coordinator: Doug Rabson <dfr@FreeBSD.org>
Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented.
Resolve the probe/attach priority issue once and for all.
Move any remaining buses over to the new architecture.
Kernel issues. Overall coordination: FreeBSD technical discussions mailing list <freebsd-hackers@FreeBSD.org>
Add more pro-active security infrastructure. Overall coordination: FreeBSD security mailing list <freebsd-security@FreeBSD.org>
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.
The following tasks need to be done, but not with any particular urgency:
Full KLD based driver support/Configuration Manager.
Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc.
PCMCIA/PCCARD. Coordinators: Michael Smith <msmith@FreeBSD.org> and Warner Losh <imp@FreeBSD.org>
Documentation!
Reliable operation of the pcic driver (needs testing).
Recognizer and handler for sio.c (mostly done).
Recognizer and handler for ed.c (mostly done).
Recognizer and handler for ep.c (mostly done).
User-mode recognizer and handler (partially done).
Advanced Power Management. Coordinators: Michael Smith <msmith@FreeBSD.org> and Poul-Henning Kamp <phk@FreeBSD.org>
APM sub-driver (mostly done).
IDE/ATA disk sub-driver (partially done).
syscons/pcvt sub-driver.
Integration with the PCMCIA/PCCARD drivers (suspend/resume).
The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon:
The first N items are from Terry Lambert <terry@lambert.org>
NetWare Server (protected mode ODI driver) loader and sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers.
An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes.
Symmetric Multiprocessing with kernel preemption (requires kernel preemption).
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 v.s.. 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 bug fixes 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)
Suggest further tasks for this list!
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.
For questions about FreeBSD, e-mail
<questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.