社区规则和潜规则

一、开源的前世今生

1、从考古学的角度，来认识历史

《第五次开始》这本书是由一名考古学家写的历史书，其中不是只写了考古学，而是从一个考古学家的角度，看待历史的发展。比如，很多历史学家在描述一件事情时，会用到“有史以来......最......的一个......”，然后这名考古学家会说，“你们历史学家说的最多也就几千年的事情，所谓有史以来也就最近几千年发生的事情，但是咱考古学家是以上万年为起点...”。因此这本书从600万年前开始阐述，将600万年的历史，浓缩成一本仅有280页的书籍，且专为普通读者所著，其中精彩程度堪比《人类简史》。

为什么要叫做《第五次开始》？该书描述的是五段人类的发展史，如何给人类发展史进行断代的问题：

1）第一次：“技术”让人类从动物界胜出。通过考古，发现人类开始使用某种技术，比如开始使用火，或者开始使用砍、砸器等工具，在这些考古遗迹上可以发现人类和动物已经不一样了，人类从动物界中脱颖而出，成为能够使用工具、驾驭技术的一群动物，这也是“人”的诞生。

2）第二次：“文化”让人真正成为人。在考古学里，开始发现很多遗迹里存在各种图腾、绘画以及雕塑等，这些东西表明人不仅仅是人，也在追求文化上的东西，记录自己的生活，观察自然甚至崇拜自然，这时，“人”变成了真正的人，“文化”因此诞生。

3）第三次：“农业”让人类从游猎走向定居。这时开始从农业耕种的遗迹上可以发现有种子、农田，甚至有育种的痕迹，这些都表明人类从游牧狩猎采集走向了定居的生活，因此可以看到家、洞穴、房子以及城堡等。

4）第四次：“国家”让文明打上不平等、暴力与战争的烙印。国家是怎么出现的呢？通过考古遗迹发现巨大的城池，也发现了攻防、战争、暴力、武器等的印记。在这样一个过程中，人类已经跟原来不一样了，开始从小型的部落走向了国家，而国与国之间的战争也随之而来。

5）第五次：正在发展中的“全球化”。该部分也是作者描述最多的部分，如果现在再去看考古遗迹，尤其是最近500年，会发现很有趣的现象--原本在更早期的历史地层里，很多东西是局限在当地，比如这种种子只会在当地出现，这种动物化石也只会在当地出现，不会在很远的其他地方出现，但是近500年，世界各地的创作物已经不再局限于一个区域，比如一艘沉船，打捞之后发现里面有世界各地的创作物，陶器、瓷器、丝绸、香料等，这也就说明，整个世界的各种各样的物质、文化、人造物等都开始在全球化流动。

那第六次开始，会是什么情况？

作为一个IT从业人员，我会认为“第六次开始”对考古学家可能是一个悲剧，因为从考古学来看，总归是可以挖出点遗迹来作为证据，但到了第六次，我们会发现很多重大历史事件，不是发生在物理世界中，而是发生在网络数字空间里，当然如果将来考古学家能够进一步努力变成数字世界的考古学家，在网上进行考古则另说。所谓第六次开始，相较于前面五次开始完全不同，前面所述的打引号的考古证据将变成数字化，这是我们的世界真正开始变得不同的一个起点。

2、从社会学的角度，来认识世界

《社会变迁》这本书是1922年美国社会学家 W.F.奥格本 所著，由我国著名社会学家、人类学家费孝通和王同惠翻译，本书讨论了社会是如何进行演变。《第五次开始》说的是时间跨度非常大的以万年计的阶段性变化，但近三四百年，甚至近二三十年，社会的变迁越来越快，不能再只靠考古学进行研究，因此社会学派上用场。社会变迁作为一种文化现象，讲述了发明是如何产生的、每一个发明之间是如何积累起来的、发明是如何传播出去的，以及发明是如何让这个世界变化得越来越快。

在古代传统社会中，人的流动性很少，社会与社会之间互不相通，东西方之间很多年都处于相互不了解的状态，各自的圈子就相当于一个个小泥潭，很难想象能从一个泥潭跳到另一个泥潭里，但当人开始流动，就好比泥潭活化融合逐渐变成池塘，当圈子里发生一件大事，就像往池塘里扔了一颗小石子，消息就会如涟漪般逐渐往外扩散，等池塘与池塘也联通之后，整个世界就成了一个地球村，在这个地球村里，任何一个发明都会以飞速的方式传播到全世界，再到有互联网之后，世界上的发明产生得更快 ，传播的东西除了技术、发明、创新等本身之外，还有一项东西也进行了传播，即产生技术、发明、创新等背后的方法论。

不难发现，这种事情在开源领域非常明显，开源首先是一种源代码开放的技术，当代码一旦开放出来，再加上互联网的加持，全世界就能够马上看到并且使用它，因此技术发明创新的传播速度非常之快，同时开源也是一种开放式协作的方法论，这种方法论能帮助任何一个国家、社会的每一个领域，让全世界以更加开放的方式进行协作。可以预期的是，未来的十年或者二十年的变化一定是越来越快，而在这过程中，开源是最核心的主导力量。

3、开源出现之前

1946年，第一台计算机诞生；1960年，小型计算机（PDP-1）诞生；40年代到60年代间，是小型机、中型机、大型机的时代，这个时代最大的特征是大多数人都买不起计算机，而有能力购买计算机的都是机构，或者是大学，比如五角大楼、麻省理工、哈佛、耶鲁等，聚集了大量的科研人员，我们对这些科研人员有一个尊称“Computer Scientists”（计算机科学家），对于他们来说，代码是科研产品，或者是科研交流的必备物品，就像交流学术论文发paper一样，需要将代码发出来，因此代码的交流是自然而然的，丝毫不考虑copyright、license以及挣钱等事情，在这种时代，代码在世界上自由流通，但还没有开源这件事。

在那个年代，也有发生一些事情。当时麻省理工大学有一个俱乐部，叫铁道模型俱乐部，该俱乐部有个小组叫信号与控制小组，这个小组一开始只是计划控制火车，让火车在他们搭建的铁路模型上更好运行，能够控制启停、转弯、换轨道等诸如此类的信号控制，直到有一天，这个小组拿到一个新玩具，这个新玩具就是一台PDP-11这样的电脑，这时，对他们来说这是最新鲜、最有趣的玩具，火车的好玩程度远远没有计算机的好玩程度大，但这个玩具特别特别贵，对于学校来说，这是属于学校的宝贵资产，一定得有人看护，因此产生了一个尖锐矛盾：学校教授/管理机构严格控制对计算机的使用，使用得预约时间，不在预约时间内不允许使用，这对于这个小组来说非常痛苦，竟然不能一天24小时，一周7天，7*24小时的时间都在那里玩？！竟然还会被赶走？！因此黑客伦理的第一句话就是：对计算机的访问（以及任何可能帮助你认识我们这个世界的事物）应该是不受限制的、完全的。任何人都有动手尝试的权利！

剩下五条黑客伦理分别是：

-- 所有的信息都应该可以自由获取。

-- 不迷信权威——促进分权。

-- 评判黑客的标准应该是他们的技术，而不是那些没有实际用途的指标，比如学位、年龄、种族或职位。

-- 你可以在计算机上创造艺术与美。

-- 计算机可以让你的生活更美好。

这就是一群爱玩、爱闹、爱钻研、爱探索的大男孩黑客给自己规范的伦理，他们认为这样才是正确的做法。

4、软件行业兴起

1975年，IBM发明了PC，到了1976年，苹果发布了Apple I，这时个人计算机、微型计算机开始兴起，大多数人咬咬牙也都能买得起了，因此产生了一大群爱好者，他们有一个很大的乐趣，就是互相之间交换盗版拷贝程序，也因此激怒了另一个人——比尔·盖茨。比尔·盖茨是微软的创始人，微软当时成立没几年，做了一个非常著名的软件叫BASIC，比尔·盖茨发现，很多人在用BASIC，但是销售量并不好，也就是说大家都不是付钱给他，所以比尔·盖茨写了一封公开信——《写给电脑爱好者的公开信》：有谁会在没有任何报酬的情况下来做这些专业的工作？什么样的爱好者可以为他的产品投入三个人年的开发时间，并且发现所有的错误、编写文档以及免费发布这个产品？这段话非常符合资本主义商业伦理价值观。

到1980年，美国的版权法修改，软件开始有版权，软件行业开始兴起。回顾之前那段历史，不能再说微软是商业魔头了，而是正因为有了这样一群商业软件公司，才能通过这些公司实现写软件赚钱的路径，现在才会有上千万的程序员，而如果仅仅只是一群爱好者，那么现在程序员的数量可能就只有几万个。

