Commits

Anonymous committed 386b066

여기저기

Comments (0)

Files changed (1)

-<chapter id="getting-started">
-
-<title>Getting Started</title>
-
-<simplesect>
-
-<para>The classic model of how free software projects get started was
-supplied by Eric Raymond, in a now-famous paper on open source
-processes entitled <citetitle>The Cathedral and the
-Bazaar</citetitle>.  He wrote:</para>
-
-    <blockquote>
-      <para><emphasis>Every good work of software starts by scratching
-      a developer's personal itch.</emphasis></para>
-
-      <para>(from <emphasis role="bold"><ulink
-      url="http://www.catb.org/~esr/writings/cathedral-bazaar/"/>
-      </emphasis>)</para>
-    </blockquote>
-
-<para>Note that Raymond wasn't saying that open source projects happen
-only when some individual gets an itch.  Rather, he was saying that
-<emphasis>good</emphasis> software results when the programmer has a
-personal interest in seeing the problem solved; the relevance of this
-to free software was that a personal itch happened to be the most
-frequent motivation for starting a free software project.</para>
-
-<para>This is still how most free software projects are started, but less so
-now than in 1997, when Raymond wrote those words.  Today, we have the
-phenomenon of organizations&mdash;including for-profit
-corporations&mdash;starting large, centrally-managed open source
-projects from scratch.  The lone programmer, banging out some code to
-solve a local problem and then realizing the result has wider
-applicability, is still the source of much new free software, but is
-not the only story.</para>
-
-<para>Raymond's point is still insightful, however.  The essential
-condition is that the producers of the software have a direct interest
-in its success, because they use it themselves.  If the software
-doesn't do what it's supposed to do, the person or organization
-producing it will feel the dissatisfaction in their daily work.  For
-example, the OpenAdapter project (<ulink
-url="http://www.openadapter.org/"/>), which was started by investment
-bank Dresdner Kleinwort Wasserstein as an open source framework for
-integrating disparate financial information systems, can hardly be
-said to scratch any individual programmer's personal itch.  It
-scratches an institutional itch.  But that itch arises directly from
-the experiences of the institution and its partners, and therefore if
-the project fails to relieve them, they will know.  This arrangement
-produces good software because the feedback loop flows in the right
-direction.  The program isn't being written to be sold to someone else
-so they can solve <emphasis>their</emphasis> problem.  It's being
-written to solve one's <emphasis>own</emphasis> problem, and then
-shared with everyone, much as though the problem were a disease and
-the software were medicine whose distribution is meant to completely
-eradicate the epidemic.</para>
-
-<para>This chapter is about how to introduce a new free software
-project to the world, but many of its recommendations would sound
-familiar to a health organization distributing medicine.  The goals
-are very similar: you want to make it clear what the medicine does,
-get it into the hands of the right people, and make sure that those
-who receive it know how to use it.  But with software, you also want
-to entice some of the recipients into joining the ongoing research
-effort to improve the medicine.</para>
-
-<para>Free software distribution is a twofold task.  The software
-needs to acquire users, and to acquire developers.  These two needs
-are not necessarily in conflict, but they do add some complexity to a
-project's initial presentation.  Some information is useful for both
-audiences, some is useful only for one or the other.  Both kinds of
-information should subscribe to the principle of scaled presentation;
-that is, the degree of detail presented at each stage should
-correspond directly to the amount of time and effort put in by the
-reader.  More effort should always equal more reward.  When the two do
-not correlate tightly, people may quickly lose faith and stop
-investing effort.</para>
-
-<para>The corollary to this is that <emphasis>appearances
-matter</emphasis>.  Programmers, in particular, often don't like to
-believe this.  Their love of substance over form is almost a point of
-professional pride.  It's no accident that so many programmers exhibit
-an antipathy for marketing and public relations work, nor that
-professional graphic designers are often horrified at what programmers
-come up with on their own.</para>
-
-<para>This is a pity, because there are situations where form
-<emphasis>is</emphasis> substance, and project presentation is one of
-them.  For example, the very first thing a visitor learns about a
-project is what its web site looks like.  This information is absorbed
-before any of the actual content on the site is
-comprehended&mdash;before any of the text has been read or links
-clicked on.  However unjust it may be, people cannot stop themselves
-from forming an immediate first impression.  The site's appearance
-signals whether care was taken in organizing the project's
-presentation.  Humans have extremely sensitive antennae for detecting
-the investment of care.  Most of us can tell in one glance whether a
-web site was thrown together quickly or was given serious thought.
-This is the first piece of information your project puts out, and the
-impression it creates will carry over to the rest of the project by
-association.</para>
-
-<para>Thus, while much of this chapter talks about the content your
-project should start out with, remember that its look and feel matter
-too.  Because the project web site has to work for two different types
-of visitors&mdash;users and developers&mdash;special attention
-must be paid to clarity and directedness.  Although this is not the
-place for a general treatise on web design, one principle is important
-enough to deserve mention, particularly when the site serves multiple
-(if overlapping) audiences: people should have a rough idea where a
-link goes before clicking on it.  For example, it should be obvious
-<emphasis>from looking at the links</emphasis> to user documentation
-that they lead to user documentation, and not to, say, developer
-documentation.  Running a project is partly about supplying
-information, but it's also about supplying comfort.  The mere presence
-of certain standard offerings, in expected places, reassures users and
-developers who are deciding whether they want to get involved.  It
-says that this project has its act together, has anticipated the
-questions people will ask, and has made an effort to answer them in a
-way that requires minimal exertion on the part of the asker.  By
-giving off this aura of preparedness, the project sends out a message:
-"Your time will not be wasted if you get involved," which is exactly
-what people need to hear.</para>
-
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="look-around">
-<title>But First, Look Around</title>
-
-<para>Before starting an open source project, there is one important
-caveat:</para>
-
-<para>Always look around to see if there's an existing project that
-does what you want.  The chances are pretty good that whatever problem
-you want solved now, someone else wanted solved before you.  If they
-did solve it, and released their code under a free license, then
-there's no reason for you to reinvent the wheel today.  There are
-exceptions, of course: if you want to start a project as an
-educational experience, pre-existing code won't help; or maybe the
-project you have in mind is so specialized that you know there is zero
-chance anyone else has done it.  But generally, there's no point not
-looking, and the payoff can be huge.  If the usual Internet search
-engines don't turn up anything, try searching on
-<ulink url="http://freshmeat.net/"/> (an open source project news
-site, about which more will be said later), on
-<ulink url="http://www.sourceforge.net/"/>, and in the Free Software
-Foundation's directory of free software at
-<ulink url="http://directory.fsf.org/"/>.</para>
-
-<para>Even if you don't find exactly what you were looking for, you
-might find something so close that it makes more sense to join that
-project and add functionality than to start from scratch
-yourself.</para>
-
-</sect2>
-
-</simplesect>
-
-
-<!-- ========================== SECTION =========================== -->
-<sect1 id="starting-from-what-you-have">
-<title>Starting From What You Have</title>
-
-<para>You've looked around, found that nothing out there really fits
-your needs, and decided to start a new project.</para>
-
-<para>What now?</para>
-
-<para>The hardest part about launching a free software project is
-transforming a private vision into a public one.  You or your
-organization may know perfectly well what you want, but expressing
-that goal comprehensibly to the world is a fair amount of work.  It is
-essential, however, that you take the time to do it.  You and the
-other founders must decide what the project is really about&mdash;that
-is, decide its limitations, what it <emphasis>won't</emphasis> do as
-well as what it will&mdash;and write up a mission statement.  This
-part is usually not too hard, though it can sometimes reveal unspoken
-assumptions and even disagreements about the nature of the project,
-which is fine: better to resolve those now than later.  The next step
-is to package up the project for public consumption, and this is,
-basically, pure drudgery.</para>
-
-<para>What makes it so laborious is that it consists mainly of
-organizing and documenting things everyone already
-knows&mdash;"everyone", that is, who's been involved in the project so
-far.  Thus, for the people doing the work, there is no immediate
-benefit.  They do not need a <filename>README</filename> file giving
-an overview of the project, nor a design document or user manual.
-They do not need a carefully arranged code tree conforming to the
-informal but widespread standards of software source distributions.
-Whatever way the source code is arranged is fine for them, because
-they're already accustomed to it anyway, and if the code runs at all,
-they know how to use it.  It doesn't even matter, for them, if the
-fundamental architectural assumptions of the project remain
-undocumented; they're already familiar with that too.</para>
-
-<para>Newcomers, on the other hand, need these things.  Fortunately,
-they don't need them all at once.  It's not necessary for you to
-provide every possible resource before taking a project public.  In a
-perfect world, perhaps, every new open source project would start out
-life with a thorough design document, a complete user manual (with
-special markings for features planned but not yet implemented),
-beautifully and portably packaged code, capable of running on any
-computing platform, and so on.  In reality, taking care of all these
-loose ends would be prohibitively time-consuming, and anyway, it's
-work that one can reasonably hope volunteers will help with once the
-project is under way.</para>
-
-<para>What <emphasis>is</emphasis> necessary, however, is that enough
-investment be put into presentation that newcomers can get past the
-initial obstacle of unfamiliarity.  Think of it as the first step in a
-bootstrapping process, to bring the project to a kind of minimum
-activation energy.  I've heard this threshold called the
-<firstterm>hacktivation energy</firstterm>: the amount of energy a
-newcomer must put in before she starts getting something back.  The
-lower a project's hacktivation energy, the better.  Your first task is
-bring the hacktivation energy down to a level that encourages people
-to get involved.</para>
-
-<para>Each of the following subsections describes one important aspect
-of starting a new project.  They are presented roughly in the order
-that a new visitor would encounter them, though of course the order in
-which you actually implement them might be different.  You can treat
-them as a checklist.  When starting a project, just go down the list
-and make sure you've got each item covered, or at least that you're
-comfortable with the potential consequences if you've left one
-out.</para>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="choosing-a-name">
-<title>Choose a Good Name</title>
-
-<para>Put yourself in the shoes of someone who's just heard about your
-project, perhaps by having stumbled across it while searching for
-software to solve some problem.  The first thing they'll encounter is
-the project's name.</para>
-
-<para>A good name will not automatically make your project successful,
-and a bad name will not doom it&mdash;well, a
-<emphasis>really</emphasis> bad name probably could do that, but we
-start from the assumption that no one here is actively trying to make
-their project fail.  However, a bad name can slow down adoption of the
-project, either because people don't take it seriously, or because
-they simply have trouble remembering it.</para>
-
-<para>A good name:
-
-<itemizedlist>
-  <listitem><para>Gives some idea what the project does, or at least
-            is related in an obvious way, such that if one knows the
-            name and knows what the project does, the name will come
-            quickly to mind thereafter.</para>
-  </listitem>
-  <listitem><para>Is easy to remember.  Here, there is no getting
-            around the fact that English has become the default
-            language of the Internet: "easy to remember" means "easy
-            for someone who can read English to remember."  Names that
-            are puns dependent on native-speaker pronounciation, for
-            example, will be opaque to the many non-native English
-            readers out there.  If the pun is particularly compelling
-            and memorable, it may still be worth it; just keep in mind
-            that many people seeing the name will not hear it in their
-            head the way a native speaker would.</para>
-  </listitem>
-  <listitem><para>Is not the same as some other project's name, and
-            does not infringe on any trademarks.  This is just good
-            manners, as well as good legal sense.  You don't want to
-            create identity confusion.  It's hard enough to keep track
-            of everything that's available on the Net already, without
-            different things having the same name.</para>
-
-            <para>The resources mentioned earlier in
-            <xref linkend="look-around"/> are useful in
-            discovering whether another project already has the name
-            you're thinking of.  Free trademark searches are
-            available at <ulink url="http://www.nameprotect.org/"/>
-            and <ulink url="http://www.uspto.gov/"/>.</para>
-  </listitem>
-  <listitem><para>If possible, is available as a domain name in the
-            <systemitem>.com</systemitem>,
-            <systemitem>.net</systemitem>, and
-            <systemitem>.org</systemitem> top-level domains.  You
-            should pick one, probably <systemitem>.org</systemitem>,
-            to advertise as the official home site for the project;
-            the other two should forward there and are simply to
-            prevent third parties from creating identity confusion
-            around the project's name.  Even if you intend to host the
-            project at some other site (see
-            <xref linkend="starting-with-canned-hosting"/>), you
-            can still register project-specific domains and forward
-            them to the hosting site.  It helps users a lot to have a
-            simple URL to remember.</para>
-    </listitem>
-</itemizedlist>
-
-</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="mission-statement">
-<title>Have a Clear Mission Statement</title>
-
-<para>Once they've found the project's web site, the next thing people
-will look for is a quick description, a mission statement, so they can
-decide (within 30 seconds) whether or not they're interested in
-learning more.  This should be prominently placed on the front page,
-preferably right under the project's name.</para>
-
-<para>The mission statement should be concrete, limiting, and above
-all, short.  Here's an example of a good one, from <ulink
-url="http://www.openoffice.org/"/>:</para>
-
-  <blockquote>
-  <para><emphasis>To create, as a community, the leading international
-  office suite that will run on all major platforms and provide access
-  to all functionality and data through open-component based APIs and
-  an XML-based file format.</emphasis></para>
-  </blockquote>
-
-<para>In just a few words, they've hit all the high points, largely by
-drawing on the reader's prior knowledge.  By saying "<emphasis>as a
-community</emphasis>", they signal that no one corporation will
-dominate development; "<emphasis>international</emphasis>" means that
-the software will allow people to work in multiple languages and
-locales; "<emphasis>all major platforms</emphasis>" means it will be
-portable to Unix, Macintosh, and Windows.  The rest signals that open
-interfaces and easily understandable file formats are an important
-part of the goal.  They don't come right out and say that they're
-trying to be a free alternative to Microsoft Office, but most people
-can probably read between the lines.  Although this mission statement
-looks broad at first glance, in fact it is quite circumscribed: the
-words "<emphasis>office suite</emphasis>" mean something very concrete
-to those familiar with such software.  Again, the reader's presumed
-prior knowledge (in this case probably from MS Office) is used to keep
-the mission statement concise.</para>
-
-<para>The nature of a mission statement depends partly on who is
-writing it, not just on the software it describes.  For example, it
-makes sense for OpenOffice.org to use the words "<emphasis>as a
-community</emphasis>", because the project was started, and is still
-largely sponsored, by Sun Microsystems.  By including those words, Sun
-indicates its sensitivity to worries that it might try to dominate the
-development process.  With this sort of thing, merely demonstrating
-awareness of the <emphasis>potential</emphasis> for a problem goes a
-long way toward avoiding the problem entirely.  On the other hand,
-projects that aren't sponsored by a single corporation probably don't
-need such language; after all, development by community is the norm,
-so there would ordinarily be no reason to list it as part of the
-mission.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="state-freedom">
-<title>State That the Project is Free</title>
-
-<para>Those who remain interested after reading the mission statement
-will next want to see more details, perhaps some user or developer
-documentation, and eventually will want to download something.  But
-before any of that, they'll need to be sure it's open source.</para>
-
-<para><emphasis>The front page must make it unambiguously clear that
-the project is open source.</emphasis> This may seem obvious, but you
-would be surprised how many projects forget to do it.  I have seen
-free software project web sites where the front page not only did not
-say which particular free license the software was distributed under,
-but did not even state outright that the software was free at all.
-Sometimes the crucial bit of information was relegated to the
-Downloads page, or the Developers page, or some other place that
-required one more mouse click to get to.  In extreme cases, the
-license was not given anywhere on the web site at all&mdash;the only
-way to find it was to download the software and look inside.</para>
-
-<para>Don't make this mistake.  Such an omission can lose many
-potential developers and users.  State up front, right below the
-mission statement, that the project is "free software" or "open source
-software", and give the exact license.  A quick guide to choosing a
-license is given in
-<xref linkend="license-quickstart"/><phrase output="printed">
-later in this chapter</phrase>, and
-licensing issues are discussed in detail in <xref
-linkend="legal"/>.</para>
-
-<para>At this point, our hypothetical visitor has
-determined&mdash;probably in a minute or less&mdash;that she's
-interested in spending, say, at least five more minutes investigating
-this project.  The next sections describe what she should encounter in
-that five minutes.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="features-and-requirements">
-<title>Features and Requirements List</title>
-
-<para>There should be a brief list of the features the software
-supports (if something isn't completed yet, you can still list it, but
-put "<emphasis>planned</emphasis>" or
-"<emphasis>in&nbsp;progress</emphasis>" next to it), and the kind of
-computing environment required to run the software.  Think of the
-features/requirements list as what you would give to someone asking
-for a quick summary of the software.  It is often just a logical
-expansion of the mission statement.  For example, the mission
-statement might say:</para>
-
-  <blockquote>
-  <para><emphasis>To create a full-text indexer and search engine
-  with a rich API, for use by programmers in providing search
-  services for large collections of text files.</emphasis></para>
-  </blockquote>
-
-<para>The features and requirements list would give the details,
-clarifying the mission statement's scope:</para>
-
-  <blockquote>
-    <para><emphasis>Features:</emphasis></para>
-    <itemizedlist>
-      <listitem><para><emphasis>Searches plain text, HTML, and
-                XML</emphasis></para>
-      </listitem>
-      <listitem><para><emphasis>Word or phrase searching</emphasis></para>
-      </listitem>
-      <listitem><para><emphasis>(planned) Fuzzy matching</emphasis></para>
-      </listitem>
-      <listitem><para><emphasis>(planned) Incremental updating of
-                indexes</emphasis></para>
-      </listitem>
-      <listitem><para><emphasis>(planned) Indexing of remote web
-                sites</emphasis></para>
-      </listitem>
-    </itemizedlist>
-    <para><emphasis>Requirements:</emphasis></para>
-    <itemizedlist>
-      <listitem><para><emphasis>Python 2.2 or higher</emphasis></para>
-      </listitem>
-      <listitem><para><emphasis>Enough disk space to hold the indexes
-                (approximately 2x original data size)</emphasis></para>
-      </listitem>
-    </itemizedlist>
-  </blockquote>
-
-<para>With this information, readers can quickly get a feel for
-whether this software has any hope of working for them, and they can
-consider getting involved as developers too.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="development-status">
-<title>Development Status</title>
-
-<para>People always want to know how a project is doing.  For new
-projects, they want to know the gap between the project's promise and
-current reality.  For mature projects, they want to know how actively
-it is maintained, how often it puts out new releases, how responsive
-it is likely to be to bug reports, etc.</para>
-
-<para>To answer these questions, you should provide a development
-status page, listing the project's near-term goals and needs (for
-example, it might be looking for developers with a particular kind of
-expertise).  The page can also give a history of past releases, with
-feature lists, so visitors can get an idea of how the project defines
-"progress" and how quickly it makes progress according to that
-definition.</para>
-
-<para>Don't be afraid of looking unready, and don't give in to the
-temptation to hype the development status.  Everyone knows that
-software evolves by stages; there's no shame in saying "This is alpha
-software with known bugs.  It runs, and works at least some of the
-time, but use at your own risk."  Such language won't scare away the
-kinds of developers you need at that stage.  As for users, one of the
-worst things a project can do is attract users before the software is
-ready for them.  A reputation for instability or bugginess is very
-hard to shake, once acquired.  Conservativism pays off in the long
-run; it's always better for the software to be
-<emphasis>more</emphasis> stable than the user expected than less, and
-pleasant surprises produce the best kind of word-of-mouth.</para>
-
-<sidebar id="alpha-and-beta">
-  <title>Alpha and Beta</title>
-  <para>The term <firstterm>alpha</firstterm> usually means a first
-  release, with which users can get real work done and which has all
-  the intended functionality, but which also has known bugs.  The main
-  purpose of alpha software is to generate feedback, so the developers
-  know what to work on.  The next stage, <firstterm>beta</firstterm>,
-  means the software has had all the serious bugs fixed, but has not
-  yet been tested enough to certify for release.  The purpose of beta
-  software is to either become the official release, assuming no bugs
-  are found, or provide detailed feedback to the developers so they
-  can reach the official release quickly.  The difference between
-  alpha and beta is very much a matter of judgement.</para>
-</sidebar>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="downloads">
-<title>Downloads</title>
-
-<para>The software should be downloadable as source code in standard
-formats.  When a project is first getting started, binary (executable)
-packages are not necessary, unless the software has such complicated
-build requirements or dependencies that merely getting it to run would
-be a lot of work for most people.  (But if this is the case, the
-project is going to have a hard time attracting developers
-anyway!)</para>
-
-<para>The distribution mechanism should be as convenient, standard,
-and low-overhead as possible.  If you were trying to eradicate a
-disease, you wouldn't distribute the medicine in such a way that it
-requires a non-standard syringe size to administer.  Likewise,
-software should conform to standard build and installation methods;
-the more it deviates from the standards, the more potential users and
-developers will give up and go away confused.</para>
-
-<para>That sounds obvious, but many projects don't bother to
-standardize their installation procedures until very late in the game,
-telling themselves they can do it any time: <emphasis>"We'll sort all
-that stuff out when the code is closer to being ready."</emphasis>
-What they don't realize is that by putting off the boring work of
-finishing the build and installation procedures, they are actually
-making the code take longer to get ready&mdash;because they
-discourage developers who might otherwise have contributed to the
-code.  Most insidiously, they don't <emphasis>know</emphasis> they're
-losing all those developers, because the process is an accumulation of
-non-events: someone visits a web site, downloads the software, tries
-to build it, fails, gives up and goes away.  Who will ever know it
-happened, except the person themselves?  No one working on the project
-will realize that someone's interest and good will have been silently
-squandered.</para>
-
-<para>Boring work with a high payoff should always be done early, and
-significantly lowering the project's barrier to entry through good
-packaging brings a very high payoff.</para>
-
-<para>When you release a downloadable package, it is vital that you
-give a unique version number to the release, so that people can
-compare any two releases and know which supersedes the other.  A
-detailed discussion of version numbering can be found in <xref
-linkend="release-numbering"/>, and the details of standardizing
-build and installation procedures are covered in
-<xref linkend="packaging"/><phrase output="printed">, both
-in <xref linkend="development-cycle"/></phrase>.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="vc-and-bug-tracker-access">
-<title>Version Control and Bug Tracker Access</title>
-
-<para>Downloading source packages is fine for those who just want to
-install and use the software, but it's not enough for those who want
-to debug or add new features.  Nightly source snapshots can help, but
-they're still not fine-grained enough for a thriving development
-community.  People need real-time access to the latest sources, and
-the way to give them that is to use a version control system.  The
-presence of anonymously accessible version controlled sources is a
-sign&mdash;to both users and developers&mdash;that this project is
-making an effort to give people what they need to participate.  If you
-can't offer version control right away, then put up a sign saying you
-intend to set it up soon.  Version control infrastructure is discussed
-in detail in <xref linkend="vc"/><phrase output="printed"> in
-<xref linkend="technical-infrastructure"/></phrase>.</para>
-
-<para>The same goes for the project's bug tracker.  The importance of
-a bug tracking system lies not only in its usefulness to developers,
-but in what it signifies for project observers.  For many people, an
-accessible bug database is one of the strongest signs that a project
-should be taken seriously.  Furthermore, the higher the number of bugs
-in the database, the better the project looks.  This might seem
-counterintuitive, but remember that the number of bugs recorded really
-depends on three things: the absolute number of bugs present in the
-software, the number of users using the software, and the convenience
-with which those users can register new bugs.  Of these three factors,
-the latter two are more significant than the first.  Any software of
-sufficient size and complexity has an essentially arbitrary number of
-bugs waiting to be discovered.  The real question is, how well will
-the project do at recording and prioritizing those bugs?  A project
-with a large and well-maintained bug database (meaning bugs are
-responded to promptly, duplicate bugs are unified, etc.) therefore
-makes a better impression than a project with no bug database, or a
-nearly empty database.</para>
-
-<para>Of course, if your project is just getting started, then the bug
-database will contain very few bugs, and there's not much you can do
-about that.  But if the status page emphasizes the project's youth,
-and if people looking at the bug database can see that most filings have
-taken place recently, they can extrapolate from that that the project
-still has a healthy <emphasis>rate</emphasis> of filings, and they
-will not be unduly alarmed by the low absolute number of bugs
-recorded.</para>
-
-<para>Note that bug trackers are often used to track not only software
-bugs, but enhancement requests, documentation changes, pending tasks,
-and more.  The details of running a bug tracker are covered in
-<xref linkend="bug-tracker"/><phrase output="printed"> in
-<xref linkend="technical-infrastructure"/></phrase>, so I won't
-go into them here.  The important thing from a presentation point of
-view is just to <emphasis>have</emphasis> a bug tracker, and to make
-sure that fact is visible from the front page of the project.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="communications-channels">
-<title>Communications Channels</title>
-
-<para>Visitors usually want to know how to reach the human beings
-involved with the project.  Provide the addresses of mailing lists,
-chat rooms, and IRC channels, and any other forums where others
-involved with the software can be reached.  Make it clear that you and
-the other authors of the project are subscribed to these mailing
-lists, so people see there's a way to give feedback that will reach
-the developers.  Your presence on the lists does not imply a
-committment to answer all questions or implement all feature requests.
-In the long run, most users will probably never join the forums
-anyway, but they will be comforted to know that they
-<emphasis>could</emphasis> if they ever needed to.</para>
-
-<para>In the early stages of a project, there's no need to have
-separate user and developer forums.  It's much better to have everyone
-involved with the software talking together, in one "room."  Among
-early adopters, the distinction between developer and user is often
-fuzzy; to the extent that the distinction can be made, the ratio of
-developers to users is usually much higher in the early days of the
-project than later on.  While you can't assume that every early
-adopter is a programmer who wants to hack on the software, you can
-assume that they are at least interested in following development
-discussions and in getting a sense of the project's direction.</para>
-   
-<para>As this chapter is only about getting a project started, it's
-enough merely to say that these communications forums need to exist.
-Later, in <xref linkend="growth"/><phrase output="printed"> in
-<xref linkend="communications"/></phrase>, we'll examine where
-and how to set up such forums, the ways in which they might need
-moderation or other management, and how to separate user forums from
-developer forums, when the time comes, without creating an
-unbridgeable gulf.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="developer-guidelines">
-<title>Developer Guidelines</title>
-
-<para>If someone is considering contributing to the project, she'll
-look for developer guidelines.  Developer guidelines are not so much
-technical as social: they explain how the developers interact with
-each other and with the users, and ultimately how things get
-done.</para>
-
-<para>This topic is covered in detail in
-<xref linkend="written-rules"/><phrase output="printed"> in
-<xref linkend="social-infrastructure"/></phrase>, but the basic
-elements of developer guidelines are:
-
-<itemizedlist>
-  <listitem><para>pointers to forums for interaction with other
-            developers</para> 
-  </listitem>
-  <listitem><para>instructions on how to report bugs and submit
-            patches</para>
-  </listitem>
-  <listitem><para>some indication of <emphasis>how</emphasis>
-            development is usually done&mdash;is the project a
-            benevolent dictatorship, a democracy, or something
-            else</para>
-  </listitem>
-</itemizedlist>
-
-No pejorative sense is intended by "dictatorship", by the way.  It's
-perfectly okay to run a tyranny where one particular developer has
-veto power over all changes.  Many successful projects work this way.
-The important thing is that the project come right out and say so.  A
-tyranny pretending to be a democracy will turn people off; a tyranny
-that says it's a tyranny will do fine as long as the tyrant is
-competent and trusted.</para>
-  
-<para>See <ulink url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>
-for an example of particularly thorough developer guidelines, or
-<ulink url="http://www.openoffice.org/dev_docs/guidelines.html"/> for
-broader guidelines that focus more on governance and the spirit of
-participation and less on technical matters.</para>
-
-<para>The separate issue of providing a programmer's introduction to
-the software is discussed in <xref
-linkend="developer-documentation"/><phrase output="printed">
-later in this chapter</phrase>.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="documentation">
-<title>Documentation</title>
-
-<para>Documentation is essential.  There needs to be
-<emphasis>something</emphasis> for people to read, even if it's
-rudimentary and incomplete.  This falls squarely into the "drudgery"
-category referred to earlier, and is often the first area where a new
-open source project falls down.  Coming up with a mission statement
-and feature list, choosing a license, summarizing development
-status&mdash;these are all relatively small tasks, which can be
-definitively completed and usually need not be returned to once done.
-Documentation, on the other hand, is never really finished, which may
-be one reason people sometimes delay starting it at all.</para>
-
-<para>The most insidious thing is that documentation's utility to
-those writing it is the reverse of its utility to those who will read
-it.  The most important documentation for initial users is the basics:
-how to quickly set up the software, an overview of how it works,
-perhaps some guides to doing common tasks.  Yet these are exactly the
-things the <emphasis>writers</emphasis> of the documentation know all
-too well&mdash;so well that it can be difficult for them to see
-things from the reader's point of view, and to laboriously spell out
-the steps that (to the writers) seem so obvious as to be unworthy of
-mention.</para>
-
-<para>There's no magic solution to this problem.  Someone just needs
-to sit down and write the stuff, and then run it by typical new users
-to test its quality.  Use a simple, easy-to-edit format such as HTML,
-plain text, Texinfo, or some variant of XML&mdash;something that's
-convenient for lightweight, quick improvements on the spur of the
-moment.  This is not only to remove any overhead that might impede the
-original writers from making incremental improvements, but also for
-those who join the project later and want to work on the
-documentation.</para>
-
-<para>One way to ensure basic initial documentation gets done is to
-limit its scope in advance.  That way, writing it at least won't feel
-like an open-ended task.  A good rule of thumb is that it should meet
-the following minimal criteria:</para>
-
-<itemizedlist>
-  <listitem><para>Tell the reader clearly how much technical
-            expertise they're expected to have.</para>
-  </listitem>
-  <listitem><para>Describe clearly and thoroughly how to set up
-            the software, and somewhere near the beginning of the
-            documentation, tell the user how to run some sort of
-            diagnostic test or simple command to confirm that
-            they've set things up correctly.  Startup
-            documentation is in some ways more important than
-            actual usage documentation.  The more effort someone has
-            invested in installing and getting started with the
-            software, the more persistent she'll be in figuring out
-            advanced functionality that's not well-documented.
-            When people abandon, they abandon early; therefore,
-            it's the earliest stages, like installation, that need
-            the most support.</para>
-  </listitem>
-  <listitem><para>Give one tutorial-style example of how to do a
-            common task.  Obviously, many examples for many tasks
-            would be even better, but if time is limited, pick one
-            task and walk through it thoroughly.  Once someone
-            sees that the software <emphasis>can</emphasis> be
-            used for one thing, they'll start to explore what else
-            it can do on their own&mdash;and, if you're lucky,
-            start filling in the documentation themselves.  Which
-            brings us to the next point...</para>
-  </listitem>
-  <listitem><para>Label the areas where the documentation is known
-            to be incomplete.  By showing the readers that you are
-            aware of its deficiencies, you align yourself with
-            their point of view.  Your empathy reassures them that
-            they don't face a struggle to convince the project of
-            what's important.  These labels needn't represent
-            promises to fill in the gaps by any particular date
-           &mdash;it's equally legitimate to treat them as open
-            requests for volunteer help.</para>
-  </listitem>
-</itemizedlist>
-
-<para>The last point is of wider importance, actually, and can be
-applied to the entire project, not just the documentation.  An
-accurate accounting of known deficiencies is the norm in the open
-source world.  You don't have to exaggerate the project's
-shortcomings, just identify them scrupulously and dispassionately when
-the context calls for it (whether in the documentation, in the bug
-tracking database, or on a mailing list discussion).  No one will
-treat this as defeatism on the part of the project, nor as a
-commitment to solve the problems by a certain date, unless the project
-makes such a commitment explicitly.  Since anyone who uses the
-software will discover the deficiencies for themselves, it's much
-better for them to be psychologically prepared&mdash;then the
-project will look like it has a solid knowledge of how it's
-doing.</para>
-
-<sidebar id="starting-a-faq">
-  <title>Maintaining a FAQ</title>
-
-  <para>A <firstterm>FAQ</firstterm> ("Frequently Asked Questions"
-  document) can be one of the best investments a project makes in
-  terms of educational payoff.  FAQs are highly tuned to the questions
-  users and developers actually ask&mdash;as opposed to the questions
-  you might have <emphasis>expected</emphasis> them to ask&mdash;and
-  therefore, a well-maintained FAQ tends to give those who consult it
-  exactly what they're looking for.  The FAQ is often the first place
-  users look when they encounter a problem, often even in preference
-  to the official manual, and it's probably the document in your
-  project most likely to be linked to from other sites.</para>
-
-  <para>Unfortunately, you cannot make the FAQ at the start of the
-  project.  Good FAQs are not written, they are grown.  They are by
-  definition reactive documents, evolving over time in response to
-  people's day-to-day usage of the software.  Since it's impossible to
-  correctly anticipate the questions people will ask, it is impossible
-  to sit down and write a useful FAQ from scratch.</para>
-
-  <para>Therefore, don't waste your time trying to.  You may, however,
-  find it useful to set up a mostly blank FAQ template, so there will
-  be an obvious place for people to contribute questions and answers
-  after the project is under way.  At this stage, the most important
-  property is not completeness, but convenience: if the FAQ is easy to
-  add to, people will add to it.  (Proper FAQ maintenance is a
-  non-trivial and intriguing problem, and is discussed more in <xref
-  linkend="faq-manager"/><phrase output="printed"> in
-  <xref linkend="managing-volunteers"/></phrase>.)</para>
-</sidebar>
-
-<sect3 id="documentation-availability">
-<title>Availability of documentation</title>
-
-<para>Documentation should be available from two places: online
-(directly from the web site), <emphasis>and</emphasis> in the
-downloadable distribution of the software (see
-<xref linkend="packaging"/><phrase output="printed"> in
-<xref linkend="development-cycle"/></phrase>).  It needs to be
-online, in browsable form, because people often read documentation
-<emphasis>before</emphasis> downloading software for the first time,
-as a way of helping them decide whether to download at all.  But it
-should also accompany the software, on the principle that downloading
-should supply (i.e., make locally accessible) everything one needs to
-use the package.</para>
-
-<para>For online documentation, make sure that there is a link that
-brings up the <emphasis>entire</emphasis> documentation in one HTML
-page (put a note like "monolithic" or "all-in-one" or "single large
-page" next to the link, so people know that it might take a while to
-load).  This is useful because people often want to search for a
-specific word or phrase across the entire documentation.  Generally,
-they already know what they're looking for; they just can't remember
-what section it's in.  For such people, nothing is more frustrating
-than encountering one HTML page for the table of contents, then a
-different page for the introduction, then a different page for
-installation instructions, etc.  When the pages are broken up like
-that, their browser's search function is useless.  The separate-page
-style is useful for those who already know what section they need, or
-who want to read the entire documentation from front to back in
-sequence.  But this is <emphasis>not</emphasis> the most common way
-documentation is accessed.  Far more often, someone who is basically
-familiar with the software is coming back to search for a specific
-word or phrase.  To fail to provide them with a single, searchable
-document would only make their lives harder.</para>
-
-</sect3>
-
-<sect3 id="developer-documentation">
-<title>Developer documentation</title>
-
-<para>Developer documentation is written to help programmers
-understand the code, so they can repair and extend it.  This is
-somewhat different from the <emphasis>developer guidelines</emphasis>
-discussed earlier, which are more social than technical.  Developer
-guidelines tell programmers how to get along with each other;
-developer documentation tells them how to get along with the code
-itself.  The two are often packaged together in one document for
-convenience (as with the <ulink
-url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/> example given
-earlier), but they don't have to be.</para>
-
-<para>Although developer documentation can be very helpful, there's no
-reason to delay a release to do it.  As long as the original authors
-are available (and willing) to answer questions about the code, that's
-enough to start with.  In fact, having to answer the same questions
-over and over is a common motivation for writing documentation.  But
-even before it's written, determined contributors will still manage to
-find their way around the code.  The force that drives people to spend
-time learning a code base is that the code does something useful for
-them.  If people have faith in that, they will take the time to figure
-things out; if they don't have that faith, no amount of developer
-documentation will get or keep them.</para>
-
-<para>So if you have time to write documentation for only one
-audience, write it for users.  All user documentation is, in effect,
-developer documentation as well; any programmer who's going to work on
-a piece of software will need to be familiar with how to use it.
-Later, when you see programmers asking the same questions over and
-over, take the time to write up some separate documents just for
-them.</para>
-
-<para>Some projects use wikis for their initial documentation, or even
-as their primary documentation.  In my experience, this really only
-works if the wiki is actively edited by a few people who agree on how
-the documentation is to be organized and what sort of "voice" it
-should have.  See
-<xref linkend="wikis"/><phrase output="printed"> in
-<xref linkend="technical-infrastructure"/></phrase> for
-more.</para>
-
-</sect3>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="example-output">
-<title>Example Output and Screenshots</title>
-
-<para>If the project involves a graphical user interface, or if it
-produces graphical or otherwise distinctive output, put some samples
-up on the project web site.  In the case of interface, this means
-screenshots; for output, it might be screenshots or just files.  Both
-cater to people's need for instant gratification: a single screenshot
-can be more convincing than paragraphs of descriptive text and mailing
-list chatter, because a screenshot is inarguable proof that the
-software <emphasis>works</emphasis>.  It may be buggy, it may be hard
-to install, it may be incompletely documented, but that screenshot is
-still proof that if one puts in enough effort, one can get it to
-run.</para>
-
-<sidebar id="screenshots">
-  <title>Screenshots</title>
-  <para>Since screenshots can be daunting until you've actually made a
-  few, here are basic instructions for making them.  Using the Gimp
-  (<ulink url="http://www.gimp.org/"/>), open
-  <guimenu>File</guimenu>-&gt;<guimenu>Acquire</guimenu>-&gt;<guimenu>Screenshot</guimenu>,
-  choose <guimenuitem>Single&nbsp;Window</guimenuitem> or
-  <guimenuitem>Whole&nbsp;Screen</guimenuitem>, then click
-  <guimenuitem>OK</guimenuitem>.  Now your next mouse click will
-  capture the window or screen clicked on as an image in the Gimp.
-  Crop and resize the image as necessary, using the instructions at 
-  <ulink url="http://www.gimp.org/tutorials/Lite_Quickies/#crop"/>.</para> 
-</sidebar>
-  
-</sect2>
-
-<para>There are many other things you could put on the project web
-site, if you have the time, or if for one reason or another they are
-especially appropriate: a news page, a project history page, a related
-links page, a site-search feature, a donations link, etc.  None of
-these are necessities at startup time, but keep them in mind for the
-future.</para>
-
-<sect2 id="starting-with-canned-hosting">
-<title>Canned Hosting</title>
-
-<para>There are a few sites that provide free hosting and
-infrastructure for open source projects: a web area, version control,
-a bug tracker, a download area, chat forums, regular backups, etc.
-The details vary from site to site, but the same basic services are
-offered at all of them.  By using one of these sites, you get a lot
-for free; what you give up, obviously, is fine-grained control over
-the user experience.  The hosting service decides what software the
-site runs, and may control or at least influence the look and feel of
-the project's web pages.</para>
-
-<para>See
-<xref linkend="canned-hosting"/><phrase output="printed"> in
-<xref linkend="technical-infrastructure"/></phrase> for a more
-detailed discussion of the advantages and disadvantages of canned
-hosting, and a list of sites that offer it.</para>
-
-</sect2>
-
-</sect1>
-
-
-<!-- ======================== SECTION ============================== -->
-<sect1 id="license-quickstart">
-<title>Choosing a License and Applying It</title>
-
-<para>This section is intended to be a very quick, very rough guide to
-choosing a license.  Read <xref linkend="legal"/> to understand
-the detailed legal implications of the different licenses, and how the
-license you choose can affect people's ability to mix your software
-with other free software.</para>
-
-<para>There are a great many free software licenses to choose from.
-Most of them we needn't consider here, as they were written to satisfy
-the particular legal needs of some corporation or person, and wouldn't
-be appropriate for your project.  We will restrict ourselves to just
-the most commonly used licenses; in most cases, you will want to
-choose one of them.</para>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="license-quickstart-non-gpl">
-<title>The "Do Anything" Licenses</title>
-
-<para>If you're comfortable with your project's code potentially being
-used in proprietary programs, then use
-an <firstterm>MIT/X-style</firstterm> license.  It is the simplest of
-several minimal licenses that do little more than assert nominal
-copyright (without actually restricting copying) and specify that the
-code comes with no warranty.  See
-<xref linkend="license-choosing-mit-x"/> for details.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="license-quickstart-gpl">
-<title>The GPL</title>
-
-<para>If you don't want your code to be used in proprietary programs,
-use the GNU General Public License
-(<ulink url="http://www.gnu.org/licenses/gpl.html"/>).  The GPL is
-probably the most widely recognized free software license in the world
-today.  This is in itself a big advantage, since many potential users
-and contributors will already be familiar with it, and therefore won't
-have to spend extra time to read and understand your license.  See
-<xref linkend="license-choosing-gpl"/><phrase output="printed">
-in <xref linkend="legal"/></phrase> for details.</para>
-
-<sidebar>
-<para>If users interact with your code primarily over a
-network&mdash;that is, the software is usually part of a hosted
-service&mdash;then consider using the <firstterm>GNU Affero
-GPL</firstterm> instead.  See
-<xref linkend="gnu-affero-gpl"/><phrase output="printed"> in
-<xref linkend="legal"/></phrase> for more.</para>
-</sidebar>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="license-quickstart-applying">
-<title>How to Apply a License to Your Software</title>
-
-<para>Once you've chosen a license, you should state it on the
-project's front page.  You don't need to include the actual text of
-the license there; just give the name of the license, and make it link
-to the full license text on another page.</para>
-
-<para>This tells the public what license you
-<emphasis>intend</emphasis> the software to be released under, but
-it's not sufficient for legal purposes.  For that, the software itself
-must contain the license.  The standard way to do this is to put the
-full license text in a file called <filename>COPYING</filename> (or
-<filename>LICENSE</filename>), and then put a short notice at the top
-of each source file, naming the copyright date, holder, and license,
-and saying where to find the full text of the license.</para>
-
-<para>There are many variations on this pattern, so we'll look at just
-one example here.  The GNU GPL says to put a notice like this at the
-top of each source file:</para>
-
-<screen>
-Copyright (C) &lt;year&gt;  &lt;name of author&gt;
-
-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 3 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, see &lt;http://www.gnu.org/licenses/&gt;
-</screen>
-
-<para>It does not say specifically that the copy of the license you
-received along with the program is in the file
-<filename>COPYING</filename>, but that's where it's usually put.  (You
-could change the above notice to state that directly.)  This template
-also gives a geographical address from which to request a copy of the
-license.  Another common method is to give a link to a web page
-containing the license.  Just use your judgement and point to wherever
-you feel the most permanent copy of the license is maintained, which
-might simply be somewhere on your project's web site.  In general, the
-notice you put in each source file does not have to look exactly like
-the one above, as long as it starts with the same notice of copyright
-holder and date, states the name of the license, and makes it clear
-where to view the full license.</para>
-
-</sect2>
-
-</sect1>
-
-<!-- ======================== SECTION ============================== -->
-<sect1 id="setting-tone">
-<title>Setting the Tone</title>
-
-<para>So far we've covered one-time tasks you do during project setup:
-picking a license, arranging the initial web site, etc.  But the most
-important aspects of starting a new project are dynamic.  Choosing a
-mailing list address is easy; ensuring that the list's conversations
-remain on-topic and productive is another matter entirely.  If the
-project is being opened up after years of closed, in-house
-development, its development processes will change, and you will have
-to prepare the existing developers for that change.</para>
-
-<para>The first steps are the hardest, because precedents and
-expectations for future conduct have not yet been set.  Stability in a
-project does not come from formal policies, but from a shared,
-hard-to-pin-down collective wisdom that develops over time.  There are
-often written rules as well, but they tend to be essentially a
-distillation of the intangible, ever-evolving agreements that really
-guide the project.  The written policies do not define the project's
-culture so much as describe it, and even then only
-approximately.</para>
-
-<para>There are a few reasons why things work out this way.  Growth
-and high turnover are not as damaging to the accumulation of social
-norms as one might think.  As long as change does not happen
-<emphasis>too</emphasis> quickly, there is time for new arrivals to
-learn how things are done, and after they learn, they will help
-reinforce those ways themselves.  Consider how children's songs
-survive the centuries.  There are children today singing roughly the
-same rhymes as children did hundreds of years ago, even though there
-are no children alive now who were alive then.  Younger children hear
-the songs sung by older ones, and when they are older, they in turn
-will sing them in front of other younger ones.  The children are not
-engaging in a conscious program of transmission, of course, but the
-reason the songs survive is nonetheless that they are transmitted
-regularly and repeatedly.  The time scale of free software projects
-may not be measured in centuries (we don't know yet), but the dynamics
-of transmission are much the same.  The turnover rate is faster,
-however, and must be compensated for by a more active and deliberate
-transmission effort.</para>
-
-<para>This effort is aided by the fact that people generally show up
-expecting and looking for social norms.  That's just how humans are
-built.  In any group unified by a common endeavor, people who join
-instinctively search for behaviors that will mark them as part of the
-group.  The goal of setting precedents early is to make those
-"in-group" behaviors be ones that are useful to the project; for once
-established, they will be largely self-perpetuating.</para>
-
-<!-- todo: maybe say this:
-
-     Point out how the sponsor's noble fair-mindedness and balanced
-     judgement are not properties that can usefully be written down
-     formally, because they wouldn't be believed.  They'd just look
-     like propaganda anyway, so there's no point.  This is one of
-     those areas where conduct and informal precedent is the *only*
-     way to solidify a social norm.  And refer to the relevant parts
-     of Chapter 5.
--->
-
-<para>Following are some examples of specific things you can do to set
-good precedents.  They're not meant as an exhaustive list, just as
-illustrations of the idea that setting a collaborative mood early
-helps a project tremendously.  Physically, every developer may be
-working alone in a room by themselves, but you can do a lot to make
-them <emphasis>feel</emphasis> like they're all working together in
-the same room.  The more they feel this way, the more time they'll
-want to spend on the project.  I chose these particular examples
-because they came up in the Subversion project (<ulink
-url="http://subversion.tigris.org/"/>),
-which I participated in and observed from its very beginning.  But
-they're not unique to Subversion; situations like these will come up
-in most open source projects, and should be seen as opportunities to
-start things off on the right foot.</para>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="avoid-private-discussions">
-<title>Avoid Private Discussions</title>
-
-<para>Even after you've taken the project public, you and the other
-founders will often find yourselves wanting to settle difficult
-questions by private communications among an inner circle.  This is
-especially true in the early days of the project, when there are so
-many important decisions to make, and, usually, few volunteers
-qualified to make them.  All the obvious disadvantages of public list
-discussions will loom palpably in front of you: the delay inherent in
-email conversations, the need to leave sufficient time for consensus
-to form, the hassle of dealing with naive volunteers who think they
-understand all the issues but actually don't (every project has these;
-sometimes they're next year's star contributors, sometimes they stay
-naive forever), the person who can't understand why you only want to
-solve problem X when it's obviously a subset of larger problem Y, and
-so on.  The temptation to make decisions behind closed doors and
-present them as <foreignphrase>faits accomplis</foreignphrase>, or at
-least as the firm recommendations of a united and influential voting
-block, will be great indeed.</para>
-
-<para>Don't do it.</para>
-
-<para>As slow and cumbersome as public discussions can be, they're
-almost always preferable in the long run.  Making important decisions
-in private is like spraying contributor repellant on your project.  No
-serious volunteer would stick around for long in an environment where
-a secret council makes all the big decisions.  Furthermore, public
-discussion has beneficial side effects that will last beyond whatever
-ephemeral technical question was at issue:
-
-<itemizedlist>
-  <listitem>
-  <para>The discussion will help train and educate new developers.
-        You never know how many eyes are watching the conversation;
-        even if most people don't participate, many may be tracking
-        silently, gleaning information about the software.</para>
-  </listitem>
-  <listitem>
-  <para>The discussion will train <emphasis>you</emphasis> in the art
-        of explaining technical issues to people who are not as
-        familiar with the software as you are.  This is a skill that
-        requires practice, and you can't get that practice by talking
-        to people who already know what you know.</para>
-  </listitem>
-  <listitem>
-  <para>The discussion and its conclusions will be available in public
-        archives forever after, enabling future discussions to avoid
-        retracing the same steps.  See
-        <xref linkend="using-archives"/><phrase output="printed">
-        in <xref linkend="communications"/></phrase>.</para>
-  </listitem>
-</itemizedlist>
-
-</para>
-
-<para>Finally, there is the possibility that someone on the list may
-make a real contribution to the conversation, by coming up with an
-idea you never anticipated.  It's hard to say how likely this is; it
-just depends on the complexity of the code and degree of
-specialization required.  But if anecdotal evidence may be permitted,
-I would hazard that this is more likely than one would intuitively
-expect.  In the Subversion project, we (the founders) believed we
-faced a deep and complex set of problems, which we had been thinking
-about hard for several months, and we frankly doubted that anyone on
-the newly created mailing list was likely to make a real contribution
-to the discussion.  So we took the lazy route and started batting some
-technical ideas back and forth in private emails, until an observer of
-the project<footnote><para>We haven't gotten to the section on
-crediting yet, but just to practice what I'll later preach: the
-observer's name was Brian Behlendorf, and it was he who pointed out
-the general importance of keeping all discussions public unless there
-was a specific need for privacy.</para></footnote> caught wind of what
-was happening and asked for the discussion to be moved to the public
-list.  Rolling our eyes a bit, we did&mdash;and were stunned by the
-number of insightful comments and suggestions that quickly resulted.
-In many cases people offered ideas that had never even occurred to us.
-It turned out there were some <emphasis>very</emphasis> smart people
-on that list; they'd just been waiting for the right bait.  It's true
-that the ensuing discussions took longer than they would have if we
-had kept the conversation private, but they were so much more
-productive that it was well worth the extra time.</para>
-
-<para>Without descending into hand-waving generalizations like "the
-group is always smarter than the individual" (we've all met enough
-groups to know better), it must be acknowledged that there are certain
-activities at which groups excel.  Massive peer review is one of them;
-generating large numbers of ideas quickly is another.  The quality of
-the ideas depends on the quality of the thinking that went into them,
-of course, but you won't know what kinds of thinkers are out there
-until you stimulate them with a challenging problem.</para>
-
-<para>Naturally, there are some discussions that must be had
-privately; throughout this book we'll see examples of those.  But the
-guiding principle should always be: <emphasis>If there's no reason for
-it to be private, it should be public.</emphasis></para>
-
-<para>Making this happen requires action.  It's not enough merely to
-ensure that all your own posts go to the public list.  You also have
-to nudge other people's unnecessarily private conversations to the
-list too.  If someone tries to start a private discussion, and there's
-no reason for it to be private, then it is incumbent on you to open
-the appropriate meta-discussion immediately.  Don't even comment on
-the original topic until you've either successfully steered the
-conversation to a public place, or ascertained that privacy really was
-needed.  If you do this consistently, people will catch on pretty
-quickly and start to use the public forums by default.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="prevent-rudeness">
-<title>Nip Rudeness in the Bud</title>
-
-<para>From the very start of your project's public existence, you
-should maintain a zero-tolerance policy toward rude or insulting
-behavior in its forums.  Zero-tolerance does not mean technical
-enforcement per se.  You don't have to remove people from the mailing
-list when they flame another subscriber, or take away their commit
-access because they made derogatory comments.  (In theory, you might
-eventually have to resort to such actions, but only after all other
-avenues have failed&mdash;which, by definition, isn't the case at the
-start of the project.)  Zero-tolerance simply means never letting bad
-behavior slide by unnoticed.  For example, when someone posts a
-technical comment mixed together with an <foreignphrase>ad
-hominem</foreignphrase> attack on some other developer in the project,
-it is imperative that your response address the <foreignphrase>ad
-hominem</foreignphrase> attack <emphasis>first</emphasis>, as a
-separate issue unto itself, and only afterward move on to the
-technical content.</para>
-
-<para>It is unfortunately very easy, and all too typical, for
-constructive discussions to lapse into destructive flame wars.
-People will say things in email that they would never say
-face-to-face.  The topics of discussion only amplify this effect: in
-technical issues, people often feel there is a single right answer to
-most questions, and that disagreement with that answer can only be
-explained by ignorance or stupidity.  It's a short distance from
-calling someone's technical proposal stupid to calling the person
-themselves stupid.  In fact, it's often hard to tell where technical
-debate leaves off and character attack begins, which is one reason why
-drastic responses or punishments are not a good idea.  Instead, when
-you think you see it happening, make a post that stresses the
-importance of keeping the discussion friendly, without accusing anyone
-of being deliberately poisonous.  Such "Nice Police" posts do have an
-unfortunate tendency to sound like a kindergarten teacher lecturing a
-class on good behavior:</para>
-
-    <blockquote>
-      <para><emphasis>First, let's please cut down on the
-      (potentially) ad hominem comments; for example, calling J's
-      design for the security layer "naive and ignorant of the basic
-      principles of computer security."  That may be true or it may
-      not, but in either case it's no way to have the discussion.  J
-      made his proposal in good faith.  If it has deficiencies, point
-      them out, and we'll fix them or get a new design.  I'm sure M
-      meant no personal insult to J, but the phrasing was unfortunate,
-      and we try to keep things constructive around here.
-      </emphasis></para>
-
-      <para><emphasis>Now, on to the proposal.  I think M was right
-      in saying that...</emphasis></para>
-    </blockquote>
-
-<para>As stilted as such responses sound, they have a noticeable
-effect.  If you consistently call out bad behavior, but don't demand
-an apology or acknowledgment from the offending party, then you leave
-people free to cool down and show their better side by behaving more
-decorously next time&mdash;and they will.  One of the secrets of
-doing this successfully is to never make the meta-discussion the main
-topic.  It should always be an aside, a brief preface to the main
-portion of your response.  Point out in passing that "we don't do
-things that way around here," but then move on to the real content, so
-that you're giving people something on-topic to respond to.  If
-someone protests that they didn't deserve your rebuke, simply refuse
-to be drawn into an argument about it.  Either don't respond (if you
-think they're just letting off steam and don't require a response), or
-say you're sorry if you overreacted and that it's hard to detect
-nuance in email, then get back to the main topic.  Never, ever insist
-on an acknowledgment, whether public or private, from someone that
-they behaved inappropriately.  If they choose of their own volition to
-post an apology, that's great, but demanding that they do so will only
-cause resentment.</para>
-
-<para>The overall goal is to make good etiquette be seen as one of the
-"in-group" behaviors.  This helps the project, because developers can
-be driven away (even from projects they like and want to support) by
-flame wars.  You may not even know that they were driven away; someone
-might lurk on the mailing list, see that it takes a thick skin to
-participate in the project, and decide against getting involved at
-all.  Keeping forums friendly is a long-term survival strategy, and
-it's easier to do when the project is still small.  Once it's part of
-the culture, you won't have to be the only person promoting it.  It
-will be maintained by everyone.</para>
-
-</sect2>
-
-<!-- ======================== subsection ============================== -->
-<sect2 id="code-review">
-<title>Practice Conspicuous Code Review</title>
-
-<para>One of the best ways to foster a productive development
-community is to get people looking at each others' code.  Some
-technical infrastructure is required to do this effectively&mdash;in
-particular, commit emails must be turned on; see
-<xref linkend="commit-emails"/> for more details.  The effect of
-commit emails is that every time someone commits a change to the
-source code, an email goes out showing the log message and diffs for
-the change (see <xref linkend="vc-vocabulary-diff"/>, in
-<xref linkend="vc-vocabulary"/>).  <firstterm>Code review</firstterm>
-is the practice of reviewing commit emails as they come in, looking
-for bugs and possible improvements.<footnote><para>This is how code
-review is usually done in open source projects, at any rate.  In more
-centralized projects, "code review" can also mean multiple people
-sitting down together and going over printouts of source code, looking
-for specific problems and patterns.</para></footnote></para>
-
-<para>Code review serves several purposes simultaneously.  It's the
-most obvious example of peer review in the open source world, and
-directly helps to maintain software quality.  Every bug that ships in
-a piece of software got there by being committed and not detected;
-therefore, the more eyes watch commits, the fewer bugs will ship.  But
-code review also serves an indirect purpose: it confirms to people
-that what they do matters, because one obviously wouldn't take time to
-review a commit unless one cared about its effect.  People do their
-best work when they know that others will take the time to evaluate
-it.</para>
-
-<para>Reviews should be public.  Even on occasions when I have been
-sitting in the same physical room with developers, and one of us has
-made a commit, we take care not to do the review verbally in the room,
-but to send it to the development mailing list instead.  Everyone
-benefits from seeing the review happen.  People follow the commentary
-and sometimes find flaws in it, and even when they don't, it still
-reminds them that review is an expected, regular activity, like
-washing the dishes or mowing the lawn.</para>
-
-<para>In the Subversion project, we did not at first make a regular
-practice of code review.  There was no guarantee that every commit
-would be reviewed, though one might sometimes look over a change if
-one was particularly interested in that area of the code.  Bugs
-slipped in that really could and should have been caught.  A developer
-named Greg Stein, who knew the value of code review from past work,
-decided that he was going to set an example by reviewing every line of
-<emphasis>every single commit</emphasis> that went into the code
-repository.  Each commit anyone made was soon followed by an email to
-the developer's list from Greg, dissecting the commit, analyzing
-possible problems, and occasionally praising a clever bit of code.  Right
-away, he was catching bugs and non-optimal coding practices that would
-otherwise have slipped by without ever being noticed.  Pointedly, he
-never complained about being the only person reviewing every commit,
-even though it took a fair amount of his time, but he did sing the
-praises of code review whenever he had the chance.  Pretty soon, other
-people, myself included, started reviewing commits regularly too.
-What was our motivation?  It wasn't that Greg had consciously shamed
-us into it.  But he had proven that reviewing code was a valuable way
-to spend time, and that one could contribute as much to the project by
-reviewing others' changes as by writing new code.  Once he
-demonstrated that, it became expected behavior, to the point where any
-commit that didn't get some reaction would cause the committer to
-worry, and even ask on the list whether anyone had had a chance to
-review it yet.  Later, Greg got a job that didn't leave him as much
-time for Subversion, and had to stop doing regular reviews.  But by
-then, the habit was so ingrained for the rest of us as to seem that it
-had been going on since time immemorial.</para>
-
-<para>Start doing reviews from very first commit.  The sorts of
-problems that are easiest to catch by reviewing diffs are security
-vulnerabilities, memory leaks, insufficient comments or API
-documentation, off-by-one errors, caller/callee discipline mismatches,
-and other problems that require a minimum of surrounding context to
-spot.  However, even larger-scale issues such as failure to abstract
-repeated patterns to a single location become spottable after one has
-been doing reviews regularly, because the memory of past diffs informs
-the review of present diffs.</para>
-
-<!-- todo: Andrew Stellman suggested putting a checklist of what to
-     look for in code review here.  That might be a good idea. -->
-
-<para>Don't worry that you might not find anything to comment on, or
-that you don't know enough about every area of the code.  There will
-usually be something to say about almost every commit; even where you
-don't find anything to question, you may find something to praise.
-The important thing is to make it clear to every committer that what
-they do is seen and understood.  Of course, code review does not
-absolve programmers of the responsibility to review and test their
-changes before committing; no one should depend on code review to
-catch things he ought to have caught on his own.</para>
-
-</sect2>
-
-<!-- ======================== SECTION ============================== -->
-<sect2 id="opening-closed-projects">
-<title>When Opening a Formerly Closed Project, be Sensitive to the
-Magnitude of the Change</title>
-
-<para>If you're opening up an existing project, one that already has
-active developers accustomed to working in a closed-source
-environment, make sure everyone understands that a big change is
-coming&mdash;and make sure that you understand how it's going to
-feel from their point of view.</para>
-
-<para>Try to imagine how the situation looks to them: formerly, all
-code and design decisions were made with a group of other programmers
-who knew the software more or less equally well, who all received the
-same pressures from the same management, and who all know each others'
-strengths and weaknesses.  Now you're asking them to expose their code
-to the scrutiny of random strangers, who will form judgements based
-only on the code, with no awareness of what business pressures may
-have forced certain decisions.  These strangers will ask lots of
-questions, questions that jolt the existing developers into realizing
-that the documentation they slaved so hard over is
-<emphasis>still</emphasis> inadequate (this is inevitable).  To top it
-all off, the newcomers are unknown, faceless entities.  If one of your
-developers already feels insecure about his skills, imagine how that
-will be exacerbated when newcomers point out flaws in code he wrote,
-and worse, do so in front of his colleagues.  Unless you have a team
-of perfect coders, this is unavoidable&mdash;in fact, it will probably
-happen to all of them at first.  This is not because they're bad
-programmers; it's just that any program above a certain size has bugs,
-and peer review will spot some of those bugs (see
-<xref linkend="code-review"/><phrase output="printed"> earlier
-in this chapter</phrase>).  At the same time, the newcomers
-themselves won't be subject to much peer review at first, since they
-can't contribute code until they're more familiar with the project.
-To your developers, it may feel like all the criticism is incoming,
-never outgoing.  Thus, there is the danger of a siege mentality taking
-hold among the old hands.</para>
-
-<para>The best way to prevent this is to warn everyone about what's
-coming, explain it, tell them that the initial discomfort is perfectly
-normal, and reassure them that it's going to get better.  Some of
-these warnings should take place privately, before the project is
-opened.  But you may also find it helpful to remind people on the
-public lists that this is a new way of development for the project,
-and that it will take some time to adjust.  The very best thing you
-can do is lead by example.  If you don't see your developers answering
-enough newbie questions, then just telling them to answer more isn't
-going to help.  They may not have a good sense of what warrants a
-response and what doesn't yet, or it could be that they don't have a
-feel for how to prioritize coding work against the new burden of
-external communications.  The way to get them to participate is to
-participate yourself.  Be on the public mailing lists, and make sure
-to answer some questions there.  When you don't have the
-expertise to field a question, then visibly hand it off to a developer
-who does&mdash;and watch to make sure he follows up with an answer,
-or at least a response.  It will naturally be tempting for the
-longtime developers to lapse into private discussions, since that's
-what they're used to.  Make sure you're subscribed to the internal
-mailing lists on which this might happen, so you can ask that such
-discussions be moved to the public lists right away.</para>
-
-<para>There are other, longer-term concerns with opening up formerly
-closed projects.  <xref linkend="money"/> explores
-techniques for mixing paid and unpaid developers successfully, and
-<xref linkend="legal"/> discusses the necessity of legal diligence
-when opening up a private code base that may contain software written
-or "owned" by other parties.</para>
-
-</sect2>
-
-</sect1>
-
-
-<!-- ======================== SECTION ============================== -->
-<sect1 id="announcing">
-<title>Announcing</title>
-
-<para>Once the project is presentable&mdash;not perfect, just
-presentable&mdash;you're ready to announce it to the world.  This is
-actually a very simple process: go to <ulink
-url="http://freshmeat.net/"/>, click on
-<guimenuitem>Submit</guimenuitem> in the top navigation bar, and fill
-out a form announcing your new project.  Freshmeat is the place
-everyone watches for new project announcements.  You only have to
-catch a few eyes there for news of your project to spread by word of
-mouth.</para>
-
-<para>If you know of mailing lists or newsgroups where an announcement
-of your project would be on-topic and of interest, then post there,
-but be careful to make exactly <emphasis>one</emphasis> post per
-forum, and to direct people to your project's own forums for follow-up
-discussion (by setting the <systemitem>Reply-to</systemitem> header).
-The posts should be short and get right to the point:</para>
-
-<screen>
-To: discuss@lists.example.org
-Subject: [ANN] Scanley full-text indexer project
-Reply-to: dev@scanley.org
-
-This is a one-time post to announce the creation of the Scanley
-project, an open source full-text indexer and search engine with a
-rich API, for use by programmers in providing search services for
-large collections of text files.  Scanley is now running code, is
-under active development, and is looking for both developers and
-testers.
-
-Home page: http://www.scanley.org/
-
-Features:
-   - Searches plain text, HTML, and XML
-   - Word or phrase searching
-   - (planned) Fuzzy matching
-   - (planned) Incremental updating of indexes
-   - (planned) Indexing of remote web sites
-
-Requirements:
-   - Python 2.2 or higher
-   - Enough disk space to hold the indexes (approximately 2x
-     original data size)
-
-For more information, please come to scanley.org.
-
-Thank you,
--J. Random
-</screen>
-
-<para>(See <xref linkend="publicity"/><phrase output="printed">
-in <xref linkend="communications"/></phrase> for advice on announcing
-further releases and other project events.)</para>
-
-<para>There is an ongoing debate in the free software world about
-whether it is necessary to begin with running code, or whether a
-project can benefit from being opened even during the
-design/discussion stage.  I used to think starting with running code
-was the most important factor, that it was what separated successful
-projects from toys, and that serious developers would only be
-attracted to software that did something concrete already.</para>
-
-<para>This turned out not to be the case.  In the Subversion project,
-we started with a design document, a core of interested and
-well-connected developers, a lot of fanfare, and
-<emphasis>no</emphasis> running code at all.  To my complete surprise,
-the project acquired active participants right from the beginning, and
-by the time we did have something running, there were quite a few
-volunteer developers already deeply involved.  Subversion is not the
-only example; the Mozilla project was also launched without running
-code, and is now a successful and popular web browser.</para>
-
-<para>In the face of such evidence, I have to back away from the
-assertion that running code is absolutely necessary for launching a
-project.  Running code is still the best foundation for success, and a
-good rule of thumb would be to wait until you have it before
-announcing your project.  However, there may be circumstances where
-announcing earlier makes sense.  I do think that at least a
-well-developed design document, or else some sort of code framework,
-is necessary&mdash;of course it may be revised based on public
-feedback, but there has to be something concrete, something more
-tangible than just good intentions, for people to sink their teeth
-into.</para>
-
-<para>Whenever you announce, don't expect a horde of volunteers to
-join the project immediately afterward.  Usually, the result of
-announcing is that you get a few casual inquiries, a few more people
-join your mailing lists, and aside from that, everything continues
-pretty much as before.  But over time, you will notice a gradual
-increase in participation from both new code contributors and users.
-Announcement is merely the planting of a seed.  It can take a long
-time for the news to spread.  If the project consistently rewards
-those who get involved, the news <emphasis>will</emphasis> spread,
-though, because people want to share when they've found something
-good.  If all goes well, the dynamics of exponential communications
-networks will slowly transform the project into a complex community,
-where you don't necessarily know everyone's name and can no longer
-follow every single conversation.  The next chapters are about working
-in that environment.</para>
-
-</sect1>
-
-</chapter>
-
-<!--
-local variables: 
-sgml-parent-document: ("book.xml" "chapter")
-end:
--->
-
+<chapter id="getting-started">
+
+<title>시작하기</title>
+
+<simplesect>
+
+<para>에릭 레이몬드는 유명한 그의 저서 <citetitle>성당과 시장(The Cathedral and the
+
+Bazaar)</citetitle>에서 전통적으로 자유 소프트웨어들은 어떻게 시작되고 있는지를 설명합니다.
+He wrote:</para>
+
+    <blockquote>
+      <para><emphasis>좋은 소프트웨어는 개발자 자신의 가려움을 긁는 것에서 시작된다</emphasis></para>
+
+      <para>(from <emphasis role="bold"><ulink url="http://www.catb.org/~esr/writings/cathedral-bazaar/"></ulink>
+      </emphasis>)</para>
+    </blockquote>
+
+<para>모든 오픈소스 소프트웨어가 개인적인 가려움을 긁는것에서만 시작된다는 말은 아닙니다.
+그보다는 개인적인 가려움을 긁는 것이 자유소프트웨어를 시작하게 되는 가장 많은 동기를 차지하고 
+프로그래머 자신이 개인적으로 문제 해결에 관심이 있을때<emphasis>좋은</emphasis>
+소프트웨어가 탄생한다는 말입니다.</para>
+
+<para>이 글은 여전히 대부분의 자유 소프트웨어가 어떻게 시작하는가를 설명하고 있지만 
+지금 시점엔 레이몬드가 글을 쓴 1997년에 비해 약간 적은 비율을 차지하고 있습니다.
+지금 우리는 
+phenomenon of 단체들&mdash;이윤을 추구하는 기업을 포함하여&mdash;
+starting large,  맨땅에서 시작하는 중앙관리형 오픈소스 프로젝트를 가지고 있습니다.
+혼자 작업하는 프로그래머, 지역적인 문제를 해결하고 그 결과를 폭넓게 적용하는일 등이 여전히 많은 자유 소프트웨어의 근원이지만 이것이 전부는 아닙니다.
+
+</para>
+
+<para>아무튼 레이몬드의 지적은 여전히 유효합니다.  The essential
+condition is that the producers of the software have a direct interest
+in its success, because they use it themselves.  If the software
+doesn't do what it's supposed to do, the person or organization
+producing it will feel the dissatisfaction in their daily work.  For
+example, the OpenAdapter project (<ulink url="http://www.openadapter.org/"></ulink>), which was started by investment
+
+bank Dresdner Kleinwort Wasserstein as an open source framework for
+
+integrating disparate financial information systems, can hardly be
+
+said to scratch any individual programmer's personal itch.  It
+
+scratches an institutional itch.  But that itch arises directly from
+
+the experiences of the institution and its partners, and therefore if
+
+the project fails to relieve them, they will know.  This arrangement
+
+produces good software because the feedback loop flows in the right
+
+direction.  The program isn't being written to be sold to someone else
+
+so they can solve<emphasis>their</emphasis> problem.  It's being
+written to solve one's <emphasis>own</emphasis>problem, and then
+
+shared with everyone, much as though the problem were a disease and
+
+the software were medicine whose distribution is meant to completely
+
+eradicate the epidemic.</para>
+
+<para>이 챕터에선 어떻게 자유 소프트웨어를 세상에 내놓을지를 소개합니다.
+아마도 많은 내용이 보건기구의 의약품 배포와 비슷하게 들릴 겁니다.
+둘의 목표는 매우 비슷합니다: 약이 무슨 일을 하는지 분명하게 해야하고,
+올바른 사람들의 손에 주ㅣ어주어야 하고, 받은 사람들은 이것을 어떻게 사용하는지 알수 있게 해야 합니다.
+하지만 소프트웨어의 경우엔 약을 받은 사람에게 어떻게 약을 향상시켜야 할지
+연구에 참여하도록 초대하는 일도 해야합니다.</para>
+
+<para>자유 소프트웨어 배포는 twofold task 입니다. 
+유저를 확보해야 하고, 개발자도 확보해야 합니다. 이 두가지가 꼭 서로 충돌하는 일은 아닙니다만
+프로젝트 최초 프레젠테이션을 약간 복잡하게 만듭니다. 
+어떤 정보는 양쪽 모두에게 유용하지만 어느 한쪽에만 유용한 정보고 있습니다.
+Both kinds of
+information should subscribe to the principle of scaled presentation;
+that is, the degree of detail presented at each stage should
+correspond directly to the amount of time and effort put in by the
+reader.  More effort should always equal more reward.  When the two do
+not correlate tightly, people may quickly lose faith and stop
+investing effort.</para>
+
+<para>The corollary to this is that <emphasis>appearances
+
+matter</emphasis>.  Programmers, in particular, often don't like to
+believe this.  Their love of substance over form is almost a point of
+professional pride.  It's no accident that so many programmers exhibit
+an antipathy for marketing and public relations work, nor that
+professional graphic designers are often horrified at what programmers
+come up with on their own.</para>
+
+<para>This is a pity, because there are situations where form
+<emphasis>is</emphasis> substance, and project presentation is one of
+them.  For example, the very first thing a visitor learns about a
+project is what its web site looks like.  This information is absorbed
+before any of the actual content on the site is
+comprehended&mdash;before any of the text has been read or links
+clicked on.  However unjust it may be, people cannot stop themselves
+from forming an immediate first impression.  The site's appearance
+signals whether care was taken in organizing the project's
+presentation.  Humans have extremely sensitive antennae for detecting
+the investment of care.  Most of us can tell in one glance whether a
+web site was thrown together quickly or was given serious thought.
+This is the first piece of information your project puts out, and the
+impression it creates will carry over to the rest of the project by
+association.</para>
+
+<para>Thus, while much of this chapter talks about the content your
+project should start out with, remember that its look and feel matter
+too.  Because the project web site has to work for two different types
+of visitors&mdash;users and developers&mdash;special attention
+must be paid to clarity and directedness.  Although this is not the
+place for a general treatise on web design, one principle is important
+enough to deserve mention, particularly when the site serves multiple
+(if overlapping) audiences: people should have a rough idea where a
+link goes before clicking on it.  For example, it should be obvious
+<emphasis>from looking at the links</emphasis> to user documentation
+that they lead to user documentation, and not to, say, developer
+documentation.  Running a project is partly about supplying
+information, but it's also about supplying comfort.  The mere presence
+of certain standard offerings, in expected places, reassures users and
+developers who are deciding whether they want to get involved.  It
+says that this project has its act together, has anticipated the
+questions people will ask, and has made an effort to answer them in a
+way that requires minimal exertion on the part of the asker.  By
+giving off this aura of preparedness, the project sends out a message:
+"Your time will not be wasted if you get involved," which is exactly
+what people need to hear.</para>
+
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="look-around">
+<title>우선 주위를 둘러보자</title>
+
+<para>오픈소스 프로젝트를 시작하기 전, 중요한 caveat이 있습니다.
+caveat:</para>
+
+<para>언제나 주변에 원하는 그런 프로젝트가 이미 존재하는지 살펴보세요. 
+ The chances are pretty good that whatever problem
+you want solved now, someone else wanted solved before you. 
+만약 그들이 문제를 해결했고 자유 라이센스로 그들의 코드를 릴리즈 했다면
+굳이 바퀴를 다시 발명할 필요는 없습니다. 
+무언가 배우기 위해서 라거나, 기존 코드가 도움이 되질 않거나;
+혹은 생각하고 있는 프로젝트가 너무나 독특한 것이라서 누구도 하지 않았을 법한 일이라면 예외겠지만
+일반적으로 there's no point not looking, 그리고 그 대가는 클 수도 있습니다.
+만약 일반적인 검색엔진에서 결과가 나오지 않는다면, 아래 사이트에서도 한번 찾아보세요.
+<ulink url="http://freshmeat.net/"></ulink> (오픈소스 프로젝트 뉴스 사이트, 뒤에서 자세히 설명할것입니다.), on
+<ulink url="http://www.sourceforge.net/"></ulink>, 혹은 자유소프트웨어 재단의 자유소프트웨어 디렉토리
+<ulink url="http://directory.fsf.org/"></ulink>.</para>
+
+<para>만약 완벽하게 마음에 드는 프로젝트를 찾지 못하였더라도 
+, you might find something so close that it makes more sense to
+프로젝트에 참여해서 기능을 추가하는것이 맨땅에서 새로 만드는것보다 낫습니다.</para>
+
+</sect2>
+
+</simplesect>
+
+
+<!-- ========================== SECTION =========================== -->
+<sect1 id="starting-from-what-you-have">
+<title>가지고 있는 선에서 시작하기</title>
+
+<para>주변을 둘어보았으나 정말로 마음에 드는 프로젝트가 없고 새로운 프로젝트를 시작하기로 결정했다면..</para>
+
+<para>What now?</para>
+
+<para>자유소프트웨어 프로젝트에서 가장 어려운 부분 중 하나는 
+개인적인 비전을 public one으로 바꾸는 과정입니다.
+당신이나 당신이 속한 단체는 프로젝트의 요구사항을 완벽하게 알겁니다.
+하지만 그 목표를 world가 이해하기 쉽게 표현하는 것은 fair amount of work입니다. 
+이건 필수적입니다. however, that you take the time to do it. 
+우선 당신과 프로젝트를 시작한 다른 사람들이 프로젝트가 정말로 무엇인지 명확하게&mdash;that
+is, decide its limitations, 무엇을 할 것인가, 그리고 무엇을 하지 <emphasis>않을</emphasis>것인가&mdash; 해야 합니다. 
+그리고 mission statement를 써야합니다.  이건 그렇게까지 어렵진 않을겁니다만
+가끔 이 과정에서 거론되지 않았던 막연한 전제나 프로젝트 성향(nature)에 대한 불일치가 드러나기도 합니다.
+
+which is fine: better to resolve those now than later.  다음으로는 대중이 소비할 수 있도록 패키지를 만드는 일입니다.
+이 작업은 기본적으로.. 순수 노가다죠.</para>
+
+<para>What makes it so laborious is that it consists mainly of
+organizing and documenting things everyone already
+knows&mdash;"everyone", that is, who's been involved in the project so
+far.  Thus, for the people doing the work, there is no immediate
+benefit.  They do not need a <filename>README</filename> file giving
+an overview of the project, nor a design document or user manual.
+They do not need a carefully arranged code tree conforming to the
+informal but widespread standards of software source distributions.
+Whatever way the source code is arranged is fine for them, because
+they're already accustomed to it anyway, and if the code runs at all,
+they know how to use it.  It doesn't even matter, for them, if the
+fundamental architectural assumptions of the project remain
+undocumented; they're already familiar with that too.</para>
+
+<para>Newcomers, on the other hand, need these things.  Fortunately,
+they don't need them all at once.  It's not necessary for you to
+provide every possible resource before taking a project public.  In a
+perfect world, perhaps, every new open source project would start out
+life with a thorough design document, a complete user manual (with
+special markings for features planned but not yet implemented),
+beautifully and portably packaged code, capable of running on any
+computing platform, and so on.  In reality, taking care of all these
+loose ends would be prohibitively time-consuming, and anyway, it's
+work that one can reasonably hope volunteers will help with once the
+project is under way.</para>
+
+<para>What <emphasis>is</emphasis> necessary, however, is that enough
+investment be put into presentation that newcomers can get past the
+initial obstacle of unfamiliarity.  Think of it as the first step in a
+bootstrapping process, to bring the project to a kind of minimum
+activation energy.  I've heard this threshold called the
+<firstterm>hacktivation energy</firstterm>: the amount of energy a
+newcomer must put in before she starts getting something back.  The
+lower a project's hacktivation energy, the better.  Your first task is
+bring the hacktivation energy down to a level that encourages people
+to get involved.</para>
+
+<para>Each of the following subsections describes one important aspect
+of starting a new project.  They are presented roughly in the order
+that a new visitor would encounter them, though of course the order in
+which you actually implement them might be different.  You can treat
+them as a checklist.  When starting a project, just go down the list
+and make sure you've got each item covered, or at least that you're
+comfortable with the potential consequences if you've left one
+out.</para>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="choosing-a-name">
+<title>좋은 이름을 골라라</title>
+
+<para>누군가가 우연히 당신 프로젝트에 대해 들었다고 해봅시다.
+ 아마 자기의 문제를 해결할 수 있는 소프트웨어를 검색하다가 운 좋게 발견하였거나 했겠죠.
+그런 사람들은 프로젝트의 이름으로 프로젝트와 처음 만나게 될겁니다.</para>
+
+<para>이름이 좋다고 프로젝트가 자연히 성공하는 것은 아닙니다. 나쁜 이름이라고 망하는것도
+아니구요. &mdash;뭐, <emphasis>정말로</emphasis> 나쁜 이름이라면 그럴수도 있겠지만, 프로젝트를
+ 일부러 망하게 하려는 사람은  없겠지요. 아무튼, 나쁜 이름은 사람들이 기억해내지 못하거나,
+ 진지하지 않게 받아들이게 만들어,  프로젝트를 채택하는데  주저하게 만들 수 있습니다.</para>
+
+<para>좋은 이름이란:
+
+<itemizedlist>
+  <listitem><para>프로젝트가 무슨 일을 하는지 알려주거나,
+			최소한  무슨 일을 하는지 쉽게 연상시킬 수 있어야 합니다.
+			such that if one knows the name and knows what the project does,
+			나중에도 쉽게 이름을 기억해낼 수 있을겁니다.</para>
+  </listitem>
+  <listitem><para>기억하기 쉬워야 합니다. 거기에 영어가 인터넷의 기본언어화 되어가고 있다는 점을 간과해선 안됩니다.
+  			: "기억하기 쉽다"는 말은 "영어를 읽을 수 있는 사람에게 기억하기 쉽다"는 것을 뜻합니다.
+  			이름에 네이티브 스피커의 발음에 기반한 말장난을 사용하였다면
+  			많은 non-native 영어 사용자들은 이해하기 어려울것입니다.
+  			만약 기억하기 쉬운 이름이라면 말장난이 다소 심하더라도 사용할 만 할겁니다.
+  			다만 많은 사람들은 그 이름을 봤을때 머리속에서 네이티브 스피커처럼 들리지 않을것이라는 것을 염두해 두시기 바랍니다.</para>
+  </listitem>
+  <listitem><para>다른 프로젝트와 중복되지 않아야 합니다. 그리고 상표권을 침해해서도 안됩니다.
+  	         이것은 법적으로도 바른 일이지만 좋은 매너이기도 합니다.
+            아마도 identiry를 혼동 하게 만들고 싶진 않을겁니다.
+            이름이 같지 않더라도 인터넷에서 무언가를 추적하는건 이미 충분히 어려운 일입니다.</para>
+
+            <para>The resources mentioned earlier in
+            <xref linkend="look-around"></xref> are useful in
+            discovering whether another project already has the name
+            you're thinking of.  Free trademark searches are
+            available at <ulink url="http://www.nameprotect.org/"></ulink>
+            and <ulink url="http://www.uspto.gov/"></ulink>.</para>
+  </listitem>
+  <listitem><para>가능하다면,
+            <systemitem>.com</systemitem>,
+            <systemitem>.net</systemitem>,
+            <systemitem>.org</systemitem> 같은 최상위 도메인을 사용할 수 있어야 합니다. 
+            이 중 하나를 골라서, (아마도  <systemitem>.org</systemitem>),
+            프로젝트의 공식 사이트로 홍보하고;
+            나머지 두개는 포워딩을 하여 
+ 	         and are simply to
+            prevent third parties from creating identity confusion
+            around the project's name. 
+            만약 프로젝트 호스팅 사이트를 시용하기로 한 경우라도  (see
+            <xref linkend="starting-with-canned-hosting"></xref>), 
+            프로젝트에 맞는 도메인을 등록해서 포워딩 할 수 있습니다.
+            이것은 유저들에게 기억하기 쉬운 단순한 URL을 제공해 많은 도움을 줍니다.</para>
+    </listitem>
+</itemizedlist>
+
+</para>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="mission-statement">
+<title>분명한 목표를 가져라</title>
+
+<para>누군가가 프로젝트 웹사이트를 발견했다면, 먼저 프로젝트의 간단한 설명과 목표를 읽어볼 것이고,
+so they can decide (30초 안에) interested in 할지 말지 결정할 수 있어야 합니다.
+
+learning more. 목표는 첫페이지의 잘 보이는 곳, 되도록 프로젝트 이름 오른쪽 아래에 두어야 합니다.</para>
+
+<para>목표는 구체적이고, limiting, and above
+all, 짧아야 합니다. 다음의 오픈오피스 사이트는 좋은 예제입니다.<ulink url="http://www.openoffice.org/"></ulink>:</para>
+
+  <blockquote>
+  <para><emphasis>To create, as a community, the leading international
+  office suite that will run on all major platforms and provide access
+  to all functionality and data through open-component based APIs and
+  an XML-based file format.</emphasis></para>
+  </blockquote>
+
+<para>길지 않은 문장으로도 중요한 포인트는 모두 짚었습니다. largely by
+drawing on the reader's prior knowledge.  By saying "<emphasis>as a
+community</emphasis>", 개발을 좌지우지하는 기업은 없다는 암시를 하고;
+"<emphasis>international</emphasis>" 라는 단어는 여러 언어들로 사용할 수 있음을 알려주고;
+"<emphasis>all major platforms</emphasis>"는 말로 윈도우즈 유닉스 맥 등과 호환 됨을 알려주고 있습니다.
+The rest signals that open
+interfaces and easily understandable file formats are an important
+part of the goal.  They don't come right out and say that they're
+trying to be a free alternative to Microsoft Office, but most people
+can probably read between the lines.  Although this mission statement
+looks broad at first glance, in fact it is quite circumscribed: the
+words "<emphasis>office suite</emphasis>" mean something very concrete
+to those familiar with such software.  Again, the reader's presumed
+prior knowledge (in this case probably from MS Office) is used to keep
+the mission statement concise.</para>
+
+<para>The nature of a mission statement depends partly on who is
+writing it, not just on the software it describes.  For example, it
+makes sense for OpenOffice.org to use the words "<emphasis>as a
+community</emphasis>", because the project was started, and is still
+largely sponsored, by Sun Microsystems.  By including those words, Sun
+indicates its sensitivity to worries that it might try to dominate the
+development process.  With this sort of thing, merely demonstrating
+awareness of the <emphasis>potential</emphasis> for a problem goes a
+long way toward avoiding the problem entirely.  On the other hand,
+projects that aren't sponsored by a single corporation probably don't
+need such language; after all, development by community is the norm,
+so there would ordinarily be no reason to list it as part of the
+mission.</para>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="state-freedom">
+<title>State That the Project is Free</title>
+
+<para>Those who remain interested after reading the mission statement
+will next want to see more details, perhaps some user or developer
+documentation, and eventually will want to download something.  But
+before any of that, they'll need to be sure it's open source.</para>
+
+<para><emphasis>The front page must make it unambiguously clear that
+the project is open source.</emphasis> This may seem obvious, but you
+would be surprised how many projects forget to do it.  I have seen
+free software project web sites where the front page not only did not
+say which particular free license the software was distributed under,
+but did not even state outright that the software was free at all.
+Sometimes the crucial bit of information was relegated to the
+Downloads page, or the Developers page, or some other place that
+required one more mouse click to get to.  In extreme cases, the
+license was not given anywhere on the web site at all&mdash;the only
+way to find it was to download the software and look inside.</para>
+
+<para>Don't make this mistake.  Such an omission can lose many
+potential developers and users.  State up front, right below the
+mission statement, that the project is "free software" or "open source
+software", and give the exact license.  A quick guide to choosing a
+license is given in
+<xref linkend="license-quickstart"></xref><phrase output="printed">
+later in this chapter</phrase>, and
+licensing issues are discussed in detail in <xref linkend="legal"></xref>.</para>
+
+<para>At this point, our hypothetical visitor has
+determined&mdash;probably in a minute or less&mdash;that she's
+interested in spending, say, at least five more minutes investigating
+this project.  The next sections describe what she should encounter in
+that five minutes.</para>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="features-and-requirements">
+<title>Features and Requirements List</title>
+
+<para>There should be a brief list of the features the software
+supports (if something isn't completed yet, you can still list it, but
+put "<emphasis>planned</emphasis>" or
+"<emphasis>in&nbsp;progress</emphasis>" next to it), and the kind of
+computing environment required to run the software.  Think of the
+features/requirements list as what you would give to someone asking
+for a quick summary of the software.  It is often just a logical
+expansion of the mission statement.  For example, the mission
+statement might say:</para>
+
+  <blockquote>
+  <para><emphasis>To create a full-text indexer and search engine
+  with a rich API, for use by programmers in providing search
+  services for large collections of text files.</emphasis></para>
+  </blockquote>
+
+<para>The features and requirements list would give the details,
+clarifying the mission statement's scope:</para>
+
+  <blockquote>
+    <para><emphasis>Features:</emphasis></para>
+    <itemizedlist>
+      <listitem><para><emphasis>Searches plain text, HTML, and
+                XML</emphasis></para>
+      </listitem>
+      <listitem><para><emphasis>Word or phrase searching</emphasis></para>
+      </listitem>
+      <listitem><para><emphasis>(planned) Fuzzy matching</emphasis></para>
+      </listitem>
+      <listitem><para><emphasis>(planned) Incremental updating of
+                indexes</emphasis></para>
+      </listitem>
+      <listitem><para><emphasis>(planned) Indexing of remote web
+                sites</emphasis></para>
+      </listitem>
+    </itemizedlist>
+    <para><emphasis>Requirements:</emphasis></para>
+    <itemizedlist>
+      <listitem><para><emphasis>Python 2.2 or higher</emphasis></para>
+      </listitem>
+      <listitem><para><emphasis>Enough disk space to hold the indexes
+                (approximately 2x original data size)</emphasis></para>
+      </listitem>
+    </itemizedlist>
+  </blockquote>
+
+<para>With this information, readers can quickly get a feel for
+whether this software has any hope of working for them, and they can
+consider getting involved as developers too.</para>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="development-status">
+<title>개발 진행 상황</title>
+
+<para>사람들은 언제나 프로젝트가 어떻게 진행 되어가는지 알고 싶어 합니다.
+새로운 프로젝트 라면 약속한 기능과 지금까지 구현된 내용의 차이를 알고 싶어하고,
+성숙한 프로젝트 하면 얼마나 활성적으로 관리되고 있는지, 얼마나 자주 새로운 릴리즈를 하고, 버그 리포트 같은것에는 잘 반응하는지 등을 알고 싶어합니다.</para>
+
+<para>개발 진행 상황 페이지나 가까운 목표의 목록을 만들어 이 궁금증들에 대해 답을 제공하세요. (예를들어, it might be looking for developers with a particular kind of
+
+expertise). 또는 개발 진행 상황 페이지에 과거의 릴리즈 기록이나 기능 목록, so visitors can get an idea of how the project defines "progress" and how quickly it makes progress according to that definition. 하는 내용들을 넣을 수도 있습니다.</para>
+
+<para>아직 준비가 되지 않았음을 두려워 하지 마세요. 그리고 개발 진행상황을 과장하고 싶은 유혹에 빠지지 마세요.
+소프트웨어는 단계를 거치며 발전된다는 것을 누구나 알고 있습니다;
+"이것은 알파 버젼이고 알려진 버그가 있습니다. It runs, and works at least some of the
+time, 하지만 위험은 스스로 감수하십시오." 라고 말하는데 부끄러워 하지 않아도 됩니다.
+Such language won't scare away the kinds of developers you need at that stage.  As for users, one of the
+worst things a project can do is attract users before the software is
+ready for them.  A reputation for instability or bugginess is very
+hard to shake, once acquired.  Conservativism pays off in the long
+run; it's always better for the software to be
+<emphasis>more</emphasis>stable than the user expected than less, and
+
+pleasant surprises produce the best kind of word-of-mouth.</para>
+
+<sidebar id="alpha-and-beta">
+  <title>알파와 베타</title>
+  <para><firstterm>알파</firstterm>는 일반적으로 첫번째 릴리즈라는 뜻을 가지고 있습니다.
+  실제 원하는 작업을 할 수도 있고 의도한 기능들이 모두 작동 가능하지만 알려진 버그들을 아직 지니고 있는 상태입니다.
+  알파 소프트웨어의 주요 목적은 의견을 수집하여 개발자들에게 무슨 일을 해야 할지 알려주는데 있습니다.
+  그 다음 상태인<firstterm>베타</firstterm>는 모든 심각한 버그는 수정했지만 아직 출시를 하기엔 확신을 가질만큼 충분한 테스트를 거치지 않은 상태를 말합니다.
+  
+  The purpose of beta
+
+  software is to either become the official release, assuming no bugs
+
+  are found, or provide detailed feedback to the developers so they
+
+  can reach the official release quickly.  The difference between
+
+  alpha and beta is very much a matter of judgement.</para>
+</sidebar>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="downloads">
+<title>다운로드</title>
+
+<para>The software should be downloadable as source code in standard
+
+formats.  When a project is first getting started, binary (executable)
+
+packages are not necessary, unless the software has such complicated
+
+build requirements or dependencies that merely getting it to run would
+
+be a lot of work for most people.  (But if this is the case, the
+
+project is going to have a hard time attracting developers
+
+anyway!)</para>
+
+<para>The distribution mechanism should be as convenient, standard,
+and low-overhead as possible.  If you were trying to eradicate a
+disease, you wouldn't distribute the medicine in such a way that it
+requires a non-standard syringe size to administer.  Likewise,
+software should conform to standard build and installation methods;
+the more it deviates from the standards, the more potential users and
+developers will give up and go away confused.</para>
+
+<para>That sounds obvious, but many projects don't bother to
+standardize their installation procedures until very late in the game,
+telling themselves they can do it any time: <emphasis>"We'll sort all
+that stuff out when the code is closer to being ready."</emphasis>
+What they don't realize is that by putting off the boring work of
+finishing the build and installation procedures, they are actually
+making the code take longer to get ready&mdash;because they
+discourage developers who might otherwise have contributed to the
+code.  Most insidiously, they don't <emphasis>know</emphasis> they're
+losing all those developers, because the process is an accumulation of
+non-events: someone visits a web site, downloads the software, tries
+to build it, fails, gives up and goes away.  Who will ever know it
+happened, except the person themselves?  No one working on the project
+will realize that someone's interest and good will have been silently
+squandered.</para>
+
+<para>Boring work with a high payoff should always be done early, and
+significantly lowering the project's barrier to entry through good
+packaging brings a very high payoff.</para>
+
+<para>When you release a downloadable package, it is vital that you
+give a unique version number to the release, so that people can
+compare any two releases and know which supersedes the other.  A
+detailed discussion of version numbering can be found in <xref linkend="release-numbering"></xref>, and the details of standardizing
+build and installation procedures are covered in
+<xref linkend="packaging"></xref><phrase output="printed">, both
+in <xref linkend="development-cycle"></xref></phrase>.</para>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="vc-and-bug-tracker-access">
+<title>형상 관리와 버그 추적기</title>
+
+<para>Downloading source packages is fine for those who just want to
+install and use the software, but it's not enough for those who want
+to debug or add new features.  Nightly source snapshots can help, but
+they're still not fine-grained enough for a thriving development
+community.  People need real-time access to the latest sources, and
+the way to give them that is to use a version control system.  The
+presence of anonymously accessible version controlled sources is a
+sign&mdash;to both users and developers&mdash;that this project is
+making an effort to give people what they need to participate.  If you
+can't offer version control right away, then put up a sign saying you
+intend to set it up soon.  Version control infrastructure is discussed
+in detail in <xref linkend="vc"></xref><phrase output="printed"> in
+<xref linkend="technical-infrastructure"></xref></phrase>.</para>
+
+<para>The same goes for the project's bug tracker.  The importance of
+
+a bug tracking system lies not only in its usefulness to developers,
+
+but in what it signifies for project observers.  For many people, an
+
+accessible bug database is one of the strongest signs that a project
+
+should be taken seriously.  Furthermore, the higher the number of bugs
+
+in the database, the better the project looks.  This might seem
+
+counterintuitive, but remember that the number of bugs recorded really
+
+depends on three things: the absolute number of bugs present in the
+
+software, the number of users using the software, and the convenience
+
+with which those users can register new bugs.  Of these three factors,
+
+the latter two are more significant than the first.  Any software of
+
+sufficient size and complexity has an essentially arbitrary number of
+
+bugs waiting to be discovered.  The real question is, how well will
+
+the project do at recording and prioritizing those bugs?  A project
+
+with a large and well-maintained bug database (meaning bugs are
+
+responded to promptly, duplicate bugs are unified, etc.) therefore
+
+makes a better impression than a project with no bug database, or a
+
+nearly empty database.</para>
+
+<para>Of course, if your project is just getting started, then the bug
+database will contain very few bugs, and there's not much you can do
+about that.  But if the status page emphasizes the project's youth,
+and if people looking at the bug database can see that most filings have
+taken place recently, they can extrapolate from that that the project
+still has a healthy <emphasis>rate</emphasis> of filings, and they
+will not be unduly alarmed by the low absolute number of bugs
+recorded.</para>
+
+<para>Note that bug trackers are often used to track not only software
+bugs, but enhancement requests, documentation changes, pending tasks,
+and more.  The details of running a bug tracker are covered in
+<xref linkend="bug-tracker"></xref><phrase output="printed"> in
+<xref linkend="technical-infrastructure"></xref></phrase>, so I won't
+go into them here.  The important thing from a presentation point of
+view is just to <emphasis>have</emphasis> a bug tracker, and to make
+sure that fact is visible from the front page of the project.</para>
+
+</sect2>
+
+<!-- ======================== subsection ============================== -->
+<sect2 id="communications-channels">
+
+
+<title>대화 통로</title><para>Visitors usually want to know how to reach the human beings
+involved with the project.  Provide the addresses of mailing lists,
+chat rooms, and IRC channels, and any other forums where others
+involved with the software can be reached.  Make it clear that you and
+the other authors of the project are subscribed to these mailing
+lists, so people see there's a way to give feedback that will reach
+the developers.  Your presence on the lists does not imply a
+committment to answer all questions or implement all feature requests.