RevisionControl

When you start out on a software project it is really important that you use some form of revision control for your code base. Even if you are the only developer on the project you will want to be able to roll back to previous versions of your software, and to tag releases for production. As your project grows you'll want to involve more people, perhaps from other organizations, and being able to offer them a code repository to interact with is key.

Some developers are tempted to only put a certain public version of the code in a public revision control system, but to have their own local deployed code be stored in a different place. Resist this temptation. Even if you don't think your actual code is generalizable enough for others, it's better to release the version you are actually using, so the community can help you MAKE it generalizable. Experience shows that 'forking' your code at this early stage will just lead to the 'public' version of your code becoming out of date and orphaned.

There are lots of choices about what sort of revision control system to use. The key decision you need to make is between centralized and decentralized repositories. Centralized revision control systems provide a single repository which people can check out, and check back in to. Decentralized repositories allow for more complex workflows where people branch your code into their own repository, and make them otherwise available to you and others as needed.

While there are lots of options for both flavors, Subversion and Git are currently the gold standard for centralized and decentralized revision control respectively. The good news is that if you would rather not run your own repository Google Code and GitHub provide free, rock-solid svn and git repositories, respectively, for any open source project that wants it.