SCons is actively looking for contributors. You can contribute to the code of SCons itself, the documentation, the examples/ cookbook, and more. If you're interested, we'd love to hear from you at

It's only fair that you get an idea of how we develop SCons before deciding if you'd like to help. There is a complete and evolving set of Developer's Guidelines that go into reasonable detail about how we're guaranteeing that SCons is always an exceptionally stable and reliable tool for building software. Here are two key points:

  • We write a lot of automated tests to test thoroughly test SCons. Lines of test code currently outnumber lines of code in SCons itself by about 3:1.
  • You can use git (via github) as a front end for submitting patches.

Please take a look at the complete guidelines before deciding to hop on board.

That said, here are resources for SCons developers (or onlookers):

Developer's Guidelines

The complete statement of guiding principles and procedures for SCons development. Subject to change and improvement.

Project Page

The SCons project page at GitHub. This is the center of active SCons development, hosting the issue tracker (bugs, patches, tasks, etc.).

Old Project Page

The SCons project page at SourceForge. This is where we used to host development, but no longer. It's now mostly of historic interest, although it's also the origination site for downloads.

.tar.gz or .zip

Archive of the latest checked-in source in a couple of formats. Updated whenever a an SCons release is made. (Note that the source tree in these archives is mostly for packaging and testing of SCons; consult the README file for information about how to build packages and how to run SCons from the source tree. It's no longer handled by executing python directly from this package.)

Latest API documentation

A set of HTML pages documenting the API of the latest SCons release. These are generated by sphinx from the SCons source code and docstrings.

The API docs are an internal resource, helpful for developing SCons. The distinction between "public API", which comes with consistency guarantees, and "internal API", which does not, is not necessarily clear from these docs; the public API is what appears in the manpage. There's also kind of an intermediate API: methods which might need to be tapped into by developers writing components to work with SCons, like new tools, builders, scanners, etc. The docstrings for internal classes and methods isn't really written consistently, or to a consistent style, and improvements here, even piecemeal, would be a nice addition to the project. If you want to help with this, drop a line to the mailing list, IRC channel, or Discord server - it's preferred to talk about it first before moving on to filing a bug report, or a Pull Request.

GitHub Repository

Our browsable GitHub repository is a primary resource. The master branch contains the most-current development, but some long-term development is carried out on subsidiary branches. Anyone may clone the main repository from github. See the Branching and Merging page in our wiki for a description of the different branches and how we handle branch management. There are also related SCons projects a level up as well - look in - each of these is its own repository and has its own issue tracker, PRs, etc.

SCons Buildbot

The SCons Buildbot, which runs the entire SCons test suite on multiple systems after every checkin. The SCons Buildbot is hosted by Bad Dog Consulting.