公平与正义——中西方法制思想比较

一、引言
  当年的李约瑟,曾经提出过一个著名的关于中国历史的问题,“为什么中国的自然科学没有像西方那样发展?”,这个问题十分重大,引得无数的中外学者,来研究分析,并试图给出解答,或者否定这个问题本身。这个问题其实是由另外一个更加重要的问题引起的,就是中国为什么从远远领先于西方,变为远远落后于西方。在李约瑟的时代,更容易发现的,是科学与技术上的差距,而到了现在,在中国在自然科学领域急起直追了将近一百年之后,我们却发现,中国在很多领域,仍然落后于西方,而另外一些领域的差距,较之自然科学,更加难以缩短,比如法制领域。于是我们产生了另外一个类似的问题:“为什么中国没有发展出西方那样的法制思想?”
自然科学的差距,还不过是最近几百年的事情,而在法制思想上,中国的人治大于法治的观念已经延续了几千年,甚至直到现在,也没有明显的改观,为什么呢?
当我们深入的分析中西方法制思想的差距时,就越来越发现这只能称之为差别,而不能称之为差距,而这样的深刻的差别,与众多其它的因素一起,共同导致了中国与西方的巨大差距,因此我们的问题变成了两个:中西方法制思想差别何在?这样的差别为何会在近代导致中国的落后?

二、法制的目标
  中西方的法律,都出现甚早,从习惯法到成文法的演变也大致相同,但是为什么中国的法律往往徒有空文,无论立法者、执法者还是犯法者,都未对之有足够的尊重?换句话说,大多数人在大多数时候,都没有太把法律当作一回事,甚至越是重要的事情,就越是需要考虑法律之外的更多因素。我们可以这样解答:在中国,由于法律的目标是追求正义,而为了追求正义,法律只是众多的手段之一,相对于其他的手段,法律既不是最高的,也不必然是最好的,为了追求更高的正义,法律即使被践踏,也不值得为之惋惜。
  也许有人会问,难道西方法制追求的不是正义吗?我这里要给出的回答是:的确,西方法制的目标首先并非正义,而是公平。但是通过追求公平,他们认为得到了正义。请注意,是他们认为,而不是中国人认为。在中国人看来,公平并不必然就是正义,而西方人认为,公平——即是正义。
公平与正义有什么区别呢?我不是语言学家,即使是,这两个词我也很难从名词解释上给出答案。但是我能够给出两个意象,通过意象,我们可以初步了解公平与正义的区别。
  说到公平,我们可以联想到天平,西方法院的门口,大多有这样一架天平,这意味着什么呢?相等,或者说对等。这将是我们接下来讨论西方法制思想的出发点。
  而对于中国人来说,正义这个词,会使我们联想到什么呢?请抬头往上看,对,就是他,老天爷!每当要追求正义的时候,中国人就会往上看,盼这父母官,盼着青天大老爷,盼着圣明的君主或者伟大的领袖,或者是圣人,再不行就是盼着老天爷。哪怕对这个天失望之极,也还是要说:“苍天已死,黄天当立”。因为正义,是从天道而来的。这个天道,与西方的上帝,大有区别,这将是我们讨论中国法制思想的出发点。

三、西方法制思想的脉络
 a)基本概念的演进
  最早出现的概念非常直观,相等的现象很容易被发现,从物质上来说,苹果与苹果是相等的,从行为上来说,你打我一拳与我打你一拳是相等的。这样的概念因为交换的行为,而演变为“对等”,凡是可以交换的物质或行为,就是对等的。随着交换形式的复杂化,物质与行为之间也可以交换,例如劳动一天可以换两块肉,被打了一拳之后,可以得到一担柴的补偿。
  再进一步,当交换不是即时完成时,就出现了权利与义务的概念,在我被打了一拳之后,我就有权力打还一拳,或者在我得到了一头牛之后,我就有义务尽快付清余款。
  再进一步,当权利与义务有可能无法实现时,就需要有一种力量来保证,这样社会与契约也就同时出现了。当各种各样的契约,需要统一的,强有力的力量来保证时,法律与国家也就同时出现了。
  当一个社会物质极度匮乏时,生存是唯一的目标,这样的社会,是不存在什么分配问题的,因为首要的问题是保证大家都能吃到足够活下去的食物。在分配的问题出现时,这一定是指多出来的财富,根据某种规则与习惯,人们进行分配,分配得让大家满意时,中国人会称之为“公平”,而在古希腊思想中称之为“分配正义”。亚里斯多德就将正义分为两类,一类是“分配正义”,另一类是“矫正正义”,也就是受到损害之后得到适当的补偿。这两种正义,在中国人看来,其实也都是“公平”,因为这样的所谓正义,都有“等量、等比例”的概念在后面。
 b)理性与法律
  在古罗马,法律得到了空前的发展,甚至有人认为,罗马法的成就至今无可超越,是什么原因使得罗马法得以如此发展呢?有人又说,罗马法在立法上贡献极大,而在思想上却没有什么重要的著作,这又是为什么呢?还有一个现象,也很奇怪,就是罗马法的私法极为发达,而在公法上却不过如此,这又是什么原因呢?
  这些问题,我认为可以通过一个问题来提出与一并解决,那就是:“罗马的法律,追求的目标是什么?”我的回答是:“公平”。一种清晰的、精确的、可以计算的公平。为此,罗马法学家们运用理性的思维,不断的努力,试图越来越准确的区分与界定各种权利与义务,这样一种不断提高“天平”精度的努力,使得罗马法成就惊人。而这种理性的努力,其实非常琐碎和平凡,不能够称之为“法制思想”,但是却实实在在地推动了法制的进步。在这样的努力中,人与人之间的各种契约是最适合用“公平”的概念来处理的,而在罗马,有神论,特别是明确的基督教的一神论,很晚才确立其正统地位,而在此基础上推演出的法制思想,要到中世纪才开始起作用,这也就是为什么罗马的公法并不发达的原因。
 c)人与神的契约
  在古希腊与古罗马,很早就有自然法的概念,但是这个概念并不清晰,它混合了神谕与理性两种意思,就像肯定存在,但尚未被完全认识的真理,自然法也是人定法的追求目标与终极的批判者。但是这自然法究竟是些什么内容,却从来没能被说出来,因此这自然法对人定法的指导意义,也就有限了。
  另一方面,基督教出现之前的西方社会,道德的基础也并不牢固,它的三个来源“习俗、荣誉、直觉”,没有一个经得起仔细推敲,强权者的道德,成为相对而言最说得通的解释。
  基督教的出现,改变了这一切,经过早期教父们的努力,上帝、圣约的概念开始深入人心,这意味着:自然是上帝的创造,而自然法则是上帝的律法,这律法中与人相关的部分,以契约的形式记载于《旧约》与《新约》之中,而这样的契约,成为人类得救的保证,上帝的最终审判,也成为世间一切道德的基础和保证。
  人对上帝犯下的原罪,使得人与人之间的犯罪显得无足轻重,因为事实上人人都“该死”,而上帝绝对公正,又使得世间的律法是否公正,不值得过于在意。人人都应该关心的是自己的得救与永生,如何进入上帝之城,至于现实中的国家与政府,反倒变得无需介怀了。
 d)回归人性
  野蛮人征服了罗马,却被罗马的基督教完全征服,那么多伟大辉煌的文化,在宗教的眼光下看来都是人类堕落荒淫的证明,中世纪之所以黑暗,就在于上帝作为最高级,使得所有的比较级失去意义。神性压制了人性,长达千年!
  历史不断的前进,回归人性的历程也从两个方面展开,一方面是人与人的关系,另一方是人与上帝的关系。人与人的契约与人与上帝的契约始终存在,所谓回归人性,是指对于这两种契约的解释权回到了人手中。
  一方面,随着商业与殖民地的发达,人与人之间可能发生的契约关系也越来越复杂,蔑视财富的基督教,不可能发展出发达的民法和商法,从神的角度出发,这些都是可耻的欲望。不值得关心,但是事实上又必须有一套法律来处理这些契约关系,罗马法的复兴,也就成为必然的趋势。这样的复兴,使得运用理性追求公平的精神,重新成为法学的主流。
  另一方面的变化,更为重要,需要打个比方来解释。中世纪的得救之路其实非常好走,人人都相信主要跟着前面的人走,目的地就是天堂。走在最前面的是教皇和他手下的一帮主教、教父们。走在前面的人,自然有资格告诉后面的人,“往左一点,往右一点,什么是对,什么是错。”那时候识字的人不多,圣经也很少,在读过了圣经,了解了庞大复杂的神学体系的人之中,敢于产生怀疑的人更是凤毛麟角。但是终于有些人走到前面去,回来后告诉后面的人:“跟着前面的人走也可能会错的,最前面的那个家伙也不知道怎么走才对!”宗教改革的意思其实就是在说:“我不要前面的人来告诉我该怎么走,我只听上帝的。”大家都各自找路走,对错的事情交给上帝来裁决,事实上上帝又从来不出来裁决人的对错(或者说他从来不急着出来),所以对于这份契约的解释权,就实质上回到了人手中。
  事情发展到这一步,也就罢了,但是更糟糕的事情发生了,当更多的人独自走到前面去看过之后,回来的说法就更多了,甚至有人说:“你们不是方向错了,而是目标根本就错了!天堂不存在,上帝也不存在!”这样的宣告,简直就是石破天惊,人类信守了千年的契约,现在发现立约的另一方并不存在,那么这份契约,还有何意义?“上帝死了”这个消息被越来越多的人知道了,接下来的日子怎么过呢?“上帝若不存在,一切恶都可作。”立约者死了,救赎的承诺无法兑现了,最后的审判也无法执行了。西方社会,面临巨大的危机,因为道德基础“坍塌”了!
 e)程序正义——对公平的精确追求
  前面的话已经有点扯远了,我们再回来,讨论西方法制的发展。现在我们很关注的“程序正义”问题,其实不能称之为“程序正义”,而是“通过程序追求公平”,再加上一个隐含的理由:“追求公平就能达到正义”。
  我们都知道沙翁的名剧《威尼斯商人》,那位律师完全遵循法律和合同,要求夏洛克完全按照合同办事,自然吓得那个残忍而又愚蠢的商人不敢履行合同,皆大欢喜。中国人看这出戏,只看到正义伸张,并且佩服那个律师机智过人。却没有想到,这样的伸张方式,背后的西方法制精神。所谓“意料之外,情理之中”妙就妙在这情理、法理,早在西方深入人心,而在中国,大多数人是看不到这一层的。
但是前面说的那个理解,其实大可怀疑,“通过程序能否追求到公平”其实并不确定。在英国,当年普通法最讲程序,所有的案件,都一定要申请到合适的“令状”才能开庭。打个比方,天平称重,只能得出“轻、重、相等”三个结果,要追求结果的精确,人们就开始制造砝码,能和砝码相等,就能有准确的重量,但是和砝码对不上的,就不知道有多重,所谓“无令状则无权利”就是指这个意思。后来英国发展出衡平法,来解决这个困难,其实就是通过放宽程序的严格程度,来追求真正的公平。
  还有另一方面的怀疑,更加动摇这一理论。“通过公平能够得到正义吗?”功利主义者明确表示:“最大多数人的最大幸福才是正义。”这两种思想其实有着同样的假设:“正义是可以计算的。”只是功利主义者认为,计算每个个人的得失是无益的,整个社会的总量增加才是有益的。一个行为总会让有些人得,有些人失,追求绝对的公平,几乎不可能,即使成功,那样得到的也不能称之为正义。这样的疑问固然有力,但是“公平主义”的反击也很有力:“每个人都是平等的,没有任何一个人,因为任何理由,而应该被牺牲。利益的最大化,不能作为剥夺一个人的利益的借口!”这样的争论,直到今天也没有分出胜负。但是基本上“公平”是体,而“功利”只能是用,是目前比较主流的观点。
 f)简单的总结
  相等->对等—>契约—>人与人的契约和人与神的契约,是西方法制思想的主线,两大基本观念分别是:人与人的契约追求公平能够得到正义,而人与上帝的契约是社会道德的基础。这两大观念,都接受着挑战。一方面公平能否保证正义,并不确定,而另一方面,对上帝信仰的动摇,使得众多后起的理论,在寻找能够代替上帝的立约者。因为整个西方法制的思想,不出公平与契约的范围,因此他们的理论走向,也无非围绕着这两个焦点展开。这里要着重指出的就是:西方法制思想的两根柱子,并不牢靠,虽然不断有人在加固其基础,但是危机始终存在,并不能被西方社会、法制成就所掩盖。

