Blog

Blog

PHODAL

个人开源的困境:开源只能交个朋友

Ledge 知识平台 发布的这一周多里,我一直在思考如何让这个项目做得更好。在和 CSDN 编辑的讨论中,我意识到我可以把这个过程中的相关经验分享出来。因为毕竟大部分的开源项目做得不好。

除了写代码之后,我们做了这么一些事情,使得这个项目可以好好的运转下去:

  • 我写了一篇宣传方案。扩散到相关的微信群里,发布在公号、知乎和其它写作平台上。
  • 我通过社交平台微博、Twitter、Bilibili 等扩散了项目的信息。
  • 我写了两篇技术实现原理。发布在 InfoQ、CSDN 等专业平台上。
  • 我和我的小伙伴们,建了个微信群,以实现快速反馈。
  • 我们鼓励开发人员为开源项目做贡献。
  • 我们联系了不同的 DevOps 厂商,来共同发展这个项目。
  • 我们以透明的方式不断公布、上线新的特性。
  • ……

它的运作模式和我早期在 GitHub 开源的学习应用 Growth 几乎是一模一样的。大抵是因为我对开源的运作模式相当的熟悉。不过,从某种意义上来说,它还是一场关于影响力的游戏。

不了解开源项目的运作模式

从我的观察来看,大部分的开发人员连 README 也写不了。因为工作或是业余开发的需要,我经常在 GitHub 上搜索到相关的项目,而这些项目,它可能:

  • 只是把代码扔在了 GitHub 上
  • 缺乏一个可读的 README
  • 没有截图(对于 UI 项目)
  • 除了看代码,不需要从哪下手
  • 找不到任务的相关资料
  • 对 issue 没有任何响应
  • ……

tips: 这些技巧基本上都可以在《GitHub 漫游指南》上找到,这里就不详细展开了。而事实上 GitHub 官方也有一份非常不错的开源指南。读一读这些指南,再开展你的开源项目,你会发现开源真的很容易。

tips: 参与一个知名的开源项目,你就知道开源项目可能是怎么运作的。

缺乏多角色能力

在这个过程中,我承担了多个角色的责任:

  • 开发人员。没啥说的
  • 布道师。我要持续地写写文章,宣传宣传项目。
  • 项目领导者。嗯,就是打杂的那个人。
  • 市场人员。总之就是尝试去对接一些公司,以获得一些相关的案例,成为合作伙伴。
  • 程序员鼓励师。是的,作为一个开源项目,大家都是拿业余时间来练手的,需要不断地鼓励他们。
  • 代码评审者。大部分人是出于提升自己水平的目的参与开源项目,所以给他们一些建议,能帮助他们更好地成长。
  • ……

tips: 所以,如果你缺乏这样的能力,你可以找找感兴趣的小伙伴来一起搞搞。

看不见收益

从某种意义上来说,开源是一种信仰。而信仰这种东西本身又是一种玄学。所以,多数时候,开心就好。

一谈及收益的时候,我们可能也就有了点结果导向的意思。当你开了一个坑,你会期望得到什么?

  • 额外的收入
  • 简历上新的一笔
  • 一份新的工作
  • 让别人觉得你很优秀
  • ……

事实上,多数时候,你刚开坑的时候,你也就只能交个朋友了。除非,你做的项目特别优秀,并且绝无仅有,否则你只能通过长期的投入来获取收益。

tips: 如果你做的是应用,那么不妨以练习技术作为目的。

tips: 优先不要考虑那些悲伤的问题,比如 IE。谁要用 IE,谁自己来支持 [狗头]

tips: 开源最重要的是让自己开心

没有时间投入

我是一个开源的狂热粉,而使用代码来创造事物又是我的乐趣,所以我会把时间投入于此。既然是如此,也需要划分一些时间来做专门的事:

  • 平时修修小 bug
  • 周末写写新功能
  • 偶尔换个项目,换个心情
  • 放松一下,什么也不做

不过呢,对于国内 996 的现状来说,大部分的开发人员是没有多余的意愿投入在这个领域。周末陪男朋友玩玩文明不好吗?周末陪女朋友逛街不好吗?

不懂得宣传

在信息同质化 + 越来越垃圾的今天,绝大部分的同类的项目都会迅速地走向死亡。只要别人在宣传上做得比你好,就有可能获得后发优势。一个典型的例子,就是前端框架 Avalon,框架本身非常好,但是却没有铺展开来。

当你觉得你做了一件非常了不起的开源项目,不要畏惧,你可以尝试:

  • 到相关的技术论坛上发个简单的介绍。
  • 写写文章,发布到一些写作平台上
  • 寻找相关领域的专家,看看他们的意见。
  • ……

关键时候,你的软能力往往比你的代码硬能力来得更重要。

缺少度量数据

开源最怕的一点是,你发现你辛辛苦苦做的东西可能没人用。所以,诸如 GitHub 这样的平台,提供了大量的度量数据,以帮助开发人员了解项目的情况。像 GitHub 的 stars、traffic 都是一些非常好的功能。

所以,不妨通过一些工具,诸如 Google Analytics 建立流量的度量等。

缺乏愿景和规划

大部分项目,可能还没有到这一步就放弃了。

开源是一个目标明确,过程松散的运作模式。大部分项目都会有一个明确的目标,基于此,大家才能一起朝这个方向前进。

所以,你可能需要花点时间:

  • 制定你的发布计划
  • 更新你的 Todo
  • 勾勒一个美好的未来

结论:开心就好

坚持你觉得对的事,你就会能得你要的东西。

如果你过于期待收益的话,那么你可能就不会开心。

THE ONLY FAIR IS NOT FAIR,ENJOY CREATE & SHARE!

附 1:Ledge 时间线

让我再梳理一下宣传的时间线,希望能给大家一点启示。

  • 2020.03.30 我在 GitHub 上 public 了代码
  • 2020.03.30 我们和同事建了 Ledge 的开发群
  • 2020.03.30 21:00 在公众号上发表了文章《Ledge:这可能是距今最好的『DevOps + 研发效能』知识平台》,距今(2020.04.11)阅读量 3829
  • 2020.03.31 微信群超过 200 人
  • 2020.03.31 在知乎发表了同上的文章,距今阅读量 5208
  • 2020.04.01 在 SegmentFault 上同步了上述的文章,阅读量 614
  • 2020.04.01 SegmentFault 微博上扩散了这篇文章
  • 2020.04.04 投稿 CSDN 公号上《程序员造轮子的正确姿势》,阅读量 2.9 万
  • 2020.04.07 《程序员造轮子的正确姿势》发布在自己的公号上,阅读量 1242
  • 2020.04.08 首发 InfoQ 网站上《文档代码化实践》,阅读量 947
  • 2020.04.08 《文档代码化实践》发布在自己的公号上,阅读量 1646
  • 2020.04.09 《程序员造轮子的正确姿势》发布在知乎上,阅读量 7,338
  • 2020.04.11 《文档代码化实践》发布在知乎上,阅读量
  • 2020.04.11 我写了这一篇新的文章,但是还没发布。

五天内的 GitHub 访问数据

03.30 03.31 04.01 04.02 04.03
访问量 999 1702 1265 390 378
访客数 229 622 352 141 114

或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签