[心得分享] 我在 GitHub 上学习开源

文章拖了将近一年的时间，我想是时候可以把两年多在 GitHub 开源的经验分享给大家，虽然不及神人级的开发者，但我始终相信，分享、自由、开放、讨论和开发者是开源的核心精神。

如果你不知道什么是 GitHub，但多少应该也知道 Bitbucket, CodePlex, Google Code, GitCafe 等等，就先假设大家都知道吧～

先说声抱歉，也许用词上大家可能不太习惯，再请大家提出修正并给予建议。

文长，对着电脑的各位，进入正题前，泡一泡咖啡提提神！

[ 接触 GitHub ]

N 年前听教授介绍开源有多厉害，国外高手都是怎么玩开源专案的，就从那个时候开始，接触了 GitHub。除了 GitHub 你还可以选择国产 GitCafe，用过 GitHub 都应该可以感受到，大众还是较为喜欢 GitHub，不论是 UI/UX、效率还是社群，GitHub 还是拥有极大的优势。

开始的时候玩一玩就立马上手，根本就是快快乐乐学 Git/GitHub，透过 GitHub 才慢慢了解 Git。一开始使用 GitHub 提供的 GitHub Desktop 来 commit push，但后来好像 bug 很多，这时就开始接触 command line (cmd)，就一直用到现在，现在已经回不去 GUI 了。

有付费买过 GitHub 私人空间的人和公司其实不少，但费用也不便宜。还记得之前在公司直接用 GitHub Importer 把整个公司专案复制一份到 GitHub 上，不费吹灰之力就完成了，如果你的专案是 svn，转换过去 git 也是没有问题的！

[ 前辈 ]

两年前自己很嫩（现在还是很嫩），前辈开始教我多学习别人的专案、学习模仿等等的，到现在我还是恨感激这位前辈，没有他推我一把，我可能就没继续开源下去了。看了几个星期后，前辈让我开一个专案，刚好公司专案是使用 AngularJS 当前端架构开发，那就写一个前端验证工具吧。定义需求、规则、功能，再来定义最重要的 SPEC，接着开始写主要模组，其中当然少不了被前辈叮说这怎么这样写等等之类的。

我还记得很清楚，前辈说：那开始写测试吧，写测试的时间是写模组的两倍时间哦！问题是，我怎么知道该如何写测试，而且是该死的 AngularJS，哪懂什么 protractor，由一堆什么 BDD/TDD, JUnit, QUnit, Jasmine, Mocha 的。就直接模仿了前辈的程式，也终于把完整的测试给写出来了。从开始到结束大约花了3个月的时间，前辈也已经离职了。大致初步功能也完成了，DEMO 页面也写好了，就立马开源，这里简称 A-V！

不要怀疑，前辈是个牛人，所以我非常的辛运！

[ N4J ]

其实在 A-V 出来之前，我只会 jQuery，正在学习 jQuery 写第三方套件的时候开发了 N4J 的前端工具，N4J 是纯粹学习用的，学习如何使用 GitHub、结构以及书写文件。还记得自己写得很开心，多年回去看还记得那时候的兴奋，后来毕业后也用 N4J 顺利拿到了聘书，毕业后就马上就业。

[ A-V ]

先说说 A-V 目前的状况，有 2xx commits、1x releases、2x contributors，比起大型专案这个数字没什么，但对我来说，这些数字都是一个肯定，一个成就，我想这是开源带给我的好处之一，也是让我持续投入时间的原因。

完成第一个版本后就马上上线了，写过程式的人都知道，这时候就会出现上线臭虫，版本 1.0.5, 1.0.6, 1.1.0 后，才开始慢慢稳定下来。

很快的，我试着在各论坛发表自己的作品，也包括中国的一些社群，分享自己这几个月下来的成果，但很可惜回应我的人没有很多，也许是作品没有爆炸性，毕竟只是个前端验证工具。其实不免有点小小的失望，没有人讨论，没有任何回馈。但有一点值得注意的是，AngularJS 在这方面还没有太多相关的套件和讨论，所以我算是进入了对的时间点。

几个月下来，我持续开发、增加功能、把程式写得更好，来了第一个 issue，后来也陆续来了几个，应该是我之前在某个论坛发文，有人看到进来给我意见。当然我就立即回覆谢谢他们的提议，马上修改或者问说有什么建议等等之类的。因为有人看到，star 了过后就会更多人看到，甚至有人开始丢 PR 给我，在这里我学到，有人丢 PR 给你，你一定要接受，除非他的程式充满问题，但也不能马上拒绝，要提出自己的理由决定是否要对方修改还是继续讨论下去。其实我在别人的开源专案也是如此，丢了一个 PR，几天内没有人回覆会觉得很伤心，但一旦被接受或者回覆，心理会很开心，太棒了，被接受了！这是一种被肯定，支持的动作。所以只要有人丢 PR 我大部分都会接受。

