启动一个项目会涉及到开发者必须努力应对的困境：潜在用户对无法工作的程序不感兴趣，而你想要采用的开发过程却将用户的参与视为必要条件。
如果你正在阅读本文档，那么你很可能已经有了项目的想法。很有可能这个想法填补了一个被感知到的空白，通过做一些其他自由软件项目没有做的事情，或者以一种足够独特的方式做事，以至于需要一个全新的软件。
Eric S. Raymond 在他的文章中写了自由软件项目是如何开始的， "大教堂与集市"，这篇文章是任何自由软件开发者的必读之作。它可以在网上找到。
在 "大教堂与集市" 中，Raymond 告诉我们："每一个优秀的软件作品都始于解决开发者的痛点。" Raymond 现在被广泛接受的假设是，新的自由软件程序首先是为了解决开发者面临的具体问题而编写的。
如果你心中有一个程序的想法，那么它很可能针对你想要解决的特定问题或 "痛点"。这个想法就是项目。 清楚地表达它。 写下来。 详细描述你将要解决的问题。 你的项目在解决特定问题方面的成功将与你早期清晰识别该问题的能力息息相关。 确切地找出你希望你的项目做什么。
Monty Manley 在一篇题为 "以开源方式管理项目。" 的文章中阐述了最初步骤的重要性。 正如下一节将展示的那样，在软件甚至准备好编码之前，还有很多工作需要完成。 Manley 说，"正确地开始一个 OSS 项目意味着开发者必须首先避免过早编写代码！"
在评估你的想法时，你需要首先问自己几个问题。 这应该在你继续阅读本 HOWTO 之前完成。 问问自己：自由软件开发模式真的是你项目的正确选择吗？
显然，由于该程序解决了你的痛点，你肯定有兴趣看到它以代码形式实现。 但是，由于一个黑客独自编码不能算作自由软件开发工作，你需要问自己第二个问题：还有其他人感兴趣吗？
你可以访问一些网站来尝试回答上述问题。 如果你对自由软件社区有经验，你可能已经熟悉许多这些站点。 以下列出的所有资源都提供对其数据库的搜索功能
freshmeat.net 将自己描述为 "网络上最大的 Linux 和开源软件索引"，并且在这方面的声誉是完全无与伦比和毋庸置疑的。 如果你在 freshmeat 上找不到它，那么你（或任何其他人）很可能根本找不到它。
Slashdot 提供 "为极客提供的新闻。 重要的事情，" 其中通常包括对自由软件、开源、技术和极客文化新闻和事件的讨论。 特别吸引人的开发工作在这里宣布并不罕见，因此绝对值得查看。
SourceForge 托管并促进了越来越多的开源和自由软件项目。 它也正在迅速成为自由软件开发者的枢纽和必要的停留地。 SourceForge 的 软件地图 和 新版本 页面应该是在开始一个新的自由软件项目之前必要的停留地。 SourceForge 还提供了一个 代码片段库，其中包含以多种语言编写的有用可重用代码块，这些代码块在任何项目中都可能派上用场。
Google 和 Google Linux 搜索，提供强大的网络搜索，可能会揭示正在从事类似项目的人员。 它不是像 freshmeat 或 Slashdot 这样的软件或新闻目录，但值得检查以确保你没有将精力投入到冗余项目中。
虽然有很多项目因描述性名称而失败，也有很多项目在没有描述性名称的情况下成功，但我认为为你的项目命名是值得深思熟虑的。 Leslie Orchard 在一篇 Advogato 文章 中探讨了这个问题。 他的文章很短，绝对值得快速浏览一下。
摘要是 Orchard 建议你选择一个名称，听到这个名称后，许多用户或开发者都会
知道项目是做什么的。
明天还能记住它。
幽默的是，Orchard 的项目 "Iajitsu" 两者都没有做到。 自文章撰写以来，开发实际上已经停滞，这可能与此无关。
不过，他提出了一个很好的观点。 有些公司的唯一工作就是为软件命名。 他们靠这个赚取惊人的金额，并且据说物有所值。 虽然你可能负担不起这样的公司，但你可以从它们的存在中学习，并稍微思考一下你给项目起的名字，因为它确实很重要。
如果你真的想要一个名字，但它不符合 Orchard 的标准，你仍然可以继续使用它。 我认为 "gnubile" 是我听过的自由软件项目最好的名字之一，即使在我停止使用该程序很久之后，我仍然在谈论它。 但是，如果你在这个问题上可以灵活一些，请听取 Orchard 的建议。 这可能会对你有所帮助。
为了在不牺牲我自己的理念的情况下，通过外交手段达成折衷方案，我将建议选择任何符合 Debian 自由软件指南 的许可证。 DFSG 最初由 Debian 项目在 Bruce Perens 的领导下编写，构成了 开源定义 的第一个版本。 DFSG 给出的自由许可证示例包括 GPL、BSD 和 Artistic License。 正如 ESR 在他的 HOWTO[ESRHOWTO] 中提到的，如果有可能，请不要编写自己的许可证。 我提到的这三个许可证都有悠久的解释传统。 它们也绝对是自由软件（因此可以作为 Debian 的一部分分发，也可以在其他允许自由软件传输的地方分发）。
根据 Richard Stallman 在 "自由软件定义" 中提供的自由软件定义，这些许可证中的任何一个都将维护 "用户运行、复制、分发、研究、更改和改进软件的自由。" 还有许多其他许可证也符合 DFSG，但坚持使用更知名的许可证将具有立即识别和理解的优势。 许多人在 COPYING 文件中写三四句话，就认为他们已经编写了一个自由软件许可证——正如我在 debian-legal 邮件列表中的长期经验所表明的那样，情况往往并非如此。
在尝试更深入的分析时，我同意 Karl Fogel 对许可证的描述，即许可证分为两类：一类是 GPL，另一类是非 GPL。
就我个人而言，我将我的所有软件都授权在 GPL 之下。 GPL 由自由软件基金会和 GNU 项目创建和保护，是 Linux 内核、GNOME、Emacs 和绝大多数 GNU/Linux 软件的许可证。 这是一个显而易见的选择，但我也认为这是一个不错的选择。 任何 BSD 狂热者都会敦促你记住，GPL 具有病毒式传播的特性，这会阻止 GPL 代码与非 GPL 代码的混合。 对许多人（包括我自己）来说，这是一个好处，但对一些人来说，这是一个主要的缺点。
许多人在 COPYING 文件中写三四句话，就认为他们已经编写了一个自由软件许可证——正如我在 debian-legal 邮件列表中的长期经验所表明的那样，情况往往并非如此。 它可能无法保护你，可能无法保护你的软件，并且可能会给那些想要使用你的软件但又非常关注许可证微妙法律要点的人带来很大的困难。 如果你对自制的许可证充满热情，请先将其交给 OSI 或 debian-legal 邮件列表 的人员，以保护自己免受许可证意外副作用的影响。
可以在以下位置找到三个主要的许可证
无论如何，请在根据任何许可证发布软件之前通读该许可证。 作为主要开发者，你承受不起任何许可证方面的意外。
GPL 的文本提供了 关于将许可证应用于软件的机制的良好描述。 我应用许可证的快速清单包括
让你自己或 FSF 成为作品的版权所有者。 在极少数情况下，你可能希望让赞助组织（如果它足够大且足够强大）成为版权所有者。 这样做就像在修改下面的版权声明时将名称放在空白处一样简单。 与流行的看法相反，你不需要向任何组织备案。 仅凭声明就足以获得作品的版权。
如果可能，请通过包含单独的文件，将许可证的完整副本附加到源代码和二进制文件并一起分发。
在程序中每个源文件的顶部，附加版权声明并包含有关在哪里可以找到完整许可证的信息。 GPL 建议每个文件都以
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.
|
GPL 接着建议附加关于通过电子邮件或实体邮件联系你（作者）的方法的信息。
GPL 继续建议，如果你的程序以交互模式运行，你应该编写程序，使其在每次进入交互模式时输出一个通知，其中包含类似这样的消息，该消息指向有关程序许可证的完整信息
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.
|
最后，如果你是一名程序员，或者如果你的雇主或学校似乎有可能在以后对你的代码的所有权提出异议，那么包含来自雇主或学校的 "版权免责声明" 可能会有所帮助。 这些通常不是必需的，但有很多自由软件开发者遇到过麻烦，并希望他们当时要求了一份免责声明。
请，请，请，将你的软件置于某种许可证之下。 它可能看起来不重要，对你来说也可能不重要，但许可证是重要的。 为了使一个软件能够包含在 Debian GNU/Linux 发行版中，它必须具有符合 Debian 自由软件指南 的许可证。 如果你的软件没有许可证，则在你在自由许可证下重新发布它之前，它不能作为 Debian 中的软件包分发。 请通过在发布软件的第一个版本时附带明确的许可证，来为你自己和他人省去麻烦。
关于版本编号系统，最重要的事情是存在一个系统。 强调这一点可能显得迂腐，但你会惊讶于有多少脚本和小程序在没有任何版本号的情况下出现。
这种方案的广泛使用就是为什么我在不了解任何发布版本的情况下，就知道 Linux 内核的 2.4.12 版本与 2.4.11、2.2.12 和 1.2.12 版本之间性质和相对程度的差异。
你可以弯曲或打破这些规则，人们也确实这样做。 但请注意，如果你选择这样做，有人会感到恼火，认为你不懂，并试图教育你，可能不会很客气。 我总是遵循这种方法，我也恳请你这样做。
有几种版本编号系统是众所周知的、有用的，并且可能值得你在发布第一个版本之前研究一下。
无论你计划采用拆分开发模型（如 第 3.3 节 中所述）还是每次只发布一个版本，我在多个自由软件项目和 Debian 项目中的经验都告诉我，使用 Linux 的版本编号系统值得考虑。 在 Debian 中，所有 次要版本都是稳定发行版（2.0、2.1 等）。 然而，许多人认为 2.1 是一个不稳定或开发版本，并继续使用旧版本，直到他们对缺乏开发进度感到沮丧，以至于他们抱怨并弄清楚系统。 如果你从不发布奇数次要版本而只发布偶数版本，没有人会受到伤害，困惑的人也会减少。 这是一个值得考虑的想法。
由于 wine 开发的特殊性质，这个非模拟器不断改进，但并非朝着任何立即可实现的目标努力，wine 每三周发布一次。 Wine 通过以 "年 月 日" 格式标记其发布版本来实现这一点，其中每个发布版本可能被标记为 "wine-XXXXXXXX"，例如 2000 年 1 月 4 日的版本将是 "wine-20000104"。 对于某些项目，"年 月 日" 格式可能很有意义。
当考虑到 Netscape 6 和供应商版本时，mozilla 项目的开发结构是可用的最复杂的自由软件模型之一。 项目的版本编号反映了其开发的独特情况。
Mozilla 的版本编号结构在历史上是由里程碑组成的。 从 mozilla 项目开始之初，项目目标及其实现顺序和程度都在一系列 路线图 上标出。 这些路线图上的主要点和成就被标记为里程碑。 因此，尽管 Mozilla 是作为 "每夜构建" 每晚构建和分发的，但在路线图上的里程碑目标实现的那一天，该特定构建被标记为 "里程碑版本。"
虽然到目前为止我还没有看到这种方法在任何其他项目中采用，但我喜欢这个想法，并认为它在大型应用程序的任何测试或开发分支中都可能具有价值。
许多其他方面都很出色的自由软件应用程序已经衰落和消亡，因为它们的作者是唯一完全了解如何使用它们的人。 即使你的程序主要是为精通技术的用户群体编写的，文档对于你的项目的生存也是有帮助的，甚至是必要的。 你将在后面的 第 4.3 节 中了解到，你应该始终发布可用的东西。 没有文档的软件是不可用的。
你需要为许多不同的人编写文档，并且有很多方法来记录你的项目。 源代码中文档的重要性对于帮助促进大型社区的开发至关重要，但这超出了本 HOWTO 的范围。 在这种情况下，本节讨论了用户导向文档的有用策略。
传统和必要的结合导致大多数自由软件项目中出现了一种半定期的文档系统，值得遵循。 用户和开发者都期望能够以多种方式获得文档，并且至关重要的是，如果你的项目要取得进展，你必须以他们可以阅读的形式提供他们正在寻求的信息。 人们已经开始期望
你的用户会希望能够输入 "man yourprojectname"，最终得到一个格式良好的 man 页面，突出显示你的应用程序的基本用法。 确保在发布程序之前，你已经为此做好了计划。
Man 页面并不难编写。 通过 "Linux Man-Page-HOWTO" 可以找到关于 man 页面编写过程的出色文档，该文档可通过 Linux 文档项目 (LDP) 获得，由 Jens Schweikhardt 编写。 可以从 Schweikhardt 的站点 或 LDP 获取。
也可以使用 DocBook SGML 编写 man 页面。 因为 man 页面非常简单，而 DocBook 方法相对较新，所以我还没有能够跟进，但很乐意得到任何可以给我更多关于如何准确完成此操作的信息的人的帮助。
apt 0.3.19 for i386 compiled on May 12 2000 21:17:27
Usage: apt-get [options] command
apt-get [options] install pkg1 [pkg2 ...]
apt-get is a simple command line interface for downloading and
installing packages. The most frequently used commands are update
and install.
Commands:
update - Retrieve new lists of packages
upgrade - Perform an upgrade
install - Install new packages (pkg is libc6 not libc6.deb)
remove - Remove packages
source - Download source archives
dist-upgrade - Distribution upgrade, see apt-get(8)
dselect-upgrade - Follow dselect selections
clean - Erase downloaded archive files
autoclean - Erase old downloaded archive files
check - Verify that there are no broken dependencies
Options:
-h This help text.
-q Loggable output - no progress indicator
-qq No output except for errors
-d Download only - do NOT install or unpack archives
-s No-act. Perform ordering simulation
-y Assume Yes to all queries and do not prompt
-f Attempt to continue if the integrity check fails
-m Attempt to continue if archives are unlocatable
-u Show a list of upgraded packages as well
-b Build the source package after fetching it
-c=? Read this configuration file
-o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
See the apt-get(8), sources.list(5) and apt.conf(5) manual
pages for more information and options.
|
版本控制系统可以使许多打包问题（以及本 HOWTO 中提到的许多其他问题）变得不那么麻烦。如果你正在使用 *NIX，CVS 是你的最佳选择。我全心全意地推荐 Karl Fogel 关于这个主题的书（以及发布的 HTML 版本）。
无论是否使用 CVS，你都应该花一些时间学习版本控制系统，因为它提供了一种自动化的方法来解决本 HOWTO 中描述的许多问题。我不知道 Windows 或 Mac OS 有任何免费的版本控制系统，但我知道 CVS 客户端在这两个平台上都存在。像 SourceForge 这样的网站也做得很好，提供了一个漂亮、易于使用的 CVS Web 界面。
我很想在本 HOWTO 中为 CVS 投入更多篇幅，因为我喜欢它（我甚至使用 CVS 来保持本 HOWTO 的版本清晰！），但我认为它超出了本文档的范围，并且已经有自己的 HOWTO。最值得注意的是 CVS 最佳实践 HOWTO[CVSBESTPRACTICES]，我已将其包含在随附的参考书目中。