【译】「开源」其实很容易

• 原文地址：Start your open-source career
• 原文做者：Vincent Voyer
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：zwwill 木羽
• 校对者：刘文哲、SeanW20

开启你的开源生涯

今年我作了一次关于如何让开源项目得到成功的演讲，讨论如何经过作好各方面的准备，来确保让咱们的开源项目吸引各类各样的贡献，包括提问、撰写文档或更新代码。以后我得到一个反馈信息，「你展现了如何让开源项目成功，这很棒，但个人开源之路究竟该从何入手呢」”。这篇文章就是对这个问题的回答，它解释了如何以及从何开始为开源项目作出贡献，以及如何开源本身的项目。

这里所分享的知识都是有经验可寻的：在 Algolia 中咱们已经发布并维护了多个开源项目，时间证实这些项目都是成功的，我也花费了大量的时间来参与和创立新的开源项目。

千里之行始于足下

六年前在 Fasterize （一个网站性能加速器供应商），我职业生涯的关键时刻。咱们在 Node.js workers 上遇到了严重的 内存泄露问题。在检查完除 Node.js 源码外的全部代码后，咱们并无发现任何可形成此问题的线索。咱们的变通策略是天天重启这些 workers 以释放内存，仅此而已，但咱们知道这并非一个优雅的解决方案，所以我想总体地去了解这个问题。

当个人联合创始人 Stéphane 建议我去看看 Node.js 的源码时，我几乎要笑出来。心想：「若是这里有 bug，最大的多是咱们的，而不是那些创造了革命性服务端框架的工程师们形成的。那好吧，我去看看」。两天后，个人两个针对 Node.js http 层的修复请求被经过合并，同时解决了咱们本身的内存泄露问题。

这样作让我信心大增。在我敬重的其余 30 个对 http.js 文件做出贡献的人中，不乏 isaacs （npm 的创造者）这样优秀的开发者，这让我明白，代码就是代码，无论是谁写的。

你是否正在经历开源项目的 bug？深刻挖掘，不要停留在你的临时解决方案。你的解决方案会让更多人受益而且得到更多开源贡献。读别人的代码。你可能不会立刻修复你的问题，它可能须要一些时间来理解，可是您将学习新的模块、新的语法和不一样的编码形式，这都将促使你成为一个开源项目的开发者。

车到山前必有路

Node.js 仓库上的首次贡献的标签

「我毫无头绪」是那些想为开源社区作贡献但又认为本身没有好的灵感或项目能够分享的开发者们共同的槽点。好吧，对此我想说：that’s OK。是有机会作开源贡献的。许多项目已经开始经过标注或标签为初学者列出优秀的贡献。

你能够经过这些网站找到贡献的灵感：Open Source Friday, First Timers Only, Your First PR, CodeTriage, 24 Pull Requests, Up For Grabs 和 Contributor-ninja (列表出自 opensource.guide).

构建一些工具

工具化是一种很好的方式来发布一些有用的东西，而没必要过多的考虑一些复杂的问题和 API 设计。您能够为您喜欢的框架或平台发布一个模板，将一些博客文章中的知识和工具使用姿式聚集到这个项目中进行诠释，并准备好实时更新和发布新特性。create-react-app 就是一个很好的例子🌰。

在 GitHub 上有大约 五万九千个模板 库，发布一个并非难事反而对你有益

如今，你仍然能够像咱们给 Atom 构建模版自动化导入插件那样对 Atom 和 Visual Studio Code 进行构建纯 JavaScript 插件。那些在 Atom 或者 Sublime Text 中已经存在了的优秀插件是否尚未出如今你最爱的编辑器中？那就去作一个吧。

你甚至能够为 webpack 或 babel 贡献插件来解决 JavaScript 技术栈的一些特殊用例。

好的一面是，大多数的平台都会说明如何建立和发布插件，因此你没必要太过考虑怎么作到这些。

成为新维护者

当你在 GitHub 上浏览项目时，你可能时常会发现或者使用一些被建立者遗弃的项目。他们仍然具备价值，可是不少问题和 PRs 被堆放在仓库中一直没有获得维护者的反馈。此刻你该怎么办？

• 发布一个新命名的分支
• 成为新的维护者

我建议你同时作掉这两点。前者将帮助推动你的项目，然后者将使你和社区受益。

你可能会问，怎样成为新的维护者？发邮件或者在 Twitter 上 @ 现有维护者，而且对他说「你好，我帮你维护这个项目怎么样？」。一般都是行之有效的，而且这是一个很好的方法能让你在一个知名且有价值的项目上开启本身的开源生涯。

示例：去复兴一个遗弃的项目

建立本身的项目

发掘本身项目的最好方法就是关注一些现在尚未很好解决的问题。若是你发现，当你须要一个特定的库来解决你的一个问题而未果时，此刻即是你建立一个开源库的最佳时机。

在我职业生涯中还有另一个关键时刻。在 Fasterize，咱们须要一个快速且轻量级的图片懒加载器来作咱们网站性能加速器，它并非一个 jQuery 插件，而是一个可在其余网站加载并生效的独立项目。我找了好久也没在整个网络上找到现成的库。因而我说「完了，我没找到一个好的项目，咱们无法立项了」。

对此，斯蒂芬回应说「好吧，那咱们就创造一个」。嗯～～好吧，我开始复制粘贴一个 StackOverflow 上的解决方案 到 JavaScript 文件夹中，建立了一个图片懒加载器 并最终用到了像 Flipkart.com （每个月有 2 亿多访问量，印度网站排行第九） 这样的网站上。通过此次成功的实践后，个人思惟就被联结到了开源。我忽然明白，开源多是我开发者生涯的另一部分，而不是一个只有传说和神话的 10x 程序员才胜任的领域。

