酒香还怕巷子深。
确实如此。

一个优秀的开源项目，
如果长时间得不到有效的宣传，
它很有可能会永远默默无闻。

如何创建一个优秀的开源项目，
这基本上与你的编程水平有关。
打铁还需自身硬，
编程水平是优秀开源项目的前提，
不过这方面的文章/书籍实在是太多了，
本文不想讨论这个话题。

那么我就从“如何宣传一个开源项目”的角度来说说我的看法。

第一，开源项目大多数是给程序员用的。

那些给普通用户用的开源项目的宣传方法会有很大的不一样，
我不太了解，所以不敢随意讲。

本文只讲那些给程序员用的开源项目。

既然是给程序员用的，
那么你的宣传手段一定要符合程序员的使用习惯。

第二，如何吸引程序员？

2.1. google搜索与SEO优化。

Python web

如果你的开源项目在搜索结果中的位置比较靠前，
那么一定会吸引更多的程序员。

那么如果提高在搜索结果中的排名呢？
可以使用SEO优化。
SEO是一门很深奥的学问，
我了解的不多，就不做介绍了。

2.2. 项目介绍

一个简洁的项目介绍可以让程序员迅速地知道你的项目是要达到什么目的，
拥有哪些功能，
与同类项目相比有哪些优势。

2.3. 软件包，软件仓库

如果你的开源项目能够被ubuntu源、pypi等软件仓库收录，
那么对于你的开源项目也是大有帮助的。

ubuntu源可以使用dpkg打包，
Python有pip，Ruby有gem，nodejs有npm。
把自己的项目代码打个包，然后提交给软件仓库的维护者。

2.4. 社区、论坛、邮件列表

还是用刚才的Python程序员做网站举例，
如果你能够在与Python web有关的社区、论坛、邮件列表里面宣传自己的开源项目，
那么就会更有针对性。

2.5. 做一个产品出来

如果你的开源项目是一个Python的web框架，
那么没什么比你自己用自己的框架做一个网站出来更有说服力。

而且很多开源项目，
也是先有的产品。
产品成熟以后，
产品的开发团队决定把核心框架开源出来。

比如django，
最初是被开发来用于管理劳伦斯出版集团旗下的一些以新闻内容为主的网站的。

第三，如何留住程序员？

好的，现在假设已经有好多程序员来到了你的项目主页。
接下来就是如何留住程序员了。

留住更多的程序员，让更多的程序员使用你的开源项目，
不但可以靠口口相传增加项目的知名度，
而且也会有更多的人帮助你完善你的开源项目。

那么如何留住程序员呢？

3.1. 一个简洁的安装配置攻略

当你发现一个开源项目的时候，
第一反应一定是在自己电脑上安装一下试试。

如果根本没有安装攻略/安装过程过于麻烦/安装过程发生意外错误，
很多人可能就直接放弃了。

最短的安装攻略通常是最好的，
比如这样：

sudo apt-get remove vim
sudo apt-get install emacs

抱歉，窜台了。

sudo npm install -g coffee-script

3.2. 一个简洁的教程和一份完整的API文档

3.2.1. tutorial
你需要一步一步地教那些刚刚看到你的开源项目的人如何使用你的代码。
这就需要一个简洁，但是可以涵盖大部分功能的教程。

3.2.2. API reference
你需要让那些已经用了这个项目有一段时间的人能够迅速地找到他需要的功能，
这就需要一个包含所有功能，易于搜索/索引的API文档。

第四，如何让已经使用你的开源项目有一段时间的人积极地为你的项目贡献代码？

在这里，我想表达一个我很久以前的观点。
这个观点可能有点偏激，大家可以讨论一下：

写出人类能理解的代码的难度，远远大于写出计算机能理解的代码的难度。

别人为你的项目贡献代码的前提肯定是他能读懂你的代码。
如果你的项目的源代码一片混乱，
比如文件夹的组织毫无规则，
类名/变量名使用无法理解的缩写或者过分奇怪的名字，
那么别说有人想为你的项目贡献代码，
可能根本不会有人读你的代码。

