技术人怎么做开源社区？
这个问题，每年都会有很多朋友问起我这个问题，问的久了，发现其实每次跟朋友聊的时候都在说重复的东西。 像我这样懒的人，今天决定干脆整理一下写出来，下次其他朋友再问起，我就直接把这篇博客发出去，哈哈哈哈。
强悍的技术能力
很多公司和组织其实没有明白开源社区的本质，开源社区的本质其实还是技术，技术的本质就是你写了一个非常牛逼的项目，但是这个世界上还有能力比你更强的高手，他们看了你的项目非常喜欢，但是想往里面加点方便自己的功能。这时候，他们往往会花几个晚上甚至几个月的业余时间来研究你的代码，hacking it，当他们终于实现自己的功能时候，就会发送一个高质量的补丁给你，希望你能Review后合并。
这个时候，其实最考验开源项目作者的能力，因为这个补丁的贡献者的能力可能比作者还强，会写非常高质量的代码，作者不但要读懂补丁的代码，还要考虑代码风格和补丁对整体架构的影响，保证补丁合并后不但功能增强，还要求补丁不能引入新的Bug和安全漏洞。
所以，开源社区做的好，第一个就是技术基本功要过硬，而不只是很多公司想的，搞一个运营部门，什么都说好，因为开源社区里大多数人都是顶尖的技术高手，光说“亲，谢谢你”是没用的，高手更喜欢被作者和同样牛逼的高手认同。你给这些高手的补丁提出你的代码改进建议或者直接合并补丁是他们最期待的东西。
要会夸人
大多数技术高手其实很容易做到刚才我说的第一点，但是第二点，我想90%的技术人都做不到。
夸人为什么这么重要？
开源社区除了很强的技术基因以外，它还具有很强的社交属性。简而言之就是你要想办法让这些社区的参与者获得挑战和成就感。
举个例子，有人想给我的 Awesome-Tab (Emacs最著名的标签插件) 贡献一个补丁，使得它可以具备Ace Jump这个功能，我第一眼看到，其实知道怎么实现的，但是这时候最应该做的反而是，鼓励这些功能要求者自己去实现这个功能。
可能当时这个开发者并不具备开发他想要功能的能力，但是他因为喜欢这个功能，对这个事情有超强的意愿，然后他会想方设法，不睡觉花很长时间去研究，去攻克技术难题，因为世界上他对这个功能最执着，也具备最强攻克难题的决心。当他历尽千辛万苦终于实现这个功能的时候，他已经不仅仅是社区的贡献者，他会从心理上变成开源项目的作者，对这个开源项目有深深的认同感，因为他被这个开源项目的复杂性给虐过好多晚上，同时他也在攻克的过程中对开源项目的代码细节越来越熟悉。一旦这个时候你合并他的补丁，会更加激励他。从我十几年的开源社区经验来看，当一个开发者贡献了一个很难的补丁以后，他往往还会贡献第二个，第三个，甚至以后变成这个开源项目中贡献最大的贡献者。
但是，我看到很多技术人遇到Github有人提出Issues时，不是鼓励社区用户变成社区贡献者，而是自己坑次坑次的把代码写完了，功能实现了，需求提出者当然很高兴，但是你因为对自己的技术和虚荣太过于自信，导致你错失了一个锻炼开源贡献者的机会。长此以往，开源项目只是你个人代码的FTP，但鲜有合作开发者帮你，当有一天你因为工作，生活或者只是简简单单的厌烦，开源社区就会因为你个人的原因而死掉。
还是以Awesome-Tab为例，其中一个开发者，贡献了自适应Emacs主题的补丁，我就狠狠的夸他，从最基础的 Thanks man 到 Wow, cool man 甚至 Awesome, you are definitely a genius! , 大多数技术人会觉得这种夸奖很浮夸，但是我要告诉你的是，当你这样被别人夸奖的时候，你会飞上天的，因为一个著名开源社区的作者当时的技术水平是你十年以后才能达到的水平，但是获得这种浮夸的夸奖以后，你真的会上天的，以后你会像打鸡血一样继续给社区项目贡献。
这就是开源社区社交属性的源泉，学会变着法子夸人，如果你不会夸，我告诉你一个方法，去那些著名的开源社区项目中，看那些已经合并的PR里面，翻他们的聊天记录，你就知道著名开源项目的作者是怎么夸人的了。
README和文档一定要写的详细
很多朋友都会觉得做开源社区很难，或者有什么技巧，其实开源社区一点技巧都没有，都是扎扎实实最简单的东西。
第三点就是README和文档，一个非常好的README应该怎么写？
- 首先要用一两句话说清楚这个项目是干嘛的，切忌不要炫耀技术，说自己多么多么牛逼，用户不关心，你要说你的项目可以给用户带来什么？
- 在第一段话下面，放一张截图，最好是几秒的GIF动图，让用户看完以后马上懂这个项目是干啥的，如果看完动图以后，用户的感觉是 “我Ca，这个项目好牛逼，我一定要把它折腾好”，你就成功了一半了
- 最简单的安装文档，你要想尽任何办法把安装文档写的最简单易懂，因为一旦用户感兴趣你的项目后，马上就会想到怎么安装？一个复杂的安装文档会导致用户受挫，最终放弃你的项目
- 简单的用法，先告诉用户一个简单的用法，先不要着急把所有功能写出来，用户安装以后马上就可以实验就最好，一定要遏止住自己把所有功能堆砌出来的冲动，慢慢来
- 用户简单方法会了以后，写各种高级功能和FAQ，避免常见问题困扰用户
- 到这里，你已经做到了60分了，加一张架构图和架构图的原理说明，架构图用Google Docs来画，注意颜色和布局，画得漂亮点，如果原理太长，可以考虑做一个链接，不是谁都关心架构设计，一个好的架构设计图会让那些技术高手快速弄懂原理，培养潜在的开源社区贡献者
- 添加一个Todolist，写下你即将要做的功能，相当于一个简单的roadmap, 不管用户还是潜在的开发者都非常关心作者对这个项目的未来规划
- 最后10分怎么弄？把怎么贡献代码的文档写好，最好不要超过3步，方便初学者快速贡献代码
按照上面的方式把README写好，就等着高手来贡献吧，不要着急，文档好了，自然有人来看来贡献。 README写不好的结果往往是用户连安装都困难，更不用说将来有高手来帮你贡献代码。
README写完以后，可以写一些API手册和Example，越多越好，文档永远都是运营开源社区的软实力。
Issue和Patch处理一定要快
一般来说，任何Issue和Patch处理的速度一定要快，我一般早上和晚上会分别看一下Github，如果问题很容易解决，我一般在晚上的时候会解决后再睡觉。如果短时间解决不了，也会在下面添加评论告诉社区用户我当时的想法。
只要有真诚的回应，这个社区项目就是活跃的，健康的。
有时候我们看一个社区项目是否活跃，不能光看Commit是否足够多，Issue和PR的数量也是重要的参考数据。
很多时候，要做的更好，你可以在Issue和PR中不断的和贡献者们聊天，对，聊天。 你们聊的越High，他们越高兴，而且这些聊天记录往往夹杂很多技术技巧，以后当用户遇到问题后，用Google等搜索引擎搜素到这些Issue和PR的技术内容，都是一种潜在的传播方式。
代码要注意分支管理
当一个开源项目活跃开发的时候，往往会引入不稳定的Commit，不同的分支不但方便不同开发者快速测试不同的功能，还能保持正式版本的稳定性。
代码分支的管理是开源项目兼具新功能尝鲜和正式版稳定的基础保障措施。
如果发布新版本最好打一个Tag，这样别人好切换不同的版本帮你测试Bug。
挂CI机器人
如果你的项目不是那种下载即可使用的脚本代码，需要编译成二进制才能体验。为了让用户快速尝鲜，你需要在Github上挂一个CI机器人，每当你推送任何补丁，CI机器人都会帮你自动构建最新版二进制。
这样用户每次使用新版的时候，就不用自己编译代码，直接下载CI机器人编译好的二进制即可。
切记，你减少了用户使用你软件的门槛，就会把潜在用户量提高一个数量级。
多写技术博客
Github更多的是在代码和聊天层面解决社区协作的问题，但是真的把开源社区运营好，少不了系统化的技术博客。
在技术博客中画画架构图，写点介绍文档，示例代码，分享一下小技巧，都是推广开源项目很好的方式。
如果你的文风不错，博客写的通俗易懂引人发笑，还会达到授人于渔的效果。
注意Copyright
如果你拷贝了别人的代码，不管是文件的开头还是代码注释中，一定要写清楚原始作者的信息，这是开源社区最起码的尊重。
有幽默感
不管别人是帮助你，吐槽你，都要保持一颗幽默的心，能抗多少吐槽，开源项目就能走的有多远。
最后
开源社区做好的本质就是：技术好、会夸人、多写文档脸皮厚