开源改变世界，改变你和我

た入场券 2022-01-20 02:51 350阅读 0赞

## 目录 ##

*  开源改变你和我
 *  敲开开源世界的大门
 *  适合的就是最好的
 *  我为开源做贡献

## 开源改变你和我 ##

大家好，讲到开源可能大家最容易想到的就是开源软件了，到今天为止，开源软件已经有二十岁了。如今已经没有人可以忽视开源对我们生活的各个领域产生的巨大影响，仅用了20年，开源就已经取得了如此巨大的成功，它成功的原因到底是什么？对我们又有哪些影响呢？我们在第一部分为大家来解密。

既然开源如此的重要，我们要如何拥抱开源呢？对于开源项目你心生畏惧吗？在第二部分中我们将给出答案。

只有适合的才是好的，在第三部分中，我们将给大家介绍如何找到适合的自己的项目？

当你找到适合自己的项目后，如何参与进来，如果为它做贡献，第四部分我将教你开启正确的姿势。

### “吞噬”世界的开源软件 ###

能够活在开源的时代毫无疑问是幸运的，今年开源已经20岁了，若是将之比喻为我们人类本身的话，正是意气风发的年龄，也是才华碧现的时候。开源成就了许多人，也是我们现在数字时代的中流砥柱。它的存在和发展意义值得你我去深思和挖掘。

20年前，也就是1998年的二月份，“Open Source”（开源）被软件所第一次使用，从某种意义上说，开源已经赢得了胜利，它已经超出了当时参与者的想象。在我看来，前十年是对抗的十年、争议的十年，后十年是接纳的十年、繁荣的十年。来，让我们来听听业内大佬们的声音：

> *谷歌说：“如果离开了开源软件，我们今天所看的的互联网将不复存在！”* *Intel说：“开源已是主流！”*  
> *红帽说：“我们利用开源赚到20亿”*  
> *微软说：“我们对开源很执着！”*  
> *Salesforce, Amazon说：“我们要换掉Oracle！”*  
> *IDG说：“开源和人工智能、深度学习、虚拟现实、云计算安全并列为2017年的顶级技术！”*

这已然是一个默认开源的时代：

> **开源已经走进历史，不可逆转！要么拥抱，要么沉沦！**

### 世界充满源代码 ###

开源顾名思义就是开放源代码，那么源代码只是软件吗？现今的“源代码”更加广泛，还包括蓝图、食谱、规则、用户界面、图形设计、撰写文档、乃至组织活动。

大家知道，20世纪最伟大的设计工程带是消费民主化，而设计工程的下一步是生产民主化。这也正是宜家、WikiHouse这样的开源项目之所以成功的秘密。

提到WikiHouse，在2016.10在北京设计周大栅栏社区快速搭建了一个WikiHouse结构的展棚，搭建活动由网络招募的6名成人志愿者和6名高中生联合完成，现场搭建过程只用了7个小时。

不可思议吧！WikiHouse提供的图纸包括了这个简易房屋的每一个零件，甚至包括板材间的连接部件，你可以把它的图纸下载下来，并借助数控机床高效地将板材“打印”成它所需要的部件。只需要2-3个人的努力就可以将这座简易房屋组装好，就像组装宜家家具一样简单。

除此之外，WikiHouse 还提供了房屋设计的标准和指南，包括钉子的使用、板材间连接部位的的结构与规格。同时，它还根据房屋的宽度将设计归于不同的系列。正是这样标准化的过程，才使得这样的开源项目的质量和效率真正得到了保障。

这样就完美了么，复杂的工艺简化，让非专业的农民都能加入工作，是目标，然而简化不等于简陋，是更花时间的精炼，结构分析也极为复杂，尤其要预判各种不可控因素的安全范围，要面临的问题依然很多，但是我认为这也正是开源的魅力所在，大家可以毫无保留天马行空的交流，也正是通过这个项目才让我了解了更多有趣的话题如：生态设计、可持续建筑、弹性城市等等，开拓了我眼界。只要你全身心的投入，我敢保证，你在开源的世界中你的收获一定超过你的贡献。

