75年生人,程序员,在西安。

未来商业的成功方向也许要参考开源社区的经验

以下摘录InfoQ文章内容:

开源成功十法则来自三十年代码经验的实战总结


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


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中文站。


评论

© 世风十三 | Powered by LOFTER