接下来的几个月，更多的 issue 更多的 PR，一个人无法承担所有的问题，所以很多我回覆后就没有继续了，一旦有时间可能是一个月后，才有时间回来看到底发生什么问题，就这样慢慢把 bug 修复。还记得有一次，有个 issue 几个月下来都解不了，某天晚上到了咖啡厅坐下，瞬间就解掉了，这一定要上一个新标签说 “fix feature or major improvement”，其实这是开发开源的小确幸，只有你知道发生了什么事，即使你公告了你修复这个功能，会理你的人没有多少。

中间当然有停下的时候，完全没有任何声音自己也没动力继续开发解 bug，但突然有人丢了一个 bug 或者 PR 过后，又会瞬间热血起来，不修掉不行的那种感觉，修掉后会很开心，然后又会安静一阵子。大概就是这样来来回回的状况。

当然如果你的专案是那种爆炸性的，比如说 pageres、express、awesome，不会是以上的故事

前几个月，因为自觉专案掉入了谷底，很久没有更新也没有人问说进度，开了一个 issue “Looking for Collaborators”，自以为会有人自告奋勇的说：“我来”，结果一个都没有。在这里我学习到的是，开源专案，就是要让他慢慢的酝酿，果然某一天有人丢了个PR 几乎大改了我整个专案的架构，改着改着他的兴趣就来了，我就问他说要不要当 Collaborator，他也就马上说好。后来我们也开了个Slack 群组，讨论著 A-V 的开发。也许有人觉得这没什么，但是这种与网友一起奋斗，讨论著彼此的专业，这份经历是工作永远无法取代的。

以上故事就是不停的 loop，持续了两年，直到现在不是一个人在开发修 bug，而是有同伴一起讨论，彼此给意见，这就是开源的魅力所在。

A-V 过后，陆陆续续展开对开源的兴趣，看了很多知识产权的选择（还是觉得迷迷糊糊的），期间也开了不少的专案，像是 IG、GE、SSS、JSD 等等的，虽然没有像 A-V 那么精彩，但难免还是有issue 有 PR（真的很珍贵）。

[ A-J ]

A-J 专案虽然不是我开始的，是我主动寄信给作者要求成为 Collaborator。A-J 属于爆炸性的专案，现在已经有四位数的星星，通常这类型的专案 issue 和 pr 会多到你接手软会想吐，大概会忽略他一阵子，然后一段时间后再来慢慢处理。但是既然是自己主动要求帮忙的，就有责任继续维护它，开源要学习的其中一点就是－主动，包括提出问题、意见、结果、拒绝，你的任何一个动作都在帮助一个开源专案的进步，这里就真的是责任制了。每个专案都有自己的步调，你也可以不要主动，让原开发者自行决定专案方向。

[ Gitter ]

其实我觉得 GitHub 提供的 Issue 已经很好用了，整个专案的讨论都能在 Issue Comment 完成，有必要还能互相关联，甚至下标签来整理 Issue 分类。但有时候不是所有人都喜欢在 Issue 问问题，也有可能担心问到重复的问题。

如果你的专案很大，你可以建议大家到 stackoverflow/segmentfault/irc 寻找问题，但对于比较小的专案，可以使用Gitter。 Gitter 是一个聊天室，会自动整合 GitHub 专案，任何的动向都会纪录在 Gitter 内，让所有人进入一个独立的空间讨论问题。多一个管道让大家凝聚，其实多少也能帮助到你，因为一个聊天室里面，大家都能发言，你不回答其他人会帮你回答的。

[ 已死? ]

常常逛 GitHub，你会发现有很多有趣的专案，但看到最新的更新时间，什么！是一年前。这时候就会开始脑补，是不是专案已经没有在开发了，作者似乎也消失了，有好多 issue 好多 PR 都没有被接受。自己也尝试丢了 issue 询问专案开发进度，当然也没得到任何回应。偶尔还是会觉得很可惜，这么棒的一个专案是不是被抛弃了。

但是不要气馁，就因为这是開源，这是一个开放的社群，任何人都有权利查看修改更新（有的是不允许的），先查查看 fork 分支，有时候分支的星星数还会比原本的专案多，再看看 issue 里面有没有人在讨论替代方案。最后一招就是自己 fork 自己改，当然你也可以开一个全新的专案来做一样的事情。

[ END ]

以上是我在 GitHub 上学习開源的经验分享。对我来说，滑 GitHub 已經成為我生活中的一部分。打开 GitHub 点击 Explore 常常会有意想不到的新专案，也是吸收新知识、新趋势的好地方。

有人说，维护開源专案，就像是开一间公司，你要不停的对他持续开发，对的时机对的功能，持续研究并找寻突破点，公司才能活得久。

原谅我把专案的名字都缩写了，因为这不能是个广告文，但不瞒各位，我就是来骗赞的啦，骗星星为其次，再来骗 followers，但我一定會持续开源，增加自己的能力。

不知道大家的开源经验是什么呢？