<revhistory>
<revision>
<revnumber>v0.01</revnumber>
- <date>25 March 2001</date>
+ <date>27 March 2001</date>
<authorinitials>bch</authorinitials>
<revremark>
Initial Release
This HOWTO is designed for people with experience in programming
and some skills in managing a software project but who are new to
the world of Free Software. This document is meant to act as a
- guide to the non-technical aspects of programming and was written
- to act as a crash course in the people skills that aren't taught
- to commercial coders but that can make or break a free software
- project.
+ guide to the non-technical aspects of free software development
+ and was written to act as a crash course in the people skills
+ that aren't taught to commercial coders but that can make or
+ break a free software project.
</para>
</abstract>
<primary>fswd!introduction</primary>
</indexterm>
- <para>
- For various reasons, this release has been code-named the
- <emphasis>homemade yogurt</emphasis> release.
- </para>
-
- <para>
- New code names will appear as per industry standard
- guidelines to emphasize the state-of-the-art-ness of this
- document.
- </para>
-
<para>
Skimming through freshmeat.net provides mountains of reasons for this
HOWTO's existence--the Internet is littered with excellently
This HOWTO tries to do a lot of thing (probably too many), but it
can't answer that question and won't attempt it. What this HOWTO
will attempt to do is give your Free Software project a fighting
- chance-an edge. If you write a piece of crap that no one is
- interested in, you can read this HOWTO until you recite it in your
- sleep and your project will probably fail. Then again, you can
+ chance--an edge. If you write a piece of crap that no one is
+ interested in, you can read this HOWTO until you can recite it in
+ your sleep and your project will probably fail. Then again, you can
write a beautiful, relevant piece of software and follow every
instruction in this HOWTO and your software may still not make
it. Sometimes life is like that. However, I'll go out a limb and
A lot of the information in this HOWTO is best called common
sense. Of course, as any debate on interfaces will prove, what is
common sense to some programmers proves totally unintuitive to
- others. After explaining bites and pieces of this HOWTO to Free
- Software developers on several occasions, I realized that that
- writing this HOWTO might provide a useful resource and a forum for
+ others. After explaining bits and pieces of this HOWTO to Free
+ Software developers on several occasions, I realized that writing
+ this HOWTO might provide a useful resource and a forum for
programmers to share ideas about what has and has not worked for
- them.
- </para>
-
- <para>
-
+ them.
</para>
<para>
</para>
<para>
- Unless otherwise stated, Linux HOWTO documents are
- copyrighted by their respective authors. Linux HOWTO documents may
- be reproduced and distributed in whole or in part, in any medium
- physical or electronic, as long as this copyright notice is
- retained on all copies. Commercial redistribution is allowed and
- encouraged; however, the author would like to be notified of any
- such distributions.
+ Unless otherwise stated, Linux HOWTO documents are copyrighted by
+ their respective authors. Linux HOWTO documents may be reproduced
+ and distributed in whole or in part, in any medium physical or
+ electronic, as long as this copyright notice is retained on all
+ copies. Commercial redistribution is allowed and encouraged;
+ however, the author would like to be notified of any such
+ distributions.
</para>
<para>
</para>
<para>
- In short, we wish to promote dissemination of this
- information through as many channels as possible. However, we do
- wish to retain copyright on the HOWTO documents, and would like to
- be notified of any plans to redistribute the HOWTOs.
+ In short, we wish to promote dissemination of this information
+ through as many channels as possible. However, we do wish to
+ retain copyright on the HOWTO documents, and would like to be
+ notified of any plans to redistribute the HOWTOs.
</para>
<para>
- If you have any questions, please contact
+ If you have any questions, please contact
<email>linux-howto@metalab.unc.edu</email>
</para>
</sect2>
<para>
No liability for the contents of this documents can be accepted.
- Use the concepts, examples and other content at your own risk.
- As this is a new edition of this document, there may be errors
- and inaccuracies, that may of course be damaging to your system.
- Proceed with caution, and although this is highly unlikely,
- the author(s) do not take any responsibility for that.
+ Use the concepts, examples and other content at your own risk. As
+ this is a new edition of this document, there may be errors and
+ inaccuracies, that may of course be damaging to your system.
+ Proceed with caution, and although this is highly unlikely, the
+ author(s) do not take any responsibility for that.
</para>
<para>
<title>New Versions</title>
<indexterm>
- <primary>(your index root)!news on</primary>
+ <primary>fswd!news on</primary>
</indexterm>
<para>
<para>
<itemizedlist>
+
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.html">HTML</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO/t1.html">HTML</ulink>.
</para>
</listitem>
+
<listitem>
<para>
- <ulink URL="http://people.debian.org/~mako/howto/fswd-howto.txt">plain text</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.html">HTML (single page)</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.US.ps.gz">compressed
- postscript (US letter format)</ulink>.
+ <ulink URL="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.txt">plain text</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.UF.ps.gz">compressed
- postscript (Universal format / 8.27x11in; 210x279mm)</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.ps.gz">compressed postscript</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://people.debian.org/~mako/howto/fswd-howto.sgml">SGML source</ulink>.
+ <ulink url="http://people.debian.org/~mako/projects/howto/FreeSoftwareDevelopment-HOWTO.sgml.gz">Compressed SGML source</ulink>.
</para>
</listitem>
</itemizedlist>
<para>
<emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
Source Development with CVS</emphasis> published by the Coriolis
- Open Press. Large parts of
the book are available <ulink
+ Open Press. Large parts of
his book are available <ulink
url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
the book are available under the GPL and constitute the best
- tutorial on CVS I have ever seen. The rest of the book covers,
- "the challenges and philosophical issues inherent in running an
- Open Source project using CVS." The book does a good job of
- covering some of the subjects brought up in this HOWTO and much
+ tutorial on CVS I've ever seen. The rest of the book covers, "the
+ challenges and philosophical issues inherent in running an Open
+ Source project using CVS." The book does a good job of covering
+ some of the subjects brought up in this HOWTO and much
more. <ulink url="http://cvsbook.red-bean.com">The book's
website</ulink> has information on ordering the book and provides
several translations of the chapters on CVS. I you are seriously
- interested in running a Free Software project, you want this book.
+ interested in running a Free Software project, you want this
+ book. I tried to mention Fogel in sections of this HOWTO where I
+ knew I was borrowing directly from his ideas. If I missed any, I'm
+ sorry, and I'll try and have those fixed in future versions.
</para>
<para>
Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
com</email>
</para>
+
<para>
- Also providing support and material, and inspiration for this
- HOWTO is Eric S. Raymond for his prolific, consistent, and
- carefully crafted arguments, to Lawrence Lessig for reminding me
- of the importance of Free Software and to every user and developer
- involved with the <ulink url="http://www.debian.org">Debian
- Project</ulink>. The project has provided me with a home, a place
- to practice Free Software advocacy and to make a difference, a
- place to learn from those how have been involved with the movement
- much longer than I, and an proof of a Free Software project that
- <emphasis>definitely, definitely works</emphasis>.
+ Also providing support material, and inspiration for this HOWTO is
+ Eric S. Raymond for his prolific, consistent, and carefully
+ crafted arguments, Lawrence Lessig for reminding me of the
+ importance of Free Software. Additionaly, I want to thank every
+ user and developer involved with the <ulink
+ url="http://www.debian.org">Debian Project</ulink>. The project
+ has provided me with a home, a place to practice Free Software
+ advocacy, a place to make a difference, a place to learn from
+ those how have been involved with the movement much longer than I,
+ and proof of a Free Software project that definitely, definitely
+ works.
</para>
<para>
Above all, I want to thank <emphasis>Richard Stallman</emphasis>
for his work at the Free Software Foundation and for never giving
- up. Stallman provided the philosophical basis that attracts me to
- Free Software and that drives me towards writing a document to
- make sure it succeeds. RMS can always be emailed at <email>rms
- (at) gnu (dot) org</email>.
+ up. Stallman provides and articulates the philosophical basis that
+ attracts me to Free Software and that drives me towards writing a
+ document to make sure it succeeds. RMS can always be emailed at
+ <email>rms (at) gnu (dot) org</email>.
</para>
</sect2>
<title>Feedback</title>
<para>
- Feedback is most certainly welcome for this document. Without your
- submissions and input, this document wouldn't exist. Something
- missing? Don't hesitate to contact me and to write a chapter. I
- want this document to be as much a product of the Free Software
- development process that it heralds and I think its ultimate
- success will be rooted in this fact. Please send your additions,
- comments and criticisms to the following email address :
- <email>mako@debian. org</email>.
+ Feedback is always and most certainly welcome for this
+ document. Without your submissions and input, this document
+ wouldn't exist. Do you feel that something is missing? Don't
+ hesitate to contact me to have me write a chapter, section, or
+ subsection or to write one yourself. I want this document to be a
+ product of the Free Software development process that it heralds
+ and I believe that its ultimate success will be rooted in this
+ fact. Please send your additions, comments and criticisms to the
+ following email address : <email>mako@debian. org</email>.
</para>
</sect2>
I'd love for this HOWTO to gain the kind of international reach
afforded by a translated version.
</para>
+
<para>
However, this HOWTO is still young and I have to yet to be
- contacted about a translation so English is all that is
+ contacted about a translation so English is all that is currently
available. If you would like to help with or do a translation, you
will gain my utmost respect and admiration and you'll get to be
part of a cool process. If you are at all interested, please don't
<primary>fswd!starting</primary>
</indexterm>
<para>
- With very little argument, starting a project is most difficult
- part of successful free software development. Laying a firm
- foundation for your project will determine whether your project
- flourishes or withers away and dies. It is also the subject that is
- of most immediate interest to anyone reading this document as a
- tutorial.
+ With very little argument, the beginning is most difficult part of
+ successful free software development. Laying a firm foundation will
+ determine whether your project flourishes or withers away and
+ dies. It is also the subject that is of most immediate interest to
+ anyone reading this document as a tutorial.
</para>
<para>
- Starting a project also involves a dilemma that you as a developer
- must try and deal with. No potential user for your program will be
- interested by a program that doesn't work. Simultaneously, the
- development process that you want to employ holds involvement of
- users as essential to the process of the development that will
- realize this working software.
+ Starting a project involves a dilemma that you as a developer must
+ try and deal with: No potential user for your program is interested
+ in a program that doesn't work. Simultaneously, the development
+ process that you want to employ holds involvement of users as
+ prerequisit to working software.
</para>
<para>
It is in these dangerous initial moments that anyone working to
- start a free software project must strike a balance. One of the
- most important ways that someone trying to start a project can work
- towards this balance is by establishing a framework for the
- development process through some of the ways mentioned in this
- section.
+ start a free software project must try and strike a balance along
+ these lines. One of the most important ways that someone trying to
+ start a project can work towards this balance is by establishing a
+ solid framework for the development process through some of the
+ suggestions mentioned in this section.
</para>
<para>
If you are reading this document, there's a good chance you
already have an idea for a project in mind. Chances are pretty
- good, it fills a gap by doing something that no other free
- software process does or or does it in a way that is unique
- enough to necessitate a separate project.
+ good, it fills in a percieved gap by doing something that no other
+ free software process does or by doing something in a way the is
+ unique enough to necessitate a separate project.
</para>
<sect3 id=identifyidea>
<title>Identify and articulate your idea</title>
<para>
Eric S. Raymond writes about how free software projects start in
- his paper, "The Cathedral and the Bazaar" which comes as required
- reading for any free software development. You can find it <ulink
+ his paper, <quote>The Cathedral and the Bazaar,</quote> which
+ comes as required reading for any free software development. It
+ is available <ulink
url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
</ulink>.
</para>
<para>
- In "The Cathedral and Bazaar," Raymond tells us that:
- <emphasis>Every good work of software starts by scratching a
- developers itch.</emphasis> Raymond now widely accepted
+ In <quote>The Cathedral and the Bazaar,</quote> Raymond tells us
+ that: <emphasis>Every good work of software starts by scratching
+ a developers itch.</emphasis> Raymond's now widely accepted
hypothesis is that new free software programs are written, first
and foremost, to solve a specific problem facing the developer.
</para>
<para>
If you have an idea for a program in mind, chances are good that
- it it is targeting a specific problem or itch you want to see
- scratched. <emphasis>This idea is the project. Articulate it
+ it targets a specific problem or <quote>itch</quote> you want to
+ see scratched. This idea is the project. Articulate it
clearly. Write it out. Describe the problem you will attack in
detail. The success of your project in tackling a particular
problem will be tied to your ability to identify that problem
early on. Find out exactly what it is that you want your project
- to do.</emphasis>
+ to do.
</para>
</sect3>
<title>Evaluate your idea</title>
<para>
- In evaluating your idea, you need to ask yourself questions.
- Before you move any further into this HOWTO, you need to
- determine if the free software development model really is the
+ In evaluating your idea, you need to first ask yourself a few
+ questions. Before you move any further into this HOWTO, you need
+ to determine if the free software development model really is the
right one for your project. Obviously, since the program
scratches your itch, you are definitely interested in seeing it
- implemented in code. But, because one hacker coding alone fails
- to qualify as a free software development effort, you need to ask
- yourself the question: <emphasis>Is anybody else
+ implemented in code. But, because one hacker coding in solitude
+ fails to qualify as a free software development effort, you need
+ to ask yourself the question: <emphasis>Is anybody else
interested?</emphasis>
</para>
<para>
- Sometimes the answer is <emphasis>no</emphasis>. If you want to
- write a set of scripts to sort <emphasis>your</emphasis>
+ Sometimes the answer is a simple <emphasis>no</emphasis>. If you
+ want to write a set of scripts to sort <emphasis>your</emphasis>
<acronym>MP3</acronym> collection on your machine, maybe the free
software development model is not the best one to
choose. However, if you want to write a set of scripts to sort
</para>
<para>
- Luckily, The Internet is a place so big and diverse that, chances
- are, there is someone, somewhere, who shares your interests and
- how feels the same itch. It is the fact that there are so many
- people with so many similar needs and desires that introduces the
- second major question: <emphasis>Has somebody already had your
- idea or a reasonably similar one?</emphasis>
+ Luckily, The Internet is a place so big and so diverse that,
+ chances are, there is someone, somewhere, who shares your
+ interests and how feels the same <quote>itch.</quote> It is the
+ fact that there are so many people with so many similar needs and
+ desires that introduces the second major question: <emphasis>Has
+ somebody already had your idea or a reasonably similar
+ one?</emphasis>
</para>
<sect4 id=evalwhere>
<title>Finding Similar Projects</title>
<para>
- There are places you can go on the web to try and answer this
- question. If you have experience with the free software
+ There are places you can go on the web to try and answer the
+ question above. If you have experience with the free software
community, you are probably already familiar with all of these
sites. All of the resources listed bellow offer searching of
their databases:
<varlistentry>
<term>freshmeat.net:</term>
<listitem>
- <para><ulink url="http://freshmeat.net">freshmeat</ulink>
+ <para><ulink url="http://freshmeat.net">freshmeat.net</ulink>
describes itself as, <quote>the Web's largest index of Linux
and Open Source software</quote> and its reputation along
- these lines remains unquestioned. If you can't find it on
- freshmeat, its doubtful that you'll find it indexed anywhere
- else.</para>
+ these lines is totally unparalleled and unquestioned. If you
+ can't find it on freshmeat, its doubtful that you (or anyone
+ else) will find it anywhere.</para>
</listitem>
</varlistentry>
<listitem>
<para><ulink url="http://sourceforge.net">SourceForge</ulink>
houses and facilitates a growing number of open source and
- free software projects, SourceForge is quickly becoming a
- nexus and an necessary stop for free software
+ free software projects. It is also quickly becoming a nexus
+ and an necessary stop for free software
developers. SourceForge's <ulink
url="http://sourceforge.net/softwaremap/trove_list.php">software
map</ulink> and <ulink url="http://sourceforge.net/new/"> new
- releases</ulink> pages. should be necessary stops before
+ releases</ulink> pages should be necessary stops before
embarking on a new free software project. SourceForge also
provides a at <ulink
url="http://sourceforge.net/snippet/">Code Snippet
- Library</ulink> which contains useful reusable chunks of
- code in an array of languages which can come in useful in any
+ Library</ulink> which contains useful reusable chunks of code
+ in an array of languaqges which can come in useful in any
project.</para>
</listitem>
</varlistentry>
bout what kinds of similar free software projects exist, every
developer needs to decide whether to proceed with their own
project. It is rare that a new project seeks to accomplish a
- goal that is not similar to related to the goal of another
+ goal that is not similar to or related to the goal of another
project. Anyone starting a new project needs to ask themselves:
- <emphasis>Will the new project be duplicating work done by
- another project? Will the new project be competing for
- developers with an existing project? Can the goals of the new
- project be accomplished by adding functionality to an existing
- project?</emphasis>
+ <quote>Will the new project be duplicating work done by another
+ project? Will the new project be competing for developers with
+ an existing project? Can the goals of the new project be
+ accomplished by adding functionality to an existing
+ project?</quote>
</para>
<para>
- If the answer to any of these questions is yes, try to contact
- the developer of the existing project in question and see if he
- or she might be willing to collaborate with you.
+ If the answer to any of these questions is <quote>yes,</quote>
+ try to contact the developer of the existing project(s) in
+ question and see if he or she might be willing to collaborate
+ with you.
</para>
<para>
This may be the single most difficult aspect of free software
- development for many developers but it is essential. It is easy
- to become fired up by and idea and be caught up in the momentum
- and excitement of a new project. It is often extremely difficult
- but it is important that any free software developer remember
- that the best interests of the of the free software community
- and the quickest way to accomplish ones own project's goals and
- the goals of similar project can often be accomplished by
- <emphasis>not</emphasis> starting a new project.
+ development for many developers but it is an essential one. It
+ is easy to become fired up by an idea and be caught up in the
+ momentum and excitement of a new project. It is often extremely
+ difficult to do but, it is important that any free software
+ developer remember that the best interests of the free software
+ community and the quickest way to accomplish ones own project's
+ goals and the goals of similar project can often be accomplished
+ by <emphasis>not</emphasis> starting a new project.
</para>
</sect4>
<title>Licensing your Software</title>
<para>
- On one level, the difference between a piece of free software and
- a piece of propriety software is the license. A license helps both
- you as the developer by protecting your legal rights to your
- software and helps demonstrate to those who wish to help you or
- your project that they are encouraged to join.
+ On one (somewhat simplistic) level, the difference between a piece
+ of free software and a piece of propriety software is the
+ license. A license helps you as the developer by protecting your
+ legal rights to have your software distributed under your terms
+ and helps demonstrate to those who wish to help you or your
+ project that they are encouraged to join.
</para>
<sect3 id="chooselicense">
<para>
Any discussion of licenses is also sure to generate at least a
small flame war as there are strong feelings that some free
- software licenses are better than other free software
- licenses. This discussion also brings up the question of
- <quote>Open Source Software</quote> and the debate around
- <quote>Open Source Software</quote> and <quote>Free
- Software</quote>. However, because I've written the Free Software
- Development HOWTO and not the Open Source Development HOWTO, my
- own allegiances in this argument are out in the open.
+ software licenses are better than others. This discussion also
+ brings up the question of <quote>Open Source Software</quote> and
+ the debate around <quote>Open Source Software</quote> and
+ <quote>Free Software</quote>. However, because I've written the
+ Free Software Development HOWTO and not the Open Source
+ Development HOWTO, my own allegiances in this argument are in the
+ open.
</para>
<para>
- In attempting to reach a middle ground, I recommend picking any
- license that conforms to the <ulink
+ In attempting to reach a middle ground through diplomacy without
+ sacrificing my own philosophy, I recommend picking any license
+ that conforms to the <ulink
url="http://www.debian.org/social_contract">Debian Free Software
- Guidelines</ulink>. Examples of these licenses are the
+ Guidelines</ulink>. Originally compiled by the Debian project
+ under Bruce Perens, the <acronym>DFSG</acronym> form the first
+ version of the Open Source definition. Examples of free licenses
+ given by the <acronym>DFSG</acronym> are the
<acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
- Artistic License. Conforming to the definition of Free Software
- offered by Richard Stallman in <ulink
- url="http://www.gnu.org/philosophy/free-sw.html">The Free
- Software Definition</ulink>, any of these licenses will
+ Artistic License.
+ </para>
+
+ <para>
+ Conforming to the definition of Free Software offered by Richard
+ Stallman in <ulink
+ url="http://www.gnu.org/philosophy/free-sw.html"><quote>The Free
+ Software Definition</quote></ulink>, any of these licenses will
uphold,<quote> users' freedom to run, copy, distribute, study,
- change and improve the software.</quote> There are other licenses
- as well but sticking with a more common license will offer the
- advantage of immediate recognition and understanding.
+ change and improve the software.</quote> There are plenty of
+ other licenses that also conform to the <acronym>DFSG</acronym>
+ but sticking with a more common license will offer the advantage
+ of immediate recognition and understanding.
</para>
<para>
<acronym>GPL</acronym>. Created and protected by the Free
Software Foundation and the GNU Project, the
<acronym>GPL</acronym> is the license for the Linux kernel,
- GNOME, Emacs, and the majority of Linux software. Its an easy
- choice but I believe it is a good one. <emphasis>However, there
- is a viral aspect to the <acronym>GPL</acronym>that prevents the
- mixture of <acronym>GPL</acronym>'ed code with
- non-<acronym>GPL</acronym>'ed code. To many people (myself
- included), this is a benefit, but to some, it is a major
- drawback.</emphasis>
+ GNOME, Emacs, and the vast majority of GNU/Linux software. It's
+ the obvious choice but I believe it is a good one. Any BSD
+ fanatic will urge you to remember that there is a viral aspect to
+ the <acronym>GPL</acronym>that prevents the mixture of
+ <acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
+ code. To many people (myself included), this is a benefit, but to
+ some, it is a major drawback.
</para>
<para>
</para>
<para>
- <emphasis>In all cases, please read through any license before
- your release your software. As the developer, you can't afford
- any license surprises.</emphasis>
+ <emphasis>In any case, please read through any license before
+ your release your software. As the primary developer, you can't
+ afford any license surprises.</emphasis>
</para>
</sect3>
The text of the <acronym>GPL</acronym> offers <ulink
url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
description</ulink> of mechanics of applying a license to a piece
- of software. A checklist for applying a license would include:
+ of software. My quick checklist for applying a license includes:
</para>
<para>
- <orderedlist>
+ <itemizedlist>
+
<listitem>
-
<para>If at all possible, attach and distribute a full copy of
the license with the source and binary in a separate
file.</para>
-
</listitem>
- <listitem>
+ <listitem>
<para>At the top of each source file in your program, attach a
notice of copyright and information on where the full license
can be found. The <acronym>GPL</acronym> recommends that each
information on contacting you (the author) via email or
physical mail.
</para>
-
</listitem>
- <listitem>
+ <listitem>
<para>
The <acronym>GPL</acronym> continues and suggests that if your
- program runs in an interactive mode, you should have the
- program output a notice each time it enters interactive mode
- that includes a message like this one that points to more
+ program runs in an interactive mode, you should write the
+ program to output a notice each time it enters interactive
+ mode that includes a message like this one that points to more
information about the programs licensing:
</para>
to redistribute it under certain conditions; type `show c'
for details.
</screen>
-
</listitem>
+
<listitem>
<para>Finally, it might be helpful to include a
<quote>copyright disclaimer</quote> with the program from an
employer or a school if you work as a programmer or if it seems
like your employer or school might be able to make an argument
- for ownership of your code.</para>
+ for ownership of your code later on. Its often needed but there
+ are plenty of free software developers who have gotten into
+ trouble and wish they had attained one.</para>
</listitem>
- </orderedlist>
- </para>
+ </itemizedlist>
+ </para>
</sect3>
<sect3 id="licensewarning">
<para>
Please, please, please, place your software under some
license. It may not seem important, and to you, it may not be,
- but licenses are important. For a piece of software to be
- included in the Debian GNU/Linux distribution, it must have a
- license that fits the <ulink
+ but licenses <emphasis>are</emphasis> important. For a piece of
+ software to be included in the Debian GNU/Linux distribution, it
+
must have a license that fits the <ulink
url="http://www.debian.org/social_contract">Debian Free Software
- Guidelines</ulink>. If you have no license, your program can be
- distributed in part of Debian until you re-release it under a free
- license. Please save yourself and others trouble by releasing the
- first version of your software with a clear license.
+ Guidelines</ulink>. If you have no license, your program can not
+ be distributed as a package in Debian until you re-release it
+ under a free license. Please save yourself and others trouble by
+ releasing the first version of your software with a clear
+ license.
</para>
</sect3>
<sect2 id="chooseversioning">
<title>Choosing a Method of Version Numbering</title>
+
<para>
- <emphasis>The most important thing about a system of numbering is
- that there is one.</emphasis> It may seem pedantic to emphasize
- this point but you'd be surprised at the number of scripts and
- small programs that pop up without any version number.
+ <emphasis>The most important thing about a system of version
+ numbering is that there is one.</emphasis> It may seem pedantic to
+ emphasize this point but you'd be surprised at the number of
+ scripts and small programs that pop up without any version number
+ at all.
</para>
<para>
<emphasis>The second most important thing about a system of
numbering is that the numbers always go up.</emphasis> Automatic
- versioning systems and people's sense of order in the universe
- will fall apart if version numbers don't rise. It doesn't
+ version tracking systems and people's sense of order in the
+ universe will fall apart if version numbers don't rise. It doesn't
<emphasis>really</emphasis> matter if 2.1 is a big jump and
2.0.005 is a small jump but it does matter that 2.1 is more recent
than 2.0.005.
</para>
<para>
- Follow these two rules and you will not go wrong. Still there are
- several versioning system that are well known, useful, and that
- might be worth looking into before you release your first version.
+ Follow these two simple rules and you will not go (too)
+ wrong. Still, there are several version numbering systems that are
+ well known, useful, and that might be worth looking into before
+ you release your first version.
</para>
<variablelist>
<varlistentry>
<term>Linux kernel version numbering:</term>
<listitem>
- <para>The Linux kernel uses a versioning system where the any
- minor odd minor version number refers to an development or
- testing release and any even minor version number refers to a
- stable version. Under this system, 2.1 and 2.3 kernels were and
- always will be development and testing kernels and 2.0, 2.2. and
- 2.4 kernels are all production code with a higher degree of
- stability.
+ <para>The Linux kernel uses a versioning system where any odd
+ minor version number refers to an development or testing release
+ and any even minor version number refers to a stable
+ version. Think about it for a second. Under this system, 2.1 and
+ 2.3 kernels were and always will be development or testing
+ kernels and 2.0, 2.2. and 2.4 kernels are all production code
+ with a higher degree of stability and more testing.
</para>
<para>
distributions (2.0, 2.1, etc). However, many people assume that
2.1 is an unstable or development version and continue to use
an older version until they get so frustrated with the lack of
- development and progress that they complain. If you never
- release an odd minor version but only release even ones, nobody
- is hurt, and less people are confused.
+ progress development that they complain and figure the system
+ out. If you never release an odd minor version but only release
+ even ones, nobody is hurt, and less people are confused. It's
+ worth taking into consideration.
</para>
-
</listitem>
</varlistentry>
+
<varlistentry>
<term>Wine version numbering:</term>
<listitem>
<para>Because of the unusual nature of wine's development where
- it constantly improving but not working towards any immediately
- achievable goal, wine is released every three weeks. Wine does
- this by versioning their releases in Year Month Day format where
- each release might be labeled <quote>wine-XXXXXXXX</quote> where
- the version from January 04, 2000 would be
- <quote>wine-20000104</quote>. For certain projects, Year Month
- Day format can make a lot of sense.
+ the not-emulator is constantly improving but not working towards
+ any immediately achievable goal, wine is released every three
+ weeks. Wine does this by labeling their releases in Year Month
+ Day format where each release might be labeled
+ <quote>wine-XXXXXXXX</quote> where the version from January 04,
+ 2000 would be <quote>wine-20000104</quote>. For certain
+ projects, Year Month Day format can make a lot of sense.
</para>
-
</listitem>
</varlistentry>
+
<varlistentry>
<term>Mozilla milestones:</term>
<listitem>
</para>
<para>
- Mozilla's development structure has historically been made up
- of milestones. From the beginning of the mozilla project, the
- goals of the project in the order and degree to which they were
- to be achieved were charted out on a series of <ulink
- url="http://www.mozilla.org/roadmap.html">road
- maps</ulink>. Major points and achievements along this road-maps
- were marked as milestones. Therefore, mozilla was built and
- distributed nightly as "nightly builds" but on a day when the
- goals of a milestone on the road-map had been reached, that
- particular build was marked as a milestone release.
+ Mozilla's version numbering structure has historically been
+ made up of milestones. From the beginning of the mozilla
+ project, the goals of the project in the order and degree to
+ which they were to be achieved were charted out on a series of
+ <ulink url="http://www.mozilla.org/roadmap.html">road
+ maps</ulink>. Major points and achievements along these
+ road-maps were marked as milestones. Therefore, mozilla was
+ built and distributed nightly as "nightly builds" but on a day
+ when the goals of a milestone on the road-map had been reached,
+ that particular build was marked as a milestone release.
</para>
<para>
any testing or development branch of a large free application
under heavy development.
</para>
-
</listitem>
</varlistentry>
+
</variablelist>
</sect2>
<para>
A huge number of otherwise fantastic free software applications
- have withered because their author was the only person who knew
- how to use them well. Even if your program is written primarily
- for a techno-savvy group of users, documentation is helpful and
- necessary for the survival of your project. You will learn later
- in <xref linkend="releasing"> that you must always release
- something that is usable. <emphasis>A piece of software without
- documentation is not usable.</emphasis>
+ have withered and died because their author was the only person
+ who knew how to use them fully. Even if your program is written
+ primarily for a techno-savvy group of users, documentation is
+ helpful and even necessary for the survival of your project. You
+ will learn later in <xref linkend="releasing"> that you should
+ always release something that is usable. <emphasis>A piece of
+ software without documentation is not usable.</emphasis>
</para>
<para>
- There are lots of ways to document your project and lots of
- different people to document for. The idea of documentation the
- code itself to help facilitate development by a large community is
- vital but is outside the scope of this HOWTO. This being the case,
- this section deals mostly useful tactics for user-directed
- documentation.
+ There are lots of different people for whom to document and
+ therefore there are lots of ways to document your project. The
+ idea of documentation in source code to help facilitate
+ development by a large community is vital but it falls outside the scope
+ of this HOWTO. This being the case, this section deals mostly
+ useful tactics for user-directed documentation.
</para>
<para>
A combination of tradition and necessity has resulted in a
- semi-regular system method of documentation in most free software
+ semi-regular system of documentation in most free software
projects that is worth following. Both users and developers expect
- to be able to get documentation in several ways and its essential
+ to be able to get documentation in several ways and it's essential
that you provide the information they are seeking in a form they
can read if your project is ever going to get off the
ground. People have come to expect:
<title>Man pages</title>
<para>Your users will want to be able to type <quote>man
- foo</quote> end up with a nicely formatted man page highlighting
- the basic use of their application. Make sure that before you
- release your program, you've planned for this.
+ projectname</quote> end up with a nicely formatted man page
+ highlighting the basic use of yourapplication. Make sure that
+ before you release your program, you've planned for this.
</para>
<para>
Man pages are not difficult to write. There is excellent
- documentation on the man page process available through the
+ documentation on the man page writing process available through the
<quote>The Linux Man-Page-HOWTO</quote> available through the
Linux Documentation project <acronym>(LDP)</acronym> written by
Jens Schweikhardt. It is available <ulink
<para>
It is also possible to write man pages using DocBook SGML and
- convert them into man pages. Because man pages are so simple, I
- have not been able to follow this up but would love help from
- anyone who can give me more information on how exactly this is
- done.
+ convert them into man pages. Because man pages are so simple and
+ the DocBook method relatively new, I have not been able to follow
+ this up but would love help from anyone who can give me more
+ information on how exactly this is done.
</para>
</sect3>
<title>Command line accessible documentation</title>
<para>
- Most users will expect the most basic amount of documentation to
- be easily available from the command line. For few programs should
- then documentation extend for more than one screen (24 or 25
- lines) but it should cover the basic usage, a brief (one or two
- sentence) description of the program, a list of commands, all the
- major options, and a pointer to more in-depth documentation for
+ Most users will expect some basic amount of documentation to be
+ easily available from the command line. For few programs should
+ this type of documentation extend for more than one screen (24 or
+ 25 lines) but it should cover the basic usage, a brief (one or
+ two sentence) description of the program, a list of the commands
+ with explanations, all the major options (also with
+ explanations), and a pointer to more in-depth documentation for
those who need it. The command line documentation for Debian's
apt-get serves as an excellent example and a useful model:
</para>
</screen>
<para>
- It has become a GNU convention to make this information
+ It has become a GNU convention to make this type of information
accessible with the <quote>-h</quote> and the
<quote>--help</quote> options. Most GNU/Linux users will expect
to be able to retrieve basic documentation these ways so if you
for the fallout that may result.
</para>
</sect3>
+
<sect3>
<title>Files users will expect</title>
<para>
- In addition to man pages and online help, there are certain files
- where people will look to documentation, especially in any
+ In addition to man pages and command-line help, there are certain
+ files where people will look for documentation, especially in any
package containing source code. In a source distribution, most of
these files can be stored in a the root directory of the source
distribution or in a subdirectory of the root called
- <quote>doc</quote> or <quote>Documentation</quote>. These files include:
+ <quote>doc</quote> or <quote>Documentation</quote>. Common files
+ places in these places include:
</para>
+
<para>
<variablelist>
<varlistentry>
<term>README or Readme</term>
<listitem>
- <para>
- A document containing all the basic installation,
- compilation, and even basic use instructions that make up
- the bare minimum information needed to get the program up and
- running. A README is not your chance to be verbose but needs
- to be concise and effective. An ideal README is at least 30
- lines long and more no more than 250.
- </para>
+ <para>A document containing all the basic installation,
+ compilation, and even basic use instructions that make up the
+ bare minimum information needed to get the program up and
+ running. A README is not your chance to be verbose but needs
+ to be concise and effective. An ideal README is at least 30
+ lines long and more no more than 250.</para>
</listitem>
</varlistentry>
<term>INSTALL or Install</term>
<listitem>
- <para>
- The INSTALL file should be much shorter than the INSTALL file
- and should quickly and concisely describe how to build and
- install the program. Usually an install simply instructs the
- user to run ./configure; make; make install and touches on
- any unusual options that may be necessary. More advanced
- users can usually avoid them but it's good practice to at
- least glance at the file to understand what can be
- expected. For most relatively standard install procedures and
- for most programs, INSTALL files are as short as possible are
- rarely over 100 lines.
- </para>
+ <para>The INSTALL file should be much shorter than the README
+ file and should quickly and concisely describe how to build
+ and install the program. Usually an INSTALL file simply
+ instructs the user to run <quote>./configure; make; make
+ install</quote> and touches on any unusual options or actions
+ that may be necessary. More advanced users can usually avoid
+ INSTALL files but it's good practice to at least glance at one
+ to understand what can be expected. For most relatively
+ standard install procedures and for most programs, INSTALL
+ files are as short as possible are rarely over 100
+ lines.</para>
</listitem>
</varlistentry>
<term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
<listitem>
- <para>
- A changelog is a simple file that every well-managed free
- software project should include. A changelog is simple the
- file that, as its name would imply, logs or documents the
- changes to a program. The most simple way to do a changelog
- is to simply keep a file with the source code for your
- program and add a section to the top of the changelog with
- each release describing what has been, changed, fixed, or
- added to the program. It's a good idea to post the changelog
- onto the website as well because it can help people decide
- whether they want or need to upgrade to a newer version or
- wait for a more significant upgrade.
- </para>
+ <para>A changelog is a simple file that every well-managed
+ free software project should include. A changelog is simple
+ the file that, as its name implies, logs or documents the
+ changes to a program. The most simple way to do a changelog is
+ to simply keep a file with the source code for your program
+ and add a section to the top of the changelog with each
+ release describing what has been, changed, fixed, or added to
+ the program. It's a good idea to post the changelog onto the
+ website as well because it can help people decide whether they
+ want or need to upgrade to a newer version or wait for a more
+ significant upgrade.</para>
+ </listitem>
+
+ </varlistentry>
+ <varlistentry>
+ <term>NEWS</term>
+
+ <listitem>
+ <para>A NEWS file and a ChangeLog are similar. A news file is
+ not typically sorted by version but just whenever new features
+ are added, the developer responisble will make a note in the
+ NEWS file. NEWS files should not have to changed before a
+ release (they should be kept up to date all along) but it's
+ usually a good idea to check first anyway because often people
+ just forget to keep them as current as they should.</para>
</listitem>
</varlistentry>
<term><acronym>FAQ</acronym></term>
<listitem>
- <para>
- For those of you that don't already
- know. <acronym>FAQ</acronym> stands for Frequently Asked
- Questions and the file is a collection of exactly that. FAQs
- are not difficult to make. Simply make a policy that if you
- are asked a question or see a question on a mailing list two
- or more times, add it the question (and its answer) to your
- FAQs. FAQs are more optional than the files listed above but
- they can save your time, increase usability, and decrease
- headaches on all sides.
- </para>
+ <para>For those of you that don't already
+ know. <acronym>FAQ</acronym> stands for Frequently Asked
+ Questions and a FAQ is a collection of exactly that. FAQs
+ are not difficult to make. Simply make a policy that if you
+ are asked a question or see a question on a mailing list two
+ or more times, add it the question (and its answer) to your
+ FAQ. FAQs are more optional than the files listed above but
+ they can save your time, increase usability, and decrease
+ headaches on all sides.</para>
</listitem>
</varlistentry>
</sect3>
<sect3>
- <title>Website</title>
+ <title>Website</title>
<para>
- It's only a sort of an issue of documentation but a good website
+ It's only idirectly an issue of documentation but a good website
is quickly becoming an essential part of any free software
- project. Your website should provide access to documentation (in
- <acronym>HTML</acronym> if possible). It should also include a
- section for news and events around your program and a section
- that details the process of getting involved with development or
- testing and creates an open invitation. It should also supply
- links to any mailing lists, similar websites, and directly to all
- the available ways of downloading your software.
+ project's documentation. Your website should provide access to
+ documentation (in <acronym>HTML</acronym> if possible). It should
+ also include a section for news and events around your program
+ and a section that details the process of getting involved with
+ development or testing and creates an open invitation. It should
+ also supply links to any mailing lists, similar websites, and
+ provide a direct link to all the available ways of downloading
+ your software.
</para>
</sect3>
<para>
Many of the remaining issues surrounding the creation of a new
free software program fall under what most people describe as
- common sense actions. Still, they are worth noting briefly in
+ common sense issues. Still, they are worth noting briefly in
hopes that they may remind a developer of something they may have
forgotten.
</para>
against a specified system with specified libraries and
distributed in tar.gz format as well. <emphasis>Remember: While
these binaries packages are nice, getting the source packaged and
- released should always be your priority. Other can and will do
- the the binary packages for you.</emphasis>
+ released should always be your priority. Your users or fellow
+ developers can and will do the the binary packages for
+ you.</emphasis>
</para>
</sect3>
<sect3>
<title>Useful tidbits and presentation hints</title>
+ <para>
+ Other useful hints include:
+ </para>
+
<para>
<itemizedlist>
quickly recognized. One effective technique is a provide a
symlink called <quote>projectname-latest</quote> that is
always pointing to the most recent released or development
- version of your free software project.
+ version of your free software project. Keep in mind that this
+ location will recieve many requests for downloads around
+ releases so make sure that the server you choose for this
+ purpose has adequate bandwidth.
</para>
</listitem>
projectname@host or projectname-bugs@host. This way if you
ever decide to hand over maintainership or if your email
address changes, you simply need to change where this email
- address forwards to. It also will allow for more than one
- person to deal with the influx of mail that is created if your
+ address forwards. It also will allow for more than one person
+ to deal with the influx of mail that is created if your
project becomes as huge as you hope it will.
</para>
</listitem>
</indexterm>
<para>
- Once you have gotten the project started, you have gotten over the
+ Once you have gotten your project started, you have overcome the
most difficult hurdles in the development process of your
program. Laying a firm foundation is essential, but the development
- process itself is equally important and provides an equal number of
- opportunities for failure. In the next two sections, I will and
- cover running a project by discussing how to maintain a project
- rough interactions with developers and with users.
+ process itself is equally important and provides quite a few
+ opportunities for failure. In the next two sections, I will cover
+ running a project by discussing how to maintain a project through
+ interactions with developers and with users.
</para>
<para>
</para>
<para>
- The major difference between free software development and propriety
- software development is the developer base. As the leader of a free
- software project, you need to attract and keep developers in a way
- that leaders of proprietary software projects simply don't have to
- worry about. <emphasis>As the person leading development of a free
- software project, you must harness the work of fellow developers by
- making responsible decisions and by and by choosing not to make
- decisions responsibly. You have to direct developers without being
- overbearing or bossy. You need to strive to earn respect and never
- forget to give it.</emphasis>
+ The major difference between free software development and
+ propriety software development is the developer base. As the leader
+ of a free software project, you need to attract and keep developers
+ in a way that leaders of proprietary software projects simply don't
+ have to worry about. <emphasis>As the person leading development of
+ a free software project, you must harness the work of fellow
+ developers by making responsible decisions and by responsibly
+ choosing not to make decisions. You have to direct developers
+ without being overbearing or bossy. You need to strive to earn
+ respect and never forget to give it out.</emphasis>
</para>
<!-- Section2: delegation -->
<para>
By now, you've hypothetically followed me through the early
- writing of a piece of software, the creation of a website and
+ programming of a piece of software, the creation of a website and
system of documentation and and we've gone ahead and (as will be
discussed in <xref linkend="releasing">) released it to the rest
of the world. Times passes, and if things go well, people become
and involved developers. It is difficult for anyone who has
invested a large deal of time and energy into a project but it
essential for the growth of any free software project. One person
- can only do so much. <emphasis>A free software project is nothing
+ can only do so much. A free software project is nothing
without the involvement of a group of developers. A group of
developers can only be maintained through respectful and
- responsible leadership and delegation.</emphasis>
+ responsible leadership and delegation.
</para>
<para>
<title>How to delegate</title>
<para>
- Like anything, its easier to see how others delegate than to do
- it yourself. You may find that other developers seem even more
- experienced or knowledgeable than you. Your job as a maintainer
- does not mean you have to have to be the best or the
- brightest. It means you need are responsible for showing good
- judgment and for recognizing solutions that are maintainable and
- are not. In a sentence: <emphasis>Keep an eye out for other
+ You may find that other developers seem even more experienced or
+ knowledgeable than you. Your job as a maintainer does not mean
+ you have to have to be the best or the brightest. It means you
+ need are responsible for showing good judgment and for
+ recognizing which solutions are maintainable and which are not.
+ </para>
+ <para>
+ Like anything, its easier to watch others delegate than to do it
+ yourself. In a sentence: <emphasis>Keep an eye out for other
qualified developers who show an interest and sustained
involvement with your project and try and shift responsibility
towards them.</emphasis> The following ideas might be good places
more than 700 developers have full responsibility for certain
aspects of the projects. All these developers can upload into
the main FTP servers, and vote on major issues. Direction for
- the project is determined by the project <ulink
+ the project is determined by the project
's <ulink
url="http://www.debian.org/social_contract">social
contract</ulink> and a <ulink
url="http://www.debian.org/devel/constitution">constitution</ulink>. To
facilitate this system, there are special teams (i.e. the
- install team, the Japanese language team) and a technical
- committee and a project lead. There is a project leader as well
- but the leader's main responsibility is to, <quote>Appoint
- Delegates or delegate decisions to the Technical
- Committee.</quote>
+ install team, the Japanese language team) as well as a technical
+ committee and a project leader. The leader's main responsibility
+ is to, <quote>Appoint Delegates or delegate decisions to the
+ Technical Committee.</quote>
</para>
<para>
While both of these projects operate on a scale that your
project will not (at least initially), their example is
- helpful. Debian's idea of a project who lead who can do
- <emphasis>nothing</emphasis> but delegate can serve as a
+ helpful. Debian's idea of a project leader who can do
+ <emphasis>nothing</emphasis> but delegate serves as a
caricature of how a project can involve and empower a huge
number of developers and grow to a huge size.
</para>
break and to shift the responsibility for accepting and
rejecting patches to someone else. It is a good way of very
clearly defining a chunk of work on the project as belonging to
- a certain person and its a great way of giving yourself a break.
+ a certain person and its a great way of giving yourself room to
+ breath.
</para>
</sect4>
linkend="branches">), it might be a good idea to appoint someone
else to be the the head of a branch. If you like focusing your
energy on development releases and the implementation of new
- features, had total control over the stable releases to a
+ features, hand total control over the stable releases to a
well-suited developer.
</para>
<para>
In <emphasis>Open Source Development with CVS</emphasis>, Karl
Fogel makes a convincing argument that the most important things
- to keep in mind are a firm knowledge of the scope of your program
- (that's the <quote>idea</quote> I talked about in <xref
- linkend="chooseproject">) and the ability to recognize,
- facilitate, and direct <quote>evolution</quote> of a free
- software program so that the program can grow and change and
- incorporate functionality that was originally unforeseen but avoid
- digressions that might expand the scope of the program too much
- and result and push the project towards an early death under its
- own weight and unwieldiness. These are the criteria that you as a
- project maintainer should take into account each time you receive
- a patch.
+ to keep in mind when rejecting or accepting patches are:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>A firm knowledge of the scope of your program (that's the
+ <quote>idea</quote> I talked about in <xref linkend="chooseproject">);</para>
+ </listitem>
+
+ <listitem>
+ <para>The ability to recognize, facilitate, and direct
+ <quote>evolution</quote> of your program so that the program
+ can grow and change and incorporate functionality that was
+ originally unforeseen;</para>
+ </listitem>
+
+ <listitem>
+ <para>The necessity to avoid digressions that might expand the
+ scope of the program too much and result and push the project
+ towards an early death under its own weight and
+ unwieldiness.</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ These are the criteria that you as a project maintainer should
+ take into account each time you receive a patch.
</para>
<para>
linkend="delegation">) that any developer needs to try and
balance your responsibility and power to make what you think are
the best technical decisions with the fact that you will lose
- support from other developers if you seem like you are on a
- power trip or being overly bossy or possessive of a community-based
+ support from other developers if you seem like you are on a power
+ trip or being overly bossy or possessive of a community-based
project. I recommend that you keep three major facts in mind when
rejecting patches (or other changes):
</para>
<sect4>
<title>Bring it to the community</title>
<para>
- One of the best ways of justifying a decision to reject a patch
- and working to not seem like you keep an iron grip on your
- project is by not making the decision alone at all. It might
- make sense to turn over larger proposed changes or more
+ One of the best ways of justifying a decision to reject a patch
+ and working to not seem like you keep an iron grip on your
+ project is by not making the decision alone at all. It might
+ make sense to turn over larger proposed changes or more
difficult decisions to a development mailing list where they can
be discussed. There will be some patches (bug fixes, etc.) which
- will definitely be accepted and some that you feel are so off
+ will definitely be accepted and some that you feel are so off
base that they do not even merit further discussion. It is those
that fall into the grey area between these two groups that might
merit a quick forward to a mailing list.
maintainer you are worried about making the best decision for
the project, for the project's users and developers, and for
yourself as a responsible project leader. Turning things over to
- an email list will demonstrate your own responsible and
+ an email list will demonstrate your own responsibility and
responsive leadership as it tests and serves the interests of
your software's community.
</para>
</sect4>
<sect4>
- <title>Technical issues is not always good justification</title>
+ <title>Technical issues are not always good justification</title>
<para>
Especially towards the beginning, you will find that many
changes are difficult to implement, introduce new bugs, or have
other technical problems. Try to see past these. Especially with
added functionality, good ideas do not always come from good
- coders. Technical merit is a valid reason to postpone the
+ coders. Technical merit is a valid reason to postpone an
application of a patch but it is not always a good reason to
reject a change outright. Even small changes are worth the
- effort of working with the developer submitting the patch to iron out bugs and
- incorporate the change if you thing you think it seems like a
- good addition to your project. The effort on your part will work
- to make your project a community project and it will pull a new
- or less experienced developer onto your project and even teach
- them something that might help them in their next patch.
+ effort of working with the developer submitting the patch to
+ iron out bugs and incorporate the change if you thing you think
+ it seems like a good addition to your project. The effort on
+ your part will work to make your project a community project and
+ it will pull a new or less experienced developer onto your
+ project and even teach them something that might help them in
+ making their next patch.
</para>
</sect4>
</para>
<para>
- It is your responsibility to first justify your action to not
+ It is your responsibility to first justify your choice to not
incorporate their change clearly and concisely. Then thank
them. Let them know that you a appreciate their help and feel
horrible that you can't incorporate their change. Let them know
that you look forward to their staying involved and you hope
that the next patch or idea meshes better with your project
because you appreciate their work and want to see it in the
- project. If you have ever had a patch rejected that put a large
- deal of time, thought, and energy into, you remember how it
- feels and it feels bad. Keep this in mind when you have to let
- someone down. It's never easy but you need to do everything you
- have to make it as not-unpleasant as possible.
+ project. If you have ever had a patch rejected after putting a
+ large deal of time, thought, and energy into it, you remember
+ how it feels and it feels bad. Keep this in mind when you have
+ to let someone down. It's never easy but you need to do
+ everything you can to make it as not-unpleasant as possible.
</para>
</sect4>
</sect3>
<para>
The idea of stable and development branches has already been
described briefly in <xref linkend="chooseversioning"> and in
- <xref linkend="delegatebranch">. These alludes attest to the fact
- to some of the ways that multiple branches can affect your
- software. Branches can let you avoid (to some extent) some of the
- problems around rejecting patches (as described in <xref
- linkend="patching">) by allowing you to temporarily compromise the
- stability of your project without affected those users who need
- that stability.
+ <xref linkend="delegatebranch">. These allusions attest to some of
+ the ways that multiple branches can affect your software. Branches
+ can let you avoid (to some extent) some of the problems around
+ rejecting patches (as described in <xref linkend="patching">) by
+ allowing you to temporarily compromise the stability of your
+ project without affecting those users who need that stability.
</para>
<para>
The most common way of branching your project is to have one
- branch that is stable and one that is development. This is the
+ branch that is stable and one that is for development. This is the
model followed by the Linux kernel that is described in <xref
linkend="chooseversioning">. In this model, there is always one
branch that is stable and always one that is in
development. Before any new release, the development branch goes
- into a <quote>feature freeze</quote> where major changes and added
- features are rejected or put on hold under the development kernel
- is released as the new stable branch and major development begins
- again on the development branch. Bug fixes and small changes that
- are unlikely to have any large negative repercussions are
- incorporated into the stable branch also to the development
- branch.
+ into a <quote>feature freeze</quote> as described in <xref
+ linkend="freezing"> where major changes and added features are
+ rejected or put on hold under the development kernel is released
+ as the new stable branch and major development resumes on the
+ development branch. Bug fixes and small changes that are unlikely
+ to have any large negative repercussions are incorporated into the
+ stable branch as well as the development branch.
</para>
<para>
testing, experimental, and (around release time) a frozen
distribution that only incorporates bug fixes during the
transition from unstable to stable. There are few projects whose
- size would necessitate a system like Debian but their use of
+ size would necessitate a system like Debian's but this use of
branches helps demonstrate how they can be used to balance
consistent and effective development with the need to make regular
and usable releases.
<varlistentry>
<term>Minimize the number of branches</term>
<listitem>
- <para>
- Debian may be able to make good use of four or five branches
- but it contains gigabytes of software in over 5000 packages
- compiled for a 5-6 different architectures. Two is a good
- number. Too many branches will confuse your users (I can't
- count how many times I had to describe Debian's system when it
- only had 2 and sometimes 3 branches!), potential developers
- and even yourself. Branches can help but they come at a cost
- so use them very sparingly.
- </para>
+ <para>Debian may be able to make good use of four or five
+ branches but it contains gigabytes of software in over 5000
+ packages compiled for a 5-6 different architectures. For you,
+ two is probably a good number. Too many branches will confuse
+ your users (I can't count how many times I had to describe
+ Debian's system when it only had 2 and sometimes 3 branches!),
+ potential developers and even yourself. Branches can help but
+ they come at a cost so use them very sparingly.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Make sure that all your different branches are explained</term>
<listitem>
- <para>
- As I mentioned in the preceding paragraph, different branches
- <emphasis>will</emphasis> confuse your users. Do everything
- you can to avoid this by clearly explaining the different
- branches in a prominent page on your website and in a Readme
- file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
- directory.
- </para>
+ <para>As I mentioned in the preceding paragraph, different
+ branches <emphasis>will</emphasis> confuse your users. Do
+ everything you can to avoid this by clearly explaining the
+ different branches in a prominent page on your website and in a
+ Readme file in the <acronym>FTP</acronym> or
+ <acronym>HTTP</acronym> directory.</para>
<para>
I might also recommend against a mistake that I think Debian
</para>
<para>
- If you are going to do branches, especially early on, keep in
+ If you are going to use branches, especially early on, keep in
mind that people are conditioned to understand the terms
<quote>stable</quote> and <quote>development</quote> and you
probably can't go wrong with this simple and common division of
<varlistentry>
<term>Make sure all your branches are always available</term>
<listitem>
- <para>
- Like a lot of document, this should probably should go without
- saying but experience has taught me that it's not always
- obvious to people. It's a good idea to physically split up
- different branches in different directories or directory trees
- on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
- site. Linux accomplishes this by having all the v2.2 and a
- v2.3 subdirectory where it is immediately obvious (after you
- know their version numbering scheme) which directory is the
- most recent stable and the current development
- releases. Debian accomplishes this by naming all their
- distribution by name and then changing symlinks named
- <quote>stable,</quote> <quote>unstable</quote> and
- <quote>frozen</quote> to point to which ever distribution (by
- name) is in whatever stage. Both methods work and their are
- others. In any case, it is important that different branches
- are always available, are accessible from consistent
- locations, and that different branches are clearly
- distinguished from each other so your users know exactly what
- they want to be downloading and where to get it.
- </para>
+ <para>Like a lot of this document, this should probably should
+ go without saying but experience has taught me that it's not
+ always obvious to people. It's a good idea to physically split
+ up different branches in different directories or directory
+ trees on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
+ site. Linux accomplishes this by having kernels in a v2.2 and a
+ v2.3 subdirectory where it is immediately obvious (after you
+ know their version numbering scheme) which directory is for the
+ most recent stable and the current development releases. Debian
+ accomplishes this by naming all their distribution with names
+ (i.e. woody, potato, etc.) and then changing symlinks named
+ <quote>stable,</quote> <quote>unstable</quote> and
+ <quote>frozen</quote> to point to which ever distribution (by
+ name) is in whatever stage. Both methods work and there are
+ others. In any case, it is important that different branches
+ are always available, are accessible from consistent locations,
+ and that different branches are clearly distinguished from each
+ other so your users know exactly what they want to be
+ downloading and where to get it.</para>
</listitem>
</varlistentry>
<sect2 id="otherdev">
<title>Other Development issues</title>
<para>
- There are more issues around surrounding interaction with
- developers in a free software project that I can touch on in great
- detail in a HOWTO of this size. Please don't hesitate to contact
- me if you see any major omissions. Other smaller issues that are
- worth mentioning are:
+ There are more issues surrounding interaction with developers in a
+ free software project that I can not touch on in great detail in a
+ HOWTO of this size. Please don't hesitate to contact me if you see
+ any major omissions.
</para>
- <sect3>
+ <para>
+ Other smaller issues that are worth mentioning are:
+ </para>
+
+ <sect3 id="freezing">
<title>Freezing</title>
<para>
For those projects that choose to adopt a split development model
</para>
<para>
- Freeze come in two major forms. A <quote>feature freeze</quote>
+ Freezes come in two major forms. A <quote>feature freeze</quote>
is a period when no significant functionality is added to a
program. It is a period where established functionality (even
skeletons of barely working functionality) can be improved and
</para>
<para>
- Even you do not choose to appoint a release manager (<xref
+ Even if you never choose to appoint a release manager (<xref
linkend="releasemanager">), you will have an easier time
justifying the rejection or postponement of patches (<xref
linkend="patching"> before a release with a publicly stated
<sect3>
<title>Forking</title>
<para>
- Forks are the most extreme interpretation of a branch. A fork is
+ Forks are the most extreme version of a branch. A fork is
when a group of developers takes code from a free software
project and actually starts a brand new free software
project. The most famous example of a fork is Emacs and
<para>
The short version of the fork section is, <emphasis>don't do
them.</emphasis> Forks force developers to choose one project to
- work with, cause nasty political divisions, redundancy of work.
- Luckily, usually the threat of the fork is enough to scare the
- maintainer or maintainers of a project into changing the way they
- run their project to avoid it.
+ work with, cause nasty political divisions and redundancy of
+ work. Luckily, usually the threat of the fork is enough to scare
+ the maintainer or maintainers of a project into changing the way
+ they run their project to avoid it.
</para>
<para>
If you've worked your way up to here, congratulations, you are
nearing the end of this document. This final section describes some
of the situations in which you, in your capacity as project
- maintainer, will be interacting with users and gives some
+ maintainer, will be interacting with users. It gives some
suggestions on how these situations might be handled effectively.
</para>
</para>
<para>
- Users in the free software community are different than users in
- the world of proprietary software and they should be treated
- differently. Some ways in which the groups differ significantly
- follow:
+ Users in the free software community are different than developers
+ and are also different than users in the world of proprietary
+ software and they should be treated differently than either
+ group. Some ways in which the groups differ significantly follow:
</para>
<para>
work of others in the free software community and because the
element of competition present in the propriety software model is
absent (or at least in an extremely different form) in the free
- software development model your users will probably be the only
- project that does what you do (or at least the only one that does
- what you do in the way that you do it). This means your
- responsiveness to your users is even more important in that in
- the proprietary world.</para>
+ software development model, you will probably be the only project
+ that does what you do (or at least the only one that does what
+ you do in the way that you do it). This means your responsiveness
+ to your users is even more important than in the proprietary
+ software world.</para>
</listitem>
<listitem>
<para>In an almost paradoxical situation, free software projects
- have less immediate or dire consequences for ignoring their
- users--it is often easier to do. Because you don't usually need
- to compete with another product in the free software model,
- chances are good that you will not be scrambling to gain the
- features of the competitor's newest program. This means that your
- development process will have to be directed either internally,
- by your users or both.</para>
+ have less immediate or dire consequences for ignoring their users
+ altogether--it is also often easier to do. Because you don't
+ usually need to compete with another product in the free software
+ model, chances are good that you will not be scrambling to gain
+ the features of the competitor's newest program. This means that
+ your development process will have to be directed either
+ internally, by a commitment to your users or by both.</para>
</listitem>
</itemizedlist>
</para>
Trying to tackle this unique situation can only be done
indirectly. Developers and maintainers need to listen to users and
to try and be as responsive as possible. A solid knowledge of the
- situation recounted above is any free software developers best tool
+ situation recounted above is any free software developer's best tool
for shifting his development or leadership style to fit the unique
process of free software development. This chapters will try and
introduce some of the more difficult or important points in any
<para>
In addition to your users being your developers, they are also
(and perhaps more commonly) your testers. Before I get flamed, I
- should rephrase my sentence: <emphasis>some</emphasis> users are
- your testers.
+ should rephrase my sentence: <emphasis>some</emphasis> of your
+ users are your testers.
</para>
<para>
It is important that this distinction be made early on because not
- all of your users wants to be testers. Many users want to use
+ all of your users want to be testers. Many users want to use
stable software and don't care if they don't have the newest
greatest software with the latest and greatest features. These
users except a stable, tested piece of software with major or
<sect3>
<title>Automated testing</title>
<para>
- For many programs, many common and mistakes can be caught by
+ For many programs, many common mistakes can be caught by
automated means. Automated tests tend to be pretty good at
catching errors that you've run into several times before or
- something you just forget and not very good at finding errors,
- even major ones, that were totally unforeseen.
+ something you just forget. They are not very good at finding
+ errors, even major ones, that were totally unforeseen.
</para>
<para>
CVS comes with a bourne shell script called sanity.sh that is
worth looking at. Debian uses a program called lintian that
checks Debian packages for all of the most common errors. While
- using these scripts may not be possible, there is a host of other
- sanity checking software on the net that may be applicable (feel
- free to email any recommendations). None of these will create a
- bug-free release but they will avoid at least some major
+ use of these scripts may not be possible, there is a host of
+ other sanity checking software on the net that may be applicable
+ (feel free to email any recommendations). None of these will
+ create a bug-free release but they will avoid at least some major
oversights. Finally, if your programs become a long term
endeavor, you will find that there are certain errors that you
tend to make over and over. Start a collection of scripts that
</para>
<para>
- <itemizedlist>
+ <variablelist>
- <listitem>
- <para><emphasis>Make things simple for your testers.</emphasis>
- Your testers are doing you a favor so make it as easy as
- possible. This means that you should be careful to package your
- software in a way that is easy to find, unpack, install, and
- uninstall. This also means you should explain what you are
- looking for to each tester and make the means for reporting
- bugs simple and well established. The key is to provide as much
- structure as possible to make your tester's job easy and
- maintain as much flexibility as possible for those that want to
- do things a little differently.</para>
- </listitem>
+ <varlistentry>
+ <term>Make things simple for your testers</term>
+ <listitem>
+ <para>Your testers are doing you a favor so make it as easy as
+ possible for them. This means that you should be careful to
+ package your software in a way that is easy to find, unpack,
+ install, and uninstall. This also means you should explain
+ what you are looking for to each tester and make the means for
+ reporting bugs simple and well established. The key is to
+ provide as much structure as possible to make your testers'
+ jobs easy and maintain as much flexibility as possible for
+ those that want to do things a little differently.</para>
+ </listitem>
+ </varlistentry>
- <listitem>
- <para><emphasis>Be responsive to your testers.</emphasis> When
- your testers submit bugs, respond to them and respond
- quickly. Even if you are only responding to tell them that the
- bug has already been fixed, quick and consistent response make
- them feel like their work is heard, important, and
- appreciated.</para>
- </listitem>
+ <varlistentry>
+ <term>Be responsive to your testers</term>
+ <listitem>
+ <para>When your testers submit bugs, respond to them and
+ respond quickly. Even if you are only responding to tell them
+ that the bug has already been fixed, quick and consistent
+ responses make them feel like their work is heard, important,
+ and appreciated.</para>
+ </listitem>
+ </varlistentry>
- <listitem>
- <para><emphasis>Thank your testers.</emphasis> Thank them
- personally each time they send you patch. Thank them publicly
- in the documentation and the about section of your program. You
- appreciate your testers and your program would not be possible
- without their help. Make sure they know and pat them on the
- back by making sure the rest of the world knows it too. It will
- be appreciated more than you expected.</para>
- </listitem>
+ <varlistentry>
+ <term>Thank your testers</term>
+ <listitem>
+ <para>Thank them personally each time they send you
+ patch. Thank them publicly in the documentation and the about
+ section of your program. You appreciate your testers and your
+ program would not be possible without their help. Make sure
+ they know it. Pat them on the back to make sure the rest of
+ the world knows it too. It will be appreciated more than you
+ expected.</para>
+ </listitem>
- </itemizedlist>
+ </varlistentry>
+ </variablelist>
</para>
+
</sect3>
</sect2>
<!-- Section2: support -->
<sect2 id="support">
- <title>Setting up a Support Infrastructure</title>
+ <title>Setting up Support Infrastructure</title>
<para>
While testing is important, the large part of your interactions
support. The best way to make sure your users are adequately
supported in using your program is to set up a good infrastructure
for this purpose so that your developers and users help each other
- and less of the burden falls on you while people get quicker and
- better responses to their questions. This infrastructure comes in
- several forms:
+ and less of the burden falls on you. This way, people will also
+ get quicker and better responses to their questions. This
+ infrastructure comes in several major forms:
</para>
<sect3>
<title>Mailing lists</title>
<para>
Aside from documentation, effective mailing lists will be your
- greatest tool in supporting user support. Running a mailing list
+ greatest tool in providing user support. Running a mailing list
well is more complicated than installing mailing list software
- onto a machine.
+ onto a machine.
</para>
<sect4>
lists (perhaps into project-user@host and project-devel@host)
and enforce the division. If people post a development question
onto -user, politely ask them to repost it onto -devel and vise
- versa. Subscribe yourself to both groups and encourage primarily
- developers to do the same.
+ versa. Subscribe yourself to both groups and encourage all
+ primarily developers to do the same.
</para>
<para>
- This system provides so that no one person is stuck doing all of
+ This system provides that no one person is stuck doing all of
the support work and works so that users learn more about the
- program, they can help new users with their questions.
+ program, they can help newer users with their questions.
</para>
</sect4>
<title>Choose mailing list software well</title>
<para>
Please don't make the selection of mailing list software
- lightly. Please consider easy accessibility by users without a
- lot of technical experience so you want to be as easy as
+ impulsively. Please consider easy accessibility by users without
+ a lot of technical experience so you want to be as easy as
possible. Web accessibility to an archive of the list is also
important.
</para>
url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
long time advocate of majordomo, I would now recommend any
- project choose GNU Mailman. It fulfills the criteria listed above
- and makes it easier to do. It provides a good mailing list
- program for a free software project maintainer as opposed to a
- good mailing list application for a mailing list administrator.
+ project choose GNU Mailman. It fulfills the criteria listed
+ above and makes it easier to do so. It provides a good mailing
+ list program for a free software project maintainer as opposed
+ to a good mailing list application for a mailing list
+ administrator.
</para>
<para>
<title>Other support ideas</title>
<para>
- A mailing list and accessible documentation all you can do to set
- up good user support infrastructure. Be creative. If you stumble
- across something works well, email me and I'll include it here in
- the HOWTO.
+ A mailing list and accessible documentation are far from all you
+ can do to set up good user support infrastructure. Be
+ creative. If you stumble across something works well, email me
+ and I'll include it here in the HOWTO.
</para>
+
<sect4>
<title>Make your self accessible</title>
<para>
weight. As well as a damn good web browser, the mozilla project
has spawned a sub-project resulting in a bug tracking system
called <ulink
- url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>.
+ url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
+ which has become extremely possible and which I like quite a
+ bit.
</para>
<para>
tracking system than on the bugs or the projects themselves. If
a project continues to grow, use of a bug tracking system can
provide an easy standard way for users and testers to report
- bugs and for developers and maintainers to fix them in an
- orderly fashion.
+ bugs and for developers and maintainers to fix them and track
+ them in an orderly fashion.
</para>
</sect4>
</sect3>
<title>Releasing Your Program</title>
<para>
- As mentioned earlier in the HOWTO, the first rule or releasing is,
+ As mentioned earlier in the HOWTO, the first rule of releasing is,
<emphasis>release something useful.</emphasis> Non-working or
not-useful software will not attract anyone to your
project. People will be turned off of your project and be likely
to simply gloss over it next time they see a new version
announced. Half-working software, if useful, will intrigue people,
- whet their appetites for the version to come, and encourage them
- to join the development process.
+ whet their appetites for versions to come, and encourage them to
+ join the development process.
</para>
<sect3>
is an incredibly important and incredibly stressful decision. But
it needs to be done. My advice is to try and make something that
is complete enough to be usable and incomplete enough to allow
- for flexibility and imagination by your future developers. It's
- not an easy decision. Ask for help on a local Linux User Group
- mailing list or from a group of developer friends.
+ for flexibility and room for imagination by your future
+ developers. It's not an easy decision. Ask for help on a local
+ Linux User Group mailing list or from a group of developer
+ friends.
</para>
<para>
<para>
If you've followed the guidelines described in this HOWTO up
until this point, the mechanics of doing a release are going to
- be the easy part of releasing. If you have set up a consistent
+ be the easy part of releasing. If you have set up consistent
distribution locations and the other infrastructure described in
- the preceding sections, releasing should be as simple as
- building the package, checking it once over, and uploading it
- into the appropriate place and then reflecting the release on
- your website.
+ the preceding sections, releasing should be as simple as building
+ the package, checking it once over, and uploading it into the
+ appropriate place and then reflecting the release on your
+ website.
</para>
</sect3>
<varlistentry>
<term>alpha releases</term>
<listitem>
- <para>
- Alpha releases are expected to be unstable, perhaps a little
- unsafe, but definitely usable. Alpha versions should have
- full functionality and limited testing. They can have known
- bugs and kinks that have yet to be worked out. Before 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>
+ <para>Alpha releases are expected to be unstable, perhaps a
+ little unsafe, but definitely usable. Alpha versions should
+ have full functionality and limited testing. They can 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 releases are general expected to be usable and
- slightly unstable, although definitely
- <emphasis>not</emphasis> unsafe. 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 in the very
- near future and can help keep interest by giving people
- <emphasis>something.</emphasis>
- </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 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>
- Development release is much more vague term than
- <quote>alpha</quote> or <quote>beta</quote>. I usually choose
- to reserve the term for discussion of a development
- branch. 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 to alpha or beta stages though and if I
- were to release a pre-alpha release in order to keep interest
- in my project live, this is probably how I would have to label
- it.
- </para>
+ <para><quote>Development release</quote> is much 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 to alpha or beta stages though and if I were
+ to release a pre-alpha version of a piece of software in order
+ to keep interest in my project live, this is probably how I
+ would have to label it.</para>
</listitem>
</varlistentry>
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 it right away.
+ downloads for those that want to try it right away.
</para>
<para>
<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 list
- announcements.
+ are almost more important than announcements on mailing lists.
</para>
<para>
- Visit the <ulink url="http://freshmeat.net">freshmeat
+ 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 on their site and in their
+ 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 skim it every night for any
interesting new releases).
</para>
-
- <para>
- Once you've finished this...
- </para>
-
- <para>
- Congratulations. You've not the maintainer of an active free
- software project. Good luck and feel free to stay in touch with
- me about your experiences. I'd love to incorporate them into this
- HOWTO.
- </para>
</sect3>
</sect2>
</sect1>
projects / fspm_howto / blobdiff