一个没有很好解决的问题: 以可重用的方式解决它!

时间尤其重要。若是你决定不构建可重用的库，而是在本身的应用程序中内联一些代码，那就错失良机了。可能在某个时候，别人将建立这个本该由你建立的项目。不如即刻从你的应用程序中提取并发布这些可复用模块。

发布，推广，分享

为了确保每一个有须要的人都乐意来找到你的模块，你必须：

• 撰写一个良好的 README，并配有版本徽章和知名度指标
• 为项目建立一个专属且精心设计的在线展现网站。能够在 Prettier 中找一些灵感
• 在 StackOverflow 和 GitHub 中找到与你已解决问题的相关提问，并将贴出你的项目做为答案
• 将你的项目投放在 HackerNews, reddit，ProductHunt， Hashnode 或者其余聚集开源项目的社区中
• 在你的新项目中投递关于你的平台的关联信息
• 参加一些讨论会或者作演讲来介绍你的项目

向全世界展现你的新项目

不要惧怕在太多网站发布信息，只要你深信本身创造出来的东西是有价值的，那么再多的信息也不为过。总的来讲，开源社区是很欢迎分享的。

保持耐心持续迭代

在「知名度指标」（star 数和下载数）上，有些项目会在第一天就飞涨，以后便早早地中止上涨了。另一些项目会在沉淀一年后成为头条最热项目。相信你的项目会在不久后被别人发掘，若是没有，你也将学会一些东西：可能对于其余人来讲它是无用的，但对于你的下一个项目来讲它将是你的又一笔财富。

我有不少 star 近似为 0 的项目，好比 mocha-browse，但我从不失望，由于我并无很高的指望。在项目开始是我就这么想：我发现一个好问题，我尽我所能地去解决它，可能有些人会须要它，也可能没有，那又有什么大不了的。

一个解决方案的两个项目

这是我在作开源中最喜欢的部分。2015年在 Algolia，咱们在寻找一种解决方案能够单元测试和冻结咱们使用 JSX 输出的 html，以便咱们为写 React 组件生成咱们的 React UI 库 InstantSearch.js。

因为 JSX 被编译成 function 调用的，所以咱们当时的解决方案是编写方法 expect(<Component />).toDeepEqual(<div><span/></div>)，也只是比较两个 function 的调用输出，可是这些调用输出都是复杂的对象树，在运行时可能会输出Expected {-type: ‘span’, …}。输入和输出比较是不可行的，并且开发者在测试时也会抓狂。

为了解决这个问题，咱们建立了 algolia/expect-jsx，他让咱们能够在单元测试中使用 JSX 字符串作比较，而不是那些不可读的对象树。测试的输入和输出将使用相同的语义。咱们并无到此为止，咱们并非仅仅发布一个库，而是两个库，其中一个是在第一个的基础上提炼出来的。

• algolia/react-element-to-jsx-string 将JSX函数返回转换为 JSX 字符串
• algolia/expect-jsx 用于关联 react-element-to-jsx-string 和断言库 mjackson/expect

经过发布两个共同解决一个问题的模块，你可使社区受益于你的底层解决方案，这些方案能够应用在许多不一样的项目中，还有一些你甚至想不到的应用方式。

好比，react-element-to-jsx-string 在许多其余的指望测试框架中使用，也有使用在像 storybooks/addon-jsx 这类的文档插件上。如今，若是想测试 React 组件的输出结果，使用 Jest 并进行快照测试，在这种状况下就不在须要 expect-jsx 了。

反馈和贡献

这里有不少问题，固然，这是我为了好看而伪造的🙂

一旦你开始了开源的反馈和贡献就要作好开放和乐观的准备。你会获得赞许也会有否认。记住，任何和用户的交流都是一种贡献，尽管这看起来只是抱怨。

首先，要在书面上传达意图或语气并不容易。你可使用「这很棒、这确实不好劲、我不明白、我很高兴、我很难过」来解释「奇怪了。。」，询问更多的细节并试着重现这个问题，以便更好地理解它是怎么产生的。

一些避免真正抱怨的建议：

• 为了更好地引导用户给予反馈，须要为他们提供一个 ISSUE_TEMPLATE，能够在建立一个新问题时预填模版。
• 尽可能减小对新晋贡献者的阻力。要知道，他们可能还没进入角色状态并很乐意向你学习。不要由于缺乏分号 ; 就拒绝他们的合并请求，要让他们有安全感。你能够温和的请求他们将其补上，若是这招没用，你能够就直接合并代码，而后本身编写测试和文档。

最后

感谢你的阅读，我但愿你会喜欢这篇文章，并能帮你找到你想要帮助或者建立的项目。对开源社区作贡献是扩展你的技能的好方法，对每一个开发者来讲并非强制性的体验，而是一个走出你的温馨区的好机会。

我如今很期待你的第一个或下一个开放源码项目，能够在 Twitter 上 @ 我 @vvoyer，我很乐意给你一些建议。

若是你喜欢开源，而且想在公司实践而不是空闲时间，Algolia 已经为 开源 JavaScript 开发者 提供岗位了。

其余你能够会喜欢的资源：

• opensource.guide，学习如何启动和发展你的项目
• Octobox， 将你的 GitHub 通知转成邮件的形式，这是避免因堆积「太多问题」以致于影响关注重要问题的很好的方法
• Probot，GitHub App 能够自动化和改善你的工做流程，好比关闭一些很是陈旧的问题
• Refined GitHub 在不少层面上为 Github UI 提供了使人钦佩的维护经验
• OctoLinker 为在 Github 上浏览别人的代码提供一种很好的体验

感谢 Ivana、Tiphaine、Adrien、Josh、Peter、Raymond、zwwill 木羽、刘文哲、SeanW20 为这篇文章做出的帮助、审查和贡献。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。