This page discusses the tools required for a distributed software development project, in particular open source development.


We prefer SubVersion over CVS.

Mailing lists

We recomment several mailing lists:


This list gets an email generated by your version control software automatically on every commit. It should contain at least who did the commit, when the commit was done, what branch it was done to, and their log message. Also containing a unified diff is also very useful.


This list should be used to announce new versions of your software.


For helping users of your software


for discussion and development.


Some tool to run tests against your software regularly and systematically. This should be running 24/7 (or on commit if your commit rate is low). This should check out the software and make sure it compiles with several different environments. It should run tests to make sure that a recent commit did not break any functionality. Before fixing a bug, you should add a new test to demonstrate the bug, this way you know if the bug is solved, and you can easily catch regressions. One of your tests should also track resource usage such as memory, diskspace, build time, and cpu time. This can be graphed against commits so you can easily see which commits have large impacts on resource usage. When the build is "broken" (ie a test fails), your software should be able to generate an email to devel@ above, and list all the commits that have occurred between the last time that test succeeded. This allows you to easily narrow down which patch broke the build.

Your build environment can also generate "nightly" builds for people to test for various platforms and archectures.

Bugtracking system

We recommend some kind of bugtracking system. All bugs (even RFE's) should have a test case which can be added to the build system above. Commit messages that contain the line "Closes: #number" should close the resulting bug in the bugtracking system.


Some webpage to view your code and be able to browse it effectively.


Doxygen can generate documentation from your source. Ideally this would be updated from cron(8) regularly, or generated on commit by your version control software.


Some content management system for posting news, screenshots etc.


Some tool to lint your source looking for problems. Maybe splint?