X-Git-Url: https://projects.mako.cc/source/fspm_howto/blobdiff_plain/24b5107d4077795776937de128305bb4a13f02d7..6356d08d1336c70711ac47151f80cab78ed8a0e8:/FreeSoftwareDevelopmentHOWTO.sgml?ds=inline
diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml
index 32091e7..4499e57 100644
--- a/FreeSoftwareDevelopmentHOWTO.sgml
+++ b/FreeSoftwareDevelopmentHOWTO.sgml
@@ -392,23 +392,487 @@
If you are reading this document, there's a good chance you
already have an idea for a project in mind. Chances are pretty
good, it fills a gap by doing something that no other free
- software process does or or does something unique
+ software process does or or does it in a way that is unique
+ enought to necessitate a seperate project.
-
+
+ Indentify and Articulate Your Idea
+
+ Eric S. Raymond writes about how free software projects start in
+ his paper, "The Cathedral and the Bazaar" which comes as required
+ reading for any free softare development. You can find it online
+ .
+
-
+
+ In "The Cathedral and Bazaar," Raymond tells us that:
+ Every good work of software starts by scratching a
+ developers itch. Raymond now widely accepted
+ hypothesis is that new free software programs are written, first
+ and foremost, to solve a specific problem facing the developer.
+
-
- Deciding on a License
-
+
+ If you have an idea for a program in mind, chances are good that
+ it it is targetting a specific problem or itch you want to see
+ scratched. This idea is the project. Articulate it
+ clearly. Write it out. Describe the problem you will attack in
+ detail. The success of your project in tackling a particular
+ problem will be tied to your ability to identify that problem
+ early on. Find out exactly what it is that you want your project
+ to do.
+
+
+
+
+ Evaluate Your Idea
+
+
+ In evaluating your idea, you need to ask yourself questions.
+ Before you move any further into this HOWTO, you need to
+ determine if the free software development model really is the
+ right one for your project. Obviously, since the program
+ scratches your itch, you are definately interested in seeing it
+ implemented in code. But, because one hacker coding alone fails
+ to qualify as a free software development effort, you need to ask
+ yourself the question: Is anybody else
+ interested?
+
+
+
+ Sometimes the answer is no. If you want to
+ write a set of scripts to sort your MP3
+ collection on your machine, maybe the free software development
+ model is not the best one to choose. However, if you want to
+ write a set of scripts to sort anyone's
+ MP3s, a free software project might fill a useful gap.
+
+
+
+ Luckily, The Internet is a place so big and diverse that, chances
+ are, there is someone, somewhere, who shares your interests and
+ how feels the same itch. It is the fact that there are so many
+ people with so many similar needs and desires that introduces the
+ second major question: Has somebody already had your
+ idea or a reasonably similar one?
+
+
+
+ Finding Similar Projects
+
+
+ There are places you can go on the web to try and answer this
+ question. If you have experience with the free software
+ community, you are probably already familiar with all of these
+ sites. All of the resources listed bellow offer searching of
+ their databases:
+
+
+
+
+
+ freshmeat.net
+
+ freshmeat
+ describes itself as, the Web's largest index of Linux
+ and Open Source software
and its reputation along
+ these lines remains unquestioned. If you can't find it on
+ freshmeat, its doubtful that you'll find it indexed anywhere
+ else.
+
+
+
+
+ Slashdot
+
+ Slashdot
+ provides News for Nerds: Stuff that Matters,
+ which usually includes discussion of free software, open
+ source, technology, and geek culture new and events. It is
+ not unusual for an particularly sexy develpment effort to be
+ announced here so it definately worth checking.
+
+
+
+
+ SourceForge
+
+ SourceForge
+ houses and facilitates a growning number of open source and
+ free software projects, SourceForge is quickly becoming a
+ nexus and an necessary stop for free software
+ developers. SourceForge's software
+ map and new
+ releases pages. should be necessary stops before
+ embarking on a new free software project. SourceForge also
+ provides a at Code Snippet
+ Library which contains useful reusuable chunks of
+ code in an array of langauges which can come in useful in any
+ project.
+
+
+
+
+ Google and Google's Linux Search
+
+ Google and
+ Google's Linux
+ Search, provide powwerful web searches that may
+ reveal people working on similar projects. It is not a
+ catalog of software or news like freshmeat or Slashdot, but
+ it is worth checking before you begin pouring your effort
+ into a redundant project.
+
+
+
+
+
+
+
+
+ Deciding to Proceed
+
+ Once you have successfull charted the terrain and have an idea
+ bout what kinds of similar free software projects exist, every
+ developer needs to decide whether to proceed with their own
+ project. It is rare that a new project seeks to accomplish a
+ goal that is not similar to related to the goal of another
+ project. Anyone starting a new project needs to ask themselves:
+ Will the new project be duplicating work done by
+ another project? Will the new project be competing for
+ developers with an existing project? Can the goals of the new
+ project be accomplished by adding functionality to an existing
+ project?
+
+
+
+ If the answer to any of these questions is yes, try to contact
+ the developer of the existing project in question and see if he
+ or she might be willing to collaborate with you.
+
+
+
+ This may be the single most difficult aspect of free software
+ development for many developers but it is essential. It is easy
+ to become fired up by and idea and be caught up in the momentum
+ and excitement of a new project. It is often extremely difficult
+ but it is important that any free software developer rememeber
+ that the best interests of the of the free software community
+ and the quickest way to accomplish ones own project's goals and
+ the goals of similar project can often be accomplished by
+ not starting a new project.
+
+
+
+
+
+
+
+ Licensing your Software
+
+
+ On one level, the difference between a piece of free software and
+ a piece of propriety software is the license. A license helps both
+ you as the developer by protecting your legal rights to your
+ software and helps demonstrate to those who wish to help you or
+ your project that they are encouraged to join.
+
+
+
+ Choosing a License
+
+
+ Any discussion of licenses is also sure to generate at least a
+ small flamewar as there are strong feelings that some free
+ software licenses are better than other free software
+ licenses. This discussion also brings up the question of
+ Open Source Software
and the debate around
+ Open Source Software
and Free
+ Software
. However, because I've written the Free Software
+ Development HOWTO and not the Open Source Development HOWTO, my
+ own allegiences in this argument are out in the open.
+
+
+
+ In attempting to reach a middle ground, I recommend picking any
+ license that conforms to the Debian Free Software
+ Guidlines. Examples of these licenses are the
+ GPL, the BSD, and the
+ Artistic License. Conforming to the definition of Free Software
+ offered by Richard Stallman in The Free
+ Software Definition, any of these licenses will
+ uphold, users' freedom to run, copy, distribute, study,
+ change and improve the software.
There are other licenses
+ as well but sticking with a more common license will offer the
+ advantage of immediate recognition and undestanding.
+
+
+
+ In attempting a more in-depth analysis, I agree with Karl Fogel's
+ description of licenses as falling into two groups: those that
+ are the GPL and those that are not the
+ GPL.
+
+
+
+ Personally, I license all my software under the
+ GPL. Created and protected by the Free
+ Software Foundation and the GNU Project, the
+ GPL is the license for the Linux kernel,
+ GNOME, Emacs, and the majority of Linux software. Its an easy
+ choice but I believe it is a good one. However, there
+ is a viral aspect to the GPLthat prevents the
+ mixture of GPL'ed code with
+ non-GPL'ed code. To many people (myself
+ included), this is a benefit, but to some, it is a major
+ drawback.
+
+
+
+ The three major license can be found at the following locations:
+
+
+
+
+
+ The GNU
+ General Public License
+
+
+ The
+ BSD License
+
+
+ The Artistic
+ License
+
+
+
+
+
+ In all cases, please read through any license before
+ your release your software. As the developer, you can't afford
+ any license surprises.
+
+
+
+
+ The Mechanics of Licensing
+
+
+ The text of the GPL offers a good
+ description of mechanics of applying a license to a piece
+ of software. A checklist for applying a license would include:
+
+
+
+
+
+
+ If at all possible, attach and distribute a full copy of
+ the license with the source and binary in a seperate
+ file.
+
+
+
+
+ At the top of each source file in your program, attach a
+ notice of copyright and information on where the full license
+ can be found. The GPL recommends that each
+ file begin with:
+
+
+one line to give the program's name and an idea of what it does.
+Copyright (C) yyyy name of author
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+
+
+ The GPL goes on to recommend attaching
+ information on contacting you (the author) via email or
+ physical mail.
+
+
+
+
+
+
+ The GPL continues and suggests that if your
+ program runs in an interactive mode, you should have the
+ program output a notice each time it enters interactive mode
+ that includes a message like this one that points to more
+ information about the programs licensing:
+
+
+
+Gnomovision version 69, Copyright (C) year name of author
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+type `show w'. This is free software, and you are welcome
+to redistribute it under certain conditions; type `show c'
+for details.
+
+
+
+
+ Finally, it might be helpful to include a
+ copyright disclaimer
with the program from an
+ employer or a school if you work as a programmer or if it seems
+ like your employer or school might be able to make an argument
+ for ownership of your code.
+
+
+
+
+
+
+
+ Final License Warning
+
+
+ Please, please, please, place your software under some
+ license. It may not seem important, and to you, it may not be,
+ but licenses are important. For a piece of software to be
+ included in the Debian GNU/Linux distrobution, it must have a
+ license that fits the Debian Free Software
+ Guidelines. If you have no license, your program can be
+ distributed in part of Debian until you rerelease it under a free
+ license. Please save yourself and others trouble by releasing the
+ first version of your software with a clear license.
+
+
+
+
+
+
Choosing a Method of Version Numbering
-
+
+ The most important thing about a system of numbering is
+ that there is one. It may seem pedantic to emphasize
+ this point but you'd be surprised at the number of scripts and
+ small programs that pop up without any version number.
+
+
+
+ The second most important thing about a system of
+ numbering is that the numbers always go up. Automatic
+ versioning systems and people's sense of order in the universe
+ will fall apart if version numbers don't rise. It doesn't
+ really matter if 2.1 is a big jump and
+ 2.0.005 is a small jump but it does matter that 2.1 is more recent
+ than 2.0.005.
+
+
+
+ Follow these two rules and you will not go wrong. Still there are
+ several versioning system that are well known, useful, and that
+ might be worth looking into before you release your first version.
+
+
+
+
+ Linux kernel version numbering:
+
+ The Linux kernel uses a versioning system where the any
+ minor odd minor version number refers to an development or
+ testing release and any even minor version number refers to a
+ stable version. Under this system, 2.1 and 2.3 kernels were and
+ always will be development and testing kernels and 2.0, 2.2. and
+ 2.4 kernels are all production code with a higher degree of
+ stability.
+
+
+
+ Whether you plan on having a split development model or only one version released at a time, my
+ experience with several free software projects and with the
+ Debian project has taught me taht use of Linux's version
+ numbering system is worth taking into consideration. In Debian,
+ all minor versions are stable distributions (2.0, 2.1,
+ etc). However, many people assume that 2.1 is an unstable or
+ development version and continue to use an older version until
+ they get so frusterated with the lack of development and
+ progress that they complain. If you never release an odd minor
+ version but only release even ones, nobody is hurt, and less
+ people are confused.
+
+
+
+
+
+ Wine version numbering:
+
+ Because of the unusual nature of wine's development where
+ it constantly improving but not working towards any immediately
+ achievable goal, wine is released every three weeks. Wine does
+ this by versioning their releases in Year Month Day format where
+ each release might be labeled wine-XXXXXXXX
where
+ the version from Janurary 04, 2000 would be
+ wine-20000104
. For certain projects, Year Month
+ Day format can make a lot of sense.
+
+
+
+
+
+ Mozilla milestones:
+
+ When one considers Netscape 6 and verdor versions, the
+ mozilla's project development structure is one of the most
+ complex free software model available. Their version numbering
+ has reflected the unique situation in which it is
+ developed.
+
+
+
+ Mozilla's development structure has historically been made up
+ of milestones. From teh beginning of the mozilla project, the
+ goals of the project in the order and degree to which they were
+ to be achieved were charted out on a series of road
+ maps. Major points and achievements along this roadmaps
+ were marked as milestones. Therefore, mozilla was built and
+ distributed nightly as "nightly builds" but on a day when the
+ goals of a milestone on the roadmap had been reached, that
+ particular build was marked as a milstone release.
+
+
+
+ While I haven't seen this method employed in any other projects
+ to date, I like the idea and think that it might have value in
+ any testing or development branch of a large free application
+ under heavy development.
+
+
+
+
+
@@ -425,13 +889,6 @@
-
-
-
- Nuturing Future Development
-
-
-
@@ -440,7 +897,6 @@
Maintaining a Project: Interacting with Developers
-
fswd!developers
@@ -524,4 +980,4 @@ sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
--->
+-->
\ No newline at end of file