<HTML
><HEAD
><TITLE
>Bibliography</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Free Software Project Management HOWTO"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Maintaining a Project: Interacting with Users"
HREF="users.html"><LINK
REL="NEXT"
TITLE="GNU Free Documentation License"
HREF="fdl.html"></HEAD
><BODY
CLASS="BIBLIOGRAPHY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Free Software Project Management HOWTO</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="users.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="fdl.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><A
NAME="AEN811"
></A
><H1
><A
NAME="AEN811">Bibliography</H1
><H2
CLASS="BIBLIODIV"
><A
NAME="AEN812">Printed Books</H2
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN814"
></A
><P
><SPAN
CLASS="AUTHOR"
>Karl Fogel</SPAN
>, <I
>Open Source Development with CVS</I
>, Coriolois Open Press, 1999, 1-57610-490-7.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> Fogel's <SPAN
CLASS="QUOTE"
>"guide to using CVS in the free software
world"</SPAN
> is much more than its subtitle. In the publisher's
own words: <SPAN
CLASS="QUOTE"
>"<EM
>Open Source Development with
CVS</EM
> is one of the first books available that teaches
you development and implementation of Open Source
software."</SPAN
> It also includes the best reference and
tutorial to CVS I have ever seen. It is the book that was
<EM
>so good</EM
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN830"
></A
><P
><SPAN
CLASS="AUTHOR"
>Lawrence Lessig</SPAN
>, <I
>Code and Other Laws of Cyberspace</I
>, Basic Books, 2000, 0-465-03913-8.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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 <SPAN
CLASS="QUOTE"
>"open code"</SPAN
> 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 <EM
>need</EM
>
free software in a way more powerfully than anything I've read
outside of <A
HREF="http://www.gnu.org/philosophy/right-to-read.html"
TARGET="_top"
>RMS's
<SPAN
CLASS="QUOTE"
>"Right to Read."</SPAN
></A
>
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN846"
></A
><P
><SPAN
CLASS="AUTHOR"
>Eric Raymond</SPAN
>, <I
>The Cathedral and the Bazaar</I
><I
>: </I
><I
>Musings on Linux and Open Source by an Accidental Revolutionary</I
>, O'Reilly, 1999, 1-56592-724-9.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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.
</P
></DIV
></DIV
></DIV
><H2
CLASS="BIBLIODIV"
><A
NAME="AEN859">Web-Accessible Resources</H2
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN864"
></A
><P
><SPAN
CLASS="AUTHOR"
>George N Dafermos</SPAN
>, <I
><A
HREF="http://firstmonday.org/issues/issue6_11/dafermos/"
TARGET="_top"
>Management and Virtual Decentralized Networks: The Linux Project</A
></I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
>Since the paper includes its own abstract, I thought I
would include it here verbatim:</P
><P
><A
NAME="AEN875"><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
>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.</P
></BLOCKQUOTE
></P
><P
>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 <EM
>you</EM
> will be be placing yourself at the
center of in your capacity as maintainer of a free software
project.</P
><P
>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 <EM
>is</EM
> 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
<SPAN
CLASS="QUOTE"
>"how?"</SPAN
>, Dafermos answers the (more difficult to
defend) questions of <SPAN
CLASS="QUOTE"
>"why?"</SPAN
> and does a very good
job.</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN883"
></A
><P
><SPAN
CLASS="AUTHOR"
>Richard Gabriel</SPAN
>, <I
><A
HREF="http://www.jwz.org/doc/worse-is-better.html"
TARGET="_top"
>The Rise of
<SPAN
CLASS="QUOTE"
>"Worse is Better"</SPAN
></A
></I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN893"
></A
><P
><SPAN
CLASS="AUTHOR"
>Montey Manley</SPAN
>, <I
><A
HREF="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD"
TARGET="_top"
>Managing
Projects the Open Source Way</A
></I
>, <A
HREF="http://www.linuxprogramming.com"
TARGET="_top"
>Linux
Programming</A
>, Oct 31, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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.
</P
><P
> I have problems much of this piece and I recommend you read
<A
HREF="b811.html#KRAWITZ"
>[KRAWITZ]</A
> at the same time you read Monty's
article for a good critique.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="ESRHOWTO"
></A
><P
><SPAN
CLASS="AUTHOR"
>Eric Steven Raymond</SPAN
>, <I
><A
HREF="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html"
TARGET="_top"
>Software Release Practice HOWTO</A
></I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
>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 (<SPAN
CLASS="QUOTE"
>"name this file this, not
this"</SPAN
>) while this HOWTO speaks more conceptually. There
are several sections that are extremely similar. It's also
<EM
>much</EM
> shorter.</P
><P
>My favorite quote from his HOWTO is: <SPAN
CLASS="QUOTE"
>""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."</SPAN
> Oh really? Perhaps I just do a poor job.</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="CVSBESTPRACTICES"
></A
><P
><SPAN
CLASS="AUTHOR"
>Vivek Venugopalan</SPAN
>, <I
><A
HREF="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html"
TARGET="_top"
>CVS Best Practices</A
></I
>.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
>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.</P
><P
>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.</P
></DIV
></DIV
></DIV
><H2
CLASS="BIBLIODIV"
><A
NAME="AEN932">Advogato Articles</H2
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN940"
></A
><P
><SPAN
CLASS="AUTHOR"
>Stephen Hindle</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/262.html"
TARGET="_top"
>'Best Practices' for Open Source?</A
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, March 21, 2001.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> Touching mostly on programming practice (as most articles on
the subject usually do), the article talks a little about
project management (<SPAN
CLASS="QUOTE"
>"Use it!"</SPAN
>) and a bit about
communication within a free software project.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN954"
></A
><P
><SPAN
CLASS="AUTHOR"
>Bram Cohen</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/258.html"
TARGET="_top"
>http://www.advogato.org/article/258.html</A
>How to
Write Maintainable Code</I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, March 15, 2001.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="KRAWITZ"
></A
><P
><SPAN
CLASS="AUTHOR"
>Robert Krawitz</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/196.html"
TARGET="_top"
>Free
Source Project Management</A
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, November 4, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> This article made me happy because it challenged many of the
problems that I had with Monty's article on <A
HREF="http://www.linuxprogramming.com"
TARGET="_top"
>LinuxProgramming</A
>. 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN981"
></A
><P
><SPAN
CLASS="AUTHOR"
>Lalo Martins</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/128.html"
TARGET="_top"
>Ask
the Advogatos: why do Free Software projects
fail?</A
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, July 20, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN994"
></A
><P
><SPAN
CLASS="AUTHOR"
>David Burley</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/107.html"
TARGET="_top"
>In-Roads to Free
Software Development</A
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, June 14, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> This document was written as a response to <A
HREF="http://www.advogato.org/article/72.html"
TARGET="_top"
>another Advogato
article</A
>. 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).
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN1008"
></A
><P
><SPAN
CLASS="AUTHOR"
>Jacob Moorman</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/72.html"
TARGET="_top"
>Importance of
Non-Developer Supporters in Free Software</A
></I
>, <I
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, April 16, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> 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.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN1022"
></A
><P
><SPAN
CLASS="AUTHOR"
>Leslie Orchard</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/67.html"
TARGET="_top"
>On
Naming an Open Source Project</A
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, April 12, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> I didn't even have a section on project naming in this HOWTO
(See <A
HREF="starting.html#NAMING"
>Section 2.2</A
>) until Leslie Orchard's article
reminded me of it. Thanks to Leslie for writing this article!
</P
></DIV
></DIV
></DIV
><DIV
CLASS="BIBLIOENTRY"
><A
NAME="AEN1036"
></A
><P
><SPAN
CLASS="AUTHOR"
>David Allen</SPAN
>, <I
><A
HREF="http://www.advogato.org/article/40.html"
TARGET="_top"
>Version Numbering Madness</A
></I
>, <A
HREF="http://www.advogato.org"
TARGET="_top"
>Advogato</A
>, February 28, 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
><DIV
CLASS="ABSTRACT"
><P
> In this article, David Allen challenges the whole
<SPAN
CLASS="QUOTE"
>"Major.Minor.Patch"</SPAN
> version numbering scheme. Its
good to read this as you read <A
HREF="starting.html#CHOOSEVERSIONING"
>Section 2.4</A
>. I liked the article and it
describes some of the projects that I bring up in my discussion
of version numbering.
</P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="users.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="fdl.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Maintaining a Project: Interacting with Users</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>GNU Free Documentation License</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