四、中国法制思想的脉络
 a)基本概念的演进
  如果认真追究词语的来源的话,其实“正义”这个词很晚才有了现在的这个意思。我们说中国的法制目标是追求正义,换成近代以前的说法,应该是追求天道,天理,这“天理昭昭,报应不爽”,就是中国人理性中的终极正义。
  相对于古希腊,古代中国很早就确立了农耕民族的特征,对于农耕来说,“天”极为重要,这种重要,不是像希腊诸神那样直接决定人的命运,而是通过寒来暑往,日换星移,雨雪风霜,沧海桑田来影响人们的生活。这样的大自然,既是神秘的,又是有可能了解的,即使变幻多端的,又是有可能共处的。中国人最早发展出来的思想,就是“如何与自然相处”的学问与艺术。
  推演开来,天道是可以体察的,天命是可以领会的,人与天是能够和睦相处的,甚至天人合一,也是可以追求,也应该追求的。
  再推一步,人与人之间,也应该和睦相处,因为人越是体察天道,就越是能够理解“合”是自然的,是美好的,也是必须的。
  再往下推出的概念,可以说都是手段,是使社会符合天道,和睦相处的手段,它们分别使“德、仁、义、礼、智、信”悲观的道家认为,正是因为失去了正道,不再和谐,人们才开始运用这些手段。“道、德、仁、义、礼、智、信”的先后次序,也非常重要,我们可以看到,作为西方法制思想基础的契约所最需要的“信用”,在中国,却是最后才要用到的手段之一。
  再推演下去,才出现了法律,但是这可以说是最糟糕的手段,因为前面的那些手段,还都是建立在人性向善的基础上的。而法律,则是对人性的不在信任的产物。中国古代对于人性的看法,以“性本善”为主流,而西方则几乎一致的认为“人性本恶”。这之间的决然不同,也是中西方法制思想差异的主因之一。
  也许有人会问,中国人难道就没有公平的概念吗?有,但是有区别。中国人的公平观念要看情况而定,远近亲疏,在公平的精度要求上,各有不同。越是不相干的人,越要跟他算清楚。越是亲近的人,就越不妨胡涂一些,不必太过分明。这种现象,也得从农耕民族的特性找原因。作为农耕民族的中国人,安土重迁,大多世世代代生活在一个狭小的村庄范围内,村里的人,低头不见抬头见,事事处处计较,这个村子肯定鸡犬不宁。因此大家都礼让三分,守着和睦相处之道,但是如果外面来个什么人,也许这辈子就见这么一次,如果被他欺了、骗了,人都找不到,所以既要提防,又要在可能受损之后及时追讨。作为善良的庄户人家,“害人之心不可有,防人之心不可无”这就是讲求公平的办法。但是越是对亲近的人,越是不该有防备之心,否则就会显得不厚道,这也是一种很常见的看法。
  于是公平与和谐,就成为一对既矛盾又统一的观念,长久地影响着中国人地思想。
 b)法家的失败
  历史到了春秋战国,中国人的这套思想已经相当完整和成熟了,整个社会的宗法体系,已经建立,详细界定远近亲疏、君臣上下该如何相处的礼法,已经繁杂到有专门的学问,而且需要刻苦的学习了。但是有一个现象却非常奇怪,守着旧礼法不变的国家,就会落后挨打,而积极彻底变法的国家,却发达强盛。过去的那一套难道错了吗?祖宗的东西已经不管用了?
  接下来的事实证明,法家是对的。最遵循法家思想的秦国统一了六国,彻底的变法早就了秦国的强大。但是再接下来的事实又证明,法家是错的。一个如此强大的秦国,竟然在短短几十年的时间里,土崩瓦解。这样的历史巨变,带来了太多的疑问。
  法家为什么能使秦国如此强大?
  法家为什么又使秦国迅速灭亡?
  和谐与发展能不能共存?
  秦国的历史如何才能不再重演?
  立国之本,究竟应该以何为基础?
  对于这些问题的回答,奠定了之后中国二千多年的法制思想基础。我们今天再来看这个问题,需要从两个方面入手:一个是当时的人们如何思考这些问题?另一个就是我们现在应该给出的自己的答案是什么?
  我们现在当然已经知道,后来是儒家思想成为了中国思想的主流,儒家的法制思想统治了中国两千多年,但是在讨论儒家对法家的反思之前,有一段插曲也非常重要,我们不得不提出来讨论,关于儒家的话题,在下一节再专门讨论。
  儒家并不是在秦朝一灭亡,或者汉朝一建立就确立了主导地位的。当时的主流思想是讲求无为而治的道家。所谓“无为而治”不是我们现在想象的废除恶法,还民自由。而是真的什么都不做,“一依秦旧”,同样的法律,同样的制度还在那里,并未废除,只是从皇帝到宰相,到下面大大小小的官吏,都有法不依,有事不管,得过且过,与民休息,自己也休息。这样当然会带来问题,否则后来道家也不会被儒家替代。但是更糟糕的是,这段历史,从来没有被真正否定过,甚至还成为每个朝代的榜样,与民休息。这样带来的坏处是什么呢?法律不再有尊严,同样的法律,在不同的人手里,会有不同的解释,同样的条规,在不同的“大方向”下,会有不同的解释。这就使得法律成了面团,任何力量,都可以把他捏成想要的形状。
 c)儒家的反思
  法家的思想可以分为三个部分,鼓励农战,加强法制,御下之术。与法制思想有关的,在古代看来,只有加强法制一方面,而现在我们看来,鼓励农战与御下之术,也是要靠法制来保证的。我们现在分析儒家对法家的反思,也就先不考虑另外两个方面了。
  1.法后王与法先王
  法家思想中,最重要的是“法后王”与“以吏为师”。这两点,在汉朝以后,一变而为“法先王”与“以儒为师”。这对中国思想史、以及法制史的影响至关重要,需要好好分析。
  “以谁为师,以谁为法”有何重要?这代表着一个社会的权威体系。当我们需要“断是非、明曲直”的时候,以谁为权威,当权威有多个时,谁大谁小,最终由谁决定?在这个权威体系中,帝王、贵族、官吏、学者、法律、道德等等,各应有何地位。这决定一个国家的基本结构与可能的发展方向。
  在各国变法之前,自然是法先王,关于先王究竟是怎么样,这门学问,掌握在贵族的手中,称为“王官学”。首先流入民间的学问,是由“王官学”而来,但是进一步发展与平民化的“儒家”。“儒家”又与后来发展出来的“诸子百家”合称“百家言”,与“王官学”相对。
  法家要想推动变法,却遇到了极大的阻力,他们就是各国的贵族,而这些贵族念念不忘的,就是“先王之法,祖宗之制”。要打破这些阻力,法家就花大力气来鼓动活着的大王:“你才是最伟大的,你才是最强的,谁都应该听你的,那些打着先王旗号的家伙,个个都有私心,借口死人来阻止活人。真正能帮你的,不是贵族,而是官吏。”随后建立起来的金字塔形的官吏体系,层层对上服从,以法律为联系,站在最高点的,就是活着的大王。这样的权力集中,权威集中,自然能够有力地推动变法。
  到了秦国统一六国之后,情况渐渐发生了变化,一方面,人们反对的不再是变法,而是当前法律中的恶法,另一方,反对的人也不再是单纯的贵族,而是各种对于现行法制的批评者。这时,原有的权威体系就顺着自身的逻辑,从进步滑向了反动,从变革滑向了保守,最终演变成了秦朝的种种暴政。
  汉朝对于秦朝的反思,就是意识到了作为民间批评力量的重要性,这是一个王朝健康发展的保障。我们一直认为“法先王”是保守的代名词,“以儒为师”则是思想僵化的表现,而实际上在西汉,事情正好相反,“儒家”作为当时最为活跃与成熟的思想流派,恰恰是进步与开放的代表,“以儒为师”的实质是在官僚体系之外,另立一套权威体系以作抗衡,以圣人、素王(孔子)、先王作为最高的权威,在此基础上的“法先王”,往往也不是真正存在的那个先王,而是思想理论与想象中的先王。借古讽今,也只是借,而不是拘泥。《春秋决狱》就是这一思想在法制领域的体现。
  由于两个方面的原因,情况又进一步起了变化。一方面,王莽新政的失败,使得儒家不再敢于探寻天命,忠君爱国,成为儒家思想当然的组成部分。而另一方面,考试、选拔制度的逐渐完善,使得儒家最终丧失了民间立场,而与“官吏”划上等号。于是社会的权威体系,再次失去制衡,成为一套由古至今,从上至下,别无选择的封闭、保守的权威体系。一直要到两千年后,才能再次打破它。
  2.中庸之道
  儒家作为诸子百家中最为重要的一家,中庸思想一直是其极为主要的思想之一,在反思法家的问题上,自然而然就会用上中庸的思考方式。
  所谓中庸,可以说得很复杂,也可以解释得很简单,就是“过犹不及”,就是不偏不倚,不走极端。在中庸得立场看来,任何事情之所以会办糟,要么是做得不够,要么是做得太过。而儒家追求的,就是要恰到好处。
  从这个思想出发,来看待秦朝的成败,自然不会对法家彻底否定,但是却隐含着两个假设,首先,从中庸之道出发,其他的一切都是手段。儒家对于法制的看法,也就不可能超越对任何一种手段的看法,自然也不可能将法制摆到一个多么崇高的位置。其次,对于中庸的把握,要靠人,最中庸的,自然是圣人。这由人来把握的中庸原则,对于法制的手段性的运用,就是后来中国法制思想的基础。
  儒家的第一点认识是:法律不能作为唯一的手段来使用,而且从重要性来说,还应该在“仁义道德”之后。所谓“德主刑辅”就是这个含义。汉朝的贾谊写《过秦论》分析秦朝的失败原因,主要就说了两点:“废先王之道,燔百家之言,以愚黔首。”,“仁义不施,攻守之势异也。”前面一点我们已经讨论过了,而后面一点,则是对于“仁义”与“法律”相对重要性的反思。
  儒家的第二点认识是:法律的功效并不与轻重成正比。法家原来有一套“重刑主义”的理论,认为刑法能够防止犯罪,因为对于轻罪使用重刑,就可以使人不敢犯轻罪,更不要说重罪了,而如果刑法重到一定的程度,就能最终使人不敢犯任何罪行,达到天下太平的境界。但是“陈胜、吴广”的经验证明了儒家的格言“水可载舟,亦可覆舟”。法律的轻重,也要恰到好处。
  那么这个恰到好处的中庸,究竟应该如何追求呢?也就是说,如果我们暂且不论那种“运用之妙,存乎一心”的最高境界,在法制方面追求中庸,该有哪些原则呢?首先是网开一面,不可赶尽杀绝。所以中国法制史上,会有“八议”的传统。其次是以合为贵,一方面遇事以化解为主,大事化小,小事化了。另一方面是做足预防功夫,尽可能阻止矛盾的发生。最后就是根据社会的情况决定对策,在“起事”前后,一般应该广施仁义,赢得民心,在“大事已定”之后,要逐渐加强法制,以正纲常。在渐渐衰落之后,要开始“乱世用重典”,最后“垂死挣扎”自然演变为暴政。当然,事情发展到了后面两个阶段,一般也已经不能称之为中庸之道了。
  关于儒家的反思,就先讨论到这里,接下来我将从现代的眼光,来分析近代中国的衰落与法制的关系。
 d)从差别到差距
  法制思想的差别与社会发展的差距之间有何关联呢?我们需要进行三个方面的讨论。
  1.社会目标与法制目标
  中西方的法制目标前文已经分析过,分别是“正义”与“公平”。那么社会目标呢?中国历代的社会目标都很清楚,是“和谐”。而在西方,却在中世纪结束之后,才逐渐清晰起来,称之为“发展”。在中国,法制的目标向来服从于社会的目标,这首先是由于法制向来是作为实现社会目标的手段而存在的,其次是由于体制上的精心设计,执政者与执法者向来合而为一,并无分别。但是在西方,法制的目标根深蒂固,而社会的目标反倒出于弱势,这使得法制拥有格外崇高的地位,并最终有可能独立于行政之外。因此,在中国历史上,极少出现法制与行政的冲突,而在西方,却存在着执法与执政之间的张力。这样的张力,在中国历史上却是另一种表现,当和谐与正义之间出现冲突时,在王朝、政府的内部,社会目标一定会消解掉法制的目标,对于正义的追求,无法在法制内实现,最终激起民变,起义军打出的旗号,往往就是“替天行道”,也就是通过暴力,推翻这个朝代,来寻求真正的正义。这样一次又一次的朝代交替,也是和谐与正义的交互作用的表现。
  2.中国的社会目标与法制实践
  在中国,在和谐这个大目标下所进行的法制实践,我们可以从正反两个方面来看,从好的方面来看,中国的法制实践作为众多手段之一,并不被孤立的看待与使用,而是与教育、礼俗、社会舆论等手段共同发挥作用,付出较少的社会管理成本,达到了较高的社会管理效果。其次,中国社会在很长的历史时期都呈现为大大小小的家族结构,这是决定社会是否稳定、和谐的基础单元,中国法制在调整近亲属关系方面向来着力最多,当然也确实收到了很好的效果。再者,历来的执法者在执法过程中,往往比较注重当地的社情、民意,考虑执法的社会效益,因此往往有利于社会的安定团结。而从坏的方面来看,维护稳定和谐,往往会成为网开一面、徇私枉法的借口,其次,阻碍社会交流,限制发展,往往成为避免矛盾、减少冲突的手段之一,再者,维护和谐的背后,存在“法不责众”的逻辑,因此,当王朝逐渐腐化时,一方面法制会越来越“重”,试图杀鸡儆猴,另一方面法制的底线、甚至社会道德的底线又会越来越低,这两方面都会最终导致王朝的覆灭。
  3.西方的社会目标与法制实践
  在西方,近代国家产生之前,我们往往很难说西方社会有什么的明确的目标,但是在文艺复兴、罗马法复兴与近代国家观念逐步确立之后,社会的目标就变得异常清晰,就是发展,甚至简单的说,就是社会财富的不断增长,为了这个目标,国家应该做它所能做的一切,包括对他国开战。法制只是对内的,文明、礼仪也只是对内的。法制实践的首要目的,当然是财富的公平分配,以及对财产安全的保障,机会均等,人人平等,每个人都有权力、也有机会发财。发展是第一位的,为了保证发展的顺利,法制实践通过对公平的追求,来尽可能地减少社会内部的摩擦,西方社会突飞猛进的发展,也的确达到了它的目的。当然,由于在西方,法制的目标比较独立,因此对于“社会无耻发展的追求”尚有一定的制约力量,但是随着与上帝契约的失灵,人与人之间,就可能“扯下温情脉脉的面纱”,只剩下“商人的道德”了。
  通过以上的对比和分析,我们可以发现,中西方社会差距的主要原因,是社会目标存在差别,次要原因则是各自的法制实践,使得中西方的社会差距,越拉越大。
 e)走出长夜
  在电视剧《走向共和》的片尾曲中,有这样两句“走出长夜,走近曙色”。这走出长夜,真是中国近代史的极贴切的写照。大家一般会认为这长夜的比喻,不过是指社会的黑暗、人民的苦难,而在我看来,长夜还意味着方向的迷茫与道路的曲折。等天蒙蒙亮的时候,我们才能稍微看出一点自己走过的路,打算一下接下来的方向,但是天并不是一下子就亮起来的,当我们在天色再亮一点的时候回头张望,才会发现自己还是走了不少弯路。不断的走弯路,又不断的修正,才是我们走出长夜的真实历程。在这样曲折的历程中,我们遗憾的发现,中国的法制进程,一次又一次被打断,一次又一次被否定,直到现在,也不能算完全走上正轨。
  从清末到现在,可以分为三个大的历史阶段,我们将从法制进程的角度,分析这三个阶段。
  1.从“中兴”到“覆灭”——革新与革命之争
  同治“中兴”时,大多数满洲贵族都感觉松了一口气,这个大清看来是不会亡在自己手里了,虽然内忧外患都没有彻底解决的前景,但是毕竟迫在眉睫的危机解除了,接下来的时间里,大清也气象日新,变革颇多。但是在社会上,总是有人会觉得这样变得太快,也有人会觉得这样变得太慢。顽固的保守派、改良派,还有一小撮与政府誓不两立的革命党。革新,看来是最可行的道路,但是这条路却越走越窄,就像一只压力锅,水要烧到100℃才能烧开,而这只腐朽的锅,70℃就会爆炸。到最后,六君子身首异处,证明了满清已不可救药,革新已不再可能。
  从社会、历史的角度,我们可以说这一切不可避免,但是法制进程却只能中断了。沈家本、伍廷芳的立法成果,在社会动乱的现实中,往往只能是徒具空文,而且从辛亥革命到民国建立像样的法律体系之前的长时期军阀割据与混战,整个中国完全处于法制的空白状态。
  2.从民国到新中国——上层与下层之争
  黄仁宇先生在《中国大历史》中分析,认为国民党和蒋介石制造了一个新的高层机构,中共与毛泽东创造了一个新的低层机构,这个论断还需再加说明,否则无法解释为什么最后是共产党取得了胜利。
  首先,国民党是继承性的,而共产党是全新的。国民党从满清王朝继承了很多东西,其中的不少方面,其实根本要不得,比如说军阀的部队、外交的条约、濒临破产的财政,而共产党却是白手起家,从头做起,看起来万般辛苦,却也少了很多历史的包袱。
  其次,国民党试图法制,而共产党主要是靠道德取胜。为什么说“试图”呢?因为在那个混乱的年代,法律条文可以颁布,法律体系可以完整建立,但是真正在法制实践背后起作用的,还是中国传统的法制思想,乱世用重典与法不责众,成为两个必然而又相互矛盾的选择。在中国,得民心者得天下,在那个年代,能够赢得民心的,不是什么法制体系,而是高尚的道德和严明的纪律。
  最后是国民党的上层基础的数量,远远少于共产党的工农联盟的数量。共产党发动了国民党不可能发动的土改,赢得了广大农民的绝对支持,数量上的优势,也许是共产党胜利的决定因素。
  3.从解放到改革开放——理想与欲望之争
  面对这一段历史,我们得先扯远一点,因为马克思主义是从西方传过来的,我们有必要简要地分析一下马克思主义在西方产生的根源。
  尼采之后,越来越多的人知道上帝已经死了,人与上帝的契约,原本是西方道德的基础,天国既然不再真实,人要再讲道德,也就毫无意义了。在众多后起的理论中,马克思的观点独树一帜,他通过历史唯物主义的理论证明,地上的天国是可能的,但是这样的可能性不能坐等,而必须依靠每一个信仰共产主义的人的努力与奉献,追求这样的理想,并最终实现这样的理想,成为新的道德的基础。有人曾经论证过马克思主义与基督教的相似之处,就在于他重新给了人们到达天国的希望。
  社会发展的动力究竟是什么?单靠理想与奉献能不能“超英赶美”?事实证明,不可能!社会发展的主要动力,是人的欲望,而不是高尚的理想。改革开放的过程,也就是不断深入认识社会发展动力的过程。但是仅仅解放人们的欲望是不够的,甚至是危险的。人类无限膨胀的欲望必须受到控制。当今的左派,往往只看到欲望的危害,极力想要回到“有理想、有道德”的年代去,而当今的自由主义者,又往往只看到欲望的威力,闭口不谈,甚至否定道德的价值。至于法制的意义与重要性,还远远没有得到应有的认识,国家的法制建设,也就更显得“步履维艰”了。
 f)寻找执法者
  文章写到了最后,我想试着谈一谈自己思考的结论,也就是回答“中国法制建设的关键何在”这样一个问题。我的回答是:“关键在于寻找执法者。”为什么这么说呢?
  我们知道正义是道德的一部分,而法律是依照正义的原则制定的,最终执行法律的,就是执法者。社会的法制要能进步,执法者是否能真正依法是问题的关键,如果执法者尚且不具备法制精神,整个社会法制意识的提高就是一句空话。另外,“寻找执法者”的另一层意思是,他不是执政者而只是纯粹的执法者,这一点我们下面还会展开讨论。
  什么样的人才是我理想中的执法者呢?我们还得先从道德说起,因为这是法制的基础。
  1.道德的基础
  有三种道德,以契约为基础的道德,以人性为基础的道德以及以理想为基础的道德。西方传统道德以契约为基础,以上帝为立约者,因为他们相信人性罪恶,不立下契约,一定会堕落。但是这样地理论基础在西方都已经开始动摇,当然更加不可能凭空移植到全无上帝信仰、也不相信人性本恶的中国来,这也就是为什么从西方移植过来的法律体系的效果就像是断了腿之后装上的假肢一样不适应的原因。
  以理想为基础的道德,的确是一种道德,但是这种道德只应该用以自律与自我激励,而不应该用来要求与约束他人,因为高尚的道德并不一定源于同样的理想,选择不同的理想,既是很自由,也是法律不应该干涉的领域。
  以人性为基础的道德,在中国有着深厚的历史基础与文化积淀,因为我们大多数都相信人之初、性本善,这并不是天真地认为所有的人都善良,而是从根本上相信,人能够依靠自身的努力得到人格的完整与道德的完善,人人都能做圣人,自然也就不需要上帝来费心。这样的逻辑,自给自足,相比西方的契约道德,却更为稳固。
  人性本善,但是这并非道德,将人性中的善发扬光大才是道德,圣人的伟大就在于他能够内省人性,外合天道,从心所欲而不逾矩。儒者的目标就是成为圣人,他们需要格物、致知、诚意、正心、修身,然后才能齐家治国平天下。在这不断提高的过程中除了理论的指导,还有就是依照圣人制定的“礼”而行事,知行合一,成圣才有望。而对于一般没有什么追求的老百姓来说,只要遵守礼仪,这个社会也能稳定和谐。
  2.什么是正义
  道德是人的思想与行为的规范,而正义则只是关于针对他人的行为的规范,我们有时候也说,某种想法不正义,那也是因为这个想法是试图进行某种行为,而对于纯粹的想法,我们会基于道德标准判定其是善还是恶。当然,有时候我们也会判断某种行为的善恶,这其实是大概念对小概念的涵盖,正义与道德,在这个时候,可以互换。
  当我们的道德以人性为基础时,所谓正义,就是符合人的本性的善的行为,恻隐之心、羞恶之心、辞让之心是人的本性,依这样的本性而行事,就是正义。否则就是不正义。依照正义的原则,我们就知道自己该做什么,不该做什么。
  该做的事很多,以孝弟为首,推而广之,则仁义礼智信,都应该身体力行。不该做的事也很多,但是有一个总的原则,就是“己所不欲,勿施于人”中国传统的法律,大多由这个原则推出。
  3.立法的精神
  这个原则本身没有问题,但是在古代中国的人治传统之下,“己所不欲”中的己,就成了各个判案者的“自己”,好的情况下他们能“将心比心”,糟糕的情况下,他们可能“以己度人”,这样的结果,就成了“公说公有理,婆说婆有理”,谁的官大,谁说了算。成文的律条,也就成了空文。依法治国,也就无从谈起。
  我们现在再来看“己所不欲,勿施于人”这句话,它本身是一条只对自己适用的规则,我不愿意遭受的行为,我也不能施加于他人。当这条规则上升到社会的行为规范时,这里的“己”也应该变成复数,“我们不原遭受的行为,不该施加于他人”,或者更加明确的说成:“大多数人不愿遭受的行为,应该立法禁止”。
  这应该成为我们现代中国的立法的总的精神。
  首先,“大多数人”有两个方面的意义,一是意味着立法需要客观的调查,而是立法需要经过民主的程序,主观臆断制订的法,不经民主程序制订的法,很有可能违背正义的精神。
  其次,不愿遭受的行为,并非一成不变,一个国家的法制,也该不断的改变(不一定是改进),只要大多数人认为某种行为无可忍受,就应该立法禁止,而另一些针对已经无人在意的行为的立法,就应该及时废除。比如说过去的人不在意肖像的权利,而现在开始重视,就应该立法禁止对肖像权的侵犯;而现在大多数人也不再害怕邻居床底下写着自己名字的扎针的小人,因此巫术害人的罪名自然也该取消。当然,这也意味着,任何超前或滞后的法律,皆不可取。
  最后,要清楚地认识到,“法律只应该禁止行为,而不应该禁止思想” 。这一点不用多谈。
  根据这一原则,我们可以界定罪与非罪,而西方的立法精神则以人的权利与义务为基础,这两者之间如何“换算”呢?我的理解是:“按照中国的传统思想,所谓人的权利,也就是人有权不遭受到大多数人都不愿意遭受的行为”,根本就不存在什么永恒不变的天赋人权,人的权利是不断变化的,权利的不变与一致,只是因为人的欲望的不变与一致,比如说生存权,并非上帝赋予我的生存的权利,而是因为世界上大多数人都不愿意被人剥夺生命。而对于病入膏肓的人来说,如果大多数人都不愿意继续被治疗,那么他们自然就有了安乐死的权利。
  西方的法制自然也有可取之处,因为我们按照前面的原则,可以区分罪与非罪,罪行的轻重,却很难界定:直接与间接,主要与次要,附加与连带之类的责任,而若从权利义务的角度来作精确的判断,则西方法制实践的丰富经验与理论超过,大可拿来参考。
  4.执法与执政
  执法与执政的区别,还是由前文讨论的法制目标与社会目标区别而来的,执法是为了追求正义,执政是为了追求和谐,在中国,一直以来执政者就是执法者,因此和谐的目标往往干扰甚至阻碍了正义的实现,最终导致民众起而依靠自身的力量来追求正义。因此,要想实现国家的长治久安,自然的推论就是国家一定要有能力充分满足民众对正义的需要,这种需要能在体制内被尽可能的消化,则社会稳定的可能性也就越大,而要保证正义始终能在体制内消化,则执法与执政就必须相互独立、互不统属并且权能相若,否则就无法保证正义的实现。纯粹的、不受执政目标所干扰的执法者,就是推进法制真正进步的关键。
  我们还需要区分法律与规则,法律的制订是依照正义的原则,因此实质上是先有正义,后有法律,某种行为即使尚未被法律定义为有罪,也是非正义的。(这并不意味着在没有法律的情况下,人们可以自行实施“正义”的行为。)而规则却不是这样,它并不是用来区分是否正义的标准,制订规则的主体是执政者,目的也是为了社会的和谐、发展,与正义无关。只有合理与不合理的区别。一个人犯法就是不正义的,而违反规则却与正义无关,甚至可能是正义的。因此,在我看来,一个具有法律意识的公民,他可以针对某项不合理的政府规定予以抵抗或不合作,但是却不会为了这样的行为而去触犯法律,这就是“公民不合作”的理论依据。
  但是在现实生活中,有很多执政者,都号称自己制定的规则是法律,将行政管理行为称之为执法行为,似乎这样就具有了正义性,其实质却很有可能只是部门利益最大化的需要,是极为霸道的非正义行为,这也就是为什么我们现在更应该多多提倡“公民不服从”的原因。