事物总是存在两面性，在软件行业兴起之后，不可避免的有人受到了伤害。Richard Stallman，被人称之为“最后一个黑客”，那时他正在MIT的人工智能实验室，与朋友一起研究UNIX，但当商业软件公司成立之后，各自将软件闭源，UNIX也不例外，Richard Stallman再没有了原来的幸福环境——能够一起写代码然后彼此交换代码，不断探索计算机能力。因此在1985年，Richard Stallman发表了GNU宣言，即GNU’s Not Unix，大致意思是：我不是要做一个UNIX，但是我要做一个完全自由的UNIX。而且他还提出了Copyleft的概念，同时开发出很多GNU的相关工具，包括Emacs、GCC等工具。1990年，Linus Torvalds在芬兰赫尔辛基大学读书期间，开始开发Linux，1991年发布最初版本，并飞速发展至今，而GNU和Linux两者之间结合非常紧密：从1983年开始的GNU计划致力于开发一个自由并且完整的类UNIX操作系统，包括软件开发工具和各种应用程序，到1991年Linux内核发布的时候，GNU已经几乎完成了除了系统内核之外的各种必备软件的开发，在Linus Torvalds和其他开发人员的努力下，GNU组件可以运行于Linux内核之上，整个内核是基于GNU通用公共许可，也就是GPL(General Pubic License)。

1991年，Linux发布了第一个开源版本，通过互联网聚集了大量的志愿者，没有严格的质量标准，没有强有力的机构协调管理，每周进行发布，然后接受反馈，通过不断迭代，在1993年底，Linux在稳定性与可靠性上，已经与很多商业UNIX不相上下，并能支持比商业UNIX多得多的软件，也就是说兼容性及可扩展性都非常的强，于是很多小型的UNIX供应商倒闭，且原因是显而易见：供应商的操作系统需要收钱，现在有免费开源版本，源代码都可以获得，而且这样一个操作系统还越做越好，有越来越多志愿者愿意免费帮忙做事情。

1997年，大神Eric S. Raymond写了一本书——《大教堂与集市》，最开始不是一本书，而只是一场在Python的大会上进行的演讲，就“开源是什么”这个主题展开，讨论“为什么会有这么多人一起做开源？这么多人来做开源，还能够把事情做成了？”。《大教堂与集市》一经发布，一纸风行传遍天下，被称之为开源运动的“圣经”，彻底颠覆传统软件开发思路，影响着整个软件开发。这本书最重要的两个要点：

1）大教堂与集市，这两种软件的开发模式到底有什么区别？在Linux这种开源的操作系统诞生之前，绝大多数的软件开发模式都是大教堂式，或者称之为瀑布模式，意思是从最开始，有一个总设计师，一层一层把工作任务分解下去，分门别类、分工合作，最后将事情做成。然而到了集市模式，好比一群人跑到集市上，一个人贡献点东西，另一个人也贡献点东西，看上去没有明确规范，没有很好的协调开发方式，但却能把事情做成，而且带来更多创新与可能性，这颠覆了传统软件工程模式。

《人月神话》中有一段描述，当有一群人，在做一个项目的时候，发现快要超期，这个时候有老板说我增派人员，是否就能缩短工期呢？然而这个时候的工期是无法缩短的，因为人多了之后，人与人之间的沟通成本会迅速上升，新增人力反而会被大量的沟通成本损耗，以致工作效率无法提升。但Eric S.Raymond认为，如果找到了好的工具，好的协作模式，以及好的技术手段，人越多效率越高、速度越快。这恰恰与《人月神话》是完全相反的，同时也是非常重要的贡献，给软件开发提供了全新的思路，但不是完全否定《人月神话》，而是集市化的开发同样是一种可能性，把一些原本没有想到的事情做成。

2）礼物文化。这也是《大教堂与集市》里非常重要的篇章，主要阐述的是为什么开源开发者愿意义务为这些开源项目做贡献。在当今这个物质丰裕的时代里，命令以及花钱并不会让他们听话，但是如果他们所做的这些事情，能够换来更多荣誉、地位以及社区影响力时，他们反而更愿意去做，正如原始社会里所看到的夸富宴，部落的酋长举办非常铺张非常奢华的宴会，通过这种夸富宴，酋长能够赢得在部落里的地位，同理，在开源社区里，当真正的大牛，写代码写得最好的人，向社区贡献最好的代码时，能够赢得社区里最好的地位，好比向社区贡献了礼物，相应就会收获尊崇。这就是一种礼物文化，也是Eric S.Raymond对开源世界的一种总结。

5、时间线

1983 年，Richard Stallman 发起了 GNU 项目；

1985 年，Richard Stallman发表了 GNU 宣言；

1989 年，GNU 通用公共许可证的第一个版本发布。1991 年GPL v2发布；

1991 年，Linus Torvalds 发起 Linux 内核项目；

1993 年，Red Hat 诞生；

1997 年，Eric S. Raymond 发表了《大教堂与集市》；

1998 年 1 月，网景公司宣布将 Navigator 开源；

1998 年 4 月， Tim O’Reilly 组织“开源峰会”，OSI成立；

1999 年 3 月，Apache基金会成立；

2000 年 10 月，Sun Microsystems 公司在 GNU Lesser General Public License 下将 StarOffice 办公套件作为自由软件发布。这个自由软件版本被重新命名为 OpenOffice.org，并与 StarOffice 共存。

2004 年 8 月，Ruby on Rails 发布；

2005 年 4 月，Git 发布；

2008 年 2 月，GitHub诞生；

2018年，IBM收购Red Hat，微软收购GitHub；

6、Free Software & Open Source 的区别

1）自由软件：任何用户都可以自由的运行软件、修改软件，之后再分发这些软件；

①自由度0：无论用户出于何种目的，必须可以按照用户意愿，自由地运行该软件。

②自由度1：用户可以自由地学习并修改该软件，以此来帮助用户完成用户自己的计算。作为前提，用户必须可以访问到该软件的源代码。

③自由度2：用户可以自由地分发该软件的拷贝，这样就可以助人。

④自由度3：用户可以自由地分发该软件修改后的拷贝。借此，用户可以把改进后的软件分享给整个社区令他人也从中受益。作为前提，用户必须可以访问到该软件的源代码。

2）开源软件的定义：

①自由再散布（Free Distribution）

②原始码（Source Code）

③派生著作（Derived Works）

④原创作者程序原始码的完整性（Integrity of The Author’s Source Code）

⑤不得对任何人或团体有差别待遇（No Discrimination Against Persons or Groups）

⑥对程序在任何领域内的利用不得有差别待遇（No Discrimination Against Fields of Endeavor）

⑦散布许可协议（Distribution of License）

⑧许可协议不得专属于特定产品（License Must Not Be Specific to a Product）

⑨许可协议不得限制其他软件（License Must Not Restrict Other Software）

⑩许可协议必须技术中立（License Must Be Technology-Neutral）

自由软件与开源软件最大的区别在于开源软件里第⑨条许可协议不得限制其他软件，相应自由软件也有一条相关条款，在GPL里面有说明：不能将自由软件，和非自由软件捆绑在一起，可以将自由软件卖钱，但不能捆绑非自由软件一起卖钱。因此两者之间真正的差异在于有没有妨碍其他人赚钱：自由软件崇尚的是自由，如果软件不自由，那么不可以捆绑销售，属于理想主义；开源软件不妨碍其他人赚钱，大家可以一起赚钱，属于实用主义。

二、开源世界的规则与潜规则

1、何为规则

①情：人情世故、基本伦理；

②礼：礼仪、礼节、礼物

③法：成文法、成文规范、授权协议

④code：代码限制、自动规则

2、何为潜规则

规则之前：在制定规则之前，比如我们有一个群，最开始这个群只有十几个人，所以没有什么规则，每个人都凭本能，大家在一起无冲突相处很好。直到群越来越大，人越来越多，开始有人在群里发广告，其他人觉得不太好，决定在群里定一个规则，这个规则可能有两种，第一种是只要发广告，一律从群里踢走；第二种就是有些群主比较开明，只要发红包就可以发广告，这两种方式都是一种规则。那么这种规则是怎么确认下来的呢？这就是所谓的判例法，就是一点点的积累下来，到后面潜规则逐渐变成规则。

概率生效：潜规则在还没有明确的变成稳定的、不可变更的规则之前，这些规则就是概率生效，即有时候有效，有时候无效。比如某人在群里发了个红包，群主说以后不允许发红包，但下次这个人还在发红包，而群主又不再说他了，可能是群主忘了，或者群主在忙，或者这个人是群主的朋友，情况很复杂，各种原因导致群主不一定会把这个人从群里踢掉。