### 为什么开源如此成功 ###

无论你承不承认，开源已在生活中无处不在，短短20年，它是如何从星星之火，成为燎原之势的呢？开源的本质到底是什么呢，接下来我们就来正本清源，为大家揭开成功的秘密！我认为最关键的有以下二点：

*  博弈全输，合作双赢！
 *  切实有效的沟通是利益最大化的关键！

首先，我先介绍一个有趣的“概念” - 囚徒困境

### 囚徒困境 ###

囚徒困境（Prisoner's Dilemma）是博弈论的非零和博弈中具代表性的例子，反映个人最佳选择并非团体最佳选择。或者说在一个群体中，个人做出理性选择却往往导致集体的非理性。虽然困境本身只属模型性质，但现实中的价格竞争、环境保护等方面，也会频繁出现类似情况。

#### 经典的囚徒困境 ####

> 警方逮捕甲、乙两名嫌疑犯，但没有足够证据指控二人有罪。于是警方分开囚禁嫌疑犯，分别和二人见面，并向双方提供以下相同的选择：
> 
>  *  若一人认罪并作证检控对方（相关术语称“背叛”对方），而对方保持沉默，此人将即时获释，沉默者将判监20年。
>  *  若二人都保持沉默（相关术语称互相“合作”），则二人同样判监1年。
>  *  若二人都互相检举（互相“背叛”），则二人同样判监5年。

#### 解说 ####

如同博弈论的其他例证，囚徒困境假定每个参与者（即“囚徒”）都是利己的，即都寻求最大自身利益，而不关心另一参与者的利益。参与者某一策略所得利益，如果在任何情况下都比其他策略要低的话，此策略称为“严格劣势”，理性的参与者绝不会选择。另外，没有任何其他力量干预个人决策，参与者可完全按照自己意愿选择策略。

囚徒到底应该选择哪一项策略，才能将自己个人的刑期缩至最短？两名囚徒由于隔绝监禁，并不知道对方选择；而即使他们能交谈，还是未必能够尽信对方不会反口。就个人的理性选择而言，检举背叛对方所得刑期，总比沉默要来得低。试设想困境中两名理性囚徒会如何作出选择：

*  若对方沉默、我背叛会让我获释，所以会选择背叛。
 *  若对方背叛指控我，我也要指控对方才能得到较低的刑期，所以也是会选择背叛。

二人面对的情况一样，所以二人的理性思考都会得出相同的结论——选择背叛。背叛是两种策略之中的支配性策略。因此，这场博弈中唯一可能达到的纳什均衡，就是双方参与者都背叛对方，结果二人同样服刑5年。

这场博弈的纳什均衡，显然不是顾及团体利益的帕累托最优解决方案。以全体利益而言，如果两个参与者都合作保持沉默，两人都只会被判刑半年，总体利益更高，结果也比两人背叛对方、判刑5年的情况较佳。

但根据以上假设，二人均为理性的个人，且只追求自己个人利益。均衡状况会是两个囚徒都选择背叛，结果二人判监均比合作为高，总体利益较合作为低。这就是“困境”所在。

**请大家思考一下现实生活中你身边有哪些例子呢？**

#### 囚徒困境揭示了什么 ####

每个人都选择利益最大化，损失最小化的的理性选择时，最终并不能得到利益最大化的结果。每个人都陷入了悲惨的困境，明明有一个本来你好我也好的可能，偏偏得到一个你不怎么好我也不咋好的结果。

#### 如果破局 ####

其实在视频中，已经道出了破解的关键。那就是沟通！

囚徒困境是一个静态条件下的博弈案例。大家想一下，如果两人有机会沟通，是不是能够改变最终结果，走出困境呢？这样他们就可以同时选择更好的结果。这就是合作。