五、结束语
  太长的文章需要简短的结束语,因此这里只多说三句话:
  1、中国的法制思想,应该当成活着的体系去研究、思考,而不是作“考古式”的研究。
  2、西方的法制思想只有更好地去理解、消化,才能对中国有益,否则就可能会带来问题。
  3、建立一支合格的、纯粹的执法者的队伍,是推进中国法制进步的关键。

试译:开源项目成功的十条准则

Ten Rules for Open Source Success

《开源项目成功的十条准则》

Everyone wants it, lots of people try it, yet doing it is mostly painful and irritating. I’m speaking about free software aka open source. Today I’m going to summarize 30 years of coding experience in ten management-proof bullet points.

每个人都想去做,也有很多人跃跃欲试,但是真做起来却常常会令人痛苦和愤怒——我说的是自由软件,或者更宽泛一些的开源软件。今天我要将自己30年来的开发经验,总结为开源软件的十条成功法则。

庄表伟:每个人都需要它,很多人跃跃欲试,但是干起来却往往会令人痛苦或者愤怒。我在谈论的是自由软件(开源软件)。今天,以我30年来的开发经验,我想要总结以下10条经营要点:

余晟:
每个人都想去做开源,也有很多人尝试了,但是真正去做却常常收获痛苦和恼怒。我所说的这回事是自由软件,或者叫开源软件。今天我要总结自己30年来的开发经验,归纳为十条经得起实践检验的准则。

魏永明:
所有人需要它,很多人尝试它,但做起来却常常是痛苦的甚至会令人不快——我说的是自由软件,或者更宽泛一些的开源软件。今天,我将把本人三十年的编码经验总结为开源软件的十条成功法则。

八刀:今天我将把我三十年的开发经验囊括在以下十点。

1、People Before Code
1、人比代码重要

This is the Golden Rule, taught to me by Isabel Drost-Fromm. Build community, not software. Without community your code will solve the wrong problems. It will be abandoned, ignored, and will die. Collect people and give them space to work together. Give them good challenges. Stop writing code yourself.
这是一条黄金法则,是Isabel Drost-Fromm【注1】教给我的。我们要建立的是社区而不是软件。没有社区,你的代码就会用来解决错误的问题。然后这些代码会被抛弃、忽略,最后死去。正确的做法是把人集结起来,给他们协同工作的空间,给他们充分的挑战。切记不要亲手来写代码!

注1:Isabel Drost-Fromm是Apache软件基金会的成员,Apache Mahout的创立者之一。

庄表伟:这是一条黄金法则,是Isabel Drost-Fromm教给我的。建立社区而非软件,没有社区,你的代码将会去解决错误的问题。然后它将会被抛弃、忽略,最后死去。将人汇集起来,给他协同工作的空间,给他们足够好的挑战,停止自己写代码!

余晟:这是金科玉律,是Isabel Drost-Fromm教给我。我们要建立的是社区而不是软件。没有社区,你的代码就会用来解决错误的问题。然后这些代码会被抛弃、忽略,最后死去。正确的做法是把人集结起来,给他们协同工作的空间,给他们充分的挑战。切记不要亲手来写代码!

Holm:..他们足够好的挑战,停止自己写代码!断句有问题,读起来想“让他们停写”

2、Use a Share-Alike License
2、使用“以相同方式共享”的许可证

庄表伟:2、使用‘以相同方式共享’型许可证

余晟:2、使用‘以相同方式共享’的许可证

Share-alike is the seat belt of open source. You can boast about how you don’t need it, until you have a bad accident. Then you will either find your face smeared on the wall, or have light bruising. Don’t become a smear. Use share-alike. If GPL/LGPL is too political for you, use MPLv2.
“以相同方式共享”是开源的安全带。在遇到严重的事故之前,你大可吹嘘自己完全不需要它。一旦出现事故,你就会发现自己满脸污垢,或者‘轻微擦伤’,不要成为一个“伤员”。使用“以相同方式共享”的许可证吧,如果你觉得GPL/LGPL太过于政治化,那就用MPLv2。

庄表伟:‘以相同方式共享’是开源的安全带,你可以吹嘘自己是如何的不需要它,直到你碰到糟糕的‘意外’。然后你会发现自己头撞南墙,或者‘轻微擦伤’,不要成为一个‘伤员’。用‘以相同方式共享’型许可证吧,如果你觉得GPL/LGPL太过于政治化,那就用MPLv2。

余晟:‘以相同方式共享’是开源的安全带。在遇到严重的事故之前,你大可吹嘘自己完全不需要它。一旦出现事故,你就会发现自己满脸污垢,或者还有轻微擦伤。你应当避免把自己搞砸,你应该使用‘以相同方式共享’的许可证吧。如果觉得GPL/LGPL太过于政治化,那就用MPLv2。

3、Use an Zero-Consensus Process
3、使用一个无需达成共识的协作流程

八刀:零共识

Seeking upfront consensus is like waiting for the ideal life partner. It is kind of crazy. Github killed upfront consensus with their fork/pull-request flow, so you’ve no excuse in 2015. Accept patches like Wikipedia accepts edits. Merge first, fix later, and discuss out of band. Do all work on master. Don’t make people wait. You’ll get consensus, after the fact.
寻求事前的共识就像是在等待理想的人生伴侣,这简直就是疯狂。借助fork/pull-request这种模式,Github已经干掉了事前共识,所以在2015年的今天你没有任何借口坚持事前共识。你应当像维基百科那样接受修改。先合并,再修复,同时单独讨论。所有工作应当在master分支上进行,不应当让大家等待。有了既成事实,共识会随之而来。