概率公开：有些时候，某个人前几天还在群里，后面就被踢掉了，群主也没有解释原因，可能是私下处理，或者群主私底下另外找个理由说这个人行为不端，总之就是踢掉了。这都是潜规则的一种表现，这个规则并没有被公开执行，也没有被公开解释。

各自解读：在一个社区里面有很多小圈子，这些小圈子会各自揣摩，为什么这个人可以这么干，那个人不能这么干呢？大家就会进行解读，可能这个人的贡献比较大，所以大家对他比较宽容，也可能是管理员的朋友，所以大家也不好意思多说什么。

诸如此类的这些都是潜规则的一种表现。

3、何为社区

最早的时候，一群志同道合的人组成一个社区，来共同创造一些东西，然后逐渐完善这个作品，这个作品可能是一个开源项目的一个版本，版本发布之后，吸引了更多对这个项目感兴趣的人来到这个社区，他们可能只是看看，也可能是试用，甚至有可能会参与贡献，总之社区的人越来越多，原来比较少的一些规则，或者不成文的规定、潜规则就不太够用，于是大家开始一起完善这些规则，进一步明确志向：之所以要定这些规则，之所以大家团结起来一起做事情，那我们的志向是什么？我们的目标是什么？在这个过程当中，通过不断的凝聚共识，社区变得越来越成熟，才会越来越健康地发展下去。

4、普通伦理与社区伦理

普通伦理：己所不欲勿施于人；君臣父子，长幼有序；仁义礼智信等

社区伦理：黑客伦理。特别强调不迷信权威，评判标准不看地位，而看实际的贡献，强调有所追求，创造艺术和美。

社区伦理中的两个现象：人人平等与精英治理。人人平等不是指每个人都有同等的权重，而是每个人都有平等的机会，是一种机会平等，好比在一个社区里，每个人都可以点fork，当做了某种修改以后，每个人都可以发PR等，这些机会是平等的。至于别人会不会接受你的代码呢？会不会接受你的贡献？提的一个issue会不会有人理睬？这些并不是平等的，社区看ID，如果某个ID大家都见过很多次，彼此都很熟悉，那么会有更多的人关注这个ID的言行、发布的代码、提的意见等，这个背后就是所谓的精英治理，即一个人在社区的贡献越大，他的话语权就越大，虽然这个权重可能不会体现在某些数量上，比如大家来投票，但是他一个人有5票，这是不可能的，但事实上，他的投票会有更大的示范效应，因为社区里的投票是公开的，如果他率先投票，他在社区里有很大的号召力，很多人可能就会跟他投一样的票。精英治理跟人人平等并不矛盾，相当于一个硬币的两面，两者是结合起来的。

5、社会之礼与社区之礼

礼仪方面，社会上有很多的婚丧嫁娶的礼仪，到了社区里就有面基大会，比如线下的技术大会等，能够跟更多的朋友一起聚一聚聊聊天。

在待人接物方面，社会上讲究为人要有礼貌，说话要有道理，不要乱说话，不要口出恶言。在社区里，大部分时候都是在网络上进行文字交流，但提问也有艺术，一开口就是：“急！有个问题谁能帮我解答一下？”，这种提问方式就不太建议，好的提问一定是描述的很清楚，过程条理清晰的列出来，然后再提问求助，而不是如上述显得很着急的样子。

社会上强调礼尚往来，而在社区里有礼物文化，在社区里，给的礼物越重，别人越会觉得这个人是个高手。同样社区里也会有礼尚往来的现象，比如某个人在社区里用到了很多好的东西，好的软件，好的代码，然后认为自己有义务贡献回馈给这个社区，这本质上也是一种礼尚往来。

6、社区中的成文法

社区里面有很多的成文法，谈及最多的是License（许可证），以及商标法、社区的章程、知识产权保护、隐私保护等，在社区里，但凡涉及开源跟软件相关的法/条款/合同/约定，都是成文列出来的，甚至比如说code style（代码风格），很多社区都非常重视，会将要求列出来，让社区内的人按照相应方式来写代码。这些都是社区的成文法，是大家需要遵从的规则。

7、社区中的自动化规则

1）Code is Law：通过代码方式，自动执行的规则。

2）BBS问答社区的积分规则：之前我在的一个社区叫ITEye，它是一个BBS问答社区，这个BBS背后有一个积分规则，当有人回答了一个问题，或者发了一个帖，或者回了一个帖，其他人会点赞，有向上的大拇指，也有向下的大拇指，基于规则相应会被加分或者被减分。随着被加分和被减分之后，个人积分发生变化，随之这个社区里面的等级也会变。当年在ITEye的时候，刚刚入门时是一颗星，到五颗星，然后是一皇冠到五皇冠。积分最高、权重最大的就是五皇冠，当时有一个规则——如果有一篇帖子，大家都觉得写的不好，那么会给它投大拇指向下的投票，如果得了20票，这篇帖子就会从普通的板块被扫到垃圾桶，而五皇冠的权重是一个人能投19票，再有一个人加一票，则这个帖子就进会垃圾桶。

3）Github 的自动化规则：Action、Robot、 Issue & PR Template 等，也是通过代码来做自动化执行，而这些自动化的规则会成为社区运作的一部分，如果有人在社区里提交代码，或者参与贡献时，会有机器人在下面留言，提醒需要注意的内容，或者需要签署一个 CLA。

4）Gerrit 里的 Code Review规则。

8、社区中的潜规则

1）社区里的人设

①莫得感情的发帖机器：在群里只发广告/文章，这类人完全没有把自己当成这个群或者社区的一份子，而只是将群当成一个传播渠道，这种只是转发文章的方法实际非常低效，很多人都非常厌恶这种方式。

②杠精体质：有些人有事没事喜欢杠一句话，以显示自己的存在感，或者认为这样能更显得自己知识渊博。对付杠精的方法就是不理会，你是杠精你说的都对。

③大妈体质：这种人设非常好，社区“大妈”会帮忙张罗很多事。社区里多多少少会有一些琐事，需要有人去做，任何一个社区都需要这样的“大妈”人设，或者叫扫地僧。

④其他……

2）规则的宽容度：

①对于新人，社区可能会更加严厉

②贡献越大，越不容易被惩罚

3）社区内部的沟通渠道：社区内有人打小报告这个事无法避免，同时社区内部除了公开的渠道外，还有很多小圈子，这也是社区里常见的现象，总会有些更合得来的朋友，一起拉个小群聊点别的事情，这种沟通渠道都会存在。

4）社区运营者的直觉：对于社区运营者来说，需要有对社区发生事情的敏感度，因为社区运营者不可能出现在每一个小圈子，不可能了解任何一个小群，知道任何一个圈子在讨论什么，但得有直觉，能清楚知道社区内到底发生了什么事情，当前社区的氛围如何，是否健康？讨论是热闹、热烈、激烈，还是剧烈的争论？是否已经有崩溃的预兆？社区运营者必须有这些敏锐的直觉。

三、开源世界里的人设与个人成长

1、个人参与开源的价值

1）如何让一个孩子痛恨学习？

强迫他学习就好。有一次我去游泳时，发生了一件这样的事情——一位妈妈带小孩在游泳，小孩才刚刚开始学，所以怕水不敢游，但妈妈言辞间非常严厉，要求孩子一定要踢水，一定要把头闷下去，一定要学会换气等等，导致小孩一脸苦相，最后跟妈妈说不想游了。那天游泳回来以后，我最大的感受就是：如果想让一个小孩痛恨游泳，那么只需要像这位妈妈一样，强迫他游泳。

2）英语学渣，如何精通十国外语？

找到“享受学习过程的方法”。有一个号称是英语学渣的人，却精通十国外语，他为何能学会这么多门外语呢？通过他在TED上的分享，了解到他并没有要求自己今天一定要学这门语言，今天一定要背10个单词等这类强制学习计划，而是一直在寻找一种方式让自己享受学习，当出现倦怠时，再发明一种新方法再去学，让自己一直保持在享受学习这个过程。

这种方法在开源上特别常见。

3）Linus关于生活的意义的“理论”：

①首先是生存，人类做事，最基础的动机，就是为了生存。

②其次是社会关系，有时候也会被称之为“秩序”。无论是为了维系社会关系，还是为了维持社会秩序，这都是重要的动机。

③最后是娱乐，或者说乐趣，在 Linus 看来，这才是动机的最高境界。

到底是什么力量，支撑Linus开发了30年的Linux操作系统？

Linus：“我本可以在1991年底就收手不干了，因为那时我已经完成了大量有意思的工作......幸好接下来发生了两件事，我才有了继续下去的动力：第一，我不小心损坏了Minix系统的分区；第二，人们不断给我发来反馈意见。”