然而合作带来了一个新的问题，两人个互相信任吗，他们能抵住背叛的诱惑吗？因为背叛可以得到更好的结局。要解决这个问题我已知的有两种方法，在第一种可信度就变得非常重要。可信度来自于声誉，也可以来自于面临的后果，如果在团伙中有帮规，如背叛同伙，虽远必诛。这就是惩罚，就保证了可信度。第二种方法，为了更好的说明，给大家介绍一个英国综艺节目，叫做Gloden Ball。

举例： 待补充

这是一个巧妙利用理性的例子，人性的根本就是“趋利避害”的理性，那么不管对方是一诺千金的君子，还是见利忘义的小人，你都可以实现最理论最完美的结果。

以上二个例子的前提都是基于沟通，个人利益最大化的前提是建立在团队利益化的基础上的，单纯的追求个人利益最大化只会适得其反，聪明反被聪明误，所以博弈全输，合作双赢，而切实有效的沟通系统才是利益最大化的关键。

### 开源项目的重要属性 ###

一个开源项目能否成功除了刚才讲到的二个关键原因，它必有还有以下几个重要属性，就是运行良好、规则清晰、自由许可的协同社区。

### 为开源正本清源 ###

既然万物皆开源，为什么大家一提到开源先想到开源软件呢？它是怎么成为了开源的先驱？它对我们又产生了怎样的影响呢？不得不得自由软件运动。

#### 自由软件运动 ####

1968年，那一年，是 Unix 操作系统的诞生之年，那一年，留着长发、蓄着大胡子、戴着厚厚的眼镜片的 Ken Thompson 缔造了Unix。

Thompson 在撰写Unix 的时候，还在为Bell实验室工作，所以在整个70年代都是由Bell实验室来分发Unix的源代码的，那时来自世界各地的研究实验室、大学、和计算机科学家都在为 Unix 贡献代码。Unix 曾经是“自由的”软件，任何组织需要都是可以采用的。

程序员们开始不乐意了，Unix 曾经是他们协作的成果，他们认为至少Unix应该对他们保持“免费”和可获取，毕竟他们帮助了Unix的成长和发展。

这时，英雄出现了。来自 MIT 的研究员 Richard Stallman 站了出来，这是一名具有嬉皮士风格的人，触动他的是他和同事索要打印机驱动程序的源代码时遭到了拒绝，他认为软件应该是自由的，从那以后，Stallman将自由软件的理念发展成为了自己的使命，也成了这一运动的领军人物。在1985年更是创立了自由软件基金会，地点设在波士顿，活动至今。

Stallman 和其他程序员开始撰写代码用来替代 Unix，这些项目称之为“GNU”（即“GNU is not Unix”的简称），他们分发的项目使用“copyleft”——和“copyright”对着干的用词。Copyleft 鼓励用户去更改现有的代码，并可以公开的保留，来自全世界的计算机开发者协作来开发GNU和其它自由软件项目。

商业软件公司，诸如微软、IBM也开发了自己的商用操作系统来和Unix竞争。但是这些操作系统并不提供让用户能够自己修改，而且也不会让用户去自行进行构建版本。

在整个80年代，自由软件开发者们不懈的努力去开发一个更好的操作系统，但是一直都缺少一个非常关键的因素：“统一的内核”，内核是管理硬件设备和为应用程序提供良好接口的关键核心程序。

在1991年因为一个个人的项目才改变了这样的局面，仅仅只有21岁的芬兰籍大学生——Linus Torvalds，创立了内核的项目，随后他以GPL协议发布了源代码，并命名为“Linux”，开发者们开始将内核和已有的GNU项目融合起来，这就是现在我们一直沿用的Linux操作系统，完整的名称应是：GNU／Linux。

从那以后，Linux的开发成爆发式的增长，(Under the radar也是红帽联合创始人Bob Young出版的书籍。)一些极客和电脑发烧友开始对他情有独钟，他们通过解决彼此的问题而一起协作，举例来说，大学的教授为了完成研究而协作编程，可有效降低成本，他们通过创建新的程序和修复漏洞来改进Linux。