庄表伟:寻求前期的共识就像是在等待理想的人生伴侣,这简直就是疯狂。借助fork/pull-request这种模式,Github已经干掉了前期共识,所以在2015年的今天,你没有任何借口。例如像维基百科那样接受修改。先合并,再修复,然后附带进行讨论。在master分支上做所有的工作,不要让人等待。事实上,你会逐渐得到共识的。

八刀:这听起来有点疯狂

余晟:寻求事前共识就像是在等待理想的人生伴侣,这很疯狂。借助fork/pull-request这种模式,Github已经干掉了事前共识,所以在2015年的今天你没有任何借口坚持事前共识。你应当像维基百科那样接受修改。先合并,再修复,同时单独讨论。所有工作应当在master分支上进行,不应当让大家等待。有了既成事实,共识会随之而来。

刘天栋:然后扩大进行体制外讨论。先上车,后补票,你会逐渐得到共识的。

Holm:寻求前期的共识:预先达成的共识;事实上,你会逐渐得到共识的:最终,你能获得事实的共识。

4、Problem, then Solution
4、首先是问题,然后才是解决方案

庄表伟:4、首先是问题,然后才是解决方案

余晟:4、问题优先,然后才是解决方案

Educate yourself and others to focus on problems not features. Every patch must be a minimal solution to a solid problem. Embrace experiments and wild ideas. Help people to not blow up the lab. Collect good solutions and throw away the bad ones. Embrace failure, at all levels. It is a necessary part of the learning process.
教育自己和其他人,聚焦于问题而非功能特性。每一个补丁都必须是解决某个实际问题的最小化的解决方案。勇于尝试,勇于接受疯狂的想法。你还需要帮助他人,确保他们干的事情不会导致实验室的爆炸。收集好的解决方案,抛弃那些糟糕的方案。在各个层面上都应当宽容失败。这是学习过程中不可缺少的一部分。

庄表伟:教育自己和其他人,聚焦于问题而非功能特性。每一个补丁都必须是解决某个实际问题的最小化的解决方案。勇于尝试,勇于接受疯狂的想法,确保实验室不会被炸掉。收集好的解决方案,抛弃那些坏的。在所有的层面上,拥抱失败。这是学习过程中不可缺少的一部分。

余晟:你必须教育自己和他人,集中关注问题,而不是功能特性。所有补丁都应当是解决某个实际问题的最小化解决方案。你应当勇于尝试,勇于接受疯狂的想法。你还需要帮助他人,确保他们干的事情不会导致实验室的爆炸。请收集好的解决方案,抛弃那些糟糕的方案。在各个层面上都应当宽容失败。这是学习过程中不可缺少的一部分。

Holm:…疯狂的想法,确保实验室不会被炸掉…:断句有问题。

5、Contracts Before Internals
5、首先约定,然后再完成内部实现

庄表伟:5、首先约定,然后再完成内部实现

余晟:5、约定优先,然后完成内部实现

Be aggressive about documenting contracts (APIs and protocols) and testing them. Use CI testing on all public contracts. Code coverage is irrelevant. Code documentation is irrelevant. All that matters is what contracts the code implements, and how well it does that.
要积极地记录约定(API与协议)并加以测试。要使用持续集成工具测试所有的公开约定。代码覆盖率是无关紧要的,代码文档也是无关紧要的。真正重要的是代码实现了哪些约定,以及它们是如何实现的。

庄表伟:要积极的记录约定(API与协议)并测试它们。使用CI工具测试所有的公开约定。代码覆盖率是无关紧要的,代码文档是无关紧要的。一切的关键都在与约定的代码实现,以及他们是如何实现的。

刘天栋:…一切的关键都在于代码如何实现约定,以及他们是如何良好地实现的。

余晟:要积极地记录约定(API与协议)并加以测试。要使用持续集成工具测试所有的公开约定。代码覆盖率是无关紧要的,代码文档也是无关紧要的。真正重要的是代码实现了哪些约定,以及它们是如何实现的。

6、Promote From Within
6、从内部提拔

Promote contributors to maintainers, and maintainers to owners. Do this smoothly, easily, and without fear. Keep final authority to ban bad actors. Encourage people to start their own projects, especially to build on, or compete, with existing projects. Remove power from people who are not earning it on a daily basis.
将贡献者提拔为维护者,将维护者提拔为负责人。以流畅、轻松且无畏地方式来做。保留干掉‘害群之马’的最终权力。鼓励大家开始自己的项目,尤其是基于已有项目,或者与已有项目竞争的项目。每天持之以恒地检视并剥夺那些不再贡献者的权力。

庄表伟:将贡献者提拔为维护者,将维护者提拔为负责人。这样做起来,将会顺利、轻松并且免于恐惧。保留干掉‘老鼠屎’的最终权力。鼓励人们开始自己的项目,尤其是基于已有项目,或者与之竞争的项目。剥夺那些不再每日贡献者的权力。

刘天栋:…以流畅、轻松而无畏地方式来做。…每天持之以恒地检视并剥夺那些不再贡献者的权力。

余晟:维护者应当从贡献者中提拔出来,负责人应当从维护者中提拔出来。整个过程应当会平稳、轻松,而不应当有任何担忧。你需要保留干掉‘害群之马’的最终权威。还需要鼓励大家开始自己的项目,尤其是基于已有项目的项目,或者与已有项目竞争的项目。对于那些不能每日做出贡献的人,应当剥夺他们的权力。

7、Write Down the Rules
7、将规则写下来

余晟:7、明文记录规则

As you develop your rules, write them down so people can learn them. Actually, don’t even bother. Just use the C4.1 rules we already designed for ZeroMQ, and simplify them if you want to.
当你制定规则时,请将他们写下来,以便人们可以了解他们。事实上,你甚至都不需要亲自动手——如果你愿意,可以直接套用我们为ZeroMQ制定的规则C4.1,再按需简化。

庄表伟:当你制定规则时,将他们写下来,以便人们可以了解他们。这样一点都不麻烦。如果你愿意的话,可以直接使用我们为ZeroMQ制定的规则,再加以简化。

刘天栋:更简单的办法是,如果你愿意的话,可以直接使用我们为ZeroMQ制定的规则C4.1…

余晟:当你制定规则时,请将它们写下来,以便人们可以了解他们。事实上,你甚至都不需要亲自动手——如果你愿意,可以直接套用我们为ZeroMQ制定的规则C4.1,再按需简化。

8、Enforce the Rules Fairly
8、公平地执行规则

Use your power to enforce rules, not bully others into your “vision” of the project’s direction. Above all, obey the rules yourself. Nothing is worse than a clique of maintainers who act special while blocking patches because “they don’t like them.” OK, that’s exaggeration. Many things are much worse. Still, the clique thing will harm a project.
用你的权力去执行规则,但不要强迫别人认同你对于项目发展方向的“愿景”。最要紧的是,你自己必须遵守规则。最糟糕的事情莫过于维护者自己形成了小圈子,仅仅因为“不喜欢”就拒绝其他人的补丁。好吧,这样说有点夸张了。不过,很多情况其实更加糟糕。还是那句话,小圈子对项目是有害的。

庄表伟:用你的权力去执行规则,但不要强迫别人遵循你对于项目发展方向的“愿景”。首先,自己就要遵守规则。没有什么比一个维护者的小圈子,仅仅因为“他们不喜欢”就拒绝补丁,更加糟糕的事情了。好吧,这样有些夸张了。不过,有些事情会更糟糕。总之,小圈子会伤害一个项目。

余晟:用你的权力去执行规则,而不要强迫别人认同你对于项目发展方向的“愿景”。最要紧的是,你自己必须遵守规则。最糟糕的事情莫过于维护者自己形成了小圈子,仅仅因为“不喜欢”就拒绝其他人的补丁。好吧,这样说有点夸张了。不过,很多情况其实更加糟糕。还是那句话,小圈子对项目是有害的。

9、Aim For the Cloud
9、以“云”为目标

庄表伟:以云为目标

刘天栋:以集思广益为目标

Aim for a cloud of small, independent, self-organizing, competing projects. Be intolerant of large projects. By “large” I mean a project that has more than 2-3 core minds working on it. Don’t use fancy dependencies like submodules. Let people pick and choose the projects they want to put together. It’s economics 101.
以小型的、独立的、自组织的、竞争性的(一群可以自由协作的)项目为目标,(市场)不能容忍大项目。所谓“大”,我的意思是一个项目包含了2~3个核心想法。要拒绝子模组那样花哨的依赖关系。让大家去挑选,并将他们选择的项目放到一起(工作)。这是经济学的常识。

庄表伟:以小型的、独立的、自组织的、竞争性的(可以在云中部署的)项目为目标,(市场)不能容忍大项目。所谓“大”,我的意思是一个项目包含了2~3个核心想法。不要用那些花哨的类似于子模组那样的依赖。让人们去挑选,并将他们选择的项目放到一起(工作)。这是经济学的基本常识。

刘天栋:以一群小型的、独立的、自组织的、竞争性的项目为目标,不要容忍大项目。所谓“大”,我的意思是一个项目包含了2~3个核心大拿,让人们自己去挑选并揉和他们选择的项目。

余晟:开源项目应当以小型的、独立的、自组织的、竞争性的(可以在云中部署的)项目为目标。对于大项目,应当坚决避免姑息。所谓“大”,我的意思是包含了2~3个核心想法的项目。要拒绝子模块那样花哨的依赖关系。让大家去挑选,去把自己选择的项目放到一起。这是经济学的常识。

10、Be Happy and Pleasant
10、开心愉快最重要

Maybe you noticed that “be innovative” isn’t anywhere on my list. It’s probably point 11 or 12. Anyhow, cultivate a positive and pleasant mood in your community. There are no stupid questions. There are no stupid people. There are a few bad actors, who mostly stay away when the rules are clear. And everyone else is valuable and welcome like a guest who has traveled far to see us.
也许你注意到了,“创新”并不在我的建议列表中。它很可能排在第11或12点。总之,你需要在你的社区里培养一种积极的、愉快的氛围。愚蠢的问题,愚蠢的人都应当被踢出去。就算有“老鼠屎”,也会在清楚的规范下自动消失。剩下的人是则有价值的,我们欢迎有朋自远方来。

庄表伟:也许你注意到了,“创新”并不在我的建议列表中。他很可能在第11或12点。总之,在你的社区里培养一种积极的、愉快的氛围,没有愚蠢的问题,也没有愚蠢的人。就算有‘老鼠屎’,也会在违反规则时被清理掉。其余的人是有价值的,我们欢迎他们像游客一样,远远的看着我们。

刘天栋:就算有“老鼠屎”,也会在清楚的规范下自动消失…我们欢迎有朋自远方来。

余晟:也许你注意到了,“创新”并不在我的建议列表中。它很可能排在第11或12点。总之,你需要在你的社区里培养一种积极的、愉快的氛围。愚蠢的问题,愚蠢的人都应当被踢出去。就算有‘捣蛋鬼’,也会在因为违规被清理掉。剩下的人是则有价值的,应当像对待远到的客人那样欢迎他们。

ps.  第一次试着翻译,求各位朋友帮忙指正,多谢了!

pps. 在诸多朋友的帮助下,再修订了一遍,有了不少自己的思考,仅仅是反映在了译文之中,没有一一说明,见谅。

ppps. 徐定翔给了我一个非常好的建议:“我通常是译完隔天不看英文读一遍译文。把不符合中文表达习惯的部分润色一下。” 谢谢!

大公司效率低最根本的原因是什么?

首先:小公司为什么会变大?
然后:在变大的过程中,发生了什么?
继续:为何大公司效率会低?
最后:为何大公司,快不起来了?

一、小公司为什么会变大?

当然,通常只有业务发展良好的公司,才会变大。所以,最直接的原因是:活干不完了,必须加人。

加了人之后,自然要派活。既然是派活,自然要有所分工。举个简单的例子:如果公司只有一个程序员,那自然所有的活都是他干。加了几个人后,自然可以分前端、后端、DBA、测试、运维…种种角色。

不同的工种,自然需要协作。开会、文档、上下级关系,自然也要逐步建立起来。这些,都可以认为是「合理的开销」。

二、在变大的过程中,发生了什么?

1. 辅助性部门开始出现:人多了以后,需要专职的HR;占地广了以后,需要专门的打扫、清洁人员;统一的后勤保障,也变成刚性需求;
2. 协调性部门开始出现:PMO这样的办公室,用于协调多个项目;会议越来越多,需要有专门的协调会议室的部门;多个部门之间的矛盾,需要有一个更高级的联席会议进行协调;做事要有规范,专门制定流程规范的部门开始出现;
3. 监察性部门开始出现:人越来越多,难免会混入坏人,所以要有「道德自律委员会」;事越来越多,难免会出纰漏,所以要有「质量保障委员会」;外部交易越来越多,难免会有风险,所以要有「合同风险审查委员会」;
4. 竞争性部门开始出现:在某种管理思路的影响下,开始设立多个目标类似的部门,以期通过内部竞争,促进效率提升;

这些部门,都没有必要吗?当然不是,老板又不是傻子!

三、为何大公司,效率会低?

首先我们需要理解,怎么算效率高?怎么算效率低?同样一件事情,如果很小,很简单,往往小公司会做得更快,甚至更好;而大公司,则会做得更慢,甚至更差。

但是,如果是一件极其复杂的事情,小公司可能根本无法完成,大公司再慢,至少他们能搞定。

所以,我们的问题应该转化为:「如果一件事情,原本可以又快又好的完成,为何大公司却有那么多浪费?」

根本原因在于:大公司的管理模式,不够柔性化,不具备「伸缩性」。打个计算机服务器的比方:「当访问量增长的时候,我们可以不断添加服务器。但是,当访问量下降的时候,大家都忘记把服务器再撤下来了。」

四、为何大公司,快不起来了?

1. 高大上意识,小事情往往也会大张旗鼓的去做。
2. 风险意识,没有人敢说:「某某流程,大多数时候并无必要」
3. 参与意识,这件事怎么能与我们部门无关呢?
4. 自保意识,只要严格遵守流程,这个事情就算搞砸了,责任也不会在我身上。

归根结底,是缺乏不断改进的意识(或者换言之,公司大到某种程度,就算是想改进的人,也会面对深深的无力感)。

28万个开源项目之番外篇

一、工具

1. 数据抓取

最初是打算使用openhub.net的Open API的,他们有不错的API,还在Github上放了一个开源项目。只可惜,他们的API,最多申请5个API Key,每个Key明天的访问请求数量,不能超过1000次。当时我还不知道,其实openhub的数据只有28万多,还以为满打满算,至少得60多天才能全部抓完,顿时心就凉了。

后来有朋友介绍了一个很棒的直接抓取HTML页面,然后做DOM分析的工具,名叫noodle

接下来,只要抓取: https://www.openhub.net/p?ref=homepage&q=&page={num}
就能够拿到所有项目的概要数据了。

