【伯乐在线导读】：开源运动愈发遭到互联网科技公司的喜欢，曾经视开源为毒瘤的微软，也都大刀阔斧地拥抱开源了。参与开源的开发者也越来越多，GitHub 的生动度也佐证了这种现象。国外程序员 Nolan Lawson 在《》分享了他的感受和阅历。 在知乎上也有一个相似的讨论帖：「维护一个大型开源项目是怎样的体验？」。原题主的弥补： （我以为）大型开源项目包含以下恣意一个或多个特征：
能够从以下几个方面中止回答。
伯乐在线摘编了两位朋友的回答，均已取得受权。 1. rebornix 的回答分享（link），伯乐在线已获受权 参与 Visual Studio Code – Code Editing. Redefined 快一年，趁这个机遇聊一聊开发和维护这个项目的感受，假如大家不反对这是一个 大型 开源项目的话。以下为个人了解，不代表公司也不代表团队。 项目 Visual Studio Code 的目的是做一个 Lightweight Editor，经过的扩展 api，让用户在 VS Code 中抵达和 IDE 中接近的开发体验（效率）。 不外很多大众对 VS Code 有诸多误解，我先来逐一解答
最后，我们一定要寻根问祖的话，VS Code 应该是师出 Eclipse（同志们，哎你们怎样扭头走人了，别怕，我话没说完呢）。团队中心的几位大爷，早年就跟着 Erich，在写了几个 Editor／IDE 之后，发明了 Eclipse。正是由于见证了 Eclipse 的兴衰，所以这一次在设计 Monaco／VS Code 的时分，才会如此的抑止。Extensibility 不好吗？当然好，但是 Eclipse 的弊病曾经在一些竞争对手身上呈现啦。 开发／维护 我 13 年参与微软后，就开端接触到 Monaco 了。在运用的过程中踩了一些坑，研讨过代码，做过好一些扩展。所以在 VS Code 正式开源后以及上线 Marketplace 后，我就开端入手写一点插件和发 Pull Request。去年五月无暇和团队结对编程了两个礼拜后，就参与了 VS Code。 VS Code 的开发简直完整是公开的。早期我们还经过 User Voice 搜集反响，但我们早就把它关掉了，一切问题的处置都放在 GitHub 上。我们的 Yearly/Monthly plan 都以 issue 的方式呈现 Microsoft/vscode ，而我个人正常的开发节拍是这样的： 计划 在上一个 milestone 快终了、新的 milestone 开端的第一周，和老板沟通新的 milestone 自己想做的功用。以及自己要不要休假。 Debt Week 我们把新 Milestone 的一周当作 debt week，集中处置一些技术债，以及为一些插件做点微小的贡献。我普通会花一点时间在 Vim 插件以及我自己的 Ruby 插件上。 开发 这之后就是两到三周正常的开发。每天起床得先把自己头上的新 issue 都 triage 一遍，遇到紧急的得先修，不然就继续完成自己的 feature。 Inbox Tracking 我参与团队的时分，我们只需 1700 个左右的 issue，往常曾经破 4000 了（大部分都是 feature request）。GitHub Inbox 在这种状况下是无用的，我们的做法是每周会有一名同事，担任 GitHub 的新 issue，assign 给适合的 owner。我曾经当过三次 Inbox Tracker，只能用可怕来形容。每天一睁眼就是一百多个 issue 要处置，一点都不想起床。 Endgame 我们在 milestone 的最后一周 endgame 会对新 feature 中止各种把戏的测试，对这个 milestone 关掉的一切 issue 中止考证。全部完成后，每个成员书写自己担任部分的 release note。最后 Endgame master 会到后台网站发布新的 Stable 版本。 印象深化的事 当之无愧就是《VS Code uses 13% CPU when idle due to blinking cursor rendering》。VS Code 是基于 Electron 的，而 Electron 则基于 Chromium。这样的话，Chromium 的锅有时分得我们来背。 VS Code 里的编辑区域并不是 textarea ，全都是 mock 的，这也是主流做法，Ace、CodeMirror、Atom 无不例外。理由也很简单，要完成Tokenize、高亮、Partial Render、Line Wrap，自己控制渲染肯定是最方便的。为了尽可能模仿 textarea，我们模仿了光标。最开端这个光标的跳动，是经过 Java 来控制光标的 opacity。后来社区给我们贡献了一个 pull request，运用 CSS animation 来调整 opacity。完成上来说肯定是比 Java 版本更文雅，同时也提供了四五种不同的光标跳动的选项。 但谁知道，Chromium 关于 CSS Animation 是有庞大的坑的。好比你写的 animation 是每秒改动一次 opacity，但是 Chromium 会依据刷新率（好比 60hz）来检测页面上的 animation。固然我不知道 Chromium 做了什么，但是你能够看到每16ms，Chromium 就会吃掉一点你的 CPU 和 Battery
真的是一点措施没有。我们起初没有发现这个问题，直到 broccoli 的作者 Jo Liss 给我们发了 issue，并且在 Twitter 上爆我们，瞬间就成了 Twitter 上大新闻。连 Miguel de Icaza 都点赞了，真的是。。。 当时我刚吃完晚饭，但是由于这个事情在我的防区，我只好开电脑 troubleshoot。最后发现是 Chromium 的 bug，开了两年多了，我只好通知 Jo Liss，这锅我们不背，但是我们会修的。 结果之后好事者把事情捅到了 HackerNews，瞬间成了当天大新闻，还上了 TheRegister 小报。一切人都开端讨论运用 Browser 技术做桌面应用是不是正确的选择，撕的不亦乐乎。 你们撕的倒是开心了，我那几天给各种老板解释什么是跳动的光标，忙的跟狗一样。好在后来 Chromium 的 PM lead Paul Irish 留言表示这是他们的 bug，算是圆满收官了。 有没有什么奇葩的 issue 或者 PR？
关于中文 issue 的问题，VS Code contribution guide 写的是比较分明的，请大家用英文提问。但是鉴于中文用户量庞大，加之人总有英文不够用的时分，VS Code 也会经常看到中文问题。我有这样一些想法：
大家都喜欢开源，但开源贡献者大部分时分是在做义务贡献。这么来看在微软搞 VS Code 就是一件高兴的事情，究竟有人给你付工资让你做 open source。而且再也不用上班搞一套代码，回家之后私自自己在 GitHub 上面逛游，搞别的项目，上班和下班后能够在同一块土地上耕耘。 当然这样缺陷也很明显，就是生活和工作常常难以分开。工作是一周五天，一天八小时，但是 GiHub issue 历来都是 7*24。遇到棘手的问题的时分，很难听任不论，哪怕曾经回了家。不外也正是由于项目的特殊性，我们组还是有比较好的 remote 和自由工作时间的文化的。 zcbenz 的回答分享（link），伯乐在线已获受权 这次籍着Electron 1.0发布的机遇，说说我自己维护两个大型开源项目的阅历吧，分别是 node-webkit（也就是往常的NW.js）和Electron。 前者是几年前自己单打独斗，在公司0资源投入的状况下从两百多star不时做到好几千star，细致数字曾经忘掉了，只记得当时在C++项目排行里做到了前十，直到自己重整旗鼓。然后者，则是披着GitHub的光环，有着公司热心的投入，毫无障碍一路跑到了往常的三万多star。 （运用Star History生成的star数统计图）
一切从node-webkit开端 假如大家有接触过前端或者桌面端的开发，那么很可能有听说过NW.js的大名，node-webkit就是其改名之前的称谓。 但绝大部分人可能并不知道，node-webkit在最初发布的时分（2011年），并不是面向开发桌面应用程序，而是一个Node.js模块，能够创建一个WebKit窗口。神奇的一点是，你能够在这个窗口的页面里调用Node.js的模块。 Node.js代码：
index.html代码：
大家能够在NW.js的webkitgtk分支里找到node-webkit的原始完成，以至尝试重新build一遍。不外这个模块不时未能稳定下来，玩具的滋味更多一些。 再后来，原作者 rogerwang 对其中止了改进，从运用WebKit改成了调用Chromium Embedded Framework（简称CEF），一个能够把Chromium嵌入应用程序的库。这个代码不时没有正式发布，但大家能够在node-webkit的cef分支里找到。代码的另一部分是针对Chromium的几十行补丁，将Chromium的message loop交流为libuv，但是NW.js在开发过程中对代码库中止了很多次rebase操作，原始代码曾经找不回来了。 找个实习生来开发 node-webkit的原作者rogerwang在Intel开源技术中心工作，固然Intel在大家心目中可能更多是个卖CPU的，其真实开源方面也十分热心，以至提供开源方面的实习工作。 在2012年的夏天，一则Intel的实习信息吸收了我的留意，上面说Intel需求一名熟习Node.js的学生来中止node-webkit的开发。我投了简历，也很侥幸地开端了node-webkit的开发。 Content Shell 我最初的工作是对node-webkit的cef分支中止改进，但是很快就发现很难继续中止开发了。CEF提供了自己的一套API来包装Chromium的内部API，而Node.js则是直接调用V8的API，假如想要把CEF和Node.js兼并到同一个项目，艰难重重。 于是我痛快将node-webkit推倒重写。新的代码基于Content Shell，一个Chromium代码库内的最小化阅读器完成。 重写后的结果十分不错，我得到了一个能够调用Node.js模块的阅读器完成。基于这套代码我发布了node-webkit v0.2.1。 把node-webkit进化成桌面开发利器 至此node-webkit曾经变成了一个独立的阅读器，而不再是Node.js模块。为什么不把它变成一个运用Java和HTML开发桌面应用的工具呢？后面几个月我开端对这个想法中止尝试。 首先我模仿游戏框架LVE framework为node-webkit完成了一个打包系统，能够把应用直接附加到exe上： （node-webkit的打包系统，来自我自己的PPT）
这个打包系统不时沿用到NW.js，但是由于性能方面的种种缘由，后来在开发Electron时我并没有运用这套系统。 接着这是各种细节上的完善：好比应用package.json文件来描画应用；给窗口加工具栏；拓展DOM来提供API；取消阅读器的保险系统；等等。当然还有无休无止的bug修复。 其中最有应战性的一点是支持Node.js的native module，我对Chromium打上各种补丁来裸露V8和OpenSSL的API，给Node.js打补丁益处置OpenSSL和NSS之间的符号抵触，提供自定义的node.lib来支持Windows，最后还要提供适用于node-webkit的编译工具。 完成这些工作以后我发布了node-webkit v0.2.5。 提供构建GUI的API 这时我的绝大部分工作都在围着阅读器转，而由于阅读器自身的局限性很多功用我都没法提供。好比说阅读器里就没法创建系统原生的菜单。（当然今天曾经有了HTML5 Menu标签，而当时是2012年。） 于是我想到增加一个新的内置模块，用来提供对窗口、菜单等系统API的绑定，也就是：
假如你有运用过NW.js的话，你应该很熟习这一套API。 经过几个月的完善后，我发布了node-webkit v0.3.6，这也是由我维护的最后一个版本。 node-webkit的推行 固然node-webkit属于Intel，但其更多属于rogerwang的个人项目，那时分这个项目在GitHub上也还挂在rogerwang的账户下。所以当时除了我自己一个人，没有其他任何来自Intel的资源投入。 而像node-webkit这样的框架类项目，只需具有用户，才会有生存下去的意义，所以在开发node-webkit的半年时间里，我也不时有在积极推行。 首先是四处发帖子宣传node-webkit的益处，一大阵地是Node.js的邮件列表。每次有新版本我就会过去发布公告，回答问题，与人撕逼。其次则是编写范例应用，让新手快速入门，让其他人置信node-webkit的才干。最后则是去技术会议宣传，让大家知道node-webkit这个东西。 当然最重要的还是认真回答Issues里的问题，努力修复bug增加功用。 我的努力最后也得到了十分好的回报，在我终了node-webkit开发的时分，项目在GitHub上取得了数千个star，排到了C++项目排行的前十。 第一个用户 另外值得一提的是node-webkit的第一个用户，Light Table 编辑器。这个编辑器的作者 ibdknox 很大胆地运用了node-webkit来中止开发，当时为node-webkit迎来了十分多的关注，也给大家吃了一枚定心丸，为项目推行助力庞大。 几年后Light Table又从node-webkit迁移到了Electron，当时好似好友重逢，感触良多。 工作的转移 在我为node-webkit工作半年之后，2012年底，这个项目开端吸收越来越多的留意力，也开端惹起Intel一定水平的留意。rogerwang得到了机遇放下其他的工作，开端全职维护node-webkit。 （GitHub的代码贡献表）
大家假如有在比较大的公司工作过，之前可能会奇特，为什么一个实习生能如此随意地修正代码，发布新版本。其实正是由于这个项目当时在Intel内部无人关注，无人管理，我才得以随心所欲地尝试各种想法。 但之后合理node-webkit冉冉升起之时，我却彻底失去了node-webkit的自治权，开端收到命令去完成指定的开发工作，被遏止随意去增加功用，也不允许去随意修复bug，而发布新版本、和客户交流的工作也被转移给更高级别的工程师手上。正如一个大公司里的螺丝钉。 可能这种开发方式才是大公司的常态，我也不想埋怨任何人，但是负疚，我只是一点也忍不了。 为GitHub而战 在我中止node-webkit开发的同时，GitHub正在秘密开发Atom编辑器。我了解到GitHub正在寻求一种运用HTMl和Node.js来开发桌面应用的方式，于是联络到Github 的工程师nathansobo，表白了为GitHub工作的意愿。 所幸node-webkit曾经为我自己赢得了足够的名气，在一面未见的状况下，我们敲定了协议，我需求将Atom迁移到node-webkit之上，并且提供支持工作。 于是2012年底，我终了了在Intel的实习，开端为GitHub作为contractor工作。 一个更好的桌面应用框架 在我参与Atom的开发时，项目还基于CEF。我们尝试了将Atom迁移到node-webkit上面，但是最终效果并不是很好，node-webkit当时并不稳定，而且API有太多的坑。 于是我开端重新思索node-webkit的API设计，发现假如想要支撑大型应用，我不得不做出很多结构性的改动，而这些改动与其修正node-webkit，不如重写愈加实践。在和GitHub讨论之后，我开端编写一个新的桌面应用框架，当时的称号叫做atom-shell。 有兴味的同窗能够去了解一下我们究竟做了哪些改动。 左右互搏 后来，经过长时间的开发，atom-shell最终开放了源代码，而与此同时node-webkit 曾经吸收了十分多的留意力和用户，我开端了和自己的竞争。 再之后node-webkit改名为NW.js，而atom-shell则改名为Electron。 （Electron 1.0）
维护开源项目的生活 说完了从node-webkit到Electron进化的进程，最后说说维护开源项目的体验吧。 和普通项目不同，开源项目简直一切的用户都来自公司外部，取决于项目的受欢送水平，每天都会遭到相当大数量的邮件。就我自己而言，来自GitHub的通知邮件每天数量在50封左右，需求花1到3小时左右逐一消化回复。很多issue要去认真重现，一些话题也需求大量的讨论，很省心。以至会有troll过来破坏一切人的心情。 其中最让人无法的一个troll，最爱跑到issue下面留言，指责Electron剽窃NW.js的代码，剽窃NW.js的理念，还四处劝人转用NW.js。简直了。/p> 维护项目的另一项工作，是审核pull request，和维护node-webkit时不同，Electron的用户群要大很多，所以每天都会收到pull request，其中不乏高质量的代码。但多数时分代码都不能直接兼并，要么设计分歧理，要么代码分歧规范，更多地则是引入新bug。所以每个pull request都需求仔细查看，还少不了和贡献者大量的讨论。 于是，做完这些工作以后，留给写代码的时分反而少了很多，也是没有措施。但关于一个开源项目而言，这些琐碎的工作其实十分重要，只需让人觉得你的项目在被精心维护，才干不时吸收更多用户。一个维护不善的项目，哪怕初期由于种种缘由吸收了很多用户，一旦更好的替代品呈现，用户马上会飞速流失。 生活上，由于是全职做开源，影响反而十分小。GitHub的远程工作氛围十分浓厚，我的大部分工作时间也是在家里而不是办公室里，所以多数时分是想写代码了便开端工作，不在状态就把工作放在一边去做做喜欢的事，以此用有限的时间维持十分高的工作效率。 但开源会给自己带来另一个问题，义务感。一个没人用的项目，弃坑不外是一转念的事情，但是当越来越多人开端用你的项目，以至有创业公司把未来压在你的项目上，义务感会越来越重，你独一的选择就是将项目继续维护下去，无法弃坑，直到更好的技术呈现。 不知道我未来还会维护Electron多久，不外就过去几年来看，还挺开心的，应该还会继续做下去吧。 看完本文有收获？请分享给更多人 关注「Linux 喜好者」，提升Linux |
名表回收网手机版
