X-Git-Url: https://projects.mako.cc/source/fspm_howto/blobdiff_plain/24b5107d4077795776937de128305bb4a13f02d7..6356d08d1336c70711ac47151f80cab78ed8a0e8:/FreeSoftwareProjectManagementHOWTO.sgml diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml index 32091e7..4499e57 100644 --- a/FreeSoftwareProjectManagementHOWTO.sgml +++ b/FreeSoftwareProjectManagementHOWTO.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