开源成功十法则

每个人都想要，不少人都在试，但是创造它的过程，说起来却都是泪。我说的是自由软件，又叫开源软件（译者注：本文重点不是辨析自由软件和开源软件的概念，作者如此说，姑且认为两者是一回事）。今天我要用十条行之有效的法则，来谈谈我三十年的写代码经验。

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

本文是 pieterh 在其博客上发表的《Ten Rules for Open Source Success》一文的翻译，经作者许可分享至 InfoQ 中文站。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。