敢吹牛的人，才能成为技术大牛

Linus Torvalds在1991年发了一个邮件：我在做一个开源的操作系统…这其实是在吹牛，但别人都觉得很厉害，竟然有人做了一个操作系统！感兴趣的人蜂拥而至，提 Bug报告、需求、补丁等等，在这个过程中，Linus也得以成长，成为一代大神。

这就是个人参与开源能够得到的一种价值。

2、个人成长的正循环

1）创造：在创造的过程中，产生真实的练习目标。

2）刻意练习：在练习过程中，找到越来越多的乐趣。

3）乐趣：在获得乐趣的过程中，产生创造的冲动。

开源社区作为个人成长的催化剂。举个例子，比如我想做一个操作系统内核，但发现做不出来，不懂的东西太多了，但我发现可以通过学习与刻意练习，积累做操作系统内核的能力，最后真的把操作系统做起来了，而在这个过程中，因为学到了不少东西，从而获得越来越多的乐趣，这个乐趣指引着我去创造更多，于是想将0.1版做到0.2版，再做0.3版，然而进一步的发现我需要学更多的东西，否则后面版本做不出来，再次通过学习...而这个过程就是个人成长的正循环：可能一开始只是想做一个自己玩的小玩具，到最后却让自己变成了大牛。

3、如何在社区里树立自己的人设

1）本色出演：建议本色出演，因为不可能装一辈子，本身是什么样就是什么样，假装成另外一个人是不真诚且不长久的行为，且人设崩塌往往就在一瞬间，总会有说漏嘴、说错话的时候，做自己最重要。

2）不卑不亢：大牛确实很牛，但是在见到大牛时，不需要卑躬屈膝、跪求大牛，只需要正常平等与其交流，比如“我有一个问题，请问能否帮我解答一下？”这种自然平等的对话即可。

3）努力成为有用的人：不论在哪个领域，打杂、写代码、提BUG、做测试、做宣传、做翻译等任何社区需要的事情，只要愿意去做，一点一滴地贡献，社区会逐渐将其定位为在某种情况下能做这件事的人，或者发现这个人这也能做，那也能做，是个多方面人才，这种人设一旦定下，很多时候社区在遇到其他事情的时候也会想着找这个人问一问，这个是否也能解决？

社区规则和潜规则（二）

一、为何要为开源贡献力量

在 [自由代码] 下工作，让我学习到了职业生涯中非常重要的技能，无论是大学还是实际的工作，我认为从开源项目中得到的收获的远大於我的贡献！ — @errietta , “我为何是如此的热衷于为开源软件贡献力量”

为开源贡献力量，得到的回报就是能够学习到很多、受教很多、且能够锻炼任何你能够想到的经验。 为什么会有人为开源做贡献？这可能是很多人都不明白的地方，这里不妨列出一些！

1、巩固现有技能

无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动，只要有实践的愿望，总能在开源项目中找到位置。

例如，作为一个学生，在一个项目中实习，一般不会参与到核心代码的开发，因为实习生很难能够直接进入生产环境的开发，对于公司的业务不熟悉，代码的技能不够，对架构的理解也不够，因此研发管理者不会让学生立马进入（特别优秀者除外）。 如果希望很快进入到生产环境中，则需要很多编码经验，尤其是与生产环境相关的开发经验，但在公司之外，很难有像开源这样更好的一个机会。因为现在开源出来的代码，在国内环境上，一些平台的代码是其生产上已经使用的一些项目、代码开放出来，通过此参与到这些代码中，无论是文档编写还是代码编写，都会从中学到很多，这能够让一个新手很快的接触到生产环境上的一些东西，能够理解业务上的问题。

对已有开发技能者来说，这也是一种学习方式。例如做后端开发者，想学习前端的内容，不论是Vue，还是React，或是CSI 4等，通过参与开源软件、学习开源软件，能够快速了解前端代码如何去写。

参与开源项目，不论是新手，还是已经掌握了一定开源技能但需要拓展更多技术领域者，或是学习更好的业务实践，这都是一种很好的方式。

2、遇见那些和你“臭味相投”的人

开源项目一般都会有一个和谐、热心的社区，以让大家团结一致。实际上，开源界经常发生这样的情形，很多人的深厚友谊都是通过共同参与开源所建立起来的，至于具体的方式，可能是在一次技术研讨会上相谈甚欢，也可能是一直在聊天室中探讨问题。

在社区里，能够相互交流是建立在对项目有共同兴趣的基础之上，且每个参与相同开源项目者的技术背景具有一定的相似性，因此在交流问题时能有共同语言。在社区里能够找到一些有趣的人，通过此来拓展人脉关系以及社交。

3、寻找导师，并且尝试帮助他人

和他人共同在一个共享的项目下工作，这意味着需要向他人解释清楚自己是如何做的，同理，也需要向他人求助，询问别人是如何做的。相互学习和彼此教学对于每位参与者都能满载而归。

现在很多开源项目，都有导师机制，有些导师可能提供的是方向性指导，有些则是实际指导，但无论如何，都是有一定帮助的。

同时在帮助其他人时也能够更好地理解该项目，当有人提出问题，在深入思考他所遇到的环境及面临的事情后，再帮他解决问题，能学到更多的东西。因此不论是得到他人的帮助，还是帮助他人，都会有所收获，同时在社区能够建立一个更好的人际关系。

4、在公众间建立你的声誉（职业口碑）

根据开源的定义，你在开源下所有的工作都是公开的，这也就意味着开源项目是一个很好展示你实力的地方。

当参与到开源中，有更多的演讲机会时，会在公众间建立口碑。现国内很多工作者会以“参与了某些开源项目/是某个项目的maintainer”为标签，包括一些公司在招聘时，都会选择在例如Apache等项目里作为maintainer，因为当他在公司内部从事某项工作时，是无法得知他的工作情况（代码不开放），但在开源项目设计中，只要参与过，就会留下足迹，因此在开源设计里就能很清楚的知道这个人的技术能力、架构能力以及为人处事方式等，以此来匹配团队岗位需求。

5、学习领导和管理的艺术

开源为实践领导力和管理技能提供了很好的机会，比如解决冲突、组织团队、工作的优先级排列。

其中存在一定条件，因为开源项目是一个分布式且是异步的模式，不是像在办公室内，能够面对面进行交流、沟通问题。开源项目是由不同的公司、不同的人参与进来，因此需要协调每个人在技术上、方向上的问题，保证项目的发展，这一点会比办公司管理更为困难，当然也存在优势，开源项目中的人彼此之间没有太多的利益关系，因此不会经历一些办公室内存在的斗争与纠纷。总之，如果能在社区里领导一个大型项目，那么其管理能力就是非常不错的。

6、鼓励作出改变，哪怕改变是很微小的

在开源的世界里，作出贡献的不一定非得是花了很长时间拥有大量经验的人。你是否遇到过浏览某些网站发现有拼写错误，希望有人能修改它？其实，在开源的项目中，你只需要做就可以了。没有那么多的顾忌，开源让人们在很舒服的状态做事，而这才是这个世界应有的体验。

这一点也是开源的精髓。在开源事业里，不论做了很多事，还是做的很少，包括帮他人改过文档，甚至是只改过错别字，也包括在社交媒体场合中讲述一个开源项目，虽然可能没有在编码上作出贡献，但以上这些都是对他人的贡献。

二、贡献的具体含义是什么

如果你是一名开源界的新手，可能会对贡献的流程心生畏惧。比如：该如何找到正确的项目？不懂编码又想参与怎么办？万一做错事情了怎么办？

其实没有关系的啦！条条大路通罗马，开源项目有太多的路径可以参与！

比如说可以做一些logo的设计，也可以参与文档的编写，也可以做测试类的工作，或者组织一些活动等等。例如国内开源社的理事林旅强是一个非常熟悉开源合规方面的专家，他参与组织了很多社区的活动，这也是对开源的一种贡献。正如上述，在邮件列表回复他人，或者给其他人发链接，指引他如何去做等，这每一件事情都是在帮助他人，开源社就是一个很典型的例子，开源社热衷于组织各种事件（其本身未持有代码，在技术层面也未曾领导过某一方向），也支持其他社区区组织一些活动，为社区提供了很多帮助，比如说偏向于设计，或者整理一个风格指南，存在统一的视觉设计（类似于设计类工作），然后做出来之后会被其他的项目比如高斯、罗根等使用。