一些早期的Linux开发者来自于哪些大公司，但是他们的上司却对他们的这些工作视而不见，偶尔也会有一些颇有经济头脑的高管注意到“自由软件”，但是他们不知道该如何处理，因为对于他们来说Linux完全是陌生的，过于深奥和难于理解。通常他们认为仅仅是“研究和开发”罢了，完全视而不见。

#### 发现洞见 ####

1992年，那时还很不起眼的创业者 Bob Young 卖掉了电脑业务，开始发行杂志《Linux Journal》，Bob 并不会撰写程序，但是在当时，他是少数意识到 Linux 的快速发展而会带来商机的人之一。

Bob 谈道：“当时，那些在加州大型杂志社工作的人们完全忽视Linux的存在，在今天看来，他们也意识到了这点，一如我在92年看到Linux时想到的‘这就是方向’”。

Bob继续回忆道：“在92年到94年间，自由软件并没有消失，相反越来越多的人们选择使用它，我当时就想，‘这也并不能说明什么，这样的现象并不符合我的世界观。’而且和我聊过的所有工程师都没有就自由软件的商业模式有任何的想法，如果找不到商业模式的话，那么就不可能有任何商业上的成功。”

Bob 继续回忆道：“我决定要做些什么了，Linux本身的发展颠覆了我的世界观，而且还让我重新认识到利他主义是可行的（尽管我不愿意承认它），就觉得这里有一些东西要发生，而这完全是工程师们无法理解的。”

为了解决这个让Bob进退维谷的难题，Bob觉得自己亲自找寻这些Linux专家来问问，希望能够找到答案：为什么Linux的程序员们不去申请专利？不去兜售他们的代码？为什么不将Linux这样的技术公司资本化运作？

Bob 的其中一站是位于马里兰州 GreenBelt 的戈达德太空飞行实验室，其中一属于 NASA 的研究机构开始安装Linux。就是这趟旅行给了 Bob 很大的启发，那就是创建红帽独一无二的商业模式的最初来源。

戈达德在当时对于Linux做了很大一个改变，使用价值$40,000的PC服务器来替代三年前花了500美金购买的超级计算机，让这些PC服务器运行的就是Linux操作系统，Bob访问了在此工作的一名程序员，一名曾为Linux撰写了以太网驱动的开发者，这名开发者本来是打算在戈达德的项目中使用这些代码的，但是他同时也以free的方式将代码上传到了社区，供人们公开使用。Bob想了解他为什么会这么做。

Bob 向这名程序员的经理 Tom Sterling 问道：“你为什么会花钱开发这些复杂的以太网驱动？还不去售卖它们？”

Tom 解释道：“我们只是作为回报提交了以太网驱动而已，要知道，我们获得整个操作系统的源代码，我们可以将之安装到任何机器上，我可以自由的做任何事情。”

Bob 继续追问：“你为什么不让Linux运行在哪些大型机上？就我所知，太阳微系统公司是非常乐意给你源代码的，如果你愿意在他们的系统上开发的话。”

Tom 接着解释道：“你说到没错，我也可以和太阳微系统公司索取源代码，但是如果我这么做了的话，我就得和我的律师商讨并查找，哪些代码我可以动，哪些不可以。如果我使用Linux的话，其许可证允许做我任何想做的事情。”

Tom 的回答，解决了 Bob 困惑已久的问题： 控制权才是用户的真正关心的，而不是那些所谓的功能。

“所以说，Tom使用linux并不是因为Linux更好，或者是更便宜，或是运行的更快，” Bob 补充道。“他使用Linux是因为Linux能够让他获得控制的权力，而且他还找不到任何的替代品，无论是从IBM，还是微软，还是Sun，亦或是苹果，没有一家商业公司可以给予他这样的好处！我是一名销售！我从来卖的不是功能，我卖的就是好处！正好Tom说出了其中的精髓，Linux具备其他任何厂家都无法提供的好处——控制！所以，自从那次旅行之后，我找到了灵感！”

