X-Git-Url: https://projects.mako.cc/source/fspm_howto/blobdiff_plain/24b5107d4077795776937de128305bb4a13f02d7..44fb1663e93995abba200e89e1982e189194010b:/FreeSoftwareDevelopmentHOWTO.sgml
diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml
index 32091e7..ad8e78f 100644
--- a/FreeSoftwareDevelopmentHOWTO.sgml
+++ b/FreeSoftwareDevelopmentHOWTO.sgml
@@ -206,9 +206,9 @@
- The latest version number of this document should always be listed
- at my webpage at
- http://people.debian.org/~mako/ Debian.
+ The latest version number of this document should always be listed
+ on my webpage at
+ Debian.
@@ -319,7 +319,7 @@
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 :
- mako (at) debian (dot) org.
+ mako@debian. org.
@@ -339,8 +339,7 @@
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: mako (at) debian (dot)
- org.
+ hesitate to contact me at: mako@debian.org.
@@ -392,46 +391,824 @@
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 something unique
+ software process does or or does it in a way that is unique
+ enought to necessitate a seperate project.
-
+
+ Indentify and articulate your idea
+
+ 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 softare development. You can find it online
+ .
+
+
+
+ In "The Cathedral and Bazaar," Raymond tells us that:
+ Every good work of software starts by scratching a
+ developers itch. Raymond now widely accepted
+ hypothesis is that new free software programs are written, first
+ and foremost, to solve a specific problem facing the developer.
+
-
+
+ If you have an idea for a program in mind, chances are good that
+ it it is targetting a specific problem or itch 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.
+
+
-
- Deciding on a License
-
+
+ Evaluate your idea
+
+
+ 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
+ right one for your project. Obviously, since the program
+ scratches your itch, you are definately 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: Is anybody else
+ interested?
+
+
+
+ Sometimes the answer is no. If you want to
+ write a set of scripts to sort your MP3
+ 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 anyone's
+ MP3s, a free software project might fill a useful gap.
+
+
+
+ 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: Has somebody already had your
+ idea or a reasonably similar one?
+
+
+
+ Finding Similar Projects
+
+
+ There are places you can go on the web to try and answer this
+ question. 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:
+
+
+
+
+
+ freshmeat.net:
+
+ freshmeat
+ describes itself as, the Web's largest index of Linux
+ and Open Source software
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.
+
+
+
+
+ Slashdot:
+
+ Slashdot
+ provides News for Nerds: Stuff that Matters,
+ which usually includes discussion of free software, open
+ source, technology, and geek culture new and events. It is
+ not unusual for an particularly sexy develpment effort to be
+ announced here so it definately worth checking.
+
+
+
+
+ SourceForge:
+
+ SourceForge
+ houses and facilitates a growning number of open source and
+ free software projects, SourceForge is quickly becoming a
+ nexus and an necessary stop for free software
+ developers. SourceForge's software
+ map and new
+ releases pages. should be necessary stops before
+ embarking on a new free software project. SourceForge also
+ provides a at Code Snippet
+ Library which contains useful reusuable chunks of
+ code in an array of langauges which can come in useful in any
+ project.
+
+
+
+
+ Google and Google's Linux Search:
+
+ Google and
+ Google's Linux
+ Search, provide powwerful web searches that may
+ reveal people working on similar projects. It is not a
+ catalog of software or news like freshmeat or Slashdot, but
+ it is worth checking before you begin pouring your effort
+ into a redundant project.
+
+
+
+
+
+
+
+
+ Deciding to Proceed
+
+ Once you have successfull charted the terrain and have an idea
+ 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
+ project. Anyone starting a new project needs to ask themselves:
+ 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?
+
+
+
+ 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.
+
+
+
+ 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 rememeber
+ 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
+ not starting a new project.
+
+
+
+
+
+
+
+ Licensing your Software
+
+
+ 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.
+
+
+
+ Choosing a license
+
+
+ Any discussion of licenses is also sure to generate at least a
+ small flamewar 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
+ Open Source Software
and the debate around
+ Open Source Software
and Free
+ Software
. However, because I've written the Free Software
+ Development HOWTO and not the Open Source Development HOWTO, my
+ own allegiences in this argument are out in the open.
+
+
+
+ In attempting to reach a middle ground, I recommend picking any
+ license that conforms to the Debian Free Software
+ Guidlines. Examples of these licenses are the
+ GPL, the BSD, and the
+ Artistic License. Conforming to the definition of Free Software
+ offered by Richard Stallman in The Free
+ Software Definition, any of these licenses will
+ uphold, users' freedom to run, copy, distribute, study,
+ change and improve the software.
There are other licenses
+ as well but sticking with a more common license will offer the
+ advantage of immediate recognition and undestanding.
+
+
+
+ In attempting a more in-depth analysis, I agree with Karl Fogel's
+ description of licenses as falling into two groups: those that
+ are the GPL and those that are not the
+ GPL.
+
+
+
+ Personally, I license all my software under the
+ GPL. Created and protected by the Free
+ Software Foundation and the GNU Project, the
+ GPL 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. However, there
+ is a viral aspect to the GPLthat prevents the
+ mixture of GPL'ed code with
+ non-GPL'ed code. To many people (myself
+ included), this is a benefit, but to some, it is a major
+ drawback.
+
+
+
+ The three major license can be found at the following locations:
+
+
+
+
+
+ The GNU
+ General Public License
+
+
+ The
+ BSD License
+
+
+ The Artistic
+ License
+
+
+
+
+
+ In all cases, please read through any license before
+ your release your software. As the developer, you can't afford
+ any license surprises.
+
+
+
+
+ The mechanics of licensing
+
+
+ The text of the GPL offers a good
+ description of mechanics of applying a license to a piece
+ of software. A checklist for applying a license would include:
+
+
+
+
+
+
+ If at all possible, attach and distribute a full copy of
+ the license with the source and binary in a seperate
+ file.
+
+
+
+
+ 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 GPL recommends that each
+ file begin with:
+
+
+one line to give the program's name and an idea of what it does.
+Copyright (C) yyyy name of author
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+
+
+ The GPL goes on to recommend attaching
+ information on contacting you (the author) via email or
+ physical mail.
+
+
+
+
+
+
+ The GPL 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
+ information about the programs licensing:
+
+
+
+Gnomovision version 69, Copyright (C) year name of author
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+type `show w'. This is free software, and you are welcome
+to redistribute it under certain conditions; type `show c'
+for details.
+
+
+
+
+ Finally, it might be helpful to include a
+ copyright disclaimer
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.
+
+
+
+
+
+
+
+ Final license warning
+
+
+ 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 distrobution, it must have a
+ license that fits the Debian Free Software
+ Guidelines. If you have no license, your program can be
+ distributed in part of Debian until you rerelease it under a free
+ license. Please save yourself and others trouble by releasing the
+ first version of your software with a clear license.
+
+
+
+
+
+
Choosing a Method of Version Numbering
-
+
+ The most important thing about a system of numbering is
+ that there is one. 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.
+
+
+
+ The second most important thing about a system of
+ numbering is that the numbers always go up. Automatic
+ versioning systems and people's sense of order in the universe
+ will fall apart if version numbers don't rise. It doesn't
+ really 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.
+
+
+
+ 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.
+
+
+
+
+ Linux kernel version numbering:
+
+ 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.
+
+
+
+ Whether you plan on having a split development model (as
+ described in ) 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.
+
+
+
+
+
+ Wine version numbering:
+
+ 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 wine-XXXXXXXX
where
+ the version from Janurary 04, 2000 would be
+ wine-20000104
. For certain projects, Year Month
+ Day format can make a lot of sense.
+
+
+
+
+
+ Mozilla milestones:
+
+ When one considers Netscape 6 and verdor versions, the
+ mozilla's project development structure is one of the most
+ complex free software model available. Their version numbering
+ has reflected the unique situation in which it is
+ developed.
+
+
+
+ Mozilla's development structure has historically been made up
+ of milestones. From teh 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 road
+ maps. Major points and achievements along this roadmaps
+ 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 roadmap had been reached, that
+ particular build was marked as a milstone release.
+
+
+
+ While I haven't seen this method employed in any other projects
+ to date, I like the idea and think that it might have value in
+ any testing or development branch of a large free application
+ under heavy development.
+
+
+
+
+
Documentation
-
+
+
+ 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 that you must always release
+ something that is usable. A piece of software without
+ documentation is not usuable.
+
+
+
+ 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.
+
+
+
+ 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:
+
+
+
+ Man pages
+
+ Your users will want to be able to type man
+ foo
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.
+
+
+
+ Man pages are not difficult to write. There is excellent
+ documentation on the man page process available through the
+ The Linux Man-Page-HOWTO
available through the
+ Linux Documentation project (LDP) written by
+ Jens Schweikhardt. It is available from
+ Schweikhardt's site or from the
+ LDP.
+
+
+
+ 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.
+
+
+
+
+ Command line accessable documentation
+
+
+ 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:
+
+
+
+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.
+
+
+
+ It has become a GNU convention to make this information
+ accessable with the -h
and the
+ --help
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.
+
+
+
+ Files users will expect
+
+ 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
+ doc
or Documentation
. These files include:
+
+
+
+
+ README or Readme
+
+
+
+ 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.
+
+
+
+
+
+ INSTALL or Install
+
+
+
+ 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.
+
+
+
+
+
+ Changelog, ChangeLog, CHANGELOG, or changelog
+
+
+
+ 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.
+
+
+
+
+
+ FAQ
+
+
+
+ For those of you that don't already
+ know. FAQ 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.
+
+
+
+
+
+
+
+
+
+ Website
+
+ 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
+ HTML 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.
+
+
+
+
+ Other documentation hints
+
+
+ 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:
+ Too much documentation is not a sin.
+
+
+
+ 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. 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.
+
+
Other Presentation Issues
-
-
+
+ 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.
+
-
+
+ Package formats
+
+ 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.
+
-
- Nuturing Future Development
-
-
+
+ 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 RPM's (.rpm),
+ Debian deb's (.deb) and source RPM's
+ SRPM's. Binary packages can also be compiled
+ against a specified system with specificed libraries and
+ distributed in tar.gz format as well. 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.
+
+
+
+ Useful tidbits and presentation hints
+
+
+
+
+
+
+ Make sure that your program can always be found in a
+ single location. Often this means that you have a
+ single directory accessable via FTP or
+ HTTP where the newest version will be
+ quickly recognized. One effective technique is a provide a
+ symlink called projectname-latest
that is
+ always pointing to the most recent released or development
+ version of your free software project.
+
+
+
+
+
+ Make sure that there is a consistent email address
+ for bug reports. 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.
+
+
+
+
+
+
+
+
@@ -440,44 +1217,567 @@
Maintaining a Project: Interacting with Developers
+
+ fswd!developers
+
-
- fswd!developers
-
+
+ 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.
+
+
+
+ In releasing your program, your program becomes free software. This
+ transition is more than just a larger user base. By releasing your
+ program as free software, your software
+ becomes the free software community's
+ software. The direction of your software's development will be
+ reshaped, redirected, and fully determined by your users and, to a
+ larger extent, by other developers in the community.
+
+
+
+ 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 sipmly don't have to
+ worry about. 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.
+
Delegating Work
-
+
+
+ By now, you've hypothetically followed me through the early
+ writing 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 ) released it to the rest
+ of the world. Times passes, and if things go well, people become
+ interested and want to help. The patches begin flowing in.
+
+
+
+ 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.
+
+
+
+ Delegation is the politcal way of describing this process of
+ letting go.
It is the process of handing some of
+ the responsibility and power over your project to other reponsible
+ 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. 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.
+
+
+
+ As your project progresses, you will notice people who are putting
+ 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 your position as the project's
+ maintainer onto them (if they want it). There are several easy
+ weays you can do this:
+
+
+
+ How to delegate
+
+
+ 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
+ judgement and for recognizing solutions that are maintainable and
+ are not. In a sentance: 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. The following ideas might be good places
+ to start or good sources of inspiriation:
+
+
+
+ Allow a larger group of people write access to your CVS
+ reponsitory and make real efforts towards rule by a
+ committee
+
+
+ Apache is an
+ example of a project that is run by small group of developers
+ who vote on major technical issues and the admission of new
+ members and all have write access to the main source
+ repository. Their process is detailed online.
+
+
+
+ The Debian Project
+ is an extreme example of rule by committee. At current count,
+ 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 social
+ contract and a constitution. 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 lead as well
+ but the lead's main responsiblity is to, Appoint
+ Delegates or delegate decisions to the Technical
+ Committee.
+
+
+
+ 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
+ nothing but delegate can serve as a
+ charicature of how a project can involve and empower a huge
+ number of developers and grow to a huge size.
+
+
+
+
+
+ Publicly appoint someone as the release manager for a
+ specific release.
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+
+ Delegate control of an entire branch.
+
+ If your project chooses to have branches (as described in ), 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
+ well-suiteded developer.
+
+
+
+ The author of linux, Linus Torvalds, came out and crowned Alan
+ Cox as the man for stable kernels.
All patches
+ for stable kernels go to Alan and, if Linus were to be taken
+ away from work on linux for any reason, Alan Cox would be more
+ than suited to fill his role as the acknowledged heir to the
+ linux maintainership.
+
+
+
+
+
+
+
+
+ Accepting and Rejecting Patches
+
+ This HOWTO has already touched on the fact that as the maintainer
+ of a free software project, one of primary and most important
+ responsibilities will be accepting and rejecting patches submitted
+ to you by other developers.
+
+
+
+ Technical judgement
+
+
+ In Open Source Development with CVS, 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 idea
I talked about in ) and the ability to recognize,
+ facilitate, and direct evolution
of a free
+ software program so that the program can grow and change and
+ incorporate functionatlity that was orignally unforseen 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 unweildiness. These are the criteria that you as a
+ project mainatiner should take into account each time you recieve
+ a patch.
+
+
+
+ Fogel elaborates on this again and states the the
+ questions to ask yourself when considering whether to implement
+ (or approve) a change are:
+
+
+
+
+
+
+ Will it benefit a significant percentage of the program's
+ user community?
+
+
+
+ Does it fit within the program's domain or within a
+ natural, intuitive extension of that domain?
+
+
+
+
+
+
+ The answers to these questions are never straighforward and its
+ very possible (and even likely) that the person who submitted the
+ patch may feel differently about the answer to those questions
+ than you do. However, if you feel that that the answer to either
+ of those questions is no,
it is your responsiblity
+ to reject the change. If you fail to do this, the project will
+ become unweildy and unmaintainable and will ultimately fail.
+
+
+
+
+ Rejecting patches
+
+
+ Rejecting patches is probably the most difficult and the most
+ sesnative job that the maintainer of any free software project
+ has to face. But sometimes it has to be done. I mentioned earlier
+ (in and in ) 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
+ powertrip or being overly bossy or possesive of a community-based
+ project. I recommend that you keep three major facts in mind when
+ rejecting patches (or other changes):
+
+
+
+ Bring it to the community
+
+ 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 definately 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.
+
+
+
+ I recommend this process wholeheartedly. As the project
+ 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
+ responsive leadership as it tests and serves the interests of
+ your software's community.
+
+
+
+
+ Technical issues is not always good justification
+
+ Especially towards the beginning, you will find that many
+ changes are difficult to implement, introduce new bugs, or have
+ other techincal 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
+ 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 submittor 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.
+
+
+
+
+ Common courtesy
+
+ It should go without saying but, above all and in all
+ cases, just be nice. If someone has an idea and cares
+ about it enough to write some code and submit a patch, they
+ care, they are motivated, and they are already involved. Your
+ goal as the maintainer is make sure they submit again. They may
+ have thrown you a dud this time but next time may be the idea or
+ feature that revolutionizes your project.
+
+
+
+ It is your responsibility to first justify your action 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 incorproate 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.
+
+
+
Stable and Development Branches
-
-
-
+
+ The idea of stable and development branches has already been
+ described briefly in and in
+ . These alluses 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 ) by allowing you to temporarily compromise the
+ stability of your project without affected those users who need
+ that stability.
+
-
- Freezing
-
-
+
+ The most common way of branching your project is to have one
+ branch that is stable and one that is development. This is the
+ model followed by the Linux kernel that is described in . 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 feature freeze
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 reprocussion are
+ incorporated into the stable branch also to the development
+ branch.
+
-
+
+ Linux's model is an extreme one. On many projects, there is no
+ need to have two versions always available. It may make sense ot
+ have two versions only near a release. The Debian project has
+ historically made both a stable and an unstable distribution
+ available but has expanded to this to include: stable, unstable,
+ 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
+ branches helps demonstrate how they can be used to balance
+ consitent and effective development with the need to make regular
+ and useable releases.
+
+
+
+ In trying to set up a development tree for yourself, there are
+ several things that might be useful to keep in mind:
+
+
+
+
+
+
+ Minimize the number of branches
+
+
+ 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.
+
+
+
+
+
+ Make sure that all your different branches are explained
+
+
+ As I mentioned in the preceeding paragraph, different branches
+ will confuse your users. Do everything
+ you can to avoid this by clearly explaining the different
+ branches in a promenant page on your website and in a Readme
+ file in the FTP or HTTP
+ directory.
+
+
+
+ I might also recommend against a mistake that I think Debian
+ has made. The terms unstable,
+ testing,
and experimental
are
+ vague and difficult to rank in order of stability (or
+ instability as the case may be). Try explaining to someone
+ that stable
actually means ultra
+ stable
and that unstable
doesn't
+ actually include any unstable software but is really stable
+ software that is untested as a distribution.
+
+
+
+ If you are going to do branches, especially early on, keep in
+ mind that people are conditioned to understand the terms
+ stable
and development
and you
+ probaly can't go wrong with this simple and common division of
+ branches.
+
+
+
+
+
+ Make sure all your branches are always available
+
+
+ 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 physicall split up
+ different branches in different directories or directory trees
+ on your FTP or HTTP
+ 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
+ stable,
unstable
and
+ frozen
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 accessable 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.
+
+
+
+
+
+
-
- Avoiding the Code Cram Effect
-
-
+
-
- Accepting and Rejecting Patches
-
+
+ Other Development issues
+
+ 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:
+
+
+
+ Freezing
+
+ For those projects that choose to adopt a split development model
+ (), freezing is a concept that is worth
+ becoming familiar with.
+
+
+
+ Freeze come in two major forms. A feature freeze
+ is a period when no signifigant functionality is added to a
+ program. It is a period where established functionality (even
+ skeletons of barely working functionality) can be improved and
+ perfected. It is a period where bugs are fixed. This type of
+ freeze is usually applied some period (a month or two) before a
+ release. It is easy to push a release back as you wait for
+ one more feature
and a freeze helps to avoid this
+ situation by drawing the much neede line in the sand. It gives
+ developers room they need to get a program ready for release.
+
+
+
+ The second type of freeze is a code freeze
which
+ is much more like a released piece of software. Once a piece of
+ software has entered a code freeze, all changes to the code are
+ frowned upon and only changes that fix known bugs are
+ permitted. This type of freeze usually follows a feature
+ freeze
and directly preceeds a release. Most released
+ software is in what could be interpreted as a sort of high
+ levelcode freeze.
+
+
+
+ Even you do not choose to appoint a release manager (), you will have an easier time
+ justifying the rejection or postponement of patches ( before a release with a publicly stated
+ freeze in effect.
+
+
+
+
+ Forking
+
+ Forks are the most extreme interpretation 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
+ XEmacs. Both emacsen are based on an almost identical codebase
+ but for technical, political, and philisophical reasons,
+ development was split into two projects which now compete with
+ each other.
+
+
+
+ The short version of the fork section is, don't do
+ them. 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.
+
+
+
+ In his chapter on The Open Source Process,
Karl
+ Fogel describes how to do a fork if you absolutely must. If you
+ have determined that is absolutely necessary and that the
+ differences between you and the people threatening to fork are
+ absolutely unresolvable, I recommend Fogel's book as a good place
+ to start.
+
+
@@ -485,12 +1785,37 @@
Maintaining a Project: Interacting with Users
+
+ fswd!users
+
-
- fswd!users
-
+
+ If you've worked your way up to here, congratuatlions, you are
+ nearing the end of this document. This final section touches upon
+
+
+
+
+ Testing and Testers
+
+
+
+
+
+
+ Setting up a Support Infrastructure
+
+
+
+
+
+
+ Releasing Your Program
+
+
+
@@ -498,12 +1823,7 @@
-
-
- Testing and Testers
-
-
@@ -524,4 +1844,4 @@ sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
--->
+-->
\ No newline at end of file