沃尔玛实验室 - 为什么我们要启动开源计划

jopen 9年前

在未来的几周,我们计划发布一些由TODO团队成员撰写的文章,解释每个企业下决心去启动开源项目、使用并提升开源软件的原因,以及由此带来的便利。首先来倾听沃尔玛实验室  Dion Almaer (@dalmaer) 的声音。

为什么公司愿意在开源项目上耗费成本, 为什么确实有必要这样做?

这是很棒的问题,并且随着时间的推移,我的观点也可能在某些方面发生改变。从职业生涯的初期,我就一直致力于开源计划,也参与了一些优秀的开源项目,比如说Apache,之后当我加入Chris DiBona在Google的开源项目团队,发现了一个特别有意思的现象。那是一次真正的洗礼。不论是Chris便签上"我又要心惊胆颤的为那家伙工作了!"的名言,还是他不可思议的提供一些使工程师受益良多的开源框架,都潜移默化的促进了业务。

过去,开源工具以及广泛性并不及现在,于是,Google Code 以及其它的解决方案,从开源组织里成长起来。

让我们将视线快速转移到现在。

您的公司处于寻求伟大开发者的激烈竞争中

全世界有很多伟大的开发者,您的公司可能正努力争取尽可能多的设计师。由于供不应求,所以,您需要极尽所能的吸引和培训人才。

大多数伟大的开发者都有GitHub档案,并致力于那里的项目(开源项目或其它)。GitHub已经无处不在,大多数开发者要么喜欢它,要么乐于待见它。这里有一些灰胡子的人(指有一定资历的年长开发者)针对Perforce或者其它事情大喊大叫,但那毕竟是少数:)

一则简短的轶事:我认识的一位伟大的开发者应聘到一家一流的公司工作。当他被告知,它必须使用旧的Java栈工作,同时工作流并非基于git的时候,他基本上就选择放弃这份工作了。

你使用和创建的开源项目是招募利器。如果你正在使用React,你将会有大量的开发者,他们可能正在寻找使用这种技术工作的项目。如果你创建了React,你将有机会找到工作于这个项目的核心团队!

在沃尔玛实验室,我们有类似的情形。我加入到创建沃尔玛实验室的移动端的工作中。我们需要创建流程编排服务层,因为目前的后端不支持移动功能。我们该选择什么?

我们决定选择 node ,不仅仅是因为它是一种适用的技术,同时我们还可以带来全世界的开发者团队,他们急切渴望创建大规模的node服务。

对比下面的:

嗨,你希望构建处理沃尔玛黑色星期五业务流量的node服务,同时向全世界证明node是可行的吗?

vs.:

嗨,你愿意构建另一个java服务用来路由一些东西吗?

绿色的通道使得团队可以做一些伟大的工作,并且我为他们创建的端对端的工作流感到非常非常地骄傲。

尽管在很多年前,node岌岌可危。因为我们在node里面发现了很多BUG(有时只是一个s/compiler/VM/上的BUG),并且发现当时node这个框架还未能支撑项目的开发和使用。这正是hapi node框架诞生和众多基于node模块群起的原因。

我们当时需要构建对应的团队,因此我们需要召集团队成员,不过还好我们有这样的优势:

  • 我们可以从hapi社区大量的开发人员中物色拉取成员

  • 已有大量不仅仅是关于开源魔法般的权衡,同时也被用于解决实际问题和传递商业价值的工作

从那时起,开源所带来的好处开始光芒四射。当你需要招募一个天才,你需要一个流程来筛选识别出哪位能够胜任此工作(同样对他们而言,他们也在筛选你)。

面谈的过程就像是约会。在一两次约会之后,你很难确定你是否想结婚。我发现,婚姻是否持久以及是否令人满意的最好的方式是,多一些约会,更好的感知什么是婚姻。

当你面试一个以开源为核心的团队的时候,你可以和他们一起解决问题列表中的问题,真正感知做事情的状态。它是一个极好的优势。

