</para>
<para>
- The latest version number of this document should always be listed
- at my webpage at<ulink url="http://people.debian.org/~mako/">
- http://people.debian.org/~mako/</ulink> Debian.
+ The latest version number of this document should always be listed
+ on <ulink url="http://people.debian.org/~mako/">my webpage at
+ Debian</ulink>.
</para>
<para>
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 (at) debian (dot) org</email>.
+ <email>mako@debian. org</email>.
</para>
</sect2>
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
- hesitate to contact me at: <email>mako (at) debian (dot)
- org</email>.
+ hesitate to contact me at: <email>mako@debian.org</email>.
</para>
</sect2>
</sect1>
</para>
<sect3 id=identifyidea>
- <title>Indentify and Articulate Your Idea</title>
+ <title>Indentify 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
</sect3>
<sect3 id=evalulateidea>
- <title>Evaluate Your Idea</title>
+ <title>Evaluate your idea</title>
<para>
In evaluating your idea, you need to ask yourself questions.
<para>
<variablelist>
<varlistentry>
- <term>freshmeat.net</term>
+ <term>freshmeat.net:</term>
<listitem>
<para><ulink url="http://freshmeat.net">freshmeat</ulink>
describes itself as, <quote>the Web's largest index of Linux
</varlistentry>
<varlistentry>
- <term>Slashdot</term>
+ <term>Slashdot:</term>
<listitem>
<para><ulink url="http://slashdot.org">Slashdot</ulink>
provides <quote>News for Nerds: Stuff that Matters,</quote>
</varlistentry>
<varlistentry>
- <term>SourceForge</term>
+ <term>SourceForge:</term>
<listitem>
<para><ulink url="http://sourceforge.net">SourceForge</ulink>
houses and facilitates a growning number of open source and
</varlistentry>
<varlistentry>
- <term>Google and Google's Linux Search</term>
+ <term>Google and Google's Linux Search:</term>
<listitem>
<para><ulink url="http://www.google.com">Google</ulink> and
<ulink url="http://www.google.com/linux"> Google's Linux
</para>
<sect3 id="chooselicense">
- <title>Choosing a License</title>
+ <title>Choosing a license</title>
<para>
Any discussion of licenses is also sure to generate at least a
</sect3>
<sect3 id="licensechoose">
- <title>The Mechanics of Licensing</title>
+ <title>The mechanics of licensing</title>
<para>
The text of the <acronym>GPL</acronym> offers <ulink
</sect3>
<sect3 id="licensewarning">
- <title>Final License Warning</title>
+ <title>Final license warning</title>
<para>
Please, please, please, place your software under some
</para>
<para>
- Whether you plan on having a split development model<xref
- linkend="branches"> or only one version released at a time, my
- experience with several free software projects and with the
- Debian project has taught me taht use of Linux's version
- numbering system is worth taking into consideration. In Debian,
- all minor versions are stable 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 frusterated 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.
+ Whether you plan on having a split development model (as
+ described in <xref linkend="branches">) or only one version
+ released at a time, my experience with several free software
+ projects and with the Debian project has taught me taht use of
+ Linux's version numbering system is worth taking into
+ consideration. In Debian, all minor versions are stable
+ 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 frusterated 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.
</para>
</listitem>
<sect2 id="documentation">
<title>Documentation</title>
- <para></para>
+
+ <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 usuable.</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.
+ </para>
+
+ <para>
+ A combination of tradition and necessity has resulted in a
+ semi-regular system method 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
+ 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:
+ </para>
+
+ <sect3>
+ <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.
+ </para>
+
+ <para>
+ Man pages are not difficult to write. There is excellent
+ documentation on the man page 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
+ url="http://www.schweikhardt.net/man_page_howto.html">from
+ Schweikhardt's site</ulink> or <ulink
+ url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
+ <acronym>LDP</acronym></ulink>.
+ </para>
+
+ <para>
+ It is also possible to write man pages using DocBook SGML and
+ convert them into man pages. Because manpages 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.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Command line accessable documentation</title>
+
+ <para>
+ Most users will expect the most basic amount of documentation to
+ be easily availabe 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
+ sentance) description of the program, a list of commands, all the
+ major options, 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>
+apt 0.3.19 for i386 compiled on May 12 2000 21:17:27
+Usage: apt-get [options] command
+ apt-get [options] install pkg1 [pkg2 ...]
+
+apt-get is a simple command line interface for downloading and
+installing packages. The most frequently used commands are update
+and install.
+
+Commands:
+ update - Retrieve new lists of packages
+ upgrade - Perform an upgrade
+ install - Install new packages (pkg is libc6 not libc6.deb)
+ remove - Remove packages
+ source - Download source archives
+ dist-upgrade - Distribution upgrade, see apt-get(8)
+ dselect-upgrade - Follow dselect selections
+ clean - Erase downloaded archive files
+ autoclean - Erase old downloaded archive files
+ check - Verify that there are no broken dependencies
+
+Options:
+ -h This help text.
+ -q Loggable output - no progress indicator
+ -qq No output except for errors
+ -d Download only - do NOT install or unpack archives
+ -s No-act. Perform ordering simulation
+ -y Assume Yes to all queries and do not prompt
+ -f Attempt to continue if the integrity check fails
+ -m Attempt to continue if archives are unlocatable
+ -u Show a list of upgraded packages as well
+ -b Build the source package after fetching it
+ -c=? Read this configuration file
+ -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
+See the apt-get(8), sources.list(5) and apt.conf(5) manual
+pages for more information and options.
+ </screen>
+
+ <para>
+ It has become a GNU convention to make this information
+ accessable 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
+ choose to use different method, be prepared for the flames and
+ 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
+ package containing source code. In a source distribution, most of
+ these files can be stored in a the root directery of the source
+ distribution or in a subdirectory of the root called
+ <quote>doc</quote> or <quote>Documentation</quote>. These files include:
+ </para>
+ <para>
+ <variablelist>
+ <varlistentry>
+ <term>README or Readme</term>
+
+ <listitem>
+ <para>
+ A document containing all the basic installation,
+ compiliation, 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>
+ <varlistentry>
+ <term>INSTALL or Install</term>
+
+ <listitem>
+ <para>
+ The INSTALL file should be much shorter than the INSTALL file
+ and should quicly 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>
+ </listitem>
+
+ </varlistentry>
+ <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 teh 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 signifigant upgrade.
+ </para>
+ </listitem>
+
+ </varlistentry>
+ <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 useability, and decrease
+ headaches on all sides.
+ </para>
+ </listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Website</title>
+ <para>
+ It's only a sort of 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.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Other documentation hints</title>
+
+ <para>
+ It doesn't hurt to distribute any documentation for your program
+ from your website or anywhere else (FAQs etc) with the
+ program. Make a FAQ by cutting and posting common questions and
+ answers from a mailing list or your own email. Then, don't
+ hesitate through this in the programs tarball. If people don't
+ need it, they will delete it. I can repeat it over and over:
+ <emphasis>Too much documentation is not a sin.</emphasis>
+ </para>
+
+ <para>
+ All your documentation should be in plaintext, or, in cases where
+ it is on your website primarily, in HTML. Everyone can cat a
+ file, everyone has a pager, (almost) everyone can render
+ HTML. <emphasis>You are welcome to distribute information in PDF,
+ PostScript, RTF, or any number of other widely used formats but
+ this information must also be available in plaintext or HTML or
+ people will be very angry at you.</emphasis>
+ </para>
+ </sect3>
</sect2>
<!-- Section2: presentation -->
<sect2 id="presentation">
<title>Other Presentation Issues</title>
- <para></para>
- </sect2>
+ <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
+ hopes that they may remind a developer of something they may have
+ forgotten.
+ </para>
+
+ <sect3>
+ <title>Package formats</title>
+ <para>
+ Package formats may differ depending on the system you are
+ developing for. For windows based software, Zip archives (.zip)
+ usually serve as the package format of choice. If you are
+ developing for GNU/Linux, *BSD, or any UN*X, make sure that your
+ source code is always available in tar'ed and gzip'ed format
+ (.tar.gz). UNIX compress (.Z) has gone out of style and
+ usefulness and faster computers have brought bzip2 (.bz2) into
+ the spotlit as a more effective compression medium. I now make
+ all my releases available in both gzip'ed and bzip2'ed formats.
+ </para>
+
+ <para>
+ Binary packages are largely distribution specific. You can build
+ binary packages against a current version of a major
+ distribution, you will only make your users happy. Try to foster
+ relationships with users or developers of large distribution to
+ develop a system for consistent binary packages. It's often a
+ good idea to provide RedHat <acronym>RPM</acronym>'s (.rpm),
+ Debian deb's (.deb) and source <acronym>RPM</acronym>'s
+ <acronym>SRPM</acronym>'s. Binary packages can also be compiled
+ against a specified system with specificed libraries and
+ distributed in tar.gz format as well. <emphasis>Remember: While
+ these binaries packages are nice, geting the source packaged and
+ released should always be your priority. Other can and will do
+ the the binary packages for you.</emphasis>
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Useful tidbits and presentation hints</title>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis>Make sure that your program can always be found in a
+ single location.</emphasis> Often this means that you have a
+ single directory accessable via <acronym>FTP</acronym> or
+ <acronym>HTTP</acronym> where the newest version will be
+ 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.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis>Make sure that there is a consistent email address
+ for bug reports.</emphasis> It's usually a good idea to make
+ this something that is NOT your primary email address like
+ 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
+ project becomes as huge as you hope it will.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </sect3>
+ </sect2>
</sect1>
<!-- Section1: starting: END -->
<primary>fswd!developers</primary>
</indexterm>
+ <para>
+ Once you have gotten the project started, you have gotten over 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
+ rhough interactions with developers and with users.
+ </para>
+
+ <para>
+ The difference between free software development and propriety
+ software development is th 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 sipmly 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>
+ </para>
+
<!-- Section2: delegation -->
<sect2 id="delegation">
<title>Delegating Work</title>
+
+ <para>
+ By now, you've hypothetically followed me through the writing of a
+ piece of software, the creation of a website and a skeleton of
+ documentation and functionality 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 people hopefully becoming
+ interested and people want to help and patches begin flowing in.
+ </para>
+
+ <para>
+ Like the parent of any child who grows up, it's now time to wince
+ and smile and do most difficult thing in any parents life: It's
+ time to let go.
+ </para>
+
+ <para>
+ Delegation is the politcal way of describing this process of
+ <quote>letting go.</quote> It is the process of handing
+ responsibility, and power, over aspects of your project to other
+ reponsible 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.
+ </para>
+
+ <para>
+ As your project progresses, you will notice people who put
+ signfigant amounts of time and effort into your project. These
+ will be the people submitting the most patches, posting most on
+ the mailing lists, engaging in long email discussions. It is your
+ responsiblity to contact these people and to try and shift some of
+ the power and responsiblity of project maintainer toward
+ them. There are several easy weays you can do this:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis>Allow a larger group of people write access to your
+ CVS reponsitory and make real efforts towards rule by a
+ committee.</emphasis>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis>Publicly appoint someone as the release manager for a
+ specific release.</emphasis> A relase manager is usually
+ responsible for coordinating testing, encforcing a code freeze,
+ being responsible for stability and quality control, packaging
+ up the software, and placing it in the approrpriate places to
+ be downloaded.
+ </para>
+
+ <para>
+ This use of the release manager is a good way to give yourself
+ a break and to shift the responsibility for accepting and
+ rejecting patches to somenoe 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.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <emphasis>Delegating control of an entire branch.</emphasis>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </sect2>
+
+<!-- Section2: patching -->
+
+ <sect2 id="patching">
+ <title>Accepting and Rejecting Patches</title>
<para></para>
</sect2>
+
<!-- Section2: branches -->
<sect2 id="branches">
<title>Avoiding the Code Cram Effect</title>
<para></para>
</sect2>
-
-<!-- Section2: patching -->
-
- <sect2 id="patching">
- <title>Accepting and Rejecting Patches</title>
- <para></para>
- </sect2>
</sect1>
<!-- Section1: users -->
<primary>fswd!users</primary>
</indexterm>
+<!-- Section2: testing -->
+
+ <sect2 id="testing">
+ <title>Testing and Testers</title>
+ <para></para>
+ </sect2>
+
+<!-- Section2: support -->
+
+ <sect2 id="support">
+ <title>Setting up a Support Infrastructure</title>
+ <para></para>
+ </sect2>
+
+<!-- Section2: releasing -->
+
+ <sect2 id="releasing">
+ <title>Releasing Your Program</title>
+ <para></para>
+ </sect2>
<!-- Section2: announcing -->
<para></para>
</sect2>
-<!-- Section2: testing -->
- <sect2 id="testing">
- <title>Testing and Testers</title>
- <para></para>
- </sect2>
</sect1>
</article>
projects / fspm_howto / blobdiff