开源 - 汲取和共享 #23
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Hi， 大家好，很高兴来参加这次平安云主办的「我与 GitHub 的故事」的分享会，先简单的自我介绍下，我叫罗冉，GitHub 账号 @Jocs，是一名前端工程师，之前在饿了么大前端，目前在石墨文档任职，工作之余，开发一款叫做 marktext 的 markdown 编辑器。
今天的分享主要分为以下三个部分：
汲取养分，茁壮成长
参与开源社区，贡献微博之力
主导开源项目的得与失
汲取养分、茁壮成长
相信很多 GitHub 新人都遇到过这样的问题：
开源就是奉献和付出，但是我作为 GitHub 新人，我几乎什么都不会，怎么参与到开源呢？
我认为上面的话，即对又不完全对，无论是普通开发者还是技术大牛在其职业生涯早期都有处于新手的阶段，在这个阶段我们参与到开源更多的是汲取一些养分，让我们的技术快速成长，作为一名前端工程师，我举一个自己的例子。我本科学习的是生物科学，在我 26 岁之前我几乎没有写过一行代码，后来我转行做程序员，在刚进入到新公司时，我几乎什么都不会，一切都需要从头学起，公司项目是使用 Angular.js 开发，但是当时我连 Angular.js 是什么都不知道，只会一些简单的 JavaScript API，根本没有办法接手公司的项目，好在当时的领导给了我一个月的时间，让我去学习一些基础知识，包括 Angular.js 等框架，在这一个月中，我看了两三本关于 JavaScript 和 Angular.js 的书籍，并且将 Angular.js 的源码从 GitHub 上 clone 下来，放到了 iPad 上面，在利用上下班的地铁上，阅读着 Angular.js 的源码，那个时候才知道，原来代码还可以写得这么美妙、优雅。
当然，一个月后，我顺利的接手了那个 Angular.js 项目，为其添加了一些新的功能，对一些组件进行了抽象和提取，并且移除了项目中所有的 jQuery 代码，增强了代码的可维护性。
其实在这个阶段，对于开源社区，我们几乎是没有奉献和付出的，但是并不能够说我们没有参与到开源社区，还是比如前端工程师，在技术选型以及开发的过程中，我们几乎做不到不和开源绝缘的，我们几乎所有的前端开发工具都是基于 node.js 开发的，比如说 babel、webpack、karma 等，在选择前端框架的过程中，我们可以在 React、Vue、Angular 等众多前端框架或库中做选择，而这些框架、库、工具，都是开源的。站在这些“巨人”的肩膀上，我们更应该去积极思考，什么样的工具或者框架才是真正适合目前项目的，打包工具有 webpack 和 rollup 等，我们选择哪一个？前端框架又有 React、Vue 等，结合目前项目的需求及团队成员的现状，我们又该怎么选？当这些问题都有答案后，其实我们也就成长了。
参与到开源社区、贡献微薄之力
在参与到开源项目之前，我们首先需要回答一个问题：
我们为什么要给开源社区做贡献？
我建议你直接去阅读这篇文章 How to contribute to Open Source ，文章内提到了很多原因，包括提升知识技能、结识有志同道合的朋友、获取声望以及获得一些与人沟通的技巧回馈开源社区等等，这儿我分享一下为什么我热爱开源并且强烈的想参与到开源的初衷。
我是 2014 年底注册 GitHub 账号的，但是到 2015 年 12 月份，我才在 GitHub 上提交第一个 PR。虽然只是一个给代码库升级依赖，将 babel 从 5.x 版本升级到 6.x 版本，但是你不知道当 PR 合并后，我有多么高兴，我第一时间将这个消息告诉当时公司的一位大牛，也是我的职业导师，当然他并没有表现出多么惊奇，但那真真确确的是我第一次从开源奉献中获得了乐趣。正如 Linux 作者 Linus Torvalds 的自传的书名一样：
当我们明确地知道我们为什么要给开源做贡献后，下一步就是如何给开源社区贡献自己的力量。
怎么去选择你想参与的开源项目？
我的回答是不要为了贡献而贡献，一定参与自己喜欢的项目中，并且这个项目在自己的学习工作中是真实用到的。因为只有你真正用到的项目，你才能够发现项目中存在的问题，当你使用目标项目中，发现问题后，你的第一反应应该是先去它的 issue 页面进行搜索，看是否已经有有人提交过相同的 issue 了，避免重复提交。如果还没有人提交过类似的 issue，那么机会就来了，我们可以为该项目建一个该问题的 issue，一般的大型项目都有固定的 issue 格式，所以在填写 issue 的时候，一定需要按照他们要求的格式来填写。
在 issue 中最好先感谢项目作者和维护者的无私奉献，因为没有他们的无私劳动，我们根本没法使用上他们的开源项目。
当你提交完 issue 后，就可以静待作者的回复了，如果问题真的存在，那么作者可能会希望你和他一起讨论问题的解决方案，或者是希望你直接提交 PR 来修复该问题。
从 issue 到 PR
就我个人而言，我是很欢迎 issue 提交者能够直接给出问题的修复方案，并且提交一个相关的 PR 的，所以我也建议当你提交一个 issue 并被确认后，你可以和作者沟通，提出想要修复该问题，是否可以提交一个 PR？我相信几乎所有的作者都是很乐意看到你提 PR 的。
最熟悉一个项目的人肯定是项目的作者和维护者，所以在你提交 PR 的过程中，有任何问题，包括代码风格，解决方案等都可以在 PR 的评论中和作者直接沟通，他们也会提出代码审核的意见，直到帮助你完成合并 PR。
我不会写代码，我还有机会为开源做贡献吗？
很多人对开源的狭隘理解就是贡献代码，其实除了贡献代码，我们还有很多方式参与到社区，如果你热爱写作，你可以帮你喜爱的项目翻译文档，或者是修改文档中的一个 typo。如果你熟悉产品或项目，你可以在 issue 中和作者就一些问题的解决方案展开讨论，也许正是你提出的解决方案，解决了项目中的大难题。如果你熟悉项目代码，但是没有时间贡献 PR，你可以去 review 项目中的 PR，项目 PR 并不是只有作者和维护者才有权利去 review，所有贡献者都可以去审查别人的 PR，并提出一些意见或者建议。如果你不擅长写代码，但是你懂设计，你可以去帮助一些开源项目设计项目的 logo，marktext 的 logo 就是由 marktext 的使用者贡献的。
其实我们还有一些其他方式参与到开源社区，比如在 Stack Overflow 上回答一个你熟悉的项目中使用问题，并且得到了采纳。或者写一些开源项目的源码分析的文章，或者是使用技巧，帮助一些项目初期使用者能够快速上手项目。
主导开源项目的得与失
很多人会产生这样的疑问，参与开源都需要自己主导一个开源项目吗？ 我的回答是否定的，是否去主导一个开源项目（开坑）其实与很多因素有关，如果你想做一个项目，首先需要去了解，在目前的开源社区有类似的项目了吗？如果有的话，我建议直接参与到该项目中，帮助他们解决一些问题，或者实现你需要的特性。为什么不是直接开一个新的项目呢？客观上来讲，新开项目，如果和已有的项目功能相同或相近，新开的项目只会造成没必要的冗余，在经济学上来说也不是帕雷托最优的。主观上来说，新开项目需要消耗比较大的时间和精力，如果你不能够保证你有足够的时间和精力，以及一颗负责到底的决心，建议在开新的开源项目前许慎重考虑，因为一旦选择了远方，你就须砥砺前行。
既然是「我与 GitHub 的故事」主题分享，我们还是回到故事上面。
为什么选择开发 marktext？
在 2017 年底，当时公司团队成员都需要写一些知乎专栏文章，主要是记录下自己在工作中的一些技术总结和解决问题的方案。因为平时写一些 blog 都是使用的 markdown 格式，而开源社区好用的 markdown 编辑器又很少，几乎都是左右分栏，而没有所输及所得的预览模式。于是当时就下定决心写一款简单、优雅并且实时预览的 markdown 编辑器，marktext 就这样诞生了。
如何规划开源项目，让更多的贡献者参与进来？
在项目初期，我预计是三个月能够完成基础功能版本，达到可用的程度，但是开发三个月过后，才发现自己还是太乐观了，我仅仅完成了支持 markdown 的一些基本语法，甚至还不能够打开文件和保存文件。我意识到，凭我一己之力几乎无可能在短时间内完成这个项目。于是我决定把项目开源出去，让更多的 markdown 爱好者参与到项目中来，后来项目的发展也证实了我的选择是正确的。
在开源之前我做了如下一些准备工作：
完善 README 文件，README 文件中包括项目的介绍，marktext 支持或者将要支持的一些特性，这些特性区别于其他 markdown 编辑器，这样才能够吸引有特殊需求的使用者和贡献者。开发者文档，即开发者怎么能够快速的上手项目，并且如何做出贡献。
添加开源协议，通常是一个 LICENSE 文件，我选择了 MIT 协议，它是一个广泛使用的开源协议，并且我对别人使用 marktext 的代码也没有过多要求，并将协议链接添加到 README 中。
我依然担心贡献者想贡献代码时无从下手，所以我又在项目中添加了一个 CONTRIBUTING.md 文件，在这个文件中包括提交 issue 的规范，需要遵从 issue template，提交 PR 的一些规范，以及一些教开发者快速上手、项目结构的信息还有项目的代码风格等。并且将这个文件链接到 README 文件中，让开发者能够快速找到。
最后一步，也是相当重要的一步，项目的 ROADMAP，也就是说项目的蓝图或者规划，只有有了项目的规划，你的潜在贡献者才知道他们的 feature requist 是否已经在计划之中了，或者这个项目是否是他们所期许的那样，同时项目的规划一旦定下来，就不能随意在更改，不然这和没有项目规划没有两样。同时项目规划在之后解决一些成员间的意见冲突以及回复 issue 中的问题时，都会发挥作用。
有了上面这些准备，那么我们就可以一边继续开发项目，一边等待着开发者的第一个 PR 或者 issue 了。但是有些时候总是事与愿违，开源的前一个月也只有我一个在贡献代码，这个时候我有些着急了，我找我的朋友，我的同事，让他们来体验 marktext，希望他们能够提出一些改进意见，终于我一个朋友在体验 marktext 之后，提交了 marktext 第一个 PR，将 marktext 的打包后的体积缩减了 10+ M。
规范成员职责，同时制定项目规范
在 2018 年三月，Mark Text 组织迎来了除我以外的另一位成员，Felix Häusler，他是 Osnabrück 大学（奥斯纳布吕克大学）的一名在校学生，年仅 21 岁，已经相当熟悉 c++，并且在之前不了解前端开发的前提下，为 marktext 修改了好多 bug 和 添加特性。
Felix 对 Windows 以及 Linux 系统下的开发打包相当熟悉，因此我邀请他加入 Mark Text 组织，并且负责 Windows 和 Linux 系统下兼容性问题，以及项目的新版本发布，他也欣然接受了，如果没有他的加入，Mark Text 绝不可能发展到目前的规模，谢谢他。
在后来，marktext 多次登上 GitHub Trending，为 marktext 带来了一些流量，同时与之俱来的是，爆发式的 issue，这些 issue 都是千奇百怪的，没有统一的格式，有的 issue 只是一句话，因此我们不得不一条一条的去询问 issue 提交者，问他 issue 怎么复现，什么操作系统、marktext 的版本等，这个重复的工作量是巨大的，于是我们制定了 issue templates 和 PR templates，用来规范提交 issue 和 PR 的格式，它为我们减轻了很大一部分的工作量。
开源与工作、学习的关系
正如上面提到，Felix 还是一个大学生，有自己的学业，开源也只是他的兴趣爱好，因此到期末考试前，他告诉我没有多少时间参与到开源项目中。我是这样回复他的：
这也许就是我看待开源和工作、学习的关系吧，我仅仅将开源作为一种爱好，并且愿意将业余时间花到开源项目中，而这一切仅仅是因为开源能给我带来乐趣，我不会把这种兴趣爱好转变为工作，因为我担心这一兴趣爱好一旦和 deadline 有关后，而失去我做开源的初衷。
开源的得与失
到这，我们终于进入到了这一部分的重点，在做开源项目的过程中，我得到了如下收获：
我认识了很多朋友，他们可能是贡献者，或者是 markdown 的爱好者，或者是编辑器爱好者。
提升了审查代码的能力，在曾经一段时间，每天都需要 review 好几个 PR，有时一个 PR 超过上千行（往往是新特性），这个时候审查代码就需要格外小心了，首先，我需要把代码拉去到本地，在本地运行一遍，确保代码执行没有问题。其次才是进入到审查代码的阶段，逐行阅读其增删的代码，在不解的地方进行批注，并希望 PR 的提交者进行回复。保证代码没有问题后，最后，看是否通过 CI 测试，是否需要添加新的测试。当测试都通过后，就进入到了合并阶段。
合作的乐趣，各自分工，在各自擅长的点上为项目添砖加瓦，我擅长写编辑器部分，但是我并不擅长英文写作文档以及回答 issue 中的问题，组织中的另外一位成员就很好的弥补了我的缺点。
为其他库修改 bug 的乐趣，在自己主导开源项目后，你也会用到其他的开源库，比如在 marktext 中，的markdown 解析器就是 fork 的 marked，并做了一些扩展，因为修改了一些解析 markdown 的 bug，同时我也把这些 patch 提交到了 marked 的项目中。又比如项目中使用 prismjs 来高亮代码，但是在使用过程中也遇到了一些小问题，在查找问题的时候，顺便也就一起帮 prismjs 修改了。
也并不是没有失去，因为做开源项目，我更少的时间陪伴家人，周末大部分时间都在写代码，审查 PR，以及解决 issue。因为过分专注一某个项目，让我很难在找到新项目的新鲜感，有时会产生代码疲劳，没有更多的时间去学习新的知识和技能。
未来不可期
可能有一天，marktext 已经达到了我想要的样子，并且有足够的开源爱好者参与到 marktext 项目中来，并且在没有我的参与下，她也能够井井有条的维护下去，那一天，可能就是我退出 marktext 的时候了，但是在这之前，正如我前文中所说的那样，一旦选择了远方，就必须砥砺前行。
也有可能有一天，我会离开开源社区，但是做开源的初衷我不会忘记，在享受汲取、奉献和付出的同时，享受开源带来的乐趣。
The text was updated successfully, but these errors were encountered: