如何加入开源项目的小手册

参与开源项目，可以快速提高自己的技术水平，学到很多学校中学不到但在工作中会非常有帮助的技巧。一份参与过开源项目的履历，也越来越受到用人单位的重视。所以最近几年，我们技术爱好者对开源项目投入的关注是越来越多了。可仍会看到很多对开源项目充满兴趣和热情的同学，用了错误的方式方法以至于不得其门而入。这段时间我特意将自己的心得整理了一下，供爱好者参考。

第一阶段：看和学

在和一些开源爱好者的接触过程中，我发现很多人都对自己关注的项目缺乏技术层面的理解。不论是对功能、代码或者项目的设计方向都很模糊，甚至大部分连代码都没有下载编译过。我想提醒爱好者的是，参与开源项目并不是靠一个简单的意愿就可以驱动的进程。阅读项目代码和了解设计脉络是必须的！

从小处着手：尝试修正bug/issue

绝大部分面向公众开放的开源项目都有issue区或者bug tracker。所谓issue区，也就是问题汇总。对项目有兴趣的爱好者，与其漫无目的开始，不如在issue/bug中先找到一个自己感兴趣的小问题，作为第一个目标并尝试解决它。

制作patch

patch又叫做补丁。是用来修补代码的文本文件。一个典型的patch文件例如:

--- clinkcc.orig/configure.in 2005-11-14 18:08:07.000000000 +0100

+++ clinkcc/configure.in 2005-11-14 18:08:13.000000000 +0100

@@ -150,6 +150,7 @@

AC_CHECK_FUNCS([iconv])

+AM_ICONV

可以看到patch文件是对修改前和修改后文件进行了比较，并将有差异的部分记录在文件中。例如使用命令行工具diff来制作的patch：

diff -u oldFile newFile > mods.diff

很多可视化版本管理工具本身也自带制作patch的功能。

通过小巧的patch，项目管理者可以快速的看到修订内容并进行评估。如果没有patch，项目管理者就很难对修改做出是否可用的判断。所以为了不浪费双方的时间，掌握制作patch的专业技巧也是必须的。

熟悉版本管理系统

开源项目中使用的版本管理系统的种类越来越多。除了被淘汰的cvs、传统主流的svn，新的版本管理体系例如Git和Mercutial(Hg)越来越流行。系统越来越多，确实增加了开发者的学习成本。但也只有掌握版本管理系统，才有可能和其他项目开发者并行开发并进行友好的协作。因此在完成第一个issue的阶段，也是摸熟版本管理工具的好时机，要好好把握。

代码规范

现代的各大开源项目对代码规范的要求越来越严格。在几十人以上和近百万行代码的项目中，必须依赖代码规范来保证代码的可读性。所以在撰写代码时，一定要注意是否符合该项目中对代码规范的要求，以免被退票。

遵守规则

一些大型项目中，可能还有除了代码规范之外的项目规则。一定要仔细阅读清楚主页或开发者社区的相关说明，以避免不必要口舌。

更进一步

联系项目管理者

当有一些可能带来重大改变的想法时，务必要先和项目管理者保持良好的沟通。通过email或邮件列表或irc将你的想法描述清楚。获得项目管理者和项目中其他开发者的认同和帮助是一个关键。附带提一句，初次联络时，务必不要忘记自我介绍，这并不仅仅是礼貌，更是建立信任的主要基础。

成为固定成员

通过积累patch和建立信任的阶段之后，通常管理者都会主动邀请你成为固定的开发成员。对于这个问题，我的建议是保持良好的心态，该来的自然会来。

建立新的分支或Fork

Fork是我认为很难翻译的词。Fork的原意就是餐具中的叉子，没有任何褒贬的倾向。在开发者的世界，可以将它理解为师出同源的几个叉子尖。当你对项目有一个“狂野”的想法时，项目管理者可能并不愿意在项目中看到这样的实验性分支。这时就可以fork一个分支项目，来实现自己的想法。尤其是git和hg大流行的背景下，fork后再merge back变得很容易，所以fork对项目的维护负担也减小变得更容易被接受。

时间管理

绝大部分参与开源项目的开发者都是利用业余时间来撰写代码的。所以良好的时间管理，才能帮助你有效的达成目标。近年来开源项目的技术规格越来越高，有一个预先制定的时间表，更能帮助你准备好一个良好的心态而不至半途而废。只要用心和持之以恒，你就会受到关注和尊重，甚至是雇主的重新评估乃至嘉许。