在未来的几周，我们计划发布一些由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有一些这样的工具，不过只是一个子集。
