+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>alpha releases</term>
+ <listitem>
+ <para>Alpha software is feature-complete but sometimes only
+ partially functional.</para>
+
+ <para>Alpha releases are expected to be unstable, perhaps a
+ little unsafe, but definitely usable. They
+ <emphasis>can</emphasis> have known bugs and kinks that have
+ yet to be worked out. Before releasing an alpha, be sure to
+ keep in mind that <emphasis>alpha releases are still
+ releases</emphasis> and people are not going to be expecting a
+ nightly build from the CVS source. An alpha should work and
+ have minimal testing and bug fixing already finished.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>beta releases</term>
+ <listitem>
+ <para>Beta software is feature-complete and functional, but is
+ in the testing cycle and still has a few bugs left to be
+ ironed out.</para>
+
+ <para>Beta releases are general expected to be usable and
+ slightly unstable, although definitely <emphasis>not
+ unsafe.</emphasis> Beta releases usually preclude a full
+ release by under a month. They can contain small known bugs
+ but no major ones. All major functionality should be fully
+ implemented although the exact mechanics can still be worked
+ out. Beta releases are great tool to whet the appetites of
+ potential users by giving them a very realistic view of where
+ your project is going to be in the very near future and can
+ help keep interest by giving people
+ <emphasis>something.</emphasis></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>development releases</term>
+ <listitem>
+ <para><quote>Development release</quote> is much a more vague
+ term than <quote>alpha</quote> or <quote>beta</quote>. I
+ usually choose to reserve the term for discussion of a
+ development branch although there are other ways to use the
+ term. So many in fact, that I feel the term has been
+ cheapened. The popular window manager <ulink
+ url="http://www.enlightenment.org">Enlightenment</ulink> has
+ released <emphasis>nothing but</emphasis> development
+ releases. Most often, the term is used to describe releases
+ that are not even alpha or beta and if I were to release a
+ pre-alpha version of a piece of software in order to keep
+ interest in my project alive, this is probably how I would
+ have to label it.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </para>
+ </sect3>
+ </sect2>
+
+<!-- Section2: announcing -->
+
+ <sect2 id="announcing">
+ <title>Announcing Your Project</title>
+
+ <para>
+ Well, you've done it. You've (at least for the purposes of this
+ HOWTO) designed, built, and released your free software
+ project. All that is left is for you to tell the world so they
+ know to come and try it out and hopefully jump on board with
+ development. If everything is in order as described above, this
+ will be a quick and painless process. A quick announcement is all
+ that it takes to put yourself on the free software community's
+ radar screen.
+ </para>
+
+ <sect3>
+ <title>Mailing lists and USENET</title>
+ <para>
+ Email is still the way that most people on the Internet get their
+ information. Its a good idea to send a message announcing your
+ program to any relevant mailing list you know of and any relevant
+ USENET discussion group. Karl Fogel recommends that use you
+ simple subject describing the fact that the message is an
+ announcement, the name of the program, the version, and a
+ half-line long description of its functionality. This way, any
+ interested user or developer will be immediately attracted to
+ your announcement. Fogel's example looks like:
+ </para>
+
+ <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
+
+ <para>
+ The rest of the email should describe the programs functionality
+ quickly and concisely in no more than two paragraphs and should
+ provide links to the projects webpage and direct links to
+ downloads for those that want to try it right away.
+ </para>
+
+ <para>
+ You should repeat this announcement process consistently in the
+ same locations for each subsequent release.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>freshmeat.net</title>
+ <para>
+ Mentioned earlier in <xref linkend="evalwhere">, in today's free
+ software community, announcements of your project on freshmeat
+ are almost more important than announcements on mailing lists.
+ </para>
+
+ <para>
+ Visit the <ulink url="http://freshmeat.net">freshmeat.net
+ website</ulink> or their <ulink
+ url="http://freshmeat.net/add-project/">submit project
+ page</ulink> to post your project onto their site and into their
+ database. In addition to a large website, freshmeat provides a
+ daily newsletter that highlights all the days releases and
+ reaches a huge audience (I personally skim it every night for any
+ interesting new releases).
+ </para>
+ </sect3>
+ </sect2>
+</sect1>
+
+ <bibliography>
+
+ <bibliodiv>
+ <title>Printed Books</title>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Fogel</surname>
+ <firstname>Karl</firstname>
+ </author>
+
+ <title>Open Source Development with CVS</title>
+
+ <publisher>
+ <publishername>Coriolois Open Press</publishername>
+ </publisher>
+ <pubdate>1999</pubdate>
+
+ <isbn>1-57610-490-7</isbn>
+
+ <abstract>
+ <para>
+ Fogel's <quote>guide to using CVS in the free software
+ world</quote> is much more than its subitle. In the publisher's
+ own words: <quote><emphasis>Open Source Development with
+ CVS</emphasis> is one of the first books available that teaches
+ you development and implementation of Open Source
+ software.</quote> It also includes the best reference and
+ tutorial to CVS I have ever seen. It is the book that was
+ <emphasis>so good</emphasis> 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry
+ <biblioset>
+ <author>
+ <surname>Lessig</surname>
+ <firstname>Lawrence</firstname>
+ </author>
+
+ <title>Code and Other Laws of Cyberspace</title>
+
+ <publisher>
+ <publishername>Basic Books</publishername>
+ </publisher>
+ <pubdate>2000</pubdate>
+
+ <isbn>0-465-03913-8</isbn>
+
+ <abstract>
+ <para>
+ 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 <quote>open code</quote> 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 <emphasis>need</emphasis>
+ free software in a way more powerfully than anything I've read
+ outside of <ulink
+ url="http://www.gnu.org/philosophy/right-to-read.html">RMS's
+ <quote>Right to Read.</quote></ulink>
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Raymond</surname>
+ <firstname>Eric</firstname>
+ </author>
+
+ <title>The Cathedral and the Bazaar</title>
+ <subtitle>Musings on Linux and Open Source by an Accidental Revolutionary</subtitle>
+
+ <publisher>
+ <publishername>O'Reilly</publishername>
+ </publisher>
+ <pubdate>1999</pubdate>
+
+ <isbn>1-56592-724-9</isbn>
+ <abstract>
+ <para>
+ 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Web-Accessable Resources</title>
+
+ <para>
+ This is a list of the web resources pertaining to this HOWTO that
+ I've found most helpful in compiling this information. If you know
+ of others that would help, please don't hesitate to email me at
+ <email>mako@debian.org</email> and we can look into getting it
+ added to the list and represented in the HOWTO.
+ </para>
+
+ <para>
+ I'd recommend that any free software developer (or potential one)
+ skim through these sites becaue they have each have a lot to say.
+ </para>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Manley</surname>
+ <firstname>Montey</firstname>
+ </author>
+
+ <title><ulink
+ url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
+ Projects the Open Source Way</ulink></title>
+
+ <publisher>
+ <publishername><ulink
+ url="http://www.linuxprogramming.com">Linux
+ Programming</ulink></publishername>
+ </publisher>
+ <pubdate>Oct 31, 2000</pubdate>
+
+ <abstract>
+ <para>
+ 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.
+ </para>
+
+ <para>
+ I have problems much of this piece and I recommend you read
+ <xref linkend="krawitz"> at the same time you read Monty's
+ article for a good critique.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Gabriel</surname>
+ <firstname>Richard</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
+ <quote>Worse is Better</quote></ulink></title>
+
+ <abstract>
+ <para>
+ 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ </bibliodiv>
+
+ <bibliodiv>
+ <title>Advogato Articles</title>
+
+ <para>
+ I've found that one of the best resources that any free software
+ developer has at his or her disposal is Advogato.org. If you haven't
+ yet had a chance to visit <ulink url="http://www.advogato.org">the
+ website</ulink>, do.
+ </para>
+
+ <para>
+ I have spent a huge amount of time on advogato and I've gone
+ through and provided links to the articles that I think might be
+ of particular interest to anyone reading this HOWTO. I think that
+ skimming through these links can be helfpul and I promise that if
+ you do, you'll learn a lot. You will learn that my idea of how a
+ free software project should be run is not the
+ <emphasis>only</emphasis> idea. I think that's important.
+ </para>
+
+ <para>
+ If nothing else, there is <emphasis>way</emphasis> more
+ information on that website than I could ever fit into, or
+ reference from this HOWTO. I have listed what I think are the most
+ relavant articles here with short descriptions that I've written.
+ </para>
+
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Hindle</surname>
+ <firstname>Stephen</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/262.html">'Best Practices' for Open Source?</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>March 21, 2001</pubdate>
+
+ <abstract>
+ <para>
+ Touching mostly on programming practice (as most articles on
+ the subject usually do), the article talks a little about
+ project managment (<quote>Use it!</quote>) and a bit about
+ communication within a free software project.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Cohen</surname>
+ <firstname>Bram</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/258.html"></ulink>How to
+ Write Maintainable Code</title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>March 15, 2001</pubdate>
+
+ <abstract>
+ <para>
+ 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+ <biblioentry id="krawitz">
+ <biblioset>
+ <author>
+ <surname>Krawitz</surname>
+ <firstname>Robert</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/196.html">Free
+ Source Project Management</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>November 4, 2000</pubdate>
+
+ <abstract>
+ <para>
+ This article made me happy because it challenged many of the
+ problems that I had with Monty's article on <ulink
+ url="http://www.linuxprogramming.com">LinuxProgramming</ulink>. 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Martins</surname>
+ <firstname>Lalo</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/128.html">Ask
+ the Advogatos: why do Free Software projects
+ fail?</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>July 20, 2000</pubdate>
+
+ <abstract>
+ <para>
+ 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Burley</surname>
+ <firstname>David</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/107.html">In-Roads to Free
+ Software Development</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>June 14, 2000</pubdate>
+
+ <abstract>
+ <para>
+ This document was written as a response to <ulink
+ url="http://www.advogato.org/article/72.html">another advogato
+ article</ulink>. 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).
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Moorman</surname>
+ <firstname>Jacob</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.advogato.org/article/72.html"></ulink>Importance
+ of Non-Developer Supporters in Free Software</title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>April 16, 2000</pubdate>
+
+ <abstract>
+ <para>
+ 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.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Orchard</surname>
+ <firstname>Leslie</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/67.html">On
+ Naming an Open Source Project</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>April 12, 2000</pubdate>
+
+ <abstract>
+ <para>
+ I didn't even have a section on project naming in this HOWTO
+ (See <xref linkend="naming">) until Leslie Orchard's article
+ reminded me of it. Thanks to Leslie for writing this article!
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Allen</surname>
+ <firstname>David</firstname>
+ </author>
+
+ <title><ulink url="http://www.advogato.org/article/40.html">Version Numbering Madness</ulink></title>
+
+ <publisher>
+ <publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
+ </publisher>
+ <pubdate>Februrary 28, 2000</pubdate>
+
+ <abstract>
+ <para>
+ In this article, David Allen challengs the whole
+ <quote>Major.Minor.Patch</quote> version numbering scheme. Its
+ good to read this as you read <xref
+ linkend="chooseversioning">. I liked the article and it
+ describes some of the projects that I bring up in my discussion
+ of verion numbering.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
projects / fspm_howto / blobdiff