在1994年，Linux 仍处于无人问津的状态，至少作为可管理的操作系统来讲是如此，那些专有软件公司仍对它视而不见，认为它仍处于研发状态，所以这些大的软件公司并不认为Linux能够威胁到他们。但是Linux默默的在壮大自己，1995年的装机量增加到150万台，要知道在1993年才只有10万台。

回顾整个90年代，越来越多的企业组织开始采用开源解决方案了，终于打开了局面，越走越顺！要知道这是多年以来坚持的结果，若是其中没有采用开放式的心态、创造性的思维，这一切可能都不会发生。

#### 揭示了什么？ ####

发现你的竞争优势，大多数的公司都在推广自己产品的功能，而不是益处，而后者恰恰是人们真正所关心的。你所在的公司能够提供的益处是什么？是控制权吗？还是可以节省时间？

### 社区优于代码，独立快，众行远！ ###

那些高效的、健康的自由开源软件项目是凭空产生的吗？为何社区如此重要？一个好的社区长什么样？

2014年Apache软件基金会执行副总裁：Apache软件基金会过去15年产生了一些非官方的座右铭，被人们口口相传，**社区胜过代码**。

> 对于社区，一切都是围绕代码产生的，无代码则社区将不复存在。在代码之上，则是如何做事如何待人、如何决策理念体现。Apache软件基金会成立15年来，拥有超过150个世界顶级项目，超过500名个人成员，拥有4000名提交者，贡献1.2亿行代码——相抵32,500人年（注：人年是工作量度单位）、20亿美金。所有这些成就，皆为社区之力！

比如说Linux，有26年的历史了，代码行数一千六百八十三万零六佰零九行，需要5472人年。

一个社区的健康程度，决定一个开源项目的生死。一个好的社区最重要的标志就是，它的成员们都拥有归属感。归属感使人们驻留在社区。

### 锻炼任何你想得到的经验 ###

一个成功的开源项目，对我们意义是什么呢？为开源贡献力量，得到的回报就是能够学习到很多、受教很多、且能够锻炼任何你能够想到的经验。

*  巩固已有技能：无论是撰写代码、设计用户界面、图形设计、撰写文档、亦或是组织活动，假如你有实践的愿望，你总能在开源项目中找到自己的位置。
 *  一拍即合、一见如故：开源项目一般都会有一个和谐、热心的社区，以让大家团结一致。实际上，开源界经常发生这样的情形，很多人的深厚友谊都是通过共同参与开源所建立起来的，至于具体的方式，可能是在一次技术研讨会上相谈甚欢，也可能是一直在聊天室中探讨问题。
 *  成就彼此的成长：和他人共同在一个共享的项目下工作，这意味着需要向他人解释清楚自己是如何做的，同理，也需要向他人求助，询问别人是如何做的。 相互学习和彼此教学对于每位参与者都能满载而归。
 *  口碑和声誉是你的财富：根据开源的定义，你在开源下所有的工作都是公开的，这也就意味着开源项目是一个很好展示你实力的地方。
 *  领导和管理是门艺术：开源为实践领导力和管理技能提供了很好的机会，比如解决冲突、组织团队、工作的优先级排列。
 *  勿以善小而不为：在开源的世界里，作出贡献的不一定非得是花了很长时间拥有大量经验的人。你是否遇到过浏览某些网站发现有拼写错误，希望有人能修改它？其实，在开源的项目中，你只需要做就可以了。没有那么多的顾忌，开源让人们在很舒服的状态做事，而这才是这个世界应有的体验。

## 敲开开源世界的大门 ##

### 拿来主义的陷阱 ###

> 总之，我们要拿来。我们要或使用，或存放，或毁灭。那么，主人是新主人，宅子也就会成为新宅子。然而首先要这人沉着，勇猛，有辨别，不自私。没有拿来的，人不能自成为新人，没有拿来的，文艺不能自成为新文艺。 --《拿来主义》鲁迅