当然,后续的331个项目的明细数据,还是得通过OpenHub的API来抓取。

2. 数据分析

完全是土法上马:sqlite3+numbers+csv+ruby,反正各种手法,什么称手用什么。

3. 数据展示

原本是打算在numbers里想想办法的,后来发现实在太弱。Excel也差不多,只能到网上搜索一些信息图制作的工具,后来找到了几个不错的在线工具,经过一番比较,最后决定用infogr.am来完成。的确非常不错。

二、释疑:项目大小与创建时间的关系

我与@云风 在微博上有一小段讨论,起因还是我之前的一些分析的观点:

  • 是否使用Github,越是新的项目越愿意用;越是大的项目越没法用。
  • 是否使用Github来管理项目的issue,越是新的项目越愿意用;越是大的项目越没法用。

这个结论,其实在用词上,是有些讲究的:按理说,新与老相对,小与大相对;愿意与不愿意相对,能用与没法用相对,我的两个结论,对仗都不公整。其实,确实故意为之。

于是,云风与我的对话如下:
云风:项目规模和项目历史本身有相关性吧。代码规模越大的项目历史很可能越久。
我:项目的规模,主要还是与项目本身的特性有关。原本就复杂的项目,才可能越长越大。原本就是小项目,也未必就会稳定的逐年增长。
云风:这只能说明小项目可以历史久,不能说明大项目可以历史短啊。很少有新项目一开始就很大啊。代码也是一行行写出来的啊。
我:那就是成长速度不同了。比如OpenStack,一开始就不小。
云风:一开始就不小只能说闭源开发过一段时间,或从别的地方搬迁过来的吧。你能想象不被版本管理工具管理的情况下,首次提交 10 万行以上的代码?看这个 link 提交日志写的 initial fork out of nova。

后来,我也没有再继续这个讨论,但是却一直在思考这个问题:「项目的大小,与项目的创建时间,究竟有大少相关性?」

后来,我将两个数据,做了一个分析:Log(第一次提交代码,至今的天数)/Log(代码行数),大概得到如下一个图:

经过强大的Excel的计算,两个数据的相关系数,大约是0.203的样子,也就是说:大致上有较弱的正相关。

三、开源

目前,我已经将这个分析的相关数据,放在Github上开源了。简单介绍一下:

data.sqlite3.zip 是28万基础数据
projects.sqlite3 是331个项目的详细数据
projects.csv 是我用来做数据分析的大表格

四、名单

331一个开源项目,名单如下:

Name Homepage
Metasploit Framework http://www.metasploit.com/framework/
NetBSD http://www.netbsd.org
GNU C Library http://www.gnu.org/software/libc/
cURL http://curl.haxx.se/
Python programming language https://www.python.org
Linux Kernel http://kernel.org/
GNU Emacs http://www.gnu.org/software/emacs
gnulib http://savannah.gnu.org/projects/gnulib/
GNU Core Utilities http://savannah.gnu.org/projects/coreutils/
GNU Compiler Collection http://gcc.gnu.org/
Wine http://www.winehq.org
Debian http://www.debian.org/
GNU Octave http://www.octave.org
Visualization Toolkit http://www.vtk.org
pf http://www.benzedrine.cx/pf.html
GDB http://www.gnu.org/software/gdb/
GNU binutils http://www.gnu.org/software/binutils/
GHC http://haskell.org/ghc/
Zope http://zope2.zope.org
FreeBSD https://github.com/trueos/trueos
Perl http://www.perl.org/
GNU LilyPond Music Typesetter http://lilypond.org/
Gnus http://gnus.org/
ikiwiki https://github.com/schmonz/ikiwiki
Samba http://www.samba.org
PHP http://php.net
FreeBSD Ports http://www.freebsd.org/ports/
pkgsrc: The NetBSD Packages Collection http://www.pkgsrc.org/
Mesa http://www.mesa3d.org/
Squid Cache http://www.squid-cache.org/
KDElibs (KDE) http://www.kde.org/
gedit http://www.gnome.org/projects/gedit/
Evolution http://www.gnome.org/projects/evolution/
Kontact http://kontact.org/
KDE PIM http://pim.kde.org
Advanced Linux Sound Architecture (ALSA) http://www.alsa-project.org/
Wireshark http://www.wireshark.org
OpenSSL http://www.openssl.org/
GIMP http://www.gimp.org/
NetBeans IDE http://www.netbeans.org
Koha Library Automation Package http://www.koha-community.org
openSUSE Linux http://www.opensuse.org/
Doxygen http://doxygen.org/
libcurl http://curl.haxx.se/libcurl
GStreamer http://github.com/zaheerm/gst-plugins-good
GNOME http://www.gnome.org/
Insight Toolkit http://www.itk.org
zsh http://zsh.sourceforge.net/
Nautilus https://wiki.gnome.org/Apps/Nautilus
X.Org http://www.x.org/wiki/
Mozilla Core http://www.ahrcloud.com
MariaDB http://mariadb.org/
CMake http://www.cmake.org
LibreOffice http://www.libreoffice.org
ALT Linux http://www.altlinux.org
ParaView http://www.paraview.org
GTK+ http://www.gtk.org/
Poedit http://www.poedit.net/
Bugzilla http://www.bugzilla.org/
Enlightenment (window manager) http://www.enlightenment.org
FFmpeg http://www.ffmpeg.org/
GLib http://library.gnome.org/devel/glib/
PEAR http://pear.php.net/
Ruby http://www.ruby-lang.org/
GnuCash http://www.gnucash.org/
phpMyAdmin http://www.phpmyadmin.net/
Mono http://www.mono-project.com
SWIG http://www.swig.org
SWT (Standard Widget Toolkit) http://www.eclipse.org/swt/
Checkstyle http://checkstyle.sourceforge.net
Eclipse Java Development Tools (JDT) http://www.eclipse.org/jdt/
Eclipse Platform Project http://www.eclipse.org/eclipse/platform-ui/
Natural Language Toolkit (NLTK) http://www.nltk.org
Ekiga http://ekiga.org/
Boost C++ Libraries http://www.boost.org
Kate (KDE) http://kate-editor.org
Devhelp http://live.gnome.org/devhelp
Arch Linux Packages http://www.archlinux.org
SPIP http://www.spip.net
GNOME Terminal https://help.gnome.org/users/gnome-terminal/stable/
ScummVM http://www.scummvm.org/
Anjuta DevStudio http://anjuta.org
BlueZ http://www.bluez.org/
Eye of GNOME http://www.gnome.org/projects/eog
Tor http://www.torproject.org/
Fedora Packages http://fedoraproject.org
Haiku http://www.haiku-os.org
Stellarium http://stellarium.org/
Totem http://projects.gnome.org/totem/
Rhythmbox http://www.gnome.org/projects/rhythmbox/
Gentoo Linux http://www.gentoo.org/
CDT (Eclipse) http://www.eclipse.org/cdt/
JRuby http://www.jruby.org
eZ Publish http://share.ez.no
VLC media player http://videolan.org/
Equinox http://www.eclipse.org/equinox/
Epiphany http://www.gnome.org/projects/epiphany/
Thunderbird http://mozilla.org/thunderbird/
GeoTools http://geotools.org
PyPy http://pypy.org
KDE http://www.kde.org
apt – Advanced Package Tool https://wiki.debian.org/Apt
Moodle http://git.moodle.org/gw?p=moodle.git
Calligra Suite http://www.calligra.org
QGIS http://qgis.org/
Mozilla Firefox http://www.firefox.com/
coreboot http://www.coreboot.org/Welcome_to_coreboot
Tiki Wiki CMS Groupware http://tiki.org
Apache Maven 2 http://github.com/apache/maven-archetype
Plone http://plone.org
Superior Lisp Interaction Mode for Emacs http://common-lisp.net/project/slime/
Kodi http://kodi.tv
MythTV http://www.mythtv.org
systemd http://www.freedesktop.org/wiki/Software/systemd
GeoServer http://www.geoserver.org
Groovy http://groovy.codehaus.org/
Blender http://www.blender.org/
MySQL http://www.mysql.com/
iproute2 http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
MonoDevelop http://www.monodevelop.com
Hibernate http://www.hibernate.org/subprojects/ogm
NetworkManager http://www.gnome.org/projects/NetworkManager/
NLog – Advanced .NET Logging http://nlog-project.org/
GParted http://gparted.org/
Seahorse http://www.gnome.org/projects/seahorse/
Glade User Interface Designer http://glade.gnome.org/
Jenkins http://jenkins-ci.org/
IntelliJ IDEA Community Edition http://www.jetbrains.org
Ruby on Rails http://rubyonrails.org
BusyBox http://busybox.net/
Evince http://projects.gnome.org/evince/
DokuWiki http://www.dokuwiki.org/
Linux NTFS file system support http://www.linux-ntfs.org/
KVM http://kvm.qumranet.com/kvmwiki
Battle for Wesnoth http://wesnoth.org/
Git http://git-scm.com/
SPIP-Zone http://zone.spip.org/trac/spip-zone/
Mercurial http://mercurial.selenic.com/
Hibernate Entity Manager http://entitymanager.hibernate.org/
Racket http://racket-lang.org/
RubyGems http://rubygems.org
SQLAlchemy http://www.sqlalchemy.org/
cabal http://haskell.org/cabal/
U-Boot http://www.denx.de/wiki/U-Boot/WebHome
WebKit http://webkit.org
OpenEmbedded http://openembedded.org
Yocto Project http://www.yoctoproject.org
matplotlib http://matplotlib.org/
Symfony http://www.symfony.com/
Meld http://meldmerge.org/
Haxe http://haxe.org/
FreeSWITCH http://www.freeswitch.org/
Geany http://geany.org/
collectd http://collectd.org/
Gramps http://gramps-project.org
phpBB Forum Software http://www.phpbb.com/
HAProxy http://www.haproxy.org/
fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page
NumPy http://numpy.scipy.org
Scala http://www.scala-lang.org/
dpkg http://wiki.debian.org/Teams/Dpkg/
Nette Framework http://nette.org
Inkscape http://www.inkscape.org
Phing http://www.phing.info/
jBPM http://jbpm.org
JBoss Drools http://www.jboss.org/drools
Bitbake http://developer.berlios.de/projects/bitbake/
Zotero http://www.zotero.org/
Lutece http://www.lutece.paris.fr
OTRS http://www.otrs.com/
Sage: Open Source Mathematics Software http://sagemath.org
Rockbox http://rockbox.org
Liferay Portal http://liferay.com
TYPO3 CMS http://typo3.org
Vala http://live.gnome.org/Vala
pylint http://pylint.org
The LLVM Compiler Infrastructure http://llvm.org/
libvirt http://libvirt.org
TinyMCE http://tinymce.moxiecode.com
Django http://www.djangoproject.com/
PHPUnit http://www.phpunit.de/
OpenStreetMap http://www.openstreetmap.org/
SymPy http://sympy.org
Xen Project (Hypervisor) http://www.xenproject.org
Eclipse Mylyn http://www.eclipse.org/mylyn/
PHP_CodeSniffer http://pear.php.net/package/PHP_CodeSniffer
Sakai LMS (core) http://www.sakaiproject.org/
Spring Framework http://github.com/SpringSource/spring-framework
Joomla! http://www.joomla.org/
Marble http://edu.kde.org/marble/
LXDE http://lxde.org
Pygments http://pygments.org/
OpenLayers http://openlayers.org/
The MacPorts Project http://www.macports.org/
calibre http://calibre-ebook.com/
Grails http://grails.org
Alfresco Content Management http://www.alfresco.com
util-linux https://github.com/karelzak/util-linux
jQuery http://jquery.com/
Vaadin http://vaadin.com/
Cython http://www.cython.org/
Dojo Toolkit http://dojotoolkit.org/
MediaWiki https://www.mediawiki.org/wiki/MediaWiki
Second Life Viewer http://www.secondlife.com/
Munin http://munin-monitoring.org/
Odoo https://www.odoo.com
Mozilla Calendar http://www.mozilla.org/projects/calendar/
KDevelop http://kdevelop.org/
ZNC http://znc.in
Werkzeug http://werkzeug.pocoo.org/
cppcheck http://cppcheck.sourceforge.net/
Wicket Stuff http://wicketstuff.org
Drush http://drupal.org/project/drush
Sphinx documentation builder http://sphinx-doc.org/
Piwik http://piwik.org
JDownloader http://www.jdownloader.org
SeaMonkey http://www.seamonkey-project.org/
Empathy http://live.gnome.org/Empathy
SilverStripe http://www.silverstripe.org
PulseAudio http://pulseaudio.org
LLVM/Clang C family frontend http://clang.llvm.org/
Pylons http://pylonsproject.org
MongoDB http://www.mongodb.org/
Mockito https://github.com/mockito/mockito
Doctrine http://www.doctrine-project.org
Pacman http://www.archlinux.org/pacman/
MAME – Multiple Arcade Machine Emulator http://mamedev.org/
Rubinius http://rubini.us/
Apache Camel http://camel.apache.org/
OpenJDK http://openjdk.java.net/
Buildbot http://buildbot.net/trac
MPD http://sourceforge.net/projects/musicpd
Tracker http://projects.gnome.org/tracker/
org-mode http://orgmode.org
Sass http://sass-lang.com/
WPA/WPA2/IEEE 802.1X Supplicant http://hostap.epitest.fi/wpa_supplicant/
Go programming language http://golang.org/
Apache CouchDB http://couchdb.apache.org/
Qt 4 http://qt-project.org/
Apache CXF http://cxf.apache.org/
CakePHP http://cakephp.org
CKeditor WYSIWYG editor http://ckeditor.com/
SciPy http://www.scipy.org
gitg http://trac.novowork.com/gitg/
Banshee http://banshee-project.org
OGRE http://www.ogre3d.org
Chromium (Google Chrome) http://code.google.com/chromium/
Gradle http://www.gradle.org/
Netty Project http://netty.io/
Sinatra http://www.sinatrarb.com
Chef http://www.opscode.com/chef
Gerrit Code Review http://code.google.com/p/gerrit
GNOME Shell http://live.gnome.org/GnomeShell
Git Extensions http://code.google.com/p/gitextensions
Qt Creator http://qt-project.org/
Kohana v3 http://kohanaframework.org/
Android http://www.android.com
JUnit http://www.junit.org
PCSX2 http://pcsx2.net/
Shotwell https://wiki.gnome.org/Apps/Shotwell
Redis http://redis.io/
Cassandra http://cassandra.apache.org/
PhoneGap http://phonegap.com/
Trinity Core http://www.trinitycore.org
Icinga http://www.icinga.org
CyanogenMod http://www.cyanogenmod.com/
Rygel http://live.gnome.org/Rygel
QEMU http://www.qemu.org/
Trinity Core2 http://www.trinitycore.org
Pitivi http://github.com/jhoolmans
Openfire http://www.igniterealtime.org/projects/openfire/
Apache Hadoop http://hadoop.apache.org/core/
akka http://akka.io
JGit http://www.eclipse.org/jgit/
Homebrew https://github.com/Homebrew/homebrew-apache
Oh My Zsh http://github.com/robbyrussell/oh-my-zsh
ehcache http://www.ehcache.org/
EGit http://www.eclipse.org/egit/
node.js (NodeJs) http://nodejs.org
Thunar http://www.xfce.org
Selenium http://seleniumhq.org/
Arquillian http://jboss.org/arquillian
Erlang http://www.erlang.org
YUI http://yuilibrary.com/
Gunicorn http://gunicorn.org
CoffeeScript http://www.coffeescript.org/
Clementine Music Player https://github.com/clementine-player/Clementine
scikit learn http://scikit-learn.org
Processing http://processing.org/
Vagrant http://vagrantup.com/
Qt 5 http://www.qt-project.org/
Yii PHP Framework http://www.yiiframework.com
Zend Framework http://framework.zend.com/
Apache Spark http://spark.apache.org
Flask http://flask.pocoo.org/
OsmAnd http://www.osmand.net
ownCloud http://ownCloud.org
Open Computer Vision Library (OpenCV) http://opencv.org/
phpDocumentor http://www.phpdoc.org
IPython http://ipython.org/
RSpec http://rspec.info/
OpenStack http://www.openstack.org/
OpenStack Nova https://launchpad.net/nova
Apache CloudStack https://github.com/apache/incubator-cloudstack
AngularJS http://angularjs.org/
GWT (formerly Google Web Toolkit) https://github.com/google-web-toolkit/gwt
Facter http://puppetlabs.com/puppet/related-projects/facter/
salt http://saltstack.org
jMonkey Engine http://jmonkeyengine.org
Puppet http://puppetlabs.com/puppet/
Play! framework http://www.playframework.org/
Elasticsearch http://www.elasticsearch.com
Bootstrap (Twitter) http://twitter.github.com/bootstrap/
Apache OpenOffice http://www.openoffice.org/
GlassFish https://glassfish.dev.java.net/
Propel http://propelorm.org
JabRef http://jabref.sourceforge.net
CodeIgniter http://www.codeigniter.com/
GNOME Boxes http://live.gnome.org/Boxes
GitLab https://www.gitlab.com/gitlab-ce/
TiddlyWiki http://www.tiddlywiki.org
Fish shell https://github.com/fish-shell/fish-shell
Ansible http://ansible.com
Simple Machines Forum http://www.simplemachines.org/
FontForge http://www.fontforge.org
libgdx http://libgdx.badlogicgames.com
py-pandas http://pandas.sourceforge.net/
javascript https://github.com/airbnb/javascript
EasyTAG https://wiki.gnome.org/Apps/EasyTAG
docker http://docker.io
Capistrano http://capistranorb.com/