开发者是当代的艺术家

当你想到IT商店的时候,我不认可,而将它关联到“高质量软件产品开发”。如果你在创建一个伟大产品设计的文化,你需要想办法让开发者繁荣起来。对我来说,这意味着有正确指导方针的独立自主权可以取消束缚。

如果开源程序办公室的工作有序开展,这个模式很适合。糟糕的是,它们只由律师来打理,仅仅只关注许可证和责任。这些是很重要的话题,你不应该忽略它们。但是,你如何才能帮助开发者创建解决方案,而不是浪费时间在那个漩涡里呢?

伟大的开源处理过程会有各种清单,它可以快速处理完,同时将公司的开发者从A到B的过程中释放出来。我们正在谈论如何使用开源软件,以及如何创建和维护它。

开源团队开发的工具有很大的影响力,单独的产品团队不应该花费时间在下面的事情上:

  • 如何知道正在使用什么开源软件

  • 标记任何问题

  • 反馈团队“那个版本由于X而不被推荐”

  • 帮助市场项目(在线,事件等)

  • 提供给领导者项目的一些状况

  • 帮助领导者了解围绕项目的社区

  • 默认情况,以及关于人们如何贡献和参与的简单处理流程

GitHub有一些这样的工具,不过只是一个子集。

远程办公

围绕着“远程办公”,社区正在讨论得如火如荼。你可以看到公司的两面性,如Slack公司创建了更利于远程沟通的产品,却没有公司招聘人来驻扎使用。

一旦你接触到了一些人后,你就开始了“远程”办公。如果你们不是在同一间房里面,那么你就需要通过工具来实现你的主工作流程。当然,你可以通过聚在一起,面对面地讨论一些主题,但这不是你通常的工作流。

这不是很有趣吗?因为这些公司都可以通过开源的工具(例如:结合Basecamp和Rails的DHH,结合Automatic和Wordpress的Matt)来实现远程办公。开源项目多年来一直生活在远程的梦境并且取得了巨大的成功。自然而言,他们就会信奉在合作的生活里的工作方式。无论他们是仅仅知道了如何让它运转(并且同时知道对应的好处),还是他们正在构建开源软件从而使得最好的工程师可以来自不同的地域不同的肤色。

我个人认为远程办公只在特定的范围内行之有效,并且开源使这条路更为顺畅。

通常而言,这带来了新的工具和针对你公司的新流程。多样性是非常重要的,并且好的开源努力可以帮助公司增长对技术、流程和工具的阅历。

杠杆作用

你可以在开源里面获得一系列的杠杆作用。再次取hapi为例:在全球各地,我们已经有大量的公司在测试和运行这个框架。他们也同样知道hapi运行在沃尔玛实验室的产品中。

我们都可以从社区提供的bugs和开发的新特性中受益。如同一个巨大的协同效应。

偿还:做正确的事

我们都是站在了巨人的肩膀上。感谢那些工作在Linx、Apache、Node、JavaScript和PostgreSQL和...(此处省略一万字)的大神。

我感觉继续将开源进行到底就是我的责任。而从开源里面抓取到了好的精华却将我正在做的事件全部隐藏起来,对我而言则是不对的。这不是说你正在做的任何事都是错的(依赖于许可证等),但我感觉就是不对。

这就是为什么我一直认为任何开源的东西都不应该是专有的,并且通常是非常有用的。

但是在你进行开源之前,你需要记住开源远远不等同于“免费”。如果一个团队准备抛一些软件出来后就不管了,那么对我而言是没用的。我的观点是,你应该着手 在社区里面建立一些内容以表明你在那里并且会以通过某些途径来支持。你最好有好的文档提供。你最好对于贡献有一个好的规划。还有,做一个好市民。

确实,打造一个出色的开源团队是需要很多时间和资源的,所以你不应该对此掉以轻心,但是我知道在这个年代,对于你能否成就一番事业还是得出“我们也承诺不起”这样的结论,我不得而知(译者注:此段意译)。