如何在GitHub上收集Star?

https://www.zhihu.com/question/23748804


# 0

链接:https://www.zhihu.com/question/23748804/answer/121413341

来自Richard Kim
medium.com/@cwRichardKi

如何在Github上得到成百上千的收藏?
——五个热门repo主的一点经验

有一个矛盾之处:你花了很多时间写了一个东西,你免费分享出去,竟然没有人想要?这是因为存在一个死循环:

想要别人用你写的东西?
那别人得相信你。

想让别人相信你?
那你得有很多star证明别人用了都觉得不错。

想要star?
你得先让别人用你的东西。
或者
写一些很好看或者很有用的东西

或者后面是打破死循环的关键,想要做到这个“或者”,可以参考一下这篇指南。

我之前是iOS程序员,六个月前才开始写开源。我和很多大牛程序员都比不了,我也没我的主页看起来那么屌。我能有看起来很屌主页,大部分要归功于我还会一些设计。我在六个月内有五个热门repo,我把我成功的经验分解为六个步骤:
  1. 项目第一
  2. 阅读调研
  3. 建立repo
  4. 写好README
  5. 图片
  6. 正确处理反馈


  1. 项目第一。解决别人的问题,意识到自己很多时候是在写重复的东西,才能知道什么时候自己创造出了一些别人可能想要的东西。做一些side project。
  2. 阅读调研。别人解决过的问题你就不要解决了。如果别人没做过或者做得不行,你的机遇就来了。Github Issues可能是个灵感源泉。
  3. 建立repo。以前我写很多优化,拖很久,力求完美,后来我发现,建立一些质量达标,可用性搞的东西性价比更高。
  4. 如果没人看得懂你在写什么,也不会有人用你的东西。我建议:写了一小时的代码,也要写一小时的README. 我认为这是我在Github成功的主要原因。我的README大概是这个样子cdn-images-1.medium.com*JK3G5F-iIO7JFwxN9Dnwrw.png。几个要点:多用图片,尤其是动图。不要说这个很好用,能用动图展示的就用动图展示。必须要有HOW TO部分,大部分人没有耐心慢慢看。如果有人提出了问题,把回答加入README。
  5. 用心的设计你的图片,图片的力量远大于文字,而且便于分享。这是我做的一张图片,简单的展示了效果:cdn-images-1.medium.com*qi3NQaPRoC-LidNdZS4lLA.gif GIFs可以用LICEcap捕捉然后用GIMP编辑,这两个工具都是不要钱的。
  6. Github的热门是这样一个机制:上了当日热门,再本周热门,再本月热门。所以你只要先争取当日热门即可,上了当日热门,只要你的东西有价值,自然很容易被Github用户收藏。为了上当月热门,你需要:
  • 在社交网络上发个带图片的链接
  • 在一小时内得到反馈
  • 根据反馈进行修改/回复反馈
  • 重复步骤2直到满意

你可以挑选一个你自己喜欢的社交网络,我个人喜欢reddit,那里的用户都比较友善。有时我也会找朋友同事,选一个你认为比较方便的方法。

总结:这不是万能的解决方法,但是这会帮助一个好的项目脱颖而出。记住:越是复杂的项目就越需要文档。

注:本文只翻译了核心要点


# 1


链接:https://www.zhihu.com/question/23748804/answer/25563561

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

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

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

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

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

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

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

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

第二,如何吸引程序员

2.1. google搜索与SEO优化。

想象一下,程序员试图解决问题的时候一定会使用google搜索。
假设一个Python程序员想做个网站,
他可能会在google里面搜索
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. 一个简洁的安装配置攻略

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

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

最短的安装攻略通常是最好的,
比如这样:

《how to install emacs》
sudo apt-get remove vim
sudo apt-get install emacs

抱歉,窜台了。

coffeescript的安装攻略:
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上的开源项目中,
可能会看见一个这样的按钮,图:

<img src="https://pic2.zhimg.com/50/08d626ceb9cbc238dec1ee2d15c34c17_hd.jpg" data-rawwidth="672" data-rawheight="206" class="origin_image zh-lightbox-thumb" width="672" data-original="https://pic2.zhimg.com/08d626ceb9cbc238dec1ee2d15c34c17_r.jpg"> 如何在GitHub上收集Star?_第1张图片这个就是一个持续集成(Continuous integration)工具,叫travis-ci。
它有很多很牛X的功能,
其中一项就是自动执行单元测试(绿色的passing就是表示测试ok)。
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. 结尾
写的比较混乱,
错误也在所难免。

欢迎大家指正。




你可能感兴趣的:(【】)