同样也存在喜欢写文档/新闻的人，这种有写作能力的人，会帮助开源项目的传播，这也是非常重要的一部份。很多项目很优秀，但是不为人所知（可能写这些项目的工程师，其文化烙印较重，不喜欢公开交流，并且没有好的文章或媒体渠道进行宣传），因此为这些项目做贡献更容易，根据自身的特点，然后决定去做相应的事情，比如组织活动等，或者编码等多件事情。

因此做开源软件帮助其他人时多方面的，不一定是开源，也不一定是软件项目。例如国外会有一些课程，这些课程也是开源的一部份，虽然没有编码，但课程会传授如何学习操作系统；比如一些面试题，在网上有 Rust 解答 LeetCode 题目的内容，这些题目的解析也是开源的一部份。

开源是文化精神，是一种理念，而非行动准则，不是一定要做某件事情才称之为参与开源/开源贡献，而是有这种精神、想法，知道自身工作内容是什么，这就是参与开源。

以下是一些实用的技巧，帮助你快速的获得经验。

1、你不具备编码的能力

对于为开源做贡献常见的误解就是：为开源做贡献必须得提交代码。事实上，代码固然重要，但是项目中不需编码的重要部分 经常被忽视 。你若做了这部分，对于项目来说可是莫大的贡献，而这根本就不需要什么撰写代码！

我被大家所熟知是因为为 CocoaPods 做了一些事, 其实大伙并不知道我实际并没有为 CocoaPods本身做了什么，我大多数的工作是诸如撰写文档、品牌宣传之类的。 — @orta , “默认迁移到开源软件”

即使你是以为开发者，非代码的贡献对于项目来说也是举足轻重的，尤其是对于社区的其他成员来说。用心维系这些关系能够让你有工作到项目其它部分的机会。我第一次接触Python开发团队（简称 python-dev)是在 2002年6月17日，当时我是向其邮件列表发送了一份邮件，是关于请求通过我的补丁的。我很快就又发现了开源的bug，于是决定开始为小组收集邮件摘要，然后他们给了我一个澄清问题的理由，但是更加重要的是，我能够捕获到某人指出需要修复的问题。 — @brettcannon , “维护者的故事”

2、是否热衷于规划事件？

  • 为项目组织研讨会或线下分享， 一如 @fzamperin 为 NodeSchool 所做的那样

  • 为项目组织大型会议（假如它有的话）

  • 帮助社区成员寻找合适的技术会议，且帮助有实力的成员提交演讲的拟稿

3、是否偏向于设计？

  • 重新布置布局以提高项目的可用性

  • 进行用户研究以重新组织和完善项目的导航或菜单

  • 整理一个风格指南，以帮助项目有一致的视觉设计

  • 创建t恤的艺术或一个新的标志， 就像 hapi.js 的贡献者那样

4、你是否热衷于写作？

  • 撰写和改进项目的文档

  • 能够以实例来展示项目该如何使用的

  • 为项目撰写新闻稿，或者到邮件列表高调布道

  • 为项目撰写教程， 一如 pypa 的贡献者所做的

  • 翻译项目的文档为本土语言

说真心话， [文档] 是非常重要的. 目前Babel的文档已经很棒了，这也是其杀手锏的特性之一。当然，还有一些章节需要大家的完善，即使是随便在哪儿增加一个段落都很感激。 — @kittens , “贡献者召集令”

5、你喜欢组织活动吗？

  • 链接重复的问题，并建议新的问题标签，使事物井井有条

  • 通过开放的问题，并建议关闭旧的， 就像 @nzakas 为 eslint 做的

  • 把最近开放的问题阐述清晰，以推动讨论

6、享受编码的乐趣？

  • 找到一个开放的问题并解决它， 就像 @dianjin 为 Leaflet 做的

  • 想一想你是否可以帮忙写一个新的功能

  • 自动化项目设置

  • 改进工具和测试

7、热衷于帮助他人？

  • 回答关于项目的问题，例如在 Stack Overflow（ 像 Postgres 的这个示例 ）或者 reddit 上

  • 为人们解答公开的问题

  • 帮助缓和讨论板或对话渠道

8、在编码方面是否喜欢帮助他人？

9、其实不必一定是软件项目！

尽管人们一提起“开源”二字，默认就是指开源软件，其实不尽然，开源可以是任何事情的修饰，而不仅仅是指软件而言的。比如图书、食谱、列表、以及任何可以开源的项目类。

举例来说：

尽管你是一名软件开发者，也可以去撰写一些文档去帮助新的入门者。其实项目中那些看起来令人生畏的项目并不是写代码，做开发者总得挑战自己，其实在做得过程中可以增强信心和获得全新的体验。

三、根据项目定位自我

如果你跟着了一条issue，还发现了令人感到困惑的事情，这很正常，不是你一个人这样。这些工具需要大量的隐式的知识，但是总会有人带着你熟悉这些，当然你要找他们问对的问题。 — @shaunagm , “如何为开源做贡献”

为开源做贡献，除了单词拼写错误之外，大多数时候就像是走在陌生人中间，浑身上下不适。这就像人们已经在西边讨论的非常深入了，你突然开始讲东，肯定会让人感到不舒服。

与其盲目的在项目中游荡，不如静下心来学习规则。这样反而会让你的想法被注意到，也会有人听到你的声音。

1、分析感兴趣的开源项目

每一个开源社区都是不一样的。

在某一个开源项目扎根多年，这意味着你只是对这一个开源项目无比的熟悉。若是切换到不同的项目，可能会发现完全是另外一回事，所谓的使用词汇、习惯用语、沟通方式都发生了变化。

然而，很多的开源项目还是遵循类似的组织结构的。理解不同的社区角色和全部的流程，可以很好的帮助你快速的切入新的项目。

一个典型的开源项目均会有如下类型的人：

  • 作者：项目的创始人或创始组织

  • 归属者：代码仓库或组织的管理员（不一定和作者是同一个人）

  • 维护者：贡献者，负责项目的未来走向和组织的管理（他们通常也是项目的作者或归属者。）

  • 贡献者：只要是为项目做出了贡献，就算。

  • 社区成员：那些实用项目的人们。他们或许是积极的讨论者，又或者是为项目的方向提出意见的人。

一个较大的项目，可能下面还会细分子社区，或者是针对不同的任务分成不同的小组，比如工具小组、分流、社区事务、以及活动组织等。径直到项目到web站点，找到“团队”页面，或者是查看治理文档，从而获得类似到信息。

靠谱的开源项目，一般都会有一个文档的，这些文档文件通常会在代码仓库的顶级目录列出。

  • 许可协议:根据开源软件的定义，每一个开源项目必须是有 开源许可协议 的。可以这么认为：假如说某个项目源码开放，但是没有任何的许可协议，那么它就不能叫做开源。

  • README:README 是一个介绍性的说明文件，对初次光临社区对人们表示欢迎，它通常会解释项目有何用处，为何发起，以及如何快速入门等。

  • 贡献:READMES 帮助人们来认识项目，贡献这个文件则是帮助对项目如何做贡献。它解释了目前项目需要什么样类型对贡献者，社区对流程是啥样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。

  • 行为准则:顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，帮助形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。

  • 其它文档:有些项目也许还有其它文档，例如教程、导游，或者是治理规则，这在大型项目中常见。

此外，开源项目还会利用如下一些工具来进行组织讨论，阅读这些归档对于理解社区的想法、是如何工作的有非常大的作用。

  • 问题追踪:这里是人们讨论项目相关问题的地方。

  • Pull Requests:审核代码、以及相关的问题讨论。

  • 论坛或邮件列表：一些项目会实用会话式的主题（例如 “How do I*…“* 或 *“*What do you think about…“ 来替代Bug报告或特性请求）。然而有一些项目关于讨论全部实用问题追踪。

  • 即时在线聊天:有一些项目会实用聊天频道（诸如 Slack 或 IRC），从而能够随意的谈话、协作和快速交流。

国内开源其实都不太习惯用issue包括PR的方式去提交代码（包括在论坛外做一些讨论），国内更喜欢使用一些即时聊天工具，尤其是封闭平台，例如微信，这些对开源来说并不是一个特别好的方式。

四、寻找打算做贡献的项目

假如你之前从来都没有为开源做过贡献的话，那么请记住来自美国总统约翰 F.肯尼迪的这段话：不要问你的国家能为你做什么，要问你能为国家做什么。

开源项目的方方面面都需要贡献者，你先不要通盘考虑该往哪里贡献，或者是它将如何看。相反，从你已经使用到的或者打算用到项目开启贡献之路，在你积极的贡献过程中，项目也会反馈给你，让你更好的定位自己。

一旦进入某项目，不论何时，你都要听从自己的直觉，做你认为更好或者不同的事情。

开源并不是高级俱乐部；它就是由你这样的人所浇铸和打造。“开源”只是针对这个世界的需要修复的问题的一个梦幻术语罢了。

