每个人都想要，不少人都在试，但是创造它的过程，说起来却都是泪。我说的是自由软件，又叫开源软件（译者注：本文重点不是辨析自由软件和开源软件的概念，作者如此说，姑且认为两者是一回事）。今天我要用十条行之有效的法则，来谈谈我三十年的写代码经验。
- 先有人，后有代码这是一条黄金定律，Isabel Drost-Fromm教我的。致力于社区建设，而不是软件本身。没有社区，你的代码解决的可能是错误的问题。这些代码会被废弃、忽略，最终消亡。先吸引人才，再给他们协作的空间。给他们有挑战的工作。不要自己写代码。
- 采用强制开源的许可证强制开源（share-alike）的许可证是开源软件的保险带。别夸口说你不需要，总有一天你会被打脸，遍体鳞伤。不要被打脸，使用强制开源的许可证。如果GPL/LGPL对你来说政治意味太浓，那么用MPLv2。
- 别指望达成共识做决定前寻求共识，就好像指望能找到理想的人生伴侣一样。有点不切实际。Github抛弃了共识，他们设计了fork/pull-request流程，所以2015年你已经没什么借口了。你接受补丁就可以了，就像维基百科会接受增补。先合并代码，再修复问题，最后再讨论。把所有开发工作都放在主分支上。不要让用户等。这样做你才能得到事实上的共识。
- 先问题后方案让你自己和你队友们关注问题，而不是功能。每个补丁都必须解决一个实在的问题。欢迎实验性代码，欢迎异想天开的创意。但不要让这些东西过度膨胀。收集好的方案，抛弃坏的。允许失败，各个层面上的失败。这是成长的必经之路。
- 先定义后实现积极地为API和协议的定义写文档并进行测试。用持续集成来测试公开的API和协议。代码覆盖率不重要，代码文档也不重要。重要的是，定义好的东西代码要去实现，并且实现得要好。
- 内部挖潜让贡献者（contributor）成为维护者（maintainer），让维护者成为负责人（owner）。平稳地、放松地做这件事，别害怕。保留权力把表现糟糕的人踢出去。鼓励人们创立他们自己的项目，尤其是基于已有的项目开发的新项目，或者与已有项目构成竞争关系的项目。日常表现不好的人，卸下他们的权力。
- 写下规则你有了自己的规则，就要写下来，这样大家才能知道。实际上都不用写了，借用我们为ZeroMQ设计的C4.1规则就行，如果你愿意，也可以简化这些规则。
- 公平地执行规则你的权力应该用来执行规则，而不是威逼别人认同项目的愿景。最重要的是，你自己要遵守规则。有这么一小撮维护者，会仅仅因为他们不喜欢一个补丁而枪毙它，而你如果自己不遵守规则，就会助长这类小团体，没什么比这更糟糕了。好吧，这么说有点夸张，更糟糕的事情多着呢。但是这类小团体会对项目造成危害。
- 细分项目力争建立一群小型、独立、自组织、互相竞争的小项目。不要搞大项目。这里说的“大项目”是指，有两到三个核心开发者的项目。不要用submodules（译者注：git的命令，用于指定外部项目的依赖性）之类的来指定依赖性。让别人自己选择想要集成的项目。这是基本的法则。
- 保持快乐的氛围也许你注意到，我并没有提及“创新”。如果要提，创新可能会排在11或12位。无论如何，你要为社区营造正向快乐的氛围。不要说某个问题愚蠢，不要说某个人愚蠢。社区总有一些人表现糟糕，即使规则很清楚也要违反。除了这些人，其他所有人都值得我们珍惜，我们应该像远道来访的客人一样对待他们。
