mirror of https://github.com/tLDP/LDP
599 lines
24 KiB
Plaintext
599 lines
24 KiB
Plaintext
<!-- This is the Software Release Practice HOWTO, SGML source -- >
|
|
<!-- Eric S. Raymond, esr@snark.thyrsus.com -- >
|
|
|
|
<!-- Reference RFC 2026-2028? -->
|
|
|
|
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<title>Software Release Practice HOWTO
|
|
<author>Eric S. Raymond <esr@thyrsus.com>
|
|
<date>2.3, 1 June 2000
|
|
|
|
<abstract>
|
|
This HOWTO describes good release practices for Linux open-source projects.
|
|
By following these practices, you will make it as easy as possible for
|
|
users to build your code and use it, and for other developers to understand
|
|
your code and cooperate with you to improve it.
|
|
|
|
This document is a must-read for novice developers. Experienced developers
|
|
should review it when they are about to release a new project. It will be
|
|
revised periodically to reflect the evolution of good-practice standards.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>Introduction
|
|
<p>
|
|
<sect1>Why this document?
|
|
<p>
|
|
There is a large body of good-practice traditions for open-source code that
|
|
helps other people port, use, and cooperate with developing it. Some of these
|
|
conventions are traditional in the Unix world and predate Linux; others
|
|
have developed recently in response to particular new tools and technologies
|
|
such as the World Wide Web.
|
|
|
|
This document will help you learn good practice. It is organized into
|
|
topic sections, each containing a series of checklist items. Think of
|
|
these as a pre-flight checklist for your distribution.
|
|
|
|
<sect1>New versions of this document
|
|
<p>
|
|
This document will be posted monthly to the newsgroups
|
|
<tt>comp.os.linux.answers</tt> . The document is archived on a number
|
|
of Linux FTP sites, including <tt>metalab.unc.edu</tt> in
|
|
<tt>pub/Linux/docs/HOWTO</tt>.
|
|
|
|
You can also view the latest version of this HOWTO on the World
|
|
Wide Web via the URL <url
|
|
url="http://metalab.unc.edu/LDP/HOWTO/Software-Release-Practice.html">.
|
|
|
|
Feel free to mail any questions or comments about this HOWTO to
|
|
Eric S. Raymond, <url
|
|
url="mailto:esr@snark.thyrsus.com" name="esr@snark.thyrsus.com">.
|
|
|
|
<sect>Good project- and archive- naming practice
|
|
<p>
|
|
As the load on maintainers of archives like Metalab, the PSA site and CPAN
|
|
increases, there is an increasing trend for submissions to be processed
|
|
partly or wholly by programs (rather than entirely by a human).
|
|
|
|
This makes it more important for project and archive-file names to fit
|
|
regular patterns that computer programs can parse and understand.
|
|
|
|
<sect1>Use GNU-style names with a stem and major.minor.patch numbering.
|
|
<p>
|
|
It's helpful to everybody if your archive files all have GNU-like
|
|
names -- all-lower-case alphanumeric stem prefix, followed by a dash,
|
|
followed by a version number, extension, and other suffixes.
|
|
|
|
Let's suppose you have a project you call `foobar' at version 1,
|
|
release 2, level 3. If it's got just one archive part (presumably the
|
|
sources), here's what its names should look
|
|
|
|
<descrip>
|
|
<tag>foobar-1.2.3.tar.gz</tag> The source archive
|
|
|
|
<tag>foobar.lsm</tag> The LSM file (assuming you're submitting to Metalab).
|
|
|
|
</descrip>
|
|
|
|
Please <em>don't</em> use these:
|
|
|
|
<descrip>
|
|
<tag>foobar123.tar.gz</tag>This looks to many programs like an archive
|
|
for a project called`foobar123' with no version number.
|
|
|
|
<tag>foobar1.2.3.tar.gz</tag>This looks to many programs like an archive
|
|
for a project called `foobar1' at version 2.3.
|
|
|
|
<tag>foobar-v1.2.3.tar.gz</tag> Many programs think this goes with a
|
|
project called `foobar-v1'.
|
|
|
|
<tag>foo_bar-1.2.3.tar.gz</tag> The underscore is hard for people to speak,
|
|
type, and remember
|
|
|
|
<tag>FooBar-1.2.3.tar.gz</tag> Unless you <em>like</em> looking like a
|
|
marketing weenie. This is also hard for people to speak, type, and remember.
|
|
</descrip>
|
|
|
|
If you have to differentiate between source and binary archives, or
|
|
between different kinds of binary, or express some kind of build
|
|
option in the file name, please treat that as a file extension to go
|
|
<em>after</em> the version number. That is, please do this:
|
|
|
|
<descrip>
|
|
<tag>foobar-1.2.3.src.tar.gz </tag> sources
|
|
|
|
<tag>foobar-1.2.3.bin.tar.gz </tag> binaries, type not specified
|
|
|
|
<tag>foobar-1.2.3.bin.ELF.tar.gz </tag> ELF binaries
|
|
|
|
<tag>foobar-1.2.3.bin.ELF.static.tar.gz </tag> ELF binaries statically linked
|
|
|
|
<tag>foobar-1.2.3.bin.SPARC.tar.gz </tag> SPARC binaries
|
|
</descrip>
|
|
|
|
Please <em>don't</em> use names like `foobar-ELF-1.2.3.tar.gz', because
|
|
programs have a hard time telling type infixes (like `-ELF') from the
|
|
stem.
|
|
|
|
A good general form of name has these parts in order:
|
|
|
|
<enum>
|
|
<item>project prefix
|
|
<item>dash
|
|
<item>version number
|
|
<item>dot
|
|
<item>"src" or "bin" (optional)
|
|
<item>dot or dash (dot preferred)
|
|
<item>binary type and options (optional)
|
|
<item>archiving and compression extensions
|
|
</enum>
|
|
|
|
<sect1>But respect local conventions where appropriate
|
|
<p>
|
|
Some projects and communities have well-defined conventions for names and
|
|
version numbers that aren't necessarily compatible with the above advice.
|
|
For instance, Apache modules are generally named like mod_foo, and have
|
|
both their own version number and the version of Apache with which they
|
|
work. Likewise, Perl modules have version numbers that can be treated as
|
|
floating point numbers (e.g., you might see 1.303 rather than 1.3.3), and
|
|
the distributions are generally named Foo-Bar-1.303.tar.gz for version
|
|
1.303 of module Foo::Bar.</p>
|
|
|
|
<p>Look for and respect the conventions of specialized
|
|
communities and developers; for general use, follow the above
|
|
guidelines.</p>
|
|
|
|
<sect1>Try hard to choose a name prefix that is unique and easy to type
|
|
<p>
|
|
The stem prefix should be common to all a project's files, and it
|
|
should be easy to read, type, and remember. So please don't use
|
|
underscores. And don't capitalize or BiCapitalize without extremely
|
|
good reason -- it messes up the natural human-eyeball search order and
|
|
looks like some marketing weenie trying to be clever.
|
|
|
|
It confuses people when two different projects have the same stem name.
|
|
So try to check for collisions before your first release. A good place
|
|
to check is the <url url="http://metalab.unc.edu/pub/Linux" name="index
|
|
file of Metalab">.
|
|
|
|
<sect>Good licensing and copyright practice: the theory
|
|
<p>
|
|
The license you choose defines the social contract you wish to set up
|
|
among your co-developers and users. The copyright you put on the software
|
|
will function mainly as a legal assertion of your right to set license
|
|
terms on the software and derivative works of the software.
|
|
|
|
<sect1>Open source and copyrights
|
|
<p>
|
|
Anything that is not public domain has a copyright, possibly more than
|
|
one. Under the Berne Convention (which has been U.S. law since 1978),
|
|
the copyright does not have to be explicit. That is, the authors of a
|
|
work hold copyright even if there is no copyright notice.<P>
|
|
|
|
Who counts as an author can be very complicated, especially for software
|
|
that has been worked on by many hands. This is why licenses are
|
|
important. By setting out the terms under which material can be used,
|
|
they grant rights to the users that protect them from arbitrary
|
|
actions by the copyright holders.<P>
|
|
|
|
In proprietary software, the license terms are designed to protect the
|
|
copyright. They're a way of granting a few rights to users while
|
|
reserving as much legal territory is possible for the owner (the
|
|
copyright holder). The copyright holder is very important, and the
|
|
license logic so restrictive that the exact technicalities of the
|
|
license terms are usually unimportant.
|
|
|
|
In open-source software, the situation is usually the exact opposite;
|
|
the copyright exists to protect the license. The only rights the
|
|
copyright holder always keeps are to enforce the license. Otherwise,
|
|
only a few rights are reserved and most choices pass to the user. In
|
|
particular, the copyright holder cannot change the terms on a copy you
|
|
already have. Therefore, in open-source software the copyright holder
|
|
is almost irrelevant -- but the license terms are very important.
|
|
|
|
Normally the copyright holder of a project is the current project leader or
|
|
sponsoring organization. Transfer of the project to a new leader is often
|
|
signaled by changing the copyright holder. However, this is not a hard and
|
|
fast rule; many open-source projects have multiple copyright holders, and
|
|
there is no instance on record of this leading to legal problems.
|
|
|
|
Some projects choose to assign copyright to the Free Software Foundation,
|
|
on the theory that it has an interest in defending open source and lawyers
|
|
available to do it.
|
|
|
|
<sect1>What qualifies as open source
|
|
<p>
|
|
For licensing purposes, we can distinguish several different kinds of
|
|
rights that a license may convey. Rights to <em>copy and
|
|
redistribute</em>, rights to <em>use</em>, rights to <em>modify for
|
|
personal use</em>, and rights to <em>redistribute modified
|
|
copies</em>. A license may restrict or attach conditions to any
|
|
of these rights.
|
|
|
|
The <url name="Open Source Initiative" url="http://www.opensource.org"> is
|
|
the result of a great deal of thought about what makes software ``open
|
|
source'' or (in older terminology) ``free''. Its constraints on licensing
|
|
require that:
|
|
|
|
<enum>
|
|
<item>An unlimited right to copy be granted.
|
|
<item>An unlimited right to use be granted.
|
|
<item>An unlimited right to modify for personal use be granted.
|
|
</enum>
|
|
|
|
The guidelines prohibit restrictions on redistribution of modified
|
|
binaries; this meets the needs of software distributors, who need to be
|
|
able to ship working code without encumbrance. It allows authors
|
|
to require that modified sources be redistributed as pristine
|
|
sources plus patches, thus establishing the author's intentions and an
|
|
``audit trail'' of any changes by others.
|
|
|
|
The OSD is the legal definition of the `OSI Certified Open Source'
|
|
certification mark, and as good a definition of ``free software'' as
|
|
anyone has ever come up with. All of the standard licenses (MIT, BSD,
|
|
Artistic, and GPL/LGPL) meet it (though some, like GPL, have other
|
|
restrictions which you should understand before choosing it).
|
|
|
|
Note that licenses which allow noncommercial use only do <em>not</em>
|
|
qualify as open-source licenses, even if they are decorated with
|
|
``GPL'' or some other standard license. They discriminate against
|
|
particular occupations, persons, and groups. They make life too
|
|
complicated for CD-ROM distributors and others trying to spread
|
|
open-source software commercially.
|
|
|
|
<sect>Good licensing and copyright practice: the practice
|
|
<p>
|
|
Here's how to translate the theory above into practice:
|
|
|
|
<sect1>Make yourself or the FSF the copyright holder
|
|
<p>
|
|
In some cases, if you have a sponsoring organization behind you with
|
|
lawyers, you might wish to give copyright to that organization.
|
|
|
|
<sect1>Use a license conformant to the Open Source Definition
|
|
<p>
|
|
The Open Source Definition is the community gold standard for licenses.
|
|
The OSD is not a license itself; rather, it defines a minimum set of rights
|
|
that a license must guarantee in order to be considered an open-source
|
|
license. The OSD, and supporting materials, may be found at the web site
|
|
of the <url name="Open Source Initiative" url="http://www.opensource.org">.
|
|
|
|
<sect1>Don't write your own license if you can possibly avoid it.
|
|
<p>
|
|
The widely-known OSD-conformant licenses have well-established interpretive
|
|
traditions. Developers (and, to the extent they care, users) know what
|
|
they imply, and have a reasonable take on the risks and tradeoffs they
|
|
involve. Therefore, use one of the standard licenses carried on the OSI
|
|
site if at all possible.
|
|
|
|
If you must write your own license, be sure to have it certified by OSI. This
|
|
will avoid a lot of argument and overhead. Unless you've been through it,
|
|
you have no idea how nasty a licensing flamewar can get; people become
|
|
passionate because the licenses are regarded as almost-sacred covenants
|
|
touching the core values of the open-source community.
|
|
|
|
Furthermore, the presence of an established interpretive tradition may
|
|
prove important if your license is ever tested in court. At time of
|
|
writing (late 1999) there is no case law either supporting or invalidating
|
|
any open-source license. However, it is a legal doctrine (at least in
|
|
the U.S., and probably in other common-law countries such as England
|
|
and the rest of the British Commonwealth) that courts are supposed to
|
|
interpret licenses and contracts according to the expectations and
|
|
practices of the community in which they originated.
|
|
|
|
<sect>Good development practice
|
|
<p>
|
|
Most of these are concerned with ensuring portability, not only across
|
|
Linuxes but to other Unixes as well. Being portable to other Unixes
|
|
is not just a worthy form of professionalism and hackerly politeness,
|
|
it's valuable insurance against future changes in Linux itself.
|
|
|
|
Finally, other people <em>will</em> try to build your code on non-Linux
|
|
systems; portability minimizes the number of annoying perplexed email
|
|
messages you will get.
|
|
|
|
<sect1>Write either pure ANSI C or a portable scripting language
|
|
<p>
|
|
For portability and stability, you should write either in ANSI C or a
|
|
scripting language that is guaranteed portable because it has just one
|
|
cross-platform implementation.
|
|
|
|
Scripting languages that qualify include Python, Perl, Tcl, and Emacs Lisp.
|
|
Plain old shell does <em>not</em> qualify; there are too many different
|
|
implementations with subtle idiosyncracies, and the shell environment
|
|
is subject to disruption by user customizations such as shell aliases.
|
|
|
|
Java holds promise as a portable language, but the Linux-available
|
|
implementations are still scratchy and poorly integrated with Linux.
|
|
Java is still a bleeding-edge choice, though one likely to become more
|
|
popular as it matures.
|
|
|
|
<sect1>Follow good C portability practices
|
|
<p>
|
|
If you are writing C, do feel free to use the full ANSI features --
|
|
including function prototypes, which will help you spot cross-module
|
|
inconsistancies. The old-style K&R compilers are history.
|
|
|
|
On the other hand, do <em>not</em> assume that GCC-specific
|
|
features such as the `-pipe' option or nested functions are available.
|
|
These will come around and bite you the second somebody ports to a
|
|
non-Linux, non-GCC system.
|
|
|
|
<sect1>Use autoconf/automake/autoheader
|
|
<p>
|
|
If you're writing C, use autoconf/automake/autoheader to handle portability
|
|
issues, do system-configuration probes, and tailor your makefiles. People
|
|
building from sources today expect to be able to type "configure; make"
|
|
and get a clean build -- and rightly so.
|
|
|
|
<sect1>Sanity-check your code before release
|
|
<p>
|
|
If you're writing C, test-compile with -Wall and clean up the errors at
|
|
least once before each release. This catches a surprising number of
|
|
errors. For real thoroughness, compile with -pedantic as well.
|
|
|
|
If you're writing Perl, check your code with perl -c (and maybe -T, if
|
|
applicable). Use perl -w and 'use strict' religiously. (See the Perl
|
|
documentation for discussion.)
|
|
|
|
<sect1>Sanity-check your documentation and READMEs before release
|
|
<p>
|
|
Run a spell-checker on them. If you look like you can't spell and
|
|
don't care, pleople will assume you code is sloppy and careless too.
|
|
|
|
<sect>Good distribution-making practice
|
|
<p>
|
|
These guidelines describe how your distribution should look when someone
|
|
downloads, retrieves and unpacks it.
|
|
|
|
<sect1>Make sure tarballs always unpack into a single new directory
|
|
<p>
|
|
The single most annoying mistake newbie developers make is to build
|
|
tarballs that unpack the files and directories in the distribution into
|
|
the current directory, potentially stepping on files already located there.
|
|
<em>Never do this!</em>
|
|
|
|
Instead, make sure your archive files all have a common directory part
|
|
named after the project, so they will unpack into a single top-level
|
|
directory directly <em>beneath</em> the current one.
|
|
|
|
Here's a makefile trick that, assuming your distribution directory is
|
|
named `foobar' and SRC contains a list of your distribution files,
|
|
accomplishes this. It requires GNU tar 1.13
|
|
|
|
<verb>
|
|
VERS=1.0
|
|
foobar-$(VERS).tar.gz:
|
|
tar --name-prefix='foobar-$(VERS)/' -czf foobar-$(VERS).tar.gz $(SRC)
|
|
</verb>
|
|
|
|
If you have an older tar program, do something like this:
|
|
|
|
<verb>
|
|
foobar-$(VERS).tar.gz:
|
|
@ls $(SRC) | sed s:^:foobar-$(VERS)/: >MANIFEST
|
|
@(cd ..; ln -s foobar foobar-$(VERS))
|
|
(cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`)
|
|
@(cd ..; rm foobar-$(VERS))
|
|
</verb>
|
|
|
|
<sect1>Have a README
|
|
<p>
|
|
Have a file called README or READ.ME that is a roadmap of your source
|
|
distribution. By ancient convention, this is the first file intrepid
|
|
explorers will read after unpacking the source.
|
|
|
|
Good things to have in the README include:
|
|
|
|
<itemize>
|
|
<item>A brief description of the project.
|
|
<item>A pointer to the project website (if it has one)
|
|
<item>Notes on the developer's build environment and potential portability
|
|
problems.
|
|
<item>A roadmap describing important files and subdirectories.
|
|
<item>Either build/installation instructions or a pointer to a file
|
|
containing same (usually INSTALL).
|
|
<item>Either a maintainers/credits list or a pointer to a file containing
|
|
same (usually CREDITS).
|
|
<item>Either recent project news or a pointer to a file containing same
|
|
(usually NEWS).
|
|
</itemize>
|
|
|
|
<sect1>Respect and follow standard file naming practices
|
|
<p>
|
|
Before even looking at the README, your intrepid explorer will have scanned
|
|
the filenames in the top-level directory of your unpacked distribution.
|
|
Those names can themselves convey information. By adhering to certain
|
|
standard naming practices, you can give the explorer valuable clues
|
|
about what to look in next.
|
|
|
|
Here are some standard top-level file names and what they mean. Not
|
|
every distribution needs all of these.
|
|
|
|
<descrip>
|
|
<tag>README or READ.ME</tag> the roadmap file, to be read first
|
|
|
|
<tag>INSTALL</tag> configuration, build, and installation instructions
|
|
|
|
<tag>CREDITS</tag> list of project contributers
|
|
|
|
<tag>NEWS</tag> recent project news
|
|
|
|
<tag>HISTORY</tag> project history
|
|
|
|
<tag>COPYING</tag> project license terms (GNU convention)
|
|
|
|
<tag>LICENSE</tag> project license terms
|
|
|
|
<tag>MANIFEST</tag> list of files in the distribution
|
|
|
|
<tag>FAQ</tag> plain-text Frequently-Asked-Questions document for the project
|
|
|
|
<tag>TAGS</tag> generated tag file for use by Emacs or vi
|
|
</descrip>
|
|
|
|
Note the overall convention that filenames with all-caps names are
|
|
human-readable metainformation about the package, rather than build
|
|
components.
|
|
|
|
Having a FAQ can save you a lot of grief. When a question about the
|
|
project comes up often, put it in the FAQ; then direct users to read the
|
|
FAQ before sending questions or bug reports. A well-nurtured FAQ can
|
|
decrease the support burden on the project maintainers by an order of
|
|
magnitude or more.
|
|
|
|
Having a HISTORY or NEWS file with timestamps in it for each release
|
|
is valuable. Among other things, it may help establish prior art if
|
|
you are ever hit with a patent-infringement lawsuit (this hasn't
|
|
happened to anyone yet, but best to be prepared).
|
|
|
|
<sect1>Design for Upgradability
|
|
<p>
|
|
Your software will change over time as you put out new releases. Some
|
|
of these changes will not be backward-compatible. Accordingly, you
|
|
should give serious thought to designing your installation layouts so
|
|
that multiple installed versions of your code can coexist on the same
|
|
system. This is especially important for libraries -- you can't
|
|
count on all your client programs to upgrade in lockstep with your
|
|
API changes.
|
|
|
|
The Emacs, Python, and Qt projects have a good convention for handling
|
|
this; version-numbered directories. Here's how an installed Qt
|
|
library hierarchy looks (${ver} is the version number):
|
|
|
|
<verb>
|
|
/usr/lib/qt
|
|
/usr/lib/qt-${ver}
|
|
/usr/lib/qt-${ver}/bin # Where you find moc
|
|
/usr/lib/qt-${ver}/lib # Where you find .so
|
|
/usr/lib/qt-${ver}/include # Where you find header files
|
|
</verb>
|
|
|
|
With this organization, you can have multiple versions coexisting.
|
|
Client programs have to specify the library version they want, but
|
|
that's a small price to pay for not having the interfaces break on them.
|
|
|
|
<sect1>Provide RPMs
|
|
<p>
|
|
The de-facto standard format for installable binary packages is that used
|
|
by the Red Hat Package manager, RPM. It's featured in the most popular
|
|
Linux distribution, and supported by effectively all other Linux
|
|
distributions (except Debian and Slackware; and Debian can install from
|
|
RPMs).
|
|
|
|
Accordingly, it's a good idea for your project site to provide installable
|
|
RPMs as well as source tarballs.
|
|
|
|
It's also a good idea for you to include in your source tarball the RPM
|
|
spec file, with a production that makes RPMs from it in your Makefile.
|
|
The spec file should have the extension `.spec'; that's how the rpm -t
|
|
option finds it in a tarball.
|
|
|
|
For extra style points, generate your spec file with a shellscript that
|
|
automatically plugs in the correct version number by analyzing the Makefile
|
|
or a version.h.
|
|
|
|
<sect>Good communication practice
|
|
<p>
|
|
Your software won't do the world much good if nobody but you knows it
|
|
exists. Also, developing a visible presence for the project on the
|
|
Internet will assist you in recruiting users and co-developers. Here
|
|
are the standard ways to do that.
|
|
|
|
<sect1>Announce to c.o.l.a and Freshmeat
|
|
<p>
|
|
Announce new releases to <url url="news:comp.os.linux.announce"
|
|
name="comp.os.linux.announce">. Besides being widely read itself,
|
|
this group is a major feeder for web-based what's-new sites like
|
|
<url url="http://www.freshmeat.net" name="Freshmeat">.
|
|
|
|
<sect1>Announce to a relevant topic newsgroup
|
|
<p>
|
|
Find USENET topics group directly relevant to your application,
|
|
and announce there as well. Post only where the <em>function</em> of the
|
|
code is relevant, and exercise restraint.
|
|
|
|
If (for example) you are releasing a program written in Perl that queries
|
|
IMAP servers, you should certainly post to comp.mail.imap. But you
|
|
should probably not post to comp.lang.perl unless the program is also
|
|
an instructive example of cutting-edge Perl techniques.
|
|
|
|
Your announcement should include the URL of a project website.
|
|
|
|
<sect1>Have a website
|
|
<p>
|
|
If you intend try to build any substantial user or developer community
|
|
around your project, it should have a website. Standard things to have
|
|
on the website include:
|
|
<itemize>
|
|
<item>The project charter (why it exists, who the audience is, etc).
|
|
<item>Download links for the project sources.
|
|
<item>Instructions on how to join the project mailing list(s).
|
|
<item>A FAQ (Frequently Asked Questions) list.
|
|
<item>HTMLized versions of the project documentation
|
|
<item>Links to related and/or competing projects.
|
|
</itemize>
|
|
|
|
Some project sites even have URLs for anonymous access to the master
|
|
source tree.
|
|
|
|
<sect1>Host project mailing lists
|
|
<p>
|
|
It's standard practice to have a private development list through which project
|
|
collaborators can communicate and exchange patches. You may also
|
|
want to have an announcements list for people who want to be kept informed
|
|
of the project's process
|
|
|
|
<sect1>Release to major archives
|
|
<p>
|
|
For the last several years, the <url
|
|
url="http://www.metalab.unc.edu/pub/Linux/" name="Metalab archive"> has
|
|
been the most important interchange location for Linux software.
|
|
|
|
Other important locations include:
|
|
|
|
<itemize>
|
|
<item>the <url url="http://www.python.org" name="Python Software Activity">
|
|
site (for software written in Python).
|
|
<item>the <url url="http://language.perl.com/CPAN" name="CPAN">, the
|
|
Comprehensive Perl Archive Network, (for software written in Perl).
|
|
</itemize>
|
|
|
|
<sect>Good project-management practice
|
|
<p>
|
|
Managing a project well when all the participants are volunteers presents
|
|
some unique challenges. This is too large a topic to cover in a HOWTO.
|
|
Fortunately, there are some useful white papers available that will help you
|
|
understand the major issues.
|
|
|
|
For discussion of basic development organization and the
|
|
release-early-release-often `bazaar mode', see <url name="The Cathedral and
|
|
the Bazaar" url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">.
|
|
|
|
For discussion of motivational psychology, community customs, and conflict
|
|
resolution, see
|
|
<url name="Homesteading the Noosphere"
|
|
url="http://www.tuxedo.org/~esr/writings/homesteading/">.
|
|
|
|
For discussion of economics and appropriate business models, see
|
|
<url name="The Magic Cauldron"
|
|
url="http://www.tuxedo.org/~esr/writings/magic-cauldron/">.
|
|
|
|
These papers are not the last word on open-source development. But they
|
|
were the first serious analyses to be written, and have yet to be
|
|
superseded.
|
|
|
|
</article>
|
|
|
|
<!--
|
|
The following sets edit modes for GNU EMACS Local Variables:
|
|
fill-column:75
|
|
compile-command:"make Software-Release-Practice-HOWTO.html"
|
|
End:
|
|
-- >
|
|
|