从28万个开源项目中,我们能够学到一些什么?

引子:开源项目那么多,哪些是值得我们学习的?

这里声明一下,仅仅是学习一下:他们是用哪些工具,来管理自己的项目的?

开源项目多如牛毛,值得分析的项目也很多很多。从哪里入手呢?幸运的是,在开源社区,有一个著名的网站,过去叫oloho,现在改名叫openhub。在他的网站首页,有这么四行字,以表明他们的数据库是多么的全面、丰富:

Indexing 669,008 open source projects
Connecting 3,742,793 open source contributors
Tracking 679,761 source control repositories
Counting 31,158,335,454 lines of code

这么说来,事情就变得比较“简单”了,我需要把openhub的数据,都抓回来。


数据的筛选过程

具体的数据抓取过程,简直不忍详述(我的内心,几乎是崩溃的)。总而言之,我只抓到了289,631个项目。openhub虽然号称自己索引了66万的开源项目,其实这仅仅是他的数据库里的最大ID号!当我顺着这个ID一个一个的去抓的时候,有很多ID,都已经被删除了。

在抓取到的项目数据中,有两个数值,特别值得参考:contributors(参与开发者的数量);users(该软件的用户数量)。相对而言,users的数据,可以认为是一个样本,即该开源项目的所有用户中,愿意并且知道该如何来openhub点击I use this的人。因此,即使是排名第一的Firefox,在openhub也只有13158个用户。考虑到Firefox的用户数,已经超过5亿(来源于维基百科英文版),因此,我们相信这个数据仅仅是一个4万分之一的采样结果。

随后,我观察了这28万多个项目的users数据与contributors数据,顿时惊讶的发现,绝大多数项目,都小的可怜,用户也少得可怜。

当我以“select count(*) from projects where contributors>30”查询时,只搜到了  1662个项目...
当我以“select count(*) from projects where users>30”查询时,只搜到了1260个项目...
当我合并以上两个条件查询时,只搜到了335个项目。
再从这335个项目中,排除掉最近一年已经不再有活动的项目,于是只剩下了331个了。

三个感想

  1. 成功的开源项目,真是凤毛麟角
  2. 绝大多数开源项目都是少数人开发的小项目
  3. 这331个项目,也许可以作为我们的重要参考

第一个问题:他们用什么配置库?

这是331个项目,使用配置库的情况(有些项目,同时使用多种配置库),有两个现象值得注意:

  1. 接近92%的项目,已经在使用git——git的统治地位,已经无可动摇
  2. 只有53%的项目,在使用Github——那些用git却不用Github的项目,是什么原因?

通过数据来分析:是否使用Github与项目创建时间的关系

通过这个图,可以看出两个现象:

  1. 越是新创建的开源项目,hosting在Github上比例越高
  2. 越是新创建的开源项目,事实上成功的也越多(当然,2010年以后的数量锐减,我们怀疑是好酒也要陈酿的原因)

通过数据来分析:是否使用Github与项目代码规模的关系

由于不同的开源项目,代码行数差异巨大,因此我们只能以log(col)对数结果,来做区间划分。可以看到一个非常明显的趋势,当然代码行数超过10万行以后,代码部署在Github上的项目,就开始明显下降,直到为0。

总结:是否使用Github,越是新的项目越愿意用;越是大的项目越没法用。


第二个问题:他们用什么来管理issue?

排名前五的工具中,Github:91个项目;Bugzilla:81个项目;JIRA:43个项目;Trac:20个项目;另外还有9个项目,完全是在maillist里“管理”issue的。

一共有39种不同的工具,另外还有6个项目,我们无法了解他究竟是用什么来管理的。

简单的来看:

  1. Github已经占据统治地位
  2. Github的占有率仅仅27%。
  3. Bugzilla也算老而弥坚
  4. 有很多项目,在选择自己的工具

通过数据来分析:使用的issue tracking工具与项目创建时间的关系

1990年之前创建的项目,其中有一个已经开始使用Github了。但是,这仅仅算是个案。更加明显的趋势是:越是新的项目,越是倾向于采用Github管理自己的issue。

相对而言,其他各种Issue Tracking工具的比例,都在下降。

通过数据来分析:使用的issue tracking工具与项目规模的关系

随着用户数量的增加,我们猜想:issue的数量与复杂度,也会逐渐增加。可以看到这样的趋势:Github的使用率,也在不断下降。

总结:是否使用Github来管理项目的issue,越是新的项目越愿意用;越是大的项目越没法用。


尚未完成的分析:

  • 开源项目使用的CI工具的情况
  • 开源项目使用的Code Review工具的情况
  • 开源项目使用的文档类工具的情况
  • ……

主要还是工作量太大了。。。对这个分析有兴趣的同学,可以与我联系,咱们可以一块来干。

Free Software vs. Open Source

首先推荐一部电视剧

很早以前看过一部港剧《龙兄鼠弟》,是万梓良、郑则仕和张卫健演的。其中万梓良饰演的雷文凤,在最后写了一本书,叫做《黑白灰》。大意是:这个世界,虽然存在黑白两色,绝大多数人,却都是灰色的。而他,却一定要坚持做一个纯白色的人。甚至在他看来,灰色的人,较之黑色的人,更加罪恶。

最近刚刚读完了另外一本书《若为自由故》,则是一本Richard Stallman的传记。在这本书里,红帽公司总裁罗伯特·杨(Robert Young)总结理查德看似矛盾的政治行为时,说道:“我崇拜也尊敬理查德和他所做的一切。我对他唯一的批评就是,有些时候,他对待朋友甚至比对待敌人还要无情。”

在我看来,也许发起开源运动的那群人,大多数自认为是RMS的朋友,而对于RMS而言,他们只是一群放弃了原则而站在灰色地带的人罢了。

说实话,在自由软件与开源之间,我究竟应该持何种立场?这是一个,我一直以来,都不愿意深想的问题,实在是太难了。只是这回读了一遍RMS亲笔签名的个人传记,又了解到了很多当事人的实际言论,总觉得应该督促自己,思考出一个结论出来。

两者的分歧,首先是哲学上的:理想主义 vs. 实用主义

在RMS看来,自由是天赋人权,可以说:因为自由本身值得追求,而RMS恰好又是个软件天才,所以他才会致力于自由软件。

而在开源运动看来:吸引更多的人参与自由软件的开发,然后实实在在的拿出优秀的开源软件来,才是真正有价值的事情。

自由软件的目的,是更多的自由,而开源软件的目的,是更好的软件

GPL是一种神奇的创造

如果RMS只是一位致力于追求软件自由的斗士,也许不会有任何人理睬他。但是他写出了Emacs、GCC这样的神级软件。以至于由此建立起了几乎无人能及的社区影响力。

因为他写的软件实在太牛,所以无论他以什么样的License来发表自己的软件,都会引发全社区的关注。

然后,GPL这种诡异的授权模式,才会有人愿意遵循。甚至,应用作为自己的开源License。

或者换句话说:RMS挂了Emacs的羊头,卖了GPL的狗肉。但是,Emacs这个羊头实在太好,买了GPL这种狗肉的人,居然也就认可了。

《大教堂与集市》对于RMS是一个重大打击

因为《大教堂与集市》一书,对于Linux成功之道的总结与宣传,使得Linus被人们提升到了世界上最知名黑客的行列。

说到底,在黑客这个圈子里,大家还是更注重实力,而非理念。当有人以完全不同的方式,创造出完全不逊于Emacs、GCC这样的开源软件时,RMS/自由软件/大教堂所代表的「道路」,就不再是唯一的选择了。

尤其是当Linus站在了开源的大旗下,更多的公司则出现在了Linux的周围。集市的胜利,不仅仅是开源相对于闭源的胜利,也是Linus相对于RMS的胜利。

在之后的世界里,虽然开源的代码越来越多,但是自由却越来越少被人提及了。

不完美的系统会激怒黑客

公正——该如何做是好》一书中,有一个经典的伦理学命题:假设铁轨上有一辆失控的火车,在岔路的一边是一个人,而另一边则是五个人。你是一个扳道工,你会选择让火车开向一个人,还是五个人?

我曾经问过我儿子这个问题,他的回答非常有趣:「如果是五个大人,与一个大人」,那就撞一个大人。「如果是五个大人,与一个小孩」,那就撞五个大人。「如果是五个男人,与一个女人」,那就撞五个男人。「如果是五个男人,与一个胖女人」,那就撞那个胖女人。。。

这其实反应了一个事实:想要通过权衡利弊,来做出最有利的选择,可能会是非常没有原则的事情。即使是一个成年人,也未必能做得有多好。

对于一个像RMS这样的黑客来说:他们会被这种问题所激怒,进而会拒绝回答问题,并想尽一切办法,要hack掉这个该死的列车与轨道系统。

在本书的第十二章《开往黑客地狱的短暂旅途》,就讲了一个令RMS暴怒的故事,在书中,作者写到:「“不完美的系统会激怒黑客。”史蒂芬·李维说过 这样的话,这是我决定与斯托曼同坐一辆车前应该听取的另一个忠告,“这是黑客们通常不喜欢开车的原因之一:这是一个充满不确定性的程序,交通信号灯总是随 机的变化,还有横七竖八的单行道,导致交通经常堵塞。这实在是太不必要了,只要让黑客们重新安排一下信号灯,打开交通灯控制盒,重新设计整个系统。”」

是的,对于真正的黑客来说:适应这个不完美的世界——取舍、权衡、妥协,是别人的事情。而黑客,就一定想要改造它!

我的结论

RMS这样的人,就像是在遥远的天边,在夕阳即将落下之时,努力为我们撑起天际线上那最后一点光明的人。

我没有资格自称为黑客。哪怕是改变世界的念头,我也常常是一闪而过。但是,这并不妨碍我始终对RMS,报以最高的崇敬!

至于Open Source,那至少是个很不坏的东西吧!

如何评价一个新技术——以Docker为例

上次与霍炬聊天,霍炬提到他在跟陈皓抬杠,陈皓认为Docker与Java是一个级别的发明,第二年就吸引了所有热门公司的加入。而霍炬认为这太夸张了,毕竟就是个配置管理器嘛。

而我的评价,可能会比陈皓的更高,我认为Docker比Java的级别还要高。而且,这与有多少公司参与无关。甚至可以反过来说:因为Docker极为重要,才会有那么多的公司,在第一时间加入进来。

因此,我也答应霍炬,要写一篇文章,仔细的阐述一下自己的观点。

新技术的三大功效

新技术的三大功效

新技术的三大功效:

  • 提升效率:某种更快的算法

或者更快、或者更省,都是好技术。可以是一个算法,也可以是一种更方便快速开发的框架。可以是更高速的网络带宽,也可以是更省电的低功耗技术。

这些,当然都是极好的。但是,也都不过是某种层面的量变而已。除非提升的幅度,达到百倍、甚至千倍、万倍。

  • 增加选择:一种新的语言

有时候,我们会把这类行为称之为重新造轮子。然而,我们也可以认为,哪怕是做同一件事情,现在也多了一种新的选择。

当然,这并非其价值所在。更重要的益处在于:新的选择,意味着新的思路,新的模式,新的「解法」。

虽然,在做这件事情本身,也许并无太多帮助。但是,却可能启发新的创造。

  • 降低门槛:更加简单的工具

有一类技术,并非直接的贡献,而是间接的。原本在这个领域,非要苦学十年以上,才能出师。现在,21天,就能从入门到精通了。以前只有国际巨头才能开发的移动电话,现在一个英语教师,就敢开整了。

但是,降低门槛的技术,往往具有颠覆性的价值。一个行业,只有100人能参与,和有100万人能参与,将会带来绝对意义上的不同。很多时候,虽然降低门槛,并不能真正化解深层次的复杂性。但是,却会吸引更多的聪明人,来一起思考和解决问题。

繁荣之后,一切皆有可能。

如何给docker定位?

  • docker所封装的容器技术,带来了更高的效率
  • 以docker容器为代表的虚拟化模式,是一种新的选择,将为架构设计带来新的启发
  • docker-registry、dockerfile、docker-compose等相关技术,大大降低了参与到这一容器化浪潮的门槛

综上所述:我认为docker是一种极具潜力的新技术。正因为其潜力巨大,才吸引了众多巨头、众多企业、众多散户以及众多一线研发者的共同热捧。

题外话

事实上,我上面画的那个模型,是自己生造的。甚至可以算是为Docker度身定制的。在以上三个要素之外,还有其他一些评价新技术的标准。

