开源 Python 库,但要说项目热度还得看 Rich。Rich repo 发布于 2020 年,在 GitHub 上拿下了 35000 星。在此之后,我又先后发布了 Textual(目前仍在开发中)和 Rich-CLI,并慢慢摸索出了在 GitHub 上获得高星的秘密……
在本文中,我想聊聊自己在 Rich 项目推广方面的种种尝试,也希望能给大家的开源项目带来一点启发。
一路飙升!后续我还会努力推广更多 Rich 式的成功项目,包括最近同样态势良好的 Pip。
我知道有些朋友确实会这么问……但是,你是认真的吗?
要知道,GitHub 上的公共 repo 在本质上其实就是专属于开发者自己的私有存储库。如果单纯是供自己使用、与外界隔绝的项目,那可能没有关系;但无论如何,提高项目知名度都肯定没有坏处。
在讨论推广收益之前,我想先跟大家聊聊搞推广可能带来哪些负面影响。
第一个问题就是 GitHub 上的 issues 选项卡会收到太多问题。别误会哦,我说的可不是 bug 报告,这东西当然是越多越好。但相反,我们收到的往往是功能请求——人们喜欢你的成果,要求进一步补充或者扩大项目的功能范围。
不管建议本身靠不靠谱,这些要求都会成为我们内心深处的一种压力,引导我们做出很多自己在规划中并不需要的东西。项目越是受欢迎,这类功能请求就会越多、占用的时间就越长。其实很多项目维护者就是这样一步步陷入倦怠,并最终带着愤怒甩手不干的。
另外一个缺点,就是项目的人气越高,我们就越是有责任保证它能跟其他项目顺畅对接。大家会发现自己需要在设计新功能与修复旧 bug 之间寻求平衡,同时考虑自己的变更是否在不经意间就毁掉了其他维护者的辛勤劳动。
总之,当我们在命令提示符中敲下 git init 的那一刻起,大家事实上已经失去了创作自由。你以为你真是这片代码王国的统治者?别搞笑了,这里遍地都是割据一方的地方势力。
是不是越听越没劲了?那咱再聊点正能量,毕竟独立创造出高人气的开源项目,对于提高个人影响力、找工作、推广业务、建立专业人脉等等还是很有帮助的。
我的个人经验也是这样,自己的小小项目让我加入到了 textualize.io 的开发团队。所以别怕麻烦,就算上面的问题都客观存在,我们也仍然值得、或者说必须走上项目推广这条正确的道路。
先给结论:千万别等到应用程序或者库的功能创建完整、优化到第 n 级而且没有任何 bug(如果真有可能)的时候再发布,这样你会错过大家参与项目的热情。当然,如果你的 repo 里只有一行 README 加 LICENSE 文件,那开展推广还为时过早。最理想的时间点,自然就是在这二者之间。
就个人经验,我认为最理想的推广点就是,当项目中已经拥有一些可供受众尝试和体验的功能时。注意,这时候功能并不需要很全面,一项核心功能就足够了。在这个阶段,我们的目标并不是占领市场、培养用户之类,唯一的诉求就是激发参与者的兴趣。
另外要提一点,README 往往比功能本身还更重要些。毕竟人们在访问 repo 时,首先看到的就是 README。所以,我们最好在第一段中清晰总结出这个项目是干什么用的,让用户知道该如何开始,向他们展示代码工作示例,最后给出展示结果。如果合适,还应该添加一些截屏信息,如果是视频或者 gif 动图就更好了。
对于某些项目,早点公开内容并吸引受众注意可能效果更好。我们可以在年轻人们喜爱的 Twitter 等平台上持续发布项目进度,这样在工作原型敲定之前没准已经获得了一定数量的关注者。
所以请在项目开发过程中定期发布消息。在本质上,这是一种表达开发热情的方式,必然能在受众群体中引发共鸣、提高影响。另外,我们还可以一边开发,一边把自己的想法、问题、代码片段甚至是项目走向投票引入进来。这种在公众视野内的开发过程更能激发情绪,人们给出的反馈也往往极具价值。
考虑到 Twitter 消息有 280 个字符的硬性限制,所以我们不太可能发布完整代码,只能用代码截屏的方式加以呈现。这里我推荐carbon.now.sh(https://carbon.now.sh/)和 snappify.io(https://carbon.now.sh/),用起来都很顺手。如果大家想让受众也能体验代码功能,可以用 gist(https://gist.github.com/)提供可粘贴的代码片段。
由 snappify.io生成的截屏
由carbon.now.sh生成的截屏
核心功能有了,清晰易读的 README 也有了,接下来就是把它们发布出去吸引人们的眼球。如果我们的项目跟特定技术关系紧密,第一步自然就是发布在该技术的相关论坛当中。但结合个人经验,我觉得发布在 Reddit 和 Hacker News 上的效果是最好的。
在 Reddit 上,我们可以选择跟当前项目关系紧密的子频道。以我的 Python 项目为例,/r/python 可能是个不错的选择;Reddit 规模庞大,总有一个子频道适合你。另外,注意给项目取个贴切而且能让人快速理解开发定位的标题。现在大家对标题党行为越来越厌恶了,所以除非各位对自己把握心态的技巧很有自信,否则最好别太过,免得弄巧成拙。发布之后,记得在评论中写下关于项目的精彩描述,之后坐等大家回复就好。
Hacker News 用起来也差不多。想要推广我们的项目,应该优先考虑把内容发布到 Show HN。这里是专门的宣传平台,帖子数量比常规平台少得多,所以内容进入首页的几率也会更高。跟 Reddit 一样,尽量别搞标题党、用良好的第一印象吸引受众、同时坚持回复每条评论。
如果一切顺利,那我们的项目往往能在首页上停留几个小时、甚至是一天以上。这时候引流作用就会显现,我们的项目开始获得 GitHub 星。同时,我们也能得到不少有助于项目发展的反馈。
但别把现实想得太美好。把项目消息发布到社交媒体也会招来不少负面消息,包括对于项目、代码甚至是开发思路的批评。尽量用宽容的心态看待这一切,从中挑出合理的部分。我们可以回应、讨论,但别想着改变对方的看法。如果总想占据智力和道德的制高点跟舆论对抗,我们终会被卷入一场毫无意义的“灾难性”对喷。
只要初步公告没出问题,接下来 GitHub 星就会慢慢涌来,甚至会有感兴趣的小伙伴加入项目开发队伍。
这时候千万别得意,继续积极参与讨论来保持项目热度,再用一个又一个新版本掀起更多小高潮。
Twitter 其实是个很好的媒介,我们可以在这里发布关于软件开发流程的看法、提出问题、获得反馈。我发现玩转 Twitter 的最好方法就是保持轻松和自嘲的心态。只有这样,我们才能让成功和失败的发布内容都成为项目的助力,让实现的功能与待修复的 bug 都化作提升项目热度的燃料。
项目中出现的代码设计缺陷可能会让开发进度停滞一到两个礼拜,但这对他人和我们自己都是一种锻炼与学习。只要始终以幽默的态度谈论这一切,轻松愉快的氛围肯定能吸引到更多关注。
下面是项目的新功能或者其他重要里程碑,这部分宣传工作最好放在博文中进行,再把文章转发到 Reddit、Hacker News 等社交媒体渠道。接下来我们就得双线作战了,既关注原帖评论、又跟进转发评论。如果可能,尽量多添加一些相关内容与截屏/GIF 动图,这样效果更好。
请注意,社交媒体上的传播效果其实有很大的运气成分。如果帖子没能得到多少关注、并很快被新消息淹没,也不要太过沮丧。等上几周,再试一次。
另外,请熟知各个网站上关于自我宣传与发布频率的管理政策。项目受众的建立并不容易,既耗费精力、也需要时间,发得太频反而可能被视为垃圾内容而遭到限流。
总之,慢慢摸索、坚持不懈就对了。
我之前提到过,功能请求这东西往往很难管理,我们需要用很礼貌的方式回绝那些热情的功能建议。但在核心功能集初步搭建完成之后,接下来倒是不妨以功能请求为参考设计应用程序/API 的开发工作。如果很多用户都提出了相同的功能需要,那这可能代表我们值得把时间投入其中。
同样的,如果很多人都觉得 API 或者功能中的某一部分用起来不舒服,那自然也需要做出调整。别固步自封,哪怕你认为用户是错的,但只要相同的意见够多,那也就是正确的。找到混乱的根源,用更直观的方案加以替代,结果一定会更好。
有些朋友觉得,总按别人的意见开发好像会让自己失去对项目的控制权。不是,千万别这么想。毕竟我们的代码可不是只供观赏的艺术品,它是产品、要拿来用的。既然是产品,就一定有使用者。关注使用者的感受,才能让产品获得成功。
原文链接:
领取专属 10元无门槛券
私享最新 技术干货