这个涉及到中西方文化的差异、知识产权等问题，并不是这次我们主要讨论的。

#### 房间里的大象 ####

上游优先具有显而易见的好处，比如：提生产品能力、提升影响力、找到适合的人、节约成本、提升流量、占据供应链上游。

然而现实的情况却是，很少有人去做参与到上游社区，只有很少的个人和公司去做Upstream First，不是我们不具备编码能力或者写文档、做设计等等的一些能力，而只是这件事情没有人做，只有行少一部分人做，你会发现在社区里面起来的大牛很少，有的公司也提倡大家做Upstream First，但是都做不到。

> 房间里的大象 - 在人们私密生活和公共生活中，对于某些显而易见的事实，集体保持沉默的社会现象。 在一个房间里放着一只象，让一群人进去，然后人们开始谈话，所有人都看到了这只象但所有人都没有说，保持集体的沉默。

#### 刻舟求剑 ####

静态地看这个问题，无论你是基与开源的项目或者软件做事情，或者是你基于开源软件做一个商业产品，或者是把它当作第三方，去做一个事情，均是从上游切出一个分支，基于这个分支蒙头做事，而上游社区的项目是一直不断的发展的方，但是我们一定会做这样一件事情，前段时间Linux发了4.4，我基于这个做事情，或者我基于个开发，然后这几个人就开始做这个事情，到半年或一年之后，发生了什么情况？上游已经发了2个版本，已经5点几了，发现我自己的东西没有它全，或者是我这边也修了bug，要付出的代价非常大，因为有的接口变了。这种现象太常见了，你环顾下四周到处都是。

#### 公地悲剧 ####

索取还是奉献？

> 公地作为一项资源或财产有许多拥有者，他们中的每一个都有使用权，但没有权利阻止其他人使用，而每一个人都倾向于过度使用，从而造成资源的枯竭。过度砍伐的森林、过度捕捞的渔业资源及污染严重的河流和空气，都是“公地悲剧”的典型例子。之所以叫悲剧，是因为每个当事人都知道资源将由于过度使用而枯竭，但每个人对阻止事态的继续恶化都感到无能为力。而且都抱着“及时捞一把”的心态加剧事态的恶化。公共物品因产权难以界定而被竞争性地过度使用或侵占是必然的结果。这一个概念经常运用在区域经济学，跨边界资源管理等学术领域。

#### Not Just Coding！ ####

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

其实没有关系的啦！条条大路通罗马，开源项目有太多的路径可以参与！以下是一些实用的技巧，帮助你快速的获得经验。

你不具备编码的能力，  
对于为开源做贡献常见的误解就是：为开源做贡献必须得提交代码。事实上，代码固然重要，但是项目中不需编码的重要部分经常被忽视。在开源项目中代码、文档、改进的话题、解决方案、品牌等等都是项目成功的核心部分，你若做了这部分，对于项目来说可是莫大的贡献，而这根本就不需要什么撰写代码！

即使你是以为开发者，非代码的贡献对于项目来说也是举足轻重的，尤其是对于社区的其他成员来说。用心维系这些关系能够让你有工作到项目其它部分的机会。

#### 我来设计Logo ####

hapi.js的例子

#### 我能做什么？ ####

是否热衷于规划事件？

*  为项目组织研讨会或线下分享，一如 @fzamperin 为 NodeSchool 所做的那样
 *  为项目组织大型会议（假如它有的话）
 *  帮助社区成员寻找合适的技术会议，且帮助有实力的成员提交演讲的拟稿

是否偏向于设计？

*  重新布置布局以提高项目的可用性
 *  进行用户研究以重新组织和完善项目的导航或菜单
 *  整理一个风格指南，以帮助项目有一致的视觉设计
 *  创建t恤的艺术或一个新的标志，就像 hapi.js 的贡献者那样

你是否热衷于写作？