还是本文开头那句话，
打铁还需自身硬。
开源项目吸引人的核心还是项目作者的编程水平。
优秀的代码，
即使是一个陌生的程序员读，也会感到赏心悦目。

好吧，又扯到编程水平上去了。
现在回到我们刚才的话题。

我们设想一下，
如果你是一个开源项目的使用者，
你在什么情况下想要为开源项目贡献代码的欲望最强烈？

我个人的总结是3种： BUG，增加支持，新功能。
BUG和新功能很好理解。
增加支持，比如支持不同的平台。了解Linux的历史的人可能会知道这样的故事。Linux最初只支持极少数型号的CPU以及其它各种硬件。最终发展到现在支持如此多不同型号的各种硬件，可以说开源的力量给了非常大的帮助。

那么无论是哪种情况，
开源项目的用户其实只有两种可能的做法，
一是把自己的发现的BUG/新想法告诉项目的作者，
二是自己写代码实现自己的想法/修正发现的BUG。
分别讨论一下这两种情况。

4.1. 收集用户的反馈

其实我本来想写bugzilla之类的工具，
不过我猛然间想起了题主把问题限定到了github，
那么其实答案就很简单了。

github上提供的issue功能，
就是项目的用户与项目的作者之间交流的地方。

那么假设有用户给你的项目提了issue，
你该怎么办？

比较大的开源项目自然不用说，
由于项目的成员比较多也比较活跃，
很快就会有人回复/处理这个issue。

但是在项目初期，
就算有三五个人帮助维护你的开源项目，
主要的处理issue的工作还是要靠你自己。

如果是BUG，
你需要迅速地确认这个BUG能否重现，
然后迅速地回复issue，
说我已经确认这个BUG，稍后会修复它。

如果是新功能，
你可能会在issue里面讨论一下这个功能，
然后明确地表示我会接受/拒绝这个功能，
并且尽可能详细地表达自己的理由。

4.2. 接受用户提交的代码

github上提交代码通常是通过pull request的方式。
那么审核代码的尺度就是一个见仁见智的问题了。

我想说一下我的观点，
这个观点也可以讨论。

拒绝掉烂程序员的烂代码，可以帮助你获得更多优秀程序员的优秀代码。

那么如何审核代码呢？

4.2.1. 代码风格
每门语言都有自己的代码风格，
遵守既定的代码风格对于写和读代码的人都有非常多的好处。

而且有很多检查代码风格的工具，
比如Python的pep8和pylint。

4.2.2. 测试
人类肯定会犯错误，再牛X的人也会，这是无法避免的。
那么如何尽早的发现错误就显示非常重要。

现在比较好的解决办法就是在代码中写单元测试。
很多语言都有非常好的单元测试的框架，
而且github上还有持续集成工具，帮助你自动执行测试。

如果你留心的话，
在一些github上的开源项目中，
可能会看见一个这样的按钮，图：

如果提交上来的pull request的代码中加入了新的功能，
那么必须要求提交者加入完整的单元测试。

4.2.3. 其它问题
比如某行代码有更好的实现方式，
或者变量命名等 工具无法检查出的问题，
只能靠项目的作者一行一行地读提交的代码才能发现。

读到某一行，觉得有问题，
可以直接在github上评论的。
github支持对某一行代码进行评论。

4.2.4. 不要过早地拒绝pull request
除非是那种错的特别离谱的问题，
一般的小问题，你可以在pull request时评论给他。

那么他修正以后，可以push新的代码上来，pull request会自动更新的。

5. 多为别人的项目贡献代码

你平常是否也使用一些开源项目？
是否在使用中发现了一些BUG或者想到了一些可以改进的地方？

你知道抱怨是没有用的。
不如去找找这个项目的源代码，
试着读一读，
分析一下BUG在哪里。

不但可以看到这个世界上最优秀的一群人写出来的代码，
也许一不小心你就帮他们解决了这个BUG呢？

然后你就可以去给他们提交你的pull request了。
他们中有些人就可能会来follow你，
看到你主页上的项目，
可能会顺手star一下。

何乐而不为？

6. 结尾
写的比较混乱，
错误也在所难免。