从量变到质变

这是我上面刻意模糊的部分。一个技术,能够快2倍、20倍、还是20万倍。将会得到完全不同的评价。

飞行速度是否能超过7.9公里/秒,是完全不同的两重境界。

创造一个新行业,甚至更多行业

在电视机出现之前,不会有电视演员,不会有现场直播,不会有主持人,不会有…沙发土豆。

能够令整个世界因此而不同的新技术。岂是小小的docker可比?

危害性

似乎,IT行业最牛的技术,也不太会有啥危害性。前一阵热炒的人工智能,也不过是某种夸张100倍之后的危言耸听而已。

毕竟,一种新技术,都无法威胁世界和平,能有多了不起?比起物理学家、化学家,咱们这些搞IT的人,简直弱爆了。

不会太灰暗的未来

霍炬前阵子写了一篇「歪理邪说」:《无论强人工智能能否出现,人类的未来注定灰暗》我第一遍阅读的时候,发了一条微信:「好一篇歪理邪说,一时间竟无法反驳」。潜台词是:总觉得有哪里不对,还是很想反驳的。。。

简单总结霍炬的观点,我认为主要包含以下两点:人们无意识地,甚至主动的分享自己的隐私;这些隐私被大公司掌握,辅之以大数据分析,以深度学习的方式理解用户,进而对人类行为实现操控。

在经过几周的思考之后,我打算将自己的观点表达如下:

1. 我的隐私,我自己都知道吗?

在没有查看网站访问日志之前,我根本不记得自己一天看了多少网站,浏览了多少内容。在没有佩戴智能手环之前,我不知道自己每天走了多少步路。在手机没有GPS定位功能之前,我甚至会偶尔迷路,不知道自己身在何处。

当然,我每天浏览的网站,走了多少路,心跳水平,吃了什么,去了哪里,都是可以算作我自己的隐私。但是,我要么自己根本不知道,或者因为信息琐碎,我自己也记不住。

那么,这些我自己都搞不清楚的隐私,还算是隐私吗?如果,这些隐私没有别人知道,我自己也不知道,这种隐私,有什么价值呢?如果是没有价值的隐私,有保护的必要吗?

换句话说,如果我上传了这些隐私(我原来自己都不知道的隐私),给我带来了更多的收益,这个是不是好事呢?

2. 基于隐私的增值服务,存在诸多灰色地带

众多的服务,哪怕是传统服务,也需要了解用户的隐私。我去做按摩,我的按摩师傅会问我:你最近哪里不太舒服。去医院看病,负责任的医生也会询问我的既往病史。如果不了解这些信息,他们就无法提供针对我的服务。

进入网络时代,我们会向从未见过的人,甚至某个网站,透露自己的隐私。我们的信用卡号,我们的身份证和年龄性别。如果我们想要去网上征婚,那还得填写更多的内容。

为什么我们愿意主动填写这些信息?因为需要换取更好的服务。

再进一步,针对一个人的数据,力量是不足的。如果网站能够收集足够多人的数据,统计、分析、甚至预测。假设:根据不同地区,针对不同商品的搜索频率,预测不同地区的商品需求趋势。这当然能够帮助商家赚取更高的利润。但是也的确能够让用户在下单购买时,以更快的速度,收到货物。

如果,网站在收集这些需求数据的时候,能够只做汇总,不记明细。那么,用户来说,就只有益处,没有损害了。

事实上,所谓隐私,是针对不同的个人意愿而界定的。我的个人信息,如果我不愿意他人知道,那就是我的隐私。如果,我不介意他人知道,那就不是隐私。

不过,我想要举一个非常令人困扰的例子:「我在微信或者微博上,分享自己孩子的照片,甚至还有姓名和乳名。这是不是会存在问题?」很多爸爸妈妈都在这么干,而且往往乐此不疲。另一方面,也有很多「有识之士」指出:「这会给人贩子、诈骗犯、敲诈勒索的绑匪以可乘之机!」

甚至,如果存在某个刻意针对你的家伙,默默收集你的各种公开信息,就能做到对你了如指掌,进而对你不利。在过去,他可能需要去翻你家的垃圾桶,再私下找你的身边人打听。现在,他们坐在家里,就能够搜集到这一切。甚至,有某种地下的黑色产业链,在兜售各种隐私的信息,以方便他购买。

问题在于:我不介意他人知道的一些个人信息,究竟是否有可能损害我的利益?而我在交出这些信息的时候,是否已经知道这一点?假设,我们公开分享的所有信息,事实上都可能对我们不利,这样的概率有多大?我们应该放心大胆的分享吗?还是应该不怕一万、就怕万一?

3. 权利的转让与契约的成立

如果跳出IT、网络以及隐私的范畴,我们可以找到另外一些相近的例子——国家与政府的出现。在国家与政府出现之前,人类比现在自由得多,当然,也短命得多。安全没有保障,随时可能被人干掉。人们居住的地方,也缺乏各种公共设施,没有路灯,没有医院,没有警察,没有城管,没有环保局,没有……

没有这些公共的服务,人类自然都朝不保夕,直到他们愿意让渡自己的一部分权利,教给一个公共的政府,由这个政府,提供各项公众需要的服务。

当然,一旦政府出现,就有了自己的生命力,甚至可能违背创立者的本意。这才是需要监督政府的根本原因。让渡权利,订立契约,保持监督。这就是现代国家的「契约论」基石。

西方的众多知识分子,有一个永恒的命题:「警惕政府走向独裁」。但是,无论多么警惕,无论多么强调监督,「取消政府」的言论,绝非主流。也不可能成为主流。

回到隐私的话题上来。我们上传自己的隐私,同样是基于我们与服务商之间的「契约」的。也许我们通常不看那些契约的文字,也许我们往往不关心可能的条文陷阱,也许我们的信息,会落入不怀好意的人手中。但是,我们已经无法回到过去,无法停止使用众多的网络服务,无法放弃在朋友圈发照片了。

唯一的选择,只能依赖法制,持续向前。如果法制不健全,就推动法制的健全,推动对服务商的监管,如此而已。

那种担忧人类注定会走向灰暗未来的心态,与担忧人类早晚会落入独裁者之手的心态一样。是相当「杞人忧天」的。

4. 借助工具,认识自己?

「认识你自己」,这是古老西方的格言。「人贵有自知之明」,这是古老东方的格言。问题在于,如何才能做到呢?在传统的方法中「反思、静观、禅修」,也许是可行的办法。在科学昌明的现代,也许工具可以帮助我们。

在霍炬的文章里,有一个很有趣的「近未来幻想」,可以通过分析购物者的心跳、血压等身理特征,判断对于这个人最具有吸引力的商品价格。

这其中有啥问题吗?以这种价格购买这种商品,违背了用户的意愿了吗?根据不同的供求关系,确定销售价格,原本就是「政治正确」的经济学规律。那么,在大数据支撑之下,商品能够根据每一个个体的需求强烈程度,确立一个针对性的价格,不是更加符合经济学规律吗?

假设通过机器的分析,我们掌握了用户的真实需求强度,这究竟是一种操纵,还是一种迎合呢?

假设,我们通过个性化推荐,列出了用户真正想要的商品,用户会因此感到恐慌吗?假设,我们不是以程序方式揣摩用户心理,而是由一个经验丰富的导购小姐,带领用户完成选购,是不是就不会令人恐慌了呢?

那么,我们恐慌的,是不是「程序而非人类,猜出了我的心意」这一事实呢?

血压计、心电图、X光机,种种医学手段,帮我们更加真实的掌握自己的健康状况,当然也能够帮助我们发现疾病,尽快恢复健康,延长寿命。那么,如果随着科技的发达,某种机器和算法,能够帮助我们更加深入的认识自己,了解自己,这样会带来什么样的益处(坏处)呢?

5. 怎么才算作被操控?怎么才算作被洗脑?怎么才算作被决策?

任何人都害怕自己被人操纵,当然,更糟糕的是被机器操纵。问题在于,怎么才算是被操纵、被洗脑、被决策呢?

当年在知乎,我曾经回答过一个类似的问题。简单说:「过程中是否可以反悔;事后是否可能后悔」。

我们在网上购物,购得兴高采烈,事后又号称自己要剁手云云。我也没听说过有几个人,真正的剁了手。如果商家提供了7天无理由退货,在7天之后,你还没有退货。那就不要说自己是被操纵购物的。

霍炬文中的有一段话,可以算作是一种惊人的预言:「那时候人们就会有更多行为会按照人工智能程序所规定的方式进行,并且,还会发自内心的认为那是他独立自主的产生想法。人会完全会成为程序的终端,为程序贡献数据,按照程序引导产生行为,依赖程序生活和工作。」

在我看来,这段话称得上是危言耸听。背后的逻辑,是对技术深深的恐惧。

6. 人是生而自由的,却无往不在枷锁之中。

在没有任何技术介入的情况下,我们从一生下来开始,就会受到引导、规劝、甚至强制教育。父母会告诉我们,这样做是对的,那样做是错的。如果干了某些事,就一定会挨揍。

在上学以后,我们读书、学习,书本上,课堂上,老师的耳提面命,书中的价值灌输。什么样的少年,才是一个好少年?我们如何才能带上小红花?我们如何才能称为三好学生?我们如何才能当上班干部?

在生活中,小说、诗歌、散文、杂志,在向我们倾诉着各种不同的价值观。形形色色的广告,在以种种价值观,无所不用其极的诱导我们消费。身边的同学、同事、朋友、亲戚,也在不断的向我们传递他们的价值观。

我们一路行来,哪有一天躲得过呢?

三十而立、四十不惑,追求的无非是确立自己的价值观。我们不断学习、思考、总结、成长,无非是为了不受人惑、有自己的主见。

那些读完了霍炬的文章,认定人类的未来注定会灰暗的朋友,也许已经不自觉的接受了某种灌输。比起尚未到来的「人工智能操纵你的未来」,只怕已经被一篇文章洗了脑!

7. 未来真的会那么灰暗?

我一直觉得未来学家,是一种非常高大上的、安全的职业。当然,他们最好不要预测自己活着就能够看到的未来,免得到时候麻烦。

那篇引发了霍炬文章的「介绍强人工智能」的文章,其中的逻辑,也非常吊诡。如果未来机器的智商,是人类的成百上千倍,差距大到了蚂蚁与人类的差距。我们谁有资格预测未来呢?蚂蚁有资格预测人类社会未来的发展趋势吗?

与其勉强预测,写些危言耸听的文章。倒不如老老实实的承认:未来无法预测!把小说写得像科普文章,真的靠谱吗?

未来将从何而来?我不知道。在我看来「未来不会那么灰暗」,至于理由,也许是因为我比较乐观吧……

三代开源社区的协作模式

一、研发工具与研发模式

据说,人之区别于禽兽,最大的特征在于利用,甚至发明工具。在没有任何其他工具时,我们只能借助于自己的肢体,一旦有了工具之后,我们的能力将会大大的增加。

但是,从另一个角度来看,工具也同时在限制我们的能力,甚至限制了我们的行为模式与思维模式。有一句俗话说得好:「手里拿着锤子,看见什么都像钉子。」

而在研发工具的领域,我们观察到另外一些有趣的现象:因为软件研发工具的开发者,同时也是工具的使用者。因此,他们不仅仅会受制于工具,也往往会由 此被激发,开发出对自己而言更加趁手的工具。开发者与使用者身份合二为一的现象,使得研发工具的发展,简直可以用「日新月异」、「层出不穷」甚至「争奇斗 艳」来形容。

随着软件复杂性的不断增加,以及软件开发的参与者不断增多,团队协作的辅助软件,也开始不断增加,随后我们发现:工具不仅仅限制了个人的行为模式,更进一步限制了团队的协作模式。

软件研发企业的管理者,往往会有某种错觉,他们会认为:管理就是定下制度、流程与规范,然后「下面的人」就会照此执行。因为有人「听话」,有人「不听话」,所以才需要奖励与惩罚的制度,来帮助管理者推行他的「规则」。所以,他们一般都很喜欢看《执行力》这样的书。

在开源社区,事情变得有些不一样。虽说开源社区也有「领导者」,甚至往往会有「精神领袖」,但他们并没有暴力手段,也没有经济手段,甚至行政手段。因此,要协调一帮自由散漫的黑客,共同开发高质量的开源软件,必须有更加高明的手段。

由于一切都是Open的,所以:不仅代码人人可见,开源社区的协作模式,也暴露在众目睽睽之下。从某种意义上来说:这促进了开源社区的协作工具的开发、进而使得开源的研发协作模式,以远远超过企业内部的演化速度飞速演化。

二、第一代开源协作模式

第一代开源协作模式,在早期几乎没有符合自身特殊需要的工具,有什么用什么,因此最为常用的email,被发展为Maillist,成为整个开发团 队的协作核心工具,大多数操作系统内置的diff/patch工具,使得代码的交流以email patch为主。这些老牌的开源项目,从使用RCS、CVS,到了后来也开始逐步引入svn/git,bugzilla这样的工具,但是围绕 mailing list开展协作的特征,则持久不变。

作为协作核心的Maillist

一个开源社区,往往就是一个邮件列表,随着软件的日益复杂,社区的不断扩大,邮件列表也会不断分化,通常会划分为:核心组、开发组、用户组。开发组与用户组的邮件列表,随着软件的架构分化为多个模块,还会进一步分解。

在邮件列表里,所有的用户都是平等的,在无法用工具保障流程的情况下,社区逐渐发展出了一套严格的邮件礼仪和格式规范。不规范的邮件,不会被理睬;不礼貌的家伙,甚至会被赶走。

邮件越来越多,即使分成多个邮件列表,依然太多。Archive这样的邮件归档、查阅的工具,就必须得有了。一封邮件,大家都来回复,严格re:的标题,组成了一个可供追溯的线索。

在邮件列表里,通常出现个人的名称,加上Reported-By、Tested-By、Acked-By的标记,即是一种代表个人名义的认可,也是流程规范的一部分,更是计算各人贡献的依据。

Bugzilla应运而生

在邮件中,有一类话题是最活跃的,那就是bug。但是,通过翻找邮件查阅bug的最新的解决状况,是非常困难的。一个bug,从提出,到最终解决, 并被确认在哪一个版本中发布fix,是一种稳定的状态转化模式。一个专有的处理工具,势必应运而生。Bugzilla、trac等一批工具,就由此被创造 出来了。

代码提交流程的规范化

开源社区,表面上非常的崇尚民主自由,但实际上却盛行精英主义、甚至是个人独裁的。我们往往会给某个开源项目的创始人,冠以「仁慈的独裁者」的头衔。虽然,是否仁慈,大家不得而知,但独裁确实是显然的了。

最大的独裁,是代码的管理权。因为作为创始人与核心开发者,他们往往以一己之力,贡献了绝大多数的代码,确定了项目最初的架构与发展方向。他们不会容忍任何人随意地向代码库提交代码。

