Debian Lessons
Project management lessons from the Debian project.
23 July 2000
This text lists the important things I think the Debian development community has learned about project management in the course of developing the Debian GNU/Linux system. These are my personal opinions, not those of the project or other developers. I hope this list will be useful to Debian, other Linux distributions, and other free software projects.
Thanks to the people on Debian's IRC channel for feedback since the first private drafts. Thanks to Mark Brown for pointing out IRC versus mailing list for communication between developers.
Make sure things scale up. Problems are always simpler when the project is small. When the number of developers and packages grows a lot, small problems become big problems.
Make things distributed so that things can be worked on in parallel.
Make sure the foundation is good. Debian has a pretty good package management system (even though it has lots of minor flaws and warts). This makes it much easier to build the system, when one can concentrate on making packages better, instead of having to fight the base system.
Document important things. When people need to work together, they need to know how to take each other in consideration. There needs to be rules about how packages are laid out so that they don't interfere with each other. If these rules aren't written down, they need to be remembered by the community memory and word of mouth, both of which are unreliable. The Debian Policy documents are a fine example of this. Debian couldn't live without it.
(Note that when documenting things it's important to document the reasons behind the decisions as well. Debian Policy documents don't do this well enough, though, at the moment.)
Automate repetitive tasks when possible. Repetitive tasks should be automated, especially if they are tricky or critical. This reduces the number of human errors, and also frees up developers to more important tasks.
Debian examples include dinstall (moves uploaded packages into the ftp server), lintian (checks for many errors that are easy to make), and the various autocompiling projects for porting efforts. They're all absolutely necessary for Debian for maintaining high levels of quality.
Avoid single points of failure, especially for volunteers. Volunteers will always lack time at the critical point. For critical jobs, have several people share the workload and make sure there are mechanisms for checking that things are going smoothly.
Do not worry about time tables; keep goals realistic. In big volunteer projects, time tables will always slip. That is not a catastrophy, and it must be tolerated, but there should still be some effort in keeping them. Goals must be kept realistic.
Make it easy to work independently. The more interdependencies things have, the more communication is needed (read: less time spent on productive hacking) and the bigger the chance that a single developer or package will cause big problems.
Do not overload developers. Developers are volunteers with too little free time. Make as few requirements on their time as possible. For example, do not require that they follow high-volume mailing lists. Overloaded developers have a tendency to disappear, or at least their packages will be of lower quality or less up-to-date than they might be. Also do not let developers overload themselves by trying to do too much, and make it easy (culturally and technically) to give up packages, when the workload gets too high.
Be open and keep things in public. If you're popular, your users will want to know what is going on. Do not decide things behind closed doors. Allow everyone to read the discussions leading to decisions and, preferably, allow everyone to participate in them, even if they aren't developers. Developers may need a private forum as well, but it should be used as little as possible. By doing things in private, you are hiding your motives and other people will be assuming the worst and react accordingly.
This applies within the project and between developers or groups of developers as well. When things are decided that affect more developers than those involved in a particular discussion, the discussion must be held in a forum that all developers can participate it. For example, IRC is not good enough, since not everyone will be present at any given time. It's OK to start a discussion on IRC, but before any decisions are made, it should be taken to, say, a mailing list.
Make it easy to contribute. There's never too many developers, so make it natural and easy for people to join in and help with what they can, even if it is just reporting bugs. Debian has recruited several hundred developers this way, and manages to have thousands of packages. Many developers only have one package, but it tends to be one they need themselves, so they're motivated to keep it working.
Have leadership. There must be some way to solve conflicts and arguments, if a natural consensus doesn't occur. Different projects may need different kinds of leadership, but there has to be some way, formal or informal.
Conflicts are natural, but mustn't get out of hand. Developers are often opinionated, strong-minded, and bullheaded. You can't avoid that. They must be allowed to scream at each other every now and then, but fights must not be allowed to escalate. Everyone in the project will have to be responsible for mediating between disagreeing parties, if they can't come to a consensus by themselves. Unfinished fights will easily haunt the project.
Developers do not have to like each other, but they do have to get along.
Use a bug tracking system. An open bug tracking system makes it harder for bugs to be forgotten when developers are too busy, or leave the project, or lose their disks. It also lets people see whether they want to use a package before installing it, and to find solutions or workarounds for bugs that are already known but not yet fixed.