</para>
<para>
- This HOWTO tries to do a lot of thing (probably too many), but it
+ This HOWTO tries to do a lot of things (probably too many), but it
can't answer that question and won't attempt it. What this HOWTO
will attempt to do is give your Free Software project a fighting
chance--an edge. If you write a piece of crap that no one is
this is a new edition of this document, there may be errors and
inaccuracies, that may of course be damaging to your system.
Proceed with caution, and although this is highly unlikely, the
- author(s) do not take any responsibility for that.
+ author(s) does not take any responsibility for that.
</para>
<para>
</para>
<para>
- You are strongly recommended to take a backup of your system
+ You are strongly recommended to make a backup of your system
before major installation and backups at regular intervals.
</para>
</sect2>
<listitem>
<para>
- <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagment-HOWTO/t1.html">HTML</ulink>.
+ <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http:///yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
+ <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink URL="http:///yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
+ <ulink URL="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http:///yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
+ <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http:///yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
+ <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
</para>
</listitem>
</itemizedlist>
url="http://www.debian.org">Debian Project</ulink>. The project
has provided me with a home, a place to practice free software
advocacy, a place to make a difference, a place to learn from
- those how have been involved with the movement much longer than I,
+ those who have been involved with the movement much longer than I,
and proof of a free software project that definitely, definitely
works.
</para>
<para>
Starting a project involves a dilemma that you as a developer must
try and deal with: no potential user for your program is interested
- in a program that doesn't work while the development process that
+ in a program that doesn't work, while the development process that
you want to employ holds involvement of users as imperative.
</para>
In evaluating your idea, you need to first ask yourself a few
questions. This should happen before you move any further
through this HOWTO. Ask yourself: <emphasis>Is the free software
- development model really is the right one for your
+ development model really the right one for your
project?</emphasis>
</para>
</para>
<para>
- Luckily, The Internet is a place so big and so diverse that,
+ Luckily, the Internet is a place so big and so diverse that,
chances are, there is someone, somewhere, who shares your
- interests and how feels the same <quote>itch.</quote> It is the
+ interests and who feels the same <quote>itch.</quote> It is the
fact that there are so many people with so many similar needs and
desires that introduces the third major question: <emphasis>Has
somebody already had your idea or a reasonably similar
There are places you can go on the web to try and answer the
question above. If you have experience with the free software
community, you are probably already familiar with many of these
- sites. All of the resources listed bellow offer searching of
+ sites. All of the resources listed below offer searching of
their databases:
</para>
<term>Slashdot</term>
<listitem>
<para><ulink url="http://slashdot.org">Slashdot</ulink>
- provides <quote>News for Nerds: Stuff that Matters,</quote>
+ provides <quote>News for Nerds. Stuff that matters,</quote>
which usually includes discussion of free software, open
- source, technology, and geek culture new and events. It is
- not unusual for an particularly sexy development effort to be
- announced here so it definitely worth checking.</para>
+ source, technology, and geek culture news and events. It is
+ not unusual for a particularly sexy development effort to be
+ announced here, so it is definitely worth checking.</para>
</listitem>
</varlistentry>
<para><ulink url="http://sourceforge.net">SourceForge</ulink>
houses and facilitates a growing number of open source and
free software projects. It is also quickly becoming a nexus
- and an necessary stop for free software
+ and a necessary stop for free software
developers. SourceForge's <ulink
url="http://sourceforge.net/softwaremap/trove_list.php">software
map</ulink> and <ulink url="http://sourceforge.net/new/"> new
release</ulink> pages should be necessary stops before
embarking on a new free software project. SourceForge also
+ provides a <ulink
url="http://sourceforge.net/snippet/">Code Snippet
Library</ulink> which contains useful reusable chunks of code
in an array of languages which can come in useful in any
<listitem>
<para><ulink url="http://www.google.com">Google</ulink> and
<ulink url="http://www.google.com/linux"> Google's Linux
- Search</ulink>, provide powerful web searches that may reveal
+ Search</ulink>, provides powerful web searches that may reveal
people working on similar projects. It is not a catalog of
software or news like freshmeat or Slashdot, but it is worth
checking to make sure you aren't pouring your effort into a
<para>
For many developers this may be the single most difficult aspect
- of free software project managment but it is an essential one. It is
- easy to become fired up by an idea and be caught up in the
+ of free software project managment, but it is an essential one. It is
+ easy to become fired up by an idea and get caught up in the
momentum and excitement of a new project. It is often extremely
- difficult to do but, it is important that any free software
- developer remember that the best interests of the free software
+ difficult to do, but it is important that any free software
+ developer remembers that the best interests of the free software
community and the quickest way to accomplish your own project's
goals and the goals of similar projects can often be
accomplished by <emphasis>not</emphasis> starting a new
criteria, you can still go ahead. I thought <quote>gnubile</quote>
was one of the best I'd heard for a free software project ever and
I still talk about it long after I've stopped using the
- program. However, if you can flexible on the subject, listen to
+ program. However, if you can be flexible on the subject, listen to
Orchard's advice. It might help you.
</para>
</sect2>
Software Foundation and the GNU Project, the
<acronym>GPL</acronym> is the license for the Linux kernel,
GNOME, Emacs, and the vast majority of GNU/Linux software. It's
- the obvious choice but I believe it is a good one. Any BSD
+ the obvious choice but I also believe it is a good one. Any BSD
fanatic will urge you to remember that there is a viral aspect to
the <acronym>GPL</acronym> that prevents the mixture of
<acronym>GPL</acronym>'ed code with non-<acronym>GPL</acronym>'ed
In addition to man pages and command-line help, there are certain
files where people will look for documentation, especially in any
package containing source code. In a source distribution, most of
- these files can be stored in a the root directory of the source
+ these files can be stored in the root directory of the source
distribution or in a subdirectory of the root called
<quote>doc</quote> or <quote>Documentation.</quote> Common files
in these places include:
install</quote> and touches on any unusual options or actions
that may be necessary. For most relatively standard install
procedures and for most programs, INSTALL files are as short
- as possible are rarely over 100 lines.</para>
+ as possible and are rarely over 100 lines.</para>
</listitem>
</varlistentry>
changes you make to your program. The most simple way to
maintain a CHANGELOG is to simply keep a file with the source
code for your program and add a section to the top of the
- CHANGELOG with each release describing what has been, changed,
+ CHANGELOG with each release describing what has been changed,
fixed, or added to the program. It's a good idea to post the
CHANGELOG onto the website as well because it can help people
decide whether they want or need to upgrade to a newer version
<para>
It doesn't hurt to distribute any documentation for your program
- from your website (FAQs etc) with your program. Don't hesitate
+ from your website (FAQs etc) with your program. Don't hesitate to
throw any of this in the program's tarball. If people don't need
it, they will delete it. I can repeat it over and over:
<emphasis>Too much documentation is not a sin.</emphasis>
Binary packages should always be distribution specific. If you
can build binary packages against a current version of a major
distribution, you will only make your users happy. Try to foster
- relationships with users or developers of large distributiosn to
+ relationships with users or developers of large distributions to
develop a system for the consistent creation of binary
packages. It's often a good idea to provide RedHat
<acronym>RPM</acronym>'s (.rpm), Debian deb's (.deb) and source
<para>
I'd love to devote more space in this HOWTO to CVS because I love
it (I even use CVS to keep versions straight on this HOWTO!) but
- I think it falls outside the scope of this document and should
+ I think it falls outside the scope of this document and should have
(already has) its own HOWTO.
</para>
<para>
It should not come as any surprise that the key element to any
support infrastructure is good documentation. This topic was
- large covered in <xref linkend="documentation"> and will not be
+ largely covered in <xref linkend="documentation"> and will not be
repeated here.
</para>
</sect3>
projects / fspm_howto / blobdiff