在邮件列表中,一个新来的家伙,从没人认识,到能够独立的向代码库提交代码,非得经历艰辛的历程不可。这样的历程,简单的说,就是一次一次的 Code Review。被审核通过、合入代码库的patch越多,一个人对于社区的贡献就越大,可信度也越高,身份地位也逐步提高,然后,他也就可以去 Review其他人的代码了。

总结:在简陋的工具条件下,发展出高效、严格的社区协作模式

三、第二代开源协作模式

第二代开源协作模式,有两大特征:Web化、集成化。随着Web技术的不断成熟,开源社区也开始创造一个又一个的Web开源项目,其中Web化的项 目管理工具,如雨后春笋般冒了出来。在wikipedia上,issue-tracking systems列出了55个,project management software列出了152个,其中开源的也有30+,open-source software hosting列出了22个,堪称蔚为壮观。

这类平台又可以分为两大类:基于开源的项目管理工具或issue tracking工具,自建平台,以JIRA、DotProject、Redmine为代表;基于免费开源托管平台,以SourceForge、Google、LaunchPad为代表;

第二代的开源项目管理工具,可以说,主要是在向企业内的开发管理学习。文档、流程、角色、权限、统计报表等等功能,都开始出现了。有些开源项目,也在用这些东西。

以SourceForge与Google Code为代表的开源托管平台免除了开源项目搭建自己的官方网站,管理工具,代码仓库之类的繁琐事务,大大促进了开源项目的发展。不过,由于平台的功能总是受限的,因此自建门户,自组工具的开源项目依然层出不穷。

issue & milestone

在第二代开源协作模式日渐成熟的过程中,另一股潮流也正方兴未艾:「敏捷软件开发」。其中,最为深入人心的概念之一,就是每个迭代,完成一批User Story

在开源社区,这个概念被进一步演绎:无论是bug和feature,都被统称为issue。这些issue,被分到不同的milestone(版本),即使最后有可能延期,milestone也会定义一个预期完成时间。

这是好事?还是坏事?其实很难评价,因为从开源的原始教义而言:所有的贡献,都是自愿、随机、不可预期的。为自然生长的软件,规定里程碑,本来就显 得荒谬。但是,从另一方面而言,我们可以引用另一个中国人过马路的例子:「不管红绿灯,凑够一堆人就过马路」,开源软件,往往也是「不管里程碑,稳定一堆 特性和bugfix,就发布一个版本」。

如果在开源软件很少,更别提形成开源生态圈的情况下,这种随意的做法还是可行的。但是在大量软件,相互依赖的情况下,一个开源项目要赢得其他协作项目的信赖与协作,必须给出稳定的规划,以便相互配合。

这种规范,也是被逼出来的。

服务平台化

虽然黑客们喜欢写程序,但是要写的程序实在太多了,能够不重复造轮子,有现成的好工具可以直接拿来用,也是件好事。如果可以打开一个网站,注册一个用户,创建一个新的项目,剩下的事情自有平台帮忙打理,那么大家都可以愉快、专心的写自己的代码了。

平台在逐步进化,因而能够帮助开源项目,打理越来越多的事务。通常主流的开源项目托管平台,都能够完成:

  • 在线代码浏览,并能够支持不同的配置库
  • 需求管理、Bug管理,通常合并为Issue tracking
  • 版本与里程碑管理
  • 文档编写与管理,以Wiki的形式为主

更进一步的,还有能够完成:简单的自定义工作流、文件夹与静态资源管理、输出各种统计报表、甚至提供论坛、搜索、邮件列表以及各种排行榜等等。

在此之前,一个开源项目,是一个社区。到了大平台的时代,整个平台,构成了一个更大的社区。

总结:以Web形式提供的集成化开源项目托管平台,标志着开源项目的协作模式,进入成熟期

四、第三代开源协作模式

到了MySpace、Facebook与Twitter这样的SNS网站的兴起,开源项目的协作模式,受到SNS的启发,也随之进入了第三代,以 Social Coding为核心的开发协作模式,这样的模式在以Github为代表的网站上,体现的最为充分,众多的模仿者也层出不穷。过去的开源项目与托管平台,都 是以项目为中心来打造,而Github则是围绕着参与开源的人来打造。首先满足的不是项目的需求,而是个人的需求,由于对人的黏性大大增加,也使得 Github成为近年来最具吸引力的开发社区。

围绕着Github,一大批周边扩展服务被建立起来,构成了一个更加有活力的生态圈。而程序员们,不仅在Github上参与开源项目,更在Github上结交朋友,分享经验,增进能力。甚至这样的协作模式,还拓展到了编程领域之外,成为开放式协作的流行模式。

激励机制

第三代开源协作模式,以Github为代表,以Social Coding为精髓,这一代模式想要解决的问题,是激励机制的问题。

第一代开源协作,虽然创造了一批大大有名的项目,但事实上却是一个非常小圈子的事业。即使是最为成功的Linux内核开发,也不过1000~2000人。一旦人多事杂,就会出现管理混乱的现象。

第二代开源协作,虽然借鉴了很多企业界的规范管理经验,但是在事实上,却是不适应开源软件的风格的,举一个例子:在Redmine中存在的角色、权限、工作流之类的东西,实际开源项目使用的,却非常少。

第三代开源协作,借鉴了社交网络中的各种数值化模型,关注者数量,Star数量,Fork数量,Issue数量,Pull Request数量,都在显要位置标示出来,对于开发者形成正向激励,还有很多的统计图表,形象的展示了项目的活跃程度。

开源社区,原本就有非常深厚的,统计补丁数计算贡献度的传统,这一点在Github被发扬光大,可以说是优秀的继承与创新。

基于fork/pull request的协作机制

在github,一键就能够fork自己的分支,然后可以跟原有的分支毫无关联,也可以非常方便的提交pull request,这就带来了更加频繁的分裂,使得分裂常态化了。

原来的开源社区,开发者修改了代码,希望能够贡献给社区,需要穿越种种障碍,如果社区不接受,最后开发者只能逼不得已,自己开一个新的分支,变成一个新的项目。

在分裂是异常的状态下,分裂是罪恶的,是不应该的,是会带来阵痛的。当分裂变得常态化,pull request也变得常态化,分分合合,以每天N次的速度发生,恰恰因为如此,他不再是一种罪恶,而是一种健康的、向上的、以更快速度进步的模式。大家不 再是在一个版本下,各自贡献,而是在各自的版本下,独立发展,想分就分,想合就合。

Pull request,从一个代码合并的方式,变成了开发者之间主要的交流方式,他们发现,最好的交流,正是通过源代码来交流,一切的讲道理,都不如用源代码来讲道理。这恰恰是程序员们最习惯,也最喜欢的一种交流方式。

围绕Github出现的扩展服务

较之上一代的平台,Github提供了优秀的开放扩展机制:OAuth、API、SDK、WebHooks、ServiceHooks等等,使得围绕Github,扩展各种满足项目特定需要的服务,变得非常容易。

这就是从上一代平台的开源大社区,进化为「围绕Github的开源生态圈」。

到目前为止,Github一共支持超过170个不同的扩展服务,其中较为热门的服务有:

  • 与其他项目管理工具集成(Bugzilla,Asana, Basecamp,Redmine,JIRA,ZohoProject)
  • 与持续集成服务集成(Travis,Bamboo,CircleCI)
  • 与消息通知服务集成(Amazon SNS,Email,IRC,Jabber)
  • 与DevOps服务集成(AWS OpsWorks, DeployHQ)

Github 开放平台与API,基于Github OAuth API,其他网站可以支持开发者用自己Github账号登录,并使用一些有趣的服务。

  • Cloud IDE,用Github账号登录,直接在浏览器里打开一个IDE,编辑自己在Github上的开源代码
  • Resume Service,根据开发者在Github上的各种社交行为与开源项目贡献度,自动生成格式化的简历

这些扩展服务,极大的丰富了开源生态圈的内涵。

总结:社区天生就应该是社交化的,Social Coding与开源社区,简直就是天作之和。

五、开源协作模式的新探索

Git:作为标配

目前看来,git作为分布式配置库的王者地位,已经不可动摇了。能够初步总结的原因,至少有三个:

  • git与github互相促进,作为全球最大也最流行的开源社区,他的标配是git。这也导致越来越多的开源项目,选择git作为标配
  • 众人拾材火焰高,越是参与开发的人不断涌入,越是帮助git发展得更快。这是一个赢家通吃的世界
  • 开源生态圈的出现,使得围绕git、github发展出一大批相关的开源项目、开源工具以及次级社区。这一现象,在docker横空出世之后,再一次得到展现。

Code Review:必不可少

开源社区,一直有非常悠久的CodeReview的历史,哪怕在最早的mail & patch的时代,Review也是开源协作的头等大事。仅仅梳理Review的历程,也可以看到其中工具与流程的发展。

最初是邮件review,然后是在集成平台上内置review功能,或者提供更强大的review插件。到github创新的提出pull request,则是一种更加方便有效的review模式。

与此同时,独立于集成平台的专门的code review工具,也开始发展起来:Review Board、Google Gerrit、Facebook Phabricator是其中重要的几个代表。

Workflow:百花齐放

在git逐步流行之后,大家发现基于git可以选择的「玩法」实在是太多了。从最初写下一行代码,到最终出现在项目发布的版本之中,期间可以有无数的「路径」。

在git-scm.com官方教程《ProGit》里,提及了三种:集中式工作流、集成管理员工作流以及司令官与副官工作流。

在蒋鑫的《Git权威指南》里,又提及基于TopGit、基于submodule、基于subtree、基于repo、基于gerrit、以及git与svn配合使用的不同工作模型。

再后来:GitFlow、Github的Pull Request、以及基于Github的Github Flow等等工作模式,堪称百花齐放。

为什么会出来这么多workflow?因为团队与项目的差别,实在太大了。现在到我们简直无法想象:那些在各种情况下都坚持使用SVN都开发者,是怎么熬过来的?

当然,从另一方面来说:选择太多,也会带来另一种烦恼…

CI、CD、DevOps

从Everything as Code到Everything Automation,是另一个越来越明显的趋势。前两天,我从机场出来,正好看到两个并列的广告牌,一个广告的大意是:「UPS助您打通全球供应链」、 另一个则是「中国银行助您打通全球供应链」。这真的很有意思,看来在各行各业,大家都开始在关注整个生命周期的各个环节之间的打通。

只是,在软件领域,我们会感觉到这是一种回归。毕竟,最初的软件开发,都是很简单的。在一台计算机上,自己写程序,自己编译,自己调试、运行,最后发布。既不用依赖他人,更不用等待什么流程。

随着项目越来越复杂,参与的人越来越多,我们的软件,不能仅仅运行在自己的机器上,或者需要部署到服务器上,或者需要发布到某种平台上。在协作者众多的情况下,如何分工合作?
在开发者水平参差不齐的情况下,如何保证质量?在分工、协作、流程与质量保证的要求之下,如何提高效率?

这些都是DevOps致力于解决的问题,也是DevOps不断得以发展的原动力。

总结:开源社区,始终在进步,Github代表的也只是「一代」而已,新的一代协作模式,还会被创造出来的。

六、暗线:工具、习俗背后的逻辑

过去是如何?未来又会怎样?想要回答这类问题,其实需要更加深入的思考:「开源社区的协作模式,为何会变?变化背后的逻辑是什么?」

开源社区研发工具的两大目标:降低门槛,提高效率

开源社区,与普通的软件开发最大的不同,就是参与者多多益善。在《大教堂与集市》中,Eric Steven Raymond总结到:「如果开发者协调者有至少一个像Internet这样好的沟通媒介,并且知道如何不靠强制来领导,那么多人合作必然强于单兵作 战」,这简直就是绝妙的预言。虽然当年的ESR也许并未预测到,基于Internet会出现那么多辅助开源的相关工具(他们当时还只有邮件列表)。

所以,开源社区一直在致力于两个看上去相反的目标:「吸引尽可能多的人,以尽可能简单、便捷的方式,参与到开源中来」、「在人多得超乎想象的情况下,依然能够保持,甚至不断提高效率」。

如何计算参与者的贡献?

开源社区,不会给参与者发工资,因此激励是一个大问题。公平、公开、公正大计算所有参与者的贡献,以所有人都能够接受都形式,计算并公布各种排行 榜,可以说是开源社区特有都「刚性需求」,因此SNS与开源社区的结合,成为必然。以后,面向开源协作的大数据分析,也一定会出现。

如何激励、吸引、回报参与者?

计算参与者的贡献,仅仅是公平激励的基础。让激励变得有趣,变得有价值,变得有意义,则是吸引与回报参与者的不二法门。因此:游戏化的思路,会被越来越多的引入到开源社区中来。

如何保障项目质量?

开源项目保障项目质量都最大利器,是引入数量众多都热心测试者。但是,仅仅有人愿意测试,主动、积极都帮助测试,已经越来越不够了。随着项目越来越复杂,开源项目必须逐步走出仅仅依赖肉眼、依赖人多+运气的质量保障模式。

自动化测试、以及更加规范的Review流程,则是必然出现,而且将越来越重要的环节之一。

如何协调一致的工作?

自由与规范,计划与变化,兴趣与责任。经常会在社区里,成为争论的热点话题。虽然在《大教堂与集市》中,ESR极力鼓吹「礼物文化远远胜过交换经济」,但是:「在一个庞大的社区,各种各样的事务都需要有人去完成,而且还不能漫无章法。」

因此:「某种调节手段、协调者与协调机制、甚至是看不见的手」之类的东西,会慢慢的回到社区

如何在社区里平等、高效的协商?

目前来说,依然只能是线上讨论+线下开会。虽然,很多开源社区,开始学习《罗伯特议事规则》这样的开会圣经。但是,开会依然是最令程序员感到苦恼的事情。在这方面,将来会不会出现更好的辅助工具,这方面很值得期待。

结束语

唯有变化,是不变的。开源协作模式,同样如此。惟愿我们,能够成为推起其前进的力量之一。

转、进、定——我的2014

看着很多朋友,都纷纷在总结回顾自己的2014,我也试着总结一下吧,原本想按照往年的传统,选一个年度汉字的,结果思前想后,发现至少需要三个字,才能表达这一年的林林总总。

一、转:这一年我有三大转变:

  • 加入华为,而且干满一年了;
  • 开始跑步,而且喜欢上跑步了(不是坚持,就是喜欢);
  • 彻底离开知乎,而且真的戒掉了;

二、进:这是我进步非常大的一年,因为在华为的工作与开源有关、与研发有关,我思考了很多、很多,也有了很多的收获。

在多年以后,也许会有人评价,2014年是华为的开源元年,而我们则是这一重大变革的亲历者。

从这个意义上来说,我感到非常自豪。

三、定:从而立到不惑,慢慢的就能定下来了

40不惑,无非是心有定见,眼看马上就要39了,我仔细思索了一下自己的心路历程,渐渐的感到:自己的想法,已经很少左右摇摆,虽然心态依然开放,但判断却很少犹豫,这大概就是一种不惑吧。

最后,祝愿所有的朋友,新年快乐,万事如意!身体健康,阖家幸福!