这篇文章的原文撰于1999年12月，我不知其作者为谁，也已经忘记是从哪个站点down下来的，只是刚才整理硬盘时，偶然发现了。觉得很好，想翻译给对自由软件开发感兴趣的人们。
许 多程序员想参与自由软件项目，但是他们不知道如何才可以置身于其中。这篇文章是一份非正式的“不成文的规则和协议”的收集，谨献给想成为自由软件 志愿者的人们。我是经历了许多错误后才了解这些的，并且对于本文中的一些建议，我也无法避免去违反；他们仅仅是一些粗略的准则。我相信每个人也都有自己不 同的一套准则的（作者很谦虚啊）。
不要从创建你自己的项目开始
许多人想写自由软件，因此他们做的第一件事是乱写一些代码，贴上GPL协议，再以0.0.1阿拉法版本发行。尽管这可以以此寻寻乐子或作为教学示范，但是总体上说这些做法一无是处。下面来说说为什么会这样：
通 过添加一些小的特性或者修正一些错误来阅读和学习他人的代码更具教育意义。许多项目都有bug跟踪系统；譬如，在Gnome项目中，我们有 bugs.gnome.org，Debian有类似系统等等。在一个bug跟踪系统中寻找bug并修复它，或者添加一个你想添加的特性才是你首先要做的。
很明显，梳理已存在的代码要比进行孤雁单飞的项目更有用处。
几乎你想要搞的项目已经有人在做了；一起来完成一个项目要比让两个项目都完不成要好得多。我可以向你保证，有95％的自由软件项目还未有结果便凋谢了。从自我学习的角度，并且也从出名和提高能力的角度来看，你需要人们帮助你的项目能成为那5％。
如果你还未潜心参与一个自由软件项目，你将不知道那些事情要做，并且你将会有一段梦魇似的时期来开展你自己的工作。
总之，如果你有一个很酷的想法并且认为它值得去做，一定要做。事实上，我们已经在做它了，而且这些项目中的一部分已经做了很大一部分。如果你有一些hacking经验并且有一个很令人感兴趣的项目，而且这个项目确实没有人在做，那么则一定要做。
编码、编码，还是编码
如 果你开始做一个项目，最重要的事情是写代码。你必须要写足够的代码让程序更为有用、漂亮；这可能要数月或多年孤军奋战，除非一些可爱的人们帮助你 来做而不是自行其是。你必须经常发布新版本、快速修正bug，并且保持着开发的兴奋。一路走下来，做一个自由软件是一项很繁重的工作。如果你单干，每周起 码要干10－20个小时。当然，你可以在现有项目的基础上来做，可以省许多力气，并且可以让你每周工作10－20个小时后，总能看到光明的未来。如果你不 能付出这多时间，就不要自讨苦吃。如果你不能写代码，同上。
做好孤军奋战的打算
许多人都想做X程序的开发，或者发布0.0.1阿拉法版本，而当他们的程序没有得到众人的回应时，他们就轻而易举的放弃了。一定要直面惨淡的人生，正视淋漓的鲜血！继续干下去，怎么想就怎么做。
当我们索取帮助时会出现相同的现象。最后，如果一个bug、错误的特性或文档的缺失是你自己的问题，那么你最好自行解决。Hacker们通常很和蔼的帮助不知道如何开始的新手，但迟早他们会期望你能够自行解决属于你自己的问题。
使用邮件列表
如 果你有问题，就在列表上发问好了。私下给开发者单独发mail是不礼貌的行为，除非你确信只有他们才可以解答你的问题。在邮件列表上发问，可以让诸多开 发人员有可能读到你的问题并予以解答（如果单独向其中某个开发者发邮件，而这个开发者并不负责其项目中你所质询的那个模块，你有可能无法得到答复，因为对 方不一定懂得你的问题）。
邮件列表和文档是项目开发者为了向尽可能多的用户提供支持而设立的。因此，要记住每个人都是志愿者，并且你也要尽你所能的解答你能解答的问题。
没有负责人
人们经常期望某人能负责自由软件项目；或者他们期望能指派任务，期望能按期完成。事实上不可能那样的，你没有权利控制其他人做什么，并且也不会有人告诉你要干什么，尽管可能会有许多的建议，你最好能潜心于其中，尽力的完成更多的事。
同他人协作
如 果你花费3个月的时间来写一些很酷的新特性，然后发现项目的维护者不喜欢你的想法并且不予接受，或者发现你的工作无法应用在该项目的最新版本，或者发现 其他人也做了相同的工作，你可能会不高兴。如果你筹划要做某项工作，应当向项目的维护者提供简短的通告以让他们清楚你的工作意图。很多项目维护者对你的通 告持怀疑态度，因为他们曾经受到过太多的通过，但从未看到结果。尽管如此，他们通常会用心给你回复并且可能给你一些建议。
如果你已经是项目的核心开发成员了，更要尽可能的与他人协作，通常使用email、CVS和IRC等工具的组合来完成。CVS可以很好的胜任于各开发者工作的合并任务。
“项目X什么时候完成？”或者“特性X会实现么？”，这类问题没有答案
没有谁能真正保证什么，包括非自由软件的开发者。
指手划脚者误事
指手划脚者貌似什么都懂，但从未写过程序，也不知道如何写程序。如果你不知道如何写程序，那么你就不可能知道软件是如何设计出来的。就是这样，你可能只为人们带来麻烦。
即使不会写程序，也是能为自由软件做很多事情的，譬如报告bug、软件特性征询、写文档、帮助用户解答问题和安装、用户群管理、web维护、服务器管理、为操作系统发行版做安装包等等。Hacker们会感激你喜欢他们的工作以及你的帮助。
潜水也是一种美德
参 加一个邮件列表的欲望并且对每件事情都品头论足，这是好事。不过不要变成指手划脚者。如果你有一些相关经验，譬如描述如何再生这个bug、在该领域中有 一些专业知识、知道如何回答这个问题，那么就公布出来。其他的事情就不要做了。另外，在一个论坛里在你准备发帖之前，潜水一会儿，看一看这个论坛的文化背 景，这是值得称赞的。
了解版权、专利、许可证、商标等等
在卷入自由软件之中时，你有必要了解一点法律常识。这意味着你必 须要进行自修了。一种常规的学习方法是在gnu.misc.discuss新闻组上翻阅每 周都在重复的论战内容。一种快速的学习方式是阅读GNU站点，有这些名词的特别分析。如果你不明白它们，不要公然去讨论它们。如果你准备写软件并且要对它 使用某种许可证时，应该去充分理解它们。
尊重软件包维护者的意愿
当你为一个软件包提交一个补丁时，使用同一份许可、代码风格等等是好事情。如果你正使用 CVS，不要未向包管理员通报就将你的工作提交到 CVS 服务器上。
当提交一个补丁之时，diff命令要使用-u选项
因为许多人都喜欢这么干。
要记住，每个人都是志愿者
对他们报以他们应该得到的尊敬。他们仅仅是因为喜欢才进行工作的。不尊重那些给予了你自由的人是很卑劣的行为。
执着
我们很多人都缺乏这项素质，但是你越是执着于一项特定的任务并完成它，你的工作成果就越有价值。我发现我只能挑一些小任务来做。其他的人们在一些长周期的项目上做的更好。根据你的个性聚集起精力。尽力完成项目，而不是野心勃勃的要做１００个。
了解社区
跟随一些新闻站点，譬如一些与你所参与的项目相关的LinuxToday, LWN 或Slashdot等站点，是个好方法。一本关于社区历史的好书叫做《Hackers》，是Steven Levy写的。http://www.gnu.org也有很多信息，在邮件列表上潜水，也可以了解好多东东。
你会愤怒
芝 麻大的事情，无论你做什么或说什么，一些人可能会激怒你。这也许是 internet上独特的现象。当这种事情发生时，没有上过这一课的人会纠缠不休。你不要如此，如果你在邮件列表上潜潜水，你将会了解到谁的观点是正确 的，并且谁是习惯性的出离愤怒的人。你需要做个厚脸皮的人。
保持快乐的心
Hacking 是最终目标；坐下来尽情的输出代码或文档。但也有许多通过IRC或Email进行的社交、讨论的机会。大多数时候，写代码也是一件乐事。因此，享受吧。那些只是这一观点的一个部分。
最后，请不要对这份文档或任何条目过于严肃。