*  撰写和改进项目的文档
 *  能够以实例来展示项目该如何使用的
 *  为项目撰写新闻稿，或者到邮件列表高调布道
 *  为项目撰写教程， 一如 pypa 的贡献者所做的
 *  翻译项目的文档为本土语言

你喜欢组织活动吗？

*  链接重复的问题，并建议新的问题标签，使事物井井有条
 *  通过开放的问题，并建议关闭旧的，就像 @nzakas 为 eslint 做的
 *  把最近开放的问题阐述清晰，以推动讨论

享受编码的乐趣？

*  找到一个开放的问题并解决它，就像 @dianjin 为 Leaflet 做的
 *  想一想你是否可以帮忙写一个新的功能
 *  自动化项目设置
 *  改进工具和测试

热衷于帮助他人？

*  回答关于项目的问题，例如在 Stack Overflow（像 Postgres 的这个示例）或者 reddit 上
 *  为人们解答公开的问题
 *  帮助缓和讨论板或对话渠道
 *  在编码方面是否喜欢帮助他人？
 *  为他人的提交审核代码
 *  为如何利用项目撰写教程
 *  为其他贡献者做导师， 正如 @ereichert 为 @bronzdoc 所做的那样，哦，是 Rust 项目

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

举例来说：

*  @sindresorhus 创建了 “惊奇” 列表
 *  @h5bp 维护了针对前端开发者的面试题
 *  @stuartlynn 和 @nicole-a-tesla 制作了收集关于海雀的有趣的事实

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

## 适合的就是最好的 ##

*  自我定位与社区理念
 *  社区文化和规则
 *  尊重他人

### 自我定位 ###

一个优秀的社区运营理念应该是贡献、共治、共荣，这也正是大平台前端技术体系的理念。如果想让开源社区发展壮大，需要号召更多人贡献参与其中，更多有识之士一齐共治，最终达成共荣的开源盛世；如何才能实现这样伟大的目标呢，靠的不是我，不是你，是我们大家。自私、自治、自由就是先决条件。

自私，这里讲的是一个中性词，即满足自己需要为前提，才能贡献更多。在满足了自己需求的同时，也恰恰满足了更多人，很多开源贡献者的行为都符合这个规律； 另一方面，共治的前提是自治，只有每个社群每个人，都治理好自己社群，不倚赖不做伸手党，这样才能空出余力协手共治，否则自己的事情都搞不好，怎么可能参与协作？ 只有自由才能最终共荣，每个人在社群中都能享有自由的权利，不受压制不受封闭，也尊重每一个人自由表达，自由参与的权利，只有这样社群才能更多人愿意贡献其中，更多人愿意协手共治，共荣的局面才会最终到来。

### 社区文化和规则 ###

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

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

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

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

**作者:** 项目的创始人或创始组织

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**项目被接收的提交活跃度：** 在主干上确认提交的活跃度。在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？
 *  维护者是否对做贡献的人们道声”谢谢”？

### 不可不知的开源协议 ###

#### http://choosealicense.online/ ####

### 尊重他人 ###

先讲两个小故事，

#### 鲁候养鸟 ####

> 昔者海鸟止于鲁郊，鲁侯御而觞之于庙。奏《九韶》以为乐，具太牢以为膳。鸟乃眩视忧悲，不敢食一脔，不敢饮一杯，三日而死。 此以己养养鸟也，非以鸟养养鸟也。出自《庄子•外篇•至乐》

译文

> 从前，有一只海鸟停留在鲁国国都的郊外，鲁王让人驾车迎接它，并且在宗庙里对它敬酒，演奏《九韶》使它高兴，准备牛、羊、猪的肉作为它的食物。于是海鸟眼花了，忧愁悲伤，一块肉也不敢吃，一杯酒也不敢喝，三天就死了。  
> 这是用自己的生活方式来养鸟，不是用养鸟的方法来养鸟啊！