你或许在查看 README的时候，发现了损坏的链接，又或者拼写错误。又或者是你是一名新手，使用的过程中发现了问题，又或者是某问题应该在文档中注明。请不要坐视不理，径直绕开，或者是请求他人修复，伸出你的援助之手，解决这些你能看到的问题。而这正是开源的精髓之所在！

28% 的随意贡献 就是说明了贡献文档，诸如拼写错误，段落语句调整、或者是翻译。

你也可以利用如下列出的资源来找到合适的新项目：

1、提交贡献之前应做的检查列表

当你找到了你打算贡献的项目时，在进一步行动之前，作一个快速的扫描工作，以确保项目是否接受贡献的。否则，你煞费苦心的工作可能没有任何的回报。 这是一个简易的检查表，用来评估一个项目是否适合新的贡献者。

符合开源的定义

  • 有许可协议吗？通常情况下，会在根目录有一个叫做 LICENSE 的文件。

项目被接收的提交活跃度

在主干上确认提交的活跃度。在GitHub上托管的开源项目，你可以在仓库主页上看到这些信息。

  • 最后一次提交是在什么时候？

  • 项目目前有多少贡献者？

  • 人们提交的频繁吗？ (在 GitHub，可以在顶栏里点击“commits”来展现。）

接下来，就是看项目的 issue 数量。

  • 目前有多少个还处于开放状态的 issue？

  • 项目的维护者对于处于开放状态的issue响应是否迅速？

  • 是否有讨论很活跃的issue？

  • issue 均是近期产生的吗？

  • 有没有关闭的issue？ (在 GitHub, 点击 "closed" 标签就可以看到所有已经关闭的 Issue 。

同样再来看看 PR的情形。

  • 现下有多少处于开放状态的PR？

  • 当提交了PR后，维护者响应是否迅速？

  • 是否有活跃讨论的 PR？

  • 均是近期的RP吗？

  • 最近有多少PR合并？ (在 GitHub, 点击 RP页面的 "closed" 的标签页来查看已经关闭的标签页。)

项目的受欢迎程度

一个项目的友好程度和受欢迎意味着更能吸引新的贡献者。

  • 在issue的问题中，维护者的回答是否非常有帮助？

  • 人们在issue的讨论中、在线聊天室、论坛是否很友好？

  • PR是否被review？

  • 维护者是否对做贡献的人们道声”谢谢”？

当你看到一个很长当对话时，来自核心开发者的零星的响应排在列表的后面。你就得考虑，他们在作建设性的总结？是否保持风度的情况下做出最后的决定？如果你看到的是更多的口水仗，而且还在继续，这通常意味着社区的能量重心已经不在开发上了。 — @kfogel , 开源软件生产力

五、如何提交成果

你已经找到了你喜爱的项目，也已准备好贡献了，迫不及待、跃跃欲试了。好吧！以下就是带领你如何以正确的姿势作贡献。

提交成果，就是提交PR，第一步是说清楚上下文，表明这个PR是做些什么事，一个好的PR相当于一篇小的作文/论文，需要解释清楚在什么场景下做什么事情。第二步是要达到什么目标，能解决什么问题，以及解决之后对其进行什么测试，最终得到什么结果。

PR的内容应该简单直接，而非充满不确定性的“比较好”/“我更优”（PR里并不能证明该解决方案最优），因此如何去写PR是国内工程师普遍的一个问题（国内大多数以代码为导向而非文档为导向）。

重要的是，尊重社区的决定，相关的社区_开源项目都具有自身的目标，做什么事情以及解决什么问题，大家的想法不一样（因为不在同一家公司，也不解决同一问题，具有差异性），需要大家一起讨论这个差异性，当然可以说服其他人，希望他们接受，如果不能接受，也没必要沮丧，这并不是技术问题或者其他核心问题。因此经常会遇到一个比较矛盾的问题，我希望使用一个项目，因为该项目做了70%的功能，但还有10%的功能我没有，那我则希望这10%的功能贡献到社区，但社区并不接受，因为这并不是社区_项目要解决的问题。

所以就面临一个问题：是 Fork 重新做，还是保持分支 Patch 然后每次进行合入。这就是技术和运营双包括架构选择的综合性结果，并不代表 Fork 就是不尊重社区/分裂社区，但在欧美有些极端的人会产生这种想法：在做一个事情，Fork 它就是在分裂社区。因此需要以一个开放的心态去做这件事。

1、有效沟通

无论你处于什么样的目的：仅仅是一次性的贡献，亦或是永久性的加入社区，都的和他人进行沟通和交往，这是你要在开源圈发展必须修炼的技能。

[作为一名新手,] 我很快的就意识到，我若是要关闭一条 Issue 时，我不得不问更多的问题。我浏览了代码库，一旦我觉得有什么问题的时候，我就得需要更多的指点，瞧！ 在我得到所有的所需要的信息后，我就可以解决这个问题！ — @shubheksha , 一名菜鸟进入开源世界的坎坷之旅

在你开启一个 Issue 或 PR之 前，或者是在聊天室问问题之前，请牢记下面所列出的几点建议，会让你的工作更加的高效。 给出上下文 以便于让其他人能够快速的理解。比方说你运行程序时遇到一个错误，要解释你是如何做的，并描述如何才能再现错误现象。又比方说你是提交一个新的想法，要解释你为什么这么想，对于项目有用处吗（不仅仅是只有你！）

😇 “当我做 Y 的时候 X 不能工作” 😢 “X 出问题! 请修复它。” 在进一步行动前，做好准备工作。 不知道没关系，但是要展现你尝试过、努力过。在寻求帮助之前，请确认阅读了项目的 README、文档、问题（开放的和关闭的）、邮件列表，并搜索了网络。当你表现出很强烈的求知欲的时候，人们是非常欣赏这点的，会很乐意的帮助你。

😇 “我不确定 X 是如何实现的，我查阅了相关的帮助文档，然而毫无所获。” 😢 “我该怎么做 X ?” 保持请求内容短小而直接。 正如发送一份邮件，每一次的贡献，无论是多么的简单，都是需要他人去查阅的。很多项目都是请求的人多，提供帮助的人少。相信我，保持简洁，你能得到他人帮助的机会会大大的增加。

😇 “我很乐意写 API 的教程。” 😢 ” 有一天我驾驶汽车行驶在高速公路上，在某个加油站加油的时候，突发奇想，我们应该这么做，不过在我进一步解释之前，我先和大家展示一下。。。” 让所有的沟通都是在公开场合下进行。 哪怕是很不起眼的小事，也不要去给维护者发私信，除非是你要分享一些敏感信息（诸如安全问题或严重的过失）。你若能够保持谈话是公开的，很多人可以你们交换的意见中学习和受益。

😇 (评论) “@维护者 你好！我们该如何处理这个PR？” 😢 (邮件) “你好，非常抱歉给发信，但是我实在很希望你能看一下我提交的PR。” 大胆的提问（但是要谨慎！）。 每个人参与社区，开始的时候都是新手，哪怕是非常有经验的贡献者也一样，在刚进入一个新的项目的时候，也是新手。出于同样的原因,甚至长期维护人员并不总是熟悉一个项目的每一部分。给他们同样的耐心,你也会得到同样的回报。

😇 “感谢查看了这个错误，我按照您的建议做了，这是输出结果。” 😢 “你为什么不修复我的问题？这难道不是你的项目吗？” 尊重社区的决定。 你的想法可能会和社区的优先级、愿景等有差异，他们可能对于你的想法提供了反馈和最后的决定的理由，这时你应该去积极的讨论，并寻求妥协的办法，维护者必须慎重的考虑你的想法。但是如果你实在是不能同意社区的做法，你可以坚持自己！保持自己的分支，或者另起炉灶。

😇 “你不能支持我的用例，我蛮失望，但是你的解释仅仅是对一小部分用户起作用，我理解是为什么。感谢你的耐心倾听。” 😢 “你为什么不支持我的用例？这是不可接受的！” 以上几点，要铭记在心。 开源是由来自世界各地的人们共同协作实现的。面临的问题是跨语言、跨文化、不同的地理为止、不同的时区，另外，撰写文字的沟通更是难上加难，无法传达语气和情绪。请让这些会话都充满善意吧！在以下情形中请保持礼貌：推动一个想法、请求更多的上下文、进一步澄清你的立场。既然你在互联网找到了自己的所需，那么请尝试让它变得更好！

2、收集上下文

在正式开始之前，做一些快速的检查项，以确保你的想法是没有被讨论过的。遍历项目的 README、问题（开放的和关闭的都算）、邮件列表、Stack Overflow。毋需去花好几个小时去全部折腾一遍，但是使用几个关键的词汇来搜索一下是必要的。

如果你没有找到和你想法一样的内容，你就可以继续了。如果项目是在 GitHub上的话，你可以通过开启一个issue或PR：

  • Issues 开启一次对话或讨论

  • Pull requests 请求接受自己的解决方法

  • 少量的沟通， 诸如澄清或how-to的问题，尝试到 Stack Overflow 、IRC、Slack或其它聊天频道。

在你创建 Issue 和 PR 之前，请检查项目的贡献者文档（文件名通常叫做 CONTRIBUTING，或者就直接包含在 README 中），找一些你需要的较具体的东西，例如，他们会要求你遵循某个模版，或者是要求你使用某个测试。

如果你做的是一个非常实际的贡献，在正式开启之前，先创建一个issue。监视项目是很有帮助的（在GitHub， 点击 “Watch” ，所有的对话都会通知到你），要让社区的成员们知道你要做的工作，免得你做了之后，再让他们知道，他们不同意，就浪费了。

你能够从单个的项目学习到 很多 ，只要你踊跃的去使用，在GitHub上密切观察项目，并阅读每一个 issue 和 PR。 — @gaearon 参与项目

3、创建 issue

你应该在遇到下列情况下，去创建一个 issue：

  • 报告你自己无法解决的错误

  • 讨论一个高级主题或想法(例如. 社区、远景、政策等)

  • 期望实现某新的特性，或者其它项目的想法

在issue的沟通中几点实用的技巧:

  • 如果你刚好看到一个开放的issue，恰是你打算解决的，添加评论，告诉他人你将负责这个。这样的话，可以避免他人重复劳动

  • 如果说某个issue已经开放很久了，这可能是已经有人正在解决中，又或者是早已经解决过了，所以也请添加评论，在打算开启工作之前，最好是确认一下。

  • 如果你创建了一issue，但是没多久自己解决了，也要添加评论，让其他人知道，然后关闭该issue。记录本身就是为社区的贡献。

4、创建 pull request

在下面的情形时，请你务必使用PR：

  • 提交补丁 (例如，纠正拼写错误、损坏的链接、或者是其它较明显的错误）

  • 开始一项别人请求的任务，或者是过去在issue中早就讨论过的

一个 PR 并不代表着工作已经完成。它通常是尽早的开启一个PR，是为了其他人可以观看或者给作者反馈意见。只需要在子标题标记为“WIP”（正在进行中）。作者可以在后面添加很多评论。

如果说项目是托管在 GitHub上的，以下是我们总结出的提交RP的建议：

  • Fork 代码仓库 并克隆到本地，在本地的仓库配置“上游”为远端仓库。这样你可以在提交你的PR时保持和“上游”同步，会减少很多解决冲突的时间。(更多关于同步的说明，请参考 这里 .)

  • 创建一个分支 用于自己编辑。

  • 参考任何相关的issue或者在你的RP中支持文档(比如. “Closes #37.”)

  • 包含之前和之后的快照 如果你的改动是包含了不同的 HTML/CSS。在你的PR中拖拉相应的图片。

  • 测试你的改动！ 若测试用例存在的话，跑一遍，以覆盖你的更改，若没有的话，则创建相应的用例。无论测试是否存在，一定要确保你的改动不会破坏掉现有的项目。

  • 和项目现有的风格保持一致 尽你最大的努力，这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭，但是为了节省维护者的精力，以及未来他人更好的理解和维护，还请你容忍一下。

如果这是你第一次提交PR。可以浏览 PR制造 的文档，这是 @kentcdodds 专门为初次创建PR的人写的公开的资料。

六、在提交完之后需要善后事宜

很不错，你做到了！恭贺你成为开源贡献者。我们希望这是一个良好的开端。 在你提交了贡献之后，下面几种情形中的某种是可能发生的：

1、😭 没有人响应你。

希望你确认在开始工作之前检查过了项目的活跃度，不过即使检查过了，也不保证一个活跃的项目，没有人理会你的贡献也是很正常的。 如果过去了一周，依旧没有人响应，请心平气和的在后面跟帖，询求他人帮助你审核下。如果你熟悉某个人可以审核你的贡献，你可以使用@+名字，直接提醒他一下。

千万不要 私下里去联系他人；一定要记住，开源项目所有的沟通都应该是公开的。

如果你做了所有该做的事情，还是没有人理你，那就是真的没有人对你的贡献做出响应。这可能感觉上不太好受，但是千万不要灰心。每个人都会遇到这样的情况。其实有太多种原因没有人响应你的提交了，包括很多个人情形都是不在你控制范围的。再接再厉，换一种方法去提交，或者换一个项目。这年头，很多社区成员都在积极的参与和响应他人，都在抢夺优秀的人才，若没有人搭理你，你换地方是没有任何不对的地方的。

这一点在国外比较明显，包括国内很多项目的一些大型技术会议都是做开源项目的人聚集在一起，开一个类似于workshop的会，有些PR_issue写的不好，无法从中了解到相应的项目是想做些什么，因此在这类会议上，大家会有一个面对面交流的机会，在这个讨论之下，就能得到对该项目的理解，然后再决定此PR是否合入_这个方向是否继续往下做。私下联系这个事情并非100%禁止，联系他人应尽量是公开的。

2、🚧 其他人的要求你对自己的提交做出变更。

对于自己的提交作出变更这件事非常的普遍，可能是你获得了反馈，也可能是变更了代码。

当有人提出变更时，请表现出大度的地方，要及时响应。他们花时间审核了你的提交，要尊重他们。开启了PR，然后一走了之，是一种恶习。如果你不知道如何修改，请花时间深入研究问题的所在，如果还是没有想到好的办法，那么是该向他人求助的时候了。

如果你因为没有时间而无法继续在此issue继续工作（举例来说，如果对话已经过去了一个月了，没有任何的回复和进度，环境肯定变得不一样了），那么请向维护者告知你无法在及时的响应了，肯定有人非常乐意接替你的工作的。

3、👎 你的贡献没有获得通过。

  • 你的提交最后可能没有被接受。真心希望你没有在此作出过多的努力。如果你不确定为什么没有被接收的话，这正是一个很好的询问维护者反馈和澄清的机会。最终，无论如何，你都要对他们的决定表示尊重。不要去做过多无谓的争论或者是充满敌意的谩骂。如果你坚持自己，你可以随意的fork项目，按照自己的思路发展出分支来。

    • 很多开源项目也是这样来的。

4、🎉 你的贡献被接收。

太棒了！你已经成功的做到了，为开源做贡献也不过如此！

七、你已经做到了!

你刚刚完成了自己的开源贡献处女秀，接下来，你可能打算寻找另外的方法来做贡献，希望本文给你提供了灵感和实践。即使是你的贡献没有被采纳或接收，也不要有失风度，请对帮助过你的维护者表示感谢！

开源就是由你这样的人所铸造：开启一个issue，在提交PR，评论、讨论、收集反馈，直到被接收。就是这么简单。 Back to all guides

七、在 GitHub 上贡献开源项目的一般步骤

在正确的场合，以正确的方式表达、参与。 作者： @nixzhu 引用：

我并不是 Git 的专家，也不太会用 GitHub。但对于开源项目，如果我在使用其过程中遇到了问题，我会很乐意去其项目代码托管处（通常是 GitHub）看看有无其他人报告同样的问题，甚至解决办法。如果没有，那我可能会写一个 Issue。同时，我也会尽我所能去研究遇到的问题，寻找其根源。如果确定能修复此问题，我也会提交一个 Pull Request。

开源项目是很好的学习材料，而且一个好的开源项目在很大程度上可以减少使用它的程序员们的工作，让他们更专注于自有的业务逻辑。但我们不该止步于此，若能共同维护一个开源项目，让其越来越好，是一件对所有人都好的事情。

有了参与的主观意愿还不够，我们得学会参与的规则和流程。我们以托管在 GitHub 上的开源项目为例（GitHub是一个运作比较良好的开源项目）。

一般方式上需要先写一个issue，这个issue有两种方式：第一种先阐述遇到什么问题、遇到该问题的场景（在什么机器上，当执行什么命令时，遇到什么结果，经过分析认为时这个程序的一个bug）；第二种就是提PR说希望来做这个什么事情，认为这个项目的什么特性可以如何去开发，把这些东西作为一个issue提出来，经过反复讨论，一致认为没问题，则可根据提的issue来提一个pull request（是Git分支的一个模型的管理方式）。

1、Issue

假如你使用某个开源项目时遇到了问题，那么你首先应该去其 Issues 页面看看，例如 Yep 的 Issues 。除了 Open 的之外，还可以看看 Closed，甚至以可能的关键字进行搜索。如果你找到了某个类似的问题，你可以进去留言，说明你所遇问题的情况，或与已有描述的差别。

假如你没有找到描述类似的问题的 Issue，那么你可以点击 New Issue 来新建一个。在 Title 里简明扼要地写下问题的描述，再在 comment 里详细描述所遇问题。除了产生问题的条件，如果可能，加上一些自己对问题的推断甚至可能的解决方案。如果你对问题没有头绪，比如代码在运行中产生了一个死锁，那么你可以将程序的调用栈贴出来。这些信息有利于项目的维护者定位问题的根源。

写 Issue 的重要原则就是不要随意，要将其看成一种参与，一种帮助和自助。因此，词句要清晰，描述要详尽。若发完 Issue 后发现还有需要补充的地方，可以进一步增加 comment。

最后，在提交新的 Issue 之前，应该检查一遍，确保没有明显的错别字和语法错误。

2、Pull Request

我想，有能力的程序员不会止步于发 Issue，他们会更想直接以修正代码的方式解决问题，这就需要明了 Pull Request 的流程。

简单来说，Pull Request 是外部开发者参与开源项目的主要方式。因为通常一个开源项目不会允许所有人都去直接修改代码，这会让项目变得混乱，难以维护和测试。

因此，外部开发者需要先 Fork 已有项目，然后在自己 Fork 的项目上进行修改，最后这两个项目就产生了差异，GitHub 可以检测到这样的差异。当外部开发者修改完成，就可以利用 GitHub 将自己的改动以 Pull Request 的方式提交到原项目，原项目维护者再对改动进行检查和测试。在确定没有问题后，将改动合并到项目中。这样外部开发者的这一次参与就完成了。

听起来似乎有些复杂，但正是这样的流程保证了代码的持续稳定。因为写代码和写文章一样，并不是一件随意的事情。

  • Fork。例如在 Yep 的项目上，点击右上角的 Fork 按钮（请大胆地点击，这不会对世界造成任何明显的伤害），然后你就得到了当前 Yep 项目的一个拷贝。

  • Clone。因为我们通常在本地电脑上做修改，因此先将 Fork 的项目 Clone 到本地，大家应该很熟悉吧。例如git clone https://github.com/XXX/Yep.git，其中 XXX 为你的 GitHub 用户名。

  • 保持同步。大多数学会 Fork 的开发者都会自然地产生一个疑问：如果原项目被改动了，那我们自己的拷贝该怎么同步原项目的改动呢？因为之前的拷贝是以那个时候的原项目为原本的。这也不难，在本地项目中，运行 git remote add upstream https://github.com/CatchChat/Yep.git，这就将原项目作为了本地项目的上游。你可以在运行此命令之前和之后运行git remote -v来观察改动。之后，若你想同步原项目的改动，执行git fetch upstream即可，这会将原项目所有分支的改动都存储在本地，例如原项目 master 分支会存为 upstream/master，不过这还不会对本地的项目造成影响。将如你想将上游 master 的改动合并到本地，只需先切换到 master 分支 git checkout master，再执行合并 git merge upstream/master 即可。同理可以按需要处理 develop 分支等。

如果你的改动很小，那么修改所持续的时间不会很长，你可以不做“保持同步”这一步。当你发出 Pull Request 后，若被维护者合并，你就可以从 GitHub 上删除你 Fork 的项目了。若下次你还想再修改，完全可以重新 Fork，这一次同样会以最新的代码为基础进行拷贝。

如果你想长期参与，那在做完第三步后，还可以 git branch --set-upstream-to=upstream/master master，这样当上游的 master 有改动后，只需在本地 master 分支 git pull 即可。同理，你也可以处理 develop 等分支。

通常，我们都在新分支里做修改，在测试改动没有问题后才合并到主分支。大家经过总结，出现了一套叫做 Git Flow 的流程。简单来说，在 master 外，建立一个 develop 分支用于开发，而且，每一个新特性的开发都会从 develop 分支创建新分支，新特性开发完成后再合并到 develop 分支。

我们也并不需要精通 Git Flow，只需记住两个命令 git flow feature start XXX 和 git flow feature finish XXX，其中 XXX 是你要开发的特性（或要修复的Bug）的名字。我搜索到一篇很清晰的 关于 Git Flow 的讲解 ，大家一起学习。

Yep 的开发使用了 Git Flow，但作为外部开发者，你也不一定非要使用它，因为本质上 Git Flow 也只是建立分支，并以分支为基础的一套方便工具。

例如 git flow feature start XXX 以 develop 为基础，创建一个新的 feature/XXX 分支，而 git flow feature finish XXX 就将 feature/XXX 分支合并到 develop，你完全可以直接用 git 命令来实现。例如 git checkout -b XXX develop 就会以 develop 分支新建一个 XXX 分支（这里没有自动写上的 feature 前缀），当你完成你的修改后，git checkout develop 然后 git merge --no-ff XXX develop 就可以将 XXX 分支合并进 develop 了。不过，你也可以直接以 XXX 分支发 Pull Request，只需先将其git push origin XXX到 GitHub，然后在你 Fork 的项目主页点击 Compare & pull request 按钮即可。如果没有这个按钮，也可以点击 New pull request 按钮来发起，注意选择正确的分支即可（你工作的分支到 Yep 的 develop 分支）。

以上是个人对 Git 以及参与 GitHub 项目的粗浅理解，如有错漏，欢迎以 Issue 或 Pull Request 的方式指正！

欢迎转载，但请一定注明出处！ https://github.com/nixzhu/dev-blog

八、开源潜规则

1、何为潜规则？

规则之前概率生效概率公开各自解读
人数很少的时候管理者的意识为何会私下处理大社区里的小圈子
判例法的意识情况的复杂性为何会另外找理由揣摩者

2、六个开源软件开发的“潜规则”

1）按部就班，循序渐进

  • 理解社区目标

  • 完成社区任务：测试补丁、复审代码、撰写文档、修正错误

  • 关注整个社区的动向，而非只关注自己开发的功能

2）博闻强识，敦善不怠

  • 在某个社区中建立声望，全面了解该项目和代码是很有必要的

  • 努力钻研项目，对项目各个部分如何与其他人协作交互有深入的理解，理解超出你擅长范围之外的知识

  • 不要只把自己的理解局限于开发者

3）粗枝大叶，自寻烦恼

代码提交完毕并不代表工作结束。如果代码被接受，还会有更改的讨论、常见的问答，以及做测试。要确保你可以准时提交，努力去理解如何在不影响社区其他成员的情况下，改进代码和补丁。

4）和谐相处，助人助己

开源社区不是自相残杀的丛林世界，我们更看重项目的价值而非个体的贡献和成功。如果你想给自己加分，让自己成为更重要的社区成员、让社区接纳你的代码，那就努力帮助别人。如果你熟悉网络部分，那就去复审网络部分，用你的专业技能让整个代码更加优雅。顶级的审查者经常和顶级的贡献者打交道。你帮助的人越多，你就越有价值。

5）八面玲珑，面面俱到

想要引进新技术，特别是比较有争议的技术，最好的办法就是让人无法拒绝它。你需要透彻地了解底层代码，考虑每个极端情况。在不影响已实现功能的前提下增加新功能。不仅仅是完成就行，还要在特性的完善上下功夫。

6）糜不有初，鲜克有终

开源社区也有许多玩玩就算的人，但是承诺了就不要轻易失信。不要就因为提交被拒就离开社区。找出原因，修正错误，然后再试一试。当你开发的时候，要和整个代码库保持一致，确保即使项目发生变化而你的补丁仍然可用。不要把你的代码留给别人修复，要自己修复，形成社区良好风气。

3、人人平等与精英治理

在开源社区存在一种现象：人人平等与精英治理。其实这背后潜在某种矛盾性。在开源社区里面，我们提倡的是人人平等，但实际上开源社区基本上是由一些Maintainer在经营治理，它不是人人都可以参与的。所以我觉得开源社区是精英治理的模式，这背后的精英，通常属于某一家公司或某几家公司。 社区里面所谓的人人平等，从发言权角度考虑是成立的。你可以表达你的意见，但并不见得你的意见会被采纳。

4、社区中的潜规则

社区里会有张罗大大小小事情的人，这种人很了不起，他是社区存在的核心或者说是社区存在的原因。可能他在社区里有一些代码大家都在用，只要开源出来放在那里，开源的项目便会持续存在。

但社区就不一定了，我们经常看到一些没有人维护的“死掉”的社区，如果社区里的人在社区里依然坚持做某件事情，其实就会使社区真正存活。所以社区是由人组成，而不是由代码组成。