开源成功十法则

  • 曹知渊

2015 年 10 月 9 日

话题:语言 & 开发架构

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

  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 读者交流群)。

语言 & 开发架构