Fogel's "guide to using CVS in the free software world" is much more than its subitle. In the publisher's own words: "Open Source Development with CVS is one of the first books available that teaches you development and implementation of Open Source software." It also includes the best reference and tutorial to CVS I have ever seen. It is the book that was so good that it prompted me to write this HOWTO because I thought the role it tried to serve was so important and useful. Please check it or buy it if you can and are seriously interested in running a free software project.

While it only briefly talks about free software (and does it by tiptoeing around the free software/open source issue with the spineless use of the term "open code" that only a laywer could coin), Lessig's book is brilliant. Written by a lawyer, it talks about how regulation on the Internet is not done with law, but with the code itself and how the nature of the code will determine the nature of future freedoms. In addition to being a quick and enjoyable read, it gives some cool history and describes how we need free software in a way more powerfully than anything I've read outside of RMS's "Right to Read."

Although I have to honestly say that I am not the ESR fan that I used to be, this book proved invaluable in getting me where I am today. The essay that gives the book its title does a good job of sketching the free software process and does an an amazing job of making an argument for free software/open source development as a road to better software. The rest of the book has other of ESR's articles, which for the most part are posted on his website. Still, it's nice thing to own in hard copy and something that every free software/open source hacker should read.

In one of the better articles on the subject that I've read, Monty sums up some of the major points I touch on including: starting a project, testing, documenation, organizing a team and leadership, and several other topics. While more opiniated that I try to be, I think its an important article that I found very helpful in writing this HOWTO. I've tried to cite him in the places where I borrowed from him most.

I have problems much of this piece and I recommend you read [KRAWITZ] at the same time you read Monty's article for a good critique.

A well written article although I think the title may have confused as many people as the rest of the essay helped. It offers a good description of how to design programs that will succeed and stay maintainable as they grow.

Touching mostly on programming practice (as most articles on the subject usually do), the article talks a little about project managment ("Use it!") and a bit about communication within a free software project.

This article touches upon the "writing maintainable code" discussion that I try hard to avoid in my HOWTO. It's one of the better (and most diplomatic) articles on the subject that I've found.

This article made me happy because it challenged many of the problems that I had with Monty's article on LinuxProgramming. The author argues that Monty calls simply for the application of old (proprietary software) project management techniques in free software projects instead of working to come up with something new. I found his article to be extremely well thought out and I think it's an essential read for any free software project manager.

While the article is little more than a question, reading the answers to this question offered by advogato's readers can help. In a lot of ways, this HOWTO acts as my answer to the questions posed in this article but there are others, many of which might take issue with whats is in this HOWTO. It's worth checking out.

This document was written as a response to another advogato article. Although not about running a project, this describes some of the ways that you can get started with free software development without starting a project. I think this is an important article. If you are interested in becoming involved with free software, this article showcases some of the ways that you can do this without actually starting a project (something that I hope this HOWTO has demonstrated is not to be taken lightly).

Moorman's is a short article but it brings up some good points. The comment reminding developers to thank their testers and end-users is invaluable and oft-forgotten.

I didn't even have a section on project naming in this HOWTO (See Section 2.2) until Leslie Orchard's article reminded me of it. Thanks to Leslie for writing this article!

In this article, David Allen challengs the whole "Major.Minor.Patch" version numbering scheme. Its good to read this as you read Section 2.4. I liked the article and it describes some of the projects that I bring up in my discussion of verion numbering.