人与人，人与物，差异很大。你认为最好的，人家可能觉得不好，甚至可能觉得最差。以己度人，有时是错误的；主观臆断，往往导致事情失败。对事，你要尊重事物的本来规律，不能想怎么干就怎么干，盲目的想当然去干，就肯定干不好。

## 我为开源做贡献 ##

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

### 问题的艺术 ###

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

在你开启一个isse或PR之前，或者是在聊天室问问题之前，请牢记下面所列出的几点建议，会让你的工作更加的高效。

*  收集然后再给出上下文  
    ? “X 出问题! 请修复它。”  
    ? “当我做 Y 的时候 X 不能工作”
 *  有备而来  
    ? “我该怎么做 X ?”  
    ? “我不确定 X 是如何实现的，我查阅了相关的帮助文档，然而毫无所获。”
 *  言简意赅  
    ? ” 有一天我驾驶汽车行驶在高速公路上，在某个加油站加油的时候，突发奇想，我们应该这么做，不过在我进一步解释之前，我先和大家展示一下…”  
    ? “我很乐意写 API 的教程。”
 *  OPEN  
    ? (邮件) “你好，非常抱歉给发信，但是我实在很希望你能看一下我提交的PR。”  
    ? (评论) “@维护者 你好！我们该如何处理这个PR？”
 *  胆大心细  
    ? “你为什么不修复我的问题？这难道不是你的项目吗？”  
    ? “感谢查看了这个错误，我按照您的建议做了，这是输出结果。”
 *  尊重社区的决定  
    ? “你为什么不支持我的用例？这是不可接受的！”  
    ? “你不能支持我的用例，我蛮失望，但是你的解释仅仅是对一小部分用户起作用，我理解是为什么。感谢你的耐心倾听。”

### 创建Issue ###

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

*  报告你自己无法解决的错误
 *  讨论一个高级主题或想法(例如. 社区、远景、政策等)
 *  期望实现某新的特性，或者其它项目的想法

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

*  如果你刚好看到一个开放的issue，恰是你打算解决的， 添加评论，告诉他人你将负责这个。这样的话，可以避免他人重复劳动。
 *  如果说某个issue已经开放很久了， 这可能是已经有人正在解决中，又或者是早已经解决过了，所以也请添加评论，在打算开启工作之前，最好是确认一下。
 *  如果你创建了一issue，但是没多久自己解决了， 也要添加评论，让其他人知道，然后关闭该issue。记录本身就是为社区的贡献。

### 创建 pull request ###

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

*  提交补丁 (例如，纠正拼写错误、损坏的链接、或者是其它较明显的错误）
 *  开始一项别人请求的任务，或者是过去在issue中早就讨论过的

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

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

### Github操作流程 ###

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

*  Fork 代码仓库 并克隆到本地，在本地的仓库配置“上游”为远端仓库。这样你可以在提交你的PR时保持和“上游”同步，会减少很多解决冲突的时间。(更多关于同步的说明，请参考这里.)
 *  创建一个分支 用于自己编辑。
 *  参考任何相关的issue 或者在你的RP中支持文档(比如. “Closes \#37.”) 包含之前和之后的快照 如果你的改动是包含了不同的 HTML/CSS。在你的PR中拖拉相应的图片。
 *  测试你的改动！ 若测试用例存在的话，跑一遍，以覆盖你的更改，若没有的话，则创建相应的用例。无论测试是否存在，一定要确保你的改动不会破坏掉现有的项目。
 *  和项目现有的风格保持一致 尽你最大的努力，这也就是意味着在使用缩进、分号、以及注释很可能和你自己的风格大相径庭，但是为了节省维护者的精力，以及未来他人更好的理解和维护，还请你容忍一下。

\#\#\#总结

自由、开放、协作、分享就是开源的精神，现在已不是一个人的时代，任何英雄和天才都无法独力将平台做好。我们的大平台不是某一个人的大平台，是大家的平台。我们就是要不断的探索和实践，实现前端技术体系的共享、共建、传播。

最后，送给大家一句话：**开源的是知识，决定价值的是我们！**