Fogel's "guide to using CVS in the free software world" is much more than its subtitle. 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 lawyer 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.

Since the paper includes its own abstract, I thought I would include it here verbatim:

This paper examines the latest of paradigms - the Virtual Network(ed) Organisation - and whether geographically dispersed knowledge workers can virtually collaborate for a project under no central planning. Co-ordination, management and the role of knowledge arise as the central areas of focus. The Linux Project and its development model are selected as a case of analysis and the critical success factors of this organisational design are identified. The study proceeds to the formulation of a framework that can be applied to all kinds of virtual decentralised work and concludes that value creation is maximized when there is intense interaction and uninhibited sharing of information between the organisation and the surrounding community. Therefore, the potential success or failure of this organisational paradigm depends on the degree of dedication and involvement by the surrounding community.

This paper was referred to me in my capacity as author of this HOWTO and I was very impressed. It's written by a graduate student in management and I think it succeeds at evaluating the Linux project as an example of a new paradigm in management--one that you will be be placing yourself at the center of in your capacity as maintainer of a free software project.

As a developer trying to control an application and guide it to success in the free software world, I'm not sure how useful Dafermos's argument is. It does however, provide a theoretical justification for my HOWTO--free software project management is a different creature than proprietary software project management. If you are interested in the conceptual and theoretical ways that free software project management differs from other types of management, this is a great paper to read. If this paper answers questions of "how?", Dafermos answers the (more difficult to defend) questions of "why?" and does a very good job.

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.

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, documentation, organizing a team and leadership, and several other topics. While more opinionated 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.

At first glance, ESR's release practice HOWTO seems to share a lot of terrain with this document. Upon closer examination, the differences become apparent but they are closely related. His document, read in conjunction with mine, will give a reader a good picture of how to go about managing a project. ESR's HOWTO goes into a bit more detail on how to write and what languages to write in. He tends to give more specific instructions and checklists ("name this file this, not this") while this HOWTO speaks more conceptually. There are several sections that are extremely similar. It's also much shorter.

My favorite quote from his HOWTO is: ""Managing a project well when all the participants are volunteers presents some unique challenges. This is too large a topic to cover in a HOWTO." Oh really? Perhaps I just do a poor job.

Venugopalan provides one of the best essays on effective use of CVS that I've come across. It is written for people who already have a good knowledge of CVS. In the chapter on branching, he describes when and how to branch but gives no information on what CVS commands you should use to do this. This is fine (technical CVS HOWTO have been written) but CVS newbies will want to spend some time with Fogel's reference before they will find this one very useful.

Venugopalan creates checklists of things to do before, after, and around releases. It's definitely worth a read through as most of his ideas will save tons of developer head aches over any longer period of time.

Touching mostly on programming practice (as most articles on the subject usually do), the article talks a little about project management ("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 challenges 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 version numbering.