Post

对开源的一些体会

2020 年首文,四五个月没写过新文章,再不出一篇,博客都快要长草了。刚好昨天 Chirpy 项目拿到了第 100 个 Star,所以踩点回忆一下将博客项目开源的初衷、过程中的体会以及对未来的一些想法。

开源的初衷

每个的项目的诞生,都会有其特定的背景需求。当时我面临的需求是,找不到自己想要的博客模版。另外,对前端技术觊觎已久却没有机会去接触实践,所以就从 2017 年末开始新建一个 Jekyll 项目,全新开发自己的博客。

从第一行代码开始,博客仓库在 GitHub 上一直保持 public 的状态,原因有两个:

  1. 在 2019 年 1 月 之前,免费账户不能把仓库设置为 private。
  2. 免费账户不能对 private 仓库启用 GitHub Pages 服务。

第 1 点因素已消逝在历史长河,而第 2 点至今还在延续。起初我选择开源,完全是受丐帮精神的驱使,旨在把博客免费托管在 GitHub Pages 上。

认真对待开源

等到项目发展成熟到一定程度,开始觉得若只有自己一个人用,未免太过浪费劳动了,虽说设计和功能没有多么的惊艳,但是让后来玩 Jekyll 的人多一个选择也不是件坏事。于是在微软的扶贫济困以及某些不文明用户的推波助澜下,2019 年 1 月,我把博客的架构分离,使之成为一个开箱即用的模版项目。不过,在 README 上只留下草草几行字和一张预览图,而且对项目没有进行任何推广,代码设计也是以自己用的爽为标准,对外传递的态度是:「爱用用,不喜欢就滚」。

这种状态维持大半年后,我开始对项目有了新的想法,假如有用户群,那么项目就可以得到不同类型、版本的浏览器和终端设备进行测试反馈,另外还可能得到其他开发者参与对项目的改进(思路或者修改源码都行)。那么,就必须要准备详尽的文档去指导别人在本地安装、运行项目。

同年 8 月,项目新增了几个方便用户运行部署的工具脚本,另外还专门上线了一个的 Demo 站点供游客直接体验项目,文档也同步补全。这是一个转折点,不知不觉间,开始有了开源项目该有的样子。一旦资料齐全,某些汇集博客设计的平台就开始爬虫抓取项目信息了,如 jekyllthemes.devjekyll-themes.com 等,它们是自动并且免费的项目推广渠道,于是开始有了第一批的用户。

随后的 9 月份,对项目 README 进行了严格标准化书写,浏览量也逐渐多了起来。随着 Issue 的数量增多,为了节省时间,应景增加了 Issue 模版。最后,对项目有实质改进的 Pull Request 也出现了,其中一些对项目有了正向推动。至此,当初的小心愿全部达成。

Star 与 Fork

项目的 Star 是每个开源项目作者都喜欢的东西,平时在技术论坛会遇到很多人发帖求 Star,但是这个 Star 的数量是不是和项目质量成正比呢?经过混在 GitHub 的日子看来,答案是否定的。GitHub 的 Explore repositories 经常推送一些项目,其中不少坐拥几百个 Star,抱着学习心态点进去看,发现内容却是一言难尽,所以我对 Star 的看法是:把它当作一种随缘的精神鼓励,实际上的作用是,可以增加项目在 GitHub 上的曝光率。另一方面,对于 Fork,通过观察派生的子树项目可以洞悉用户的使用习惯,以及他们会遇到的阻碍,进而改进项目工具脚本以及文档。

遇到的一些事

困扰

开源遇到的第一件事情是:来自别人的提问。有疑问是正常的,项目文档可以帮助用户自我排查问题,省去提问的环节,对用户和作者双方来说都可以省下可观的时间和精力。因此,我尽可能的把所有安装使用细节写在 README 或者 Demo 网站上。然而,偏偏是有那么一群人,不屑文档的存在,或者不曾尝试自行去思考、搜索答案,把开源作者当人工服务专线:一个劲的发邮件私信或者 Issue,甚至有的还要求加社交 APP 一对一辅导解答,真是喵了个咪了。一开始还能心平气和地应对,后来次数多了,不堪其扰,对这类情况处理的方式逐渐变得果断高效:邮件私信提此类问题的一律怒删;跑到 GitHub Issue 留下无脑提问的,一律加上标签 RTFM 教做人。作为伸手党不看文档瞎提问,缺失最基本道德标准和人文素养,那么休怪我无情了。人生苦短,不值得为这些琐碎事浪费时间。

接着,还会发现有些「人才」喜欢悄悄拿走项目,然后删掉源码文件头部版权声明。博客项目基于 MIT 协议开源,允许改为私用没有问题,可是删出处声明这也太恶心了,MIT 协议是限制要求保留原项目 License 的。即使被删地址改名称,但如果我想找出来,还是很容易的。有这类奇葩行为的用户不限某一地区或国家,本人不针对特定的文化背景或者地域的人,吐槽的是行为,对事不对人。

欣慰

除去上述种种怪象,开源社区本质上仍旧是一个充满阳光和爱心的地方。譬如,项目不定期收到「谢谢分享」之类的留言,对作者就是莫大的精神鼓励,还有就是很开心看到用户们在此基础上部署自己的博客,然后分享他们在各自领域上耕耘的成果,促进了互联网的知识分享和流通,这难道不是博客项目开源的最大价值吗?

最后,讨论一下项目打赏(网络乞讨)。事情是这样发生的:某天醒来,我收到一条暖心留言说要为项目打赏,但随后下意识地婉拒了。当时我的认知是 ── 开源意味着免费提供使用,无须和金钱挂钩。过了一段时间,无意间看了一些国外开源大佬对打赏文化的解读,才逐渐了解到:开源接受打赏未尝不可,因为打赏是用户对作者表达感谢的一种方式,这个渠道不应该被强行阻断。其次,平心而论,项目的开发及运营必定会占用开发者的私人时间,时间就是金钱,打赏可以补偿一下开源作者的时间的损失,或者运营的成本支出,使其能够更好地投入开发,保持开源社区的良性发展。一番考虑过后,只好含泪把讨饭链接贴在 GitHub 项目里面了。

未来的计划

将来如果有新的想法,就会把有复用价值的新项目开源出来,但是不会公开那些实验性质的项目,毕竟保障开源项目质量人人有责。

再说句题外话凑字数:当下 COVID-19 全球扩散,希望健康的人们疾疫不临,感染者早日康复,逝者的灵魂可以安息。

This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.