Facebook 开源部门主管畅谈

图片来自

Opensource.com

以下是 James Pearce 在 OSCON 会议上题为重启 Facebook 的开源的演讲的部分文字记录。

数百年来，开放胜过封闭——分享胜过保密。

在某种程度上，这影响了我们在 Facebook 的项目。我们在 Facebook 拥有 200 个活跃项目，代码行数达 1000 万行。数百名工程师参与这些项目，拥有超过 10 万名关注者和 2 万个 fork。我们为广泛的项目做出贡献（例如 kernel、mercurial、D 等）。我们甚至在开放计算项目中开源了数据中心和机器的设计。我们希望分享一路走来学到的一些经验。

为什么这如此重要？

原因是，开源对宿舍非常友好。我们的根源可以追溯到 2004 年一位年轻的本科生，他选择了当时可用的 FOSS（自由和开源）软件，即经典的 LAMP 堆栈。我们参与社区以创建一个更美好地方的能力得到了提升。

当我们找到一个开源软件 (OSS) 时，我们首先尝试扩展它，然后找到项目的局限性。因此，我们尝试改进它们，使它们能够在规模化的环境中工作，我们一遍又一遍地看到这种模式。例如，马克决定使用 PHP，但它存在局限性。我们构建了 HipHop “编译器” HHVM 项目，甚至在最近，推出了增强型 PHP 语言 Hack，该语言于三月份发布。数据、Web、基础设施、前端，我们所有的技术堆栈都与我们的黑客文化以及我们的组织被感知的方式紧密相连。我们询问了我们的员工...

“您是否了解 Facebook 的开源软件项目？”

2/3 的人回答“是”
1/2 的人表示该项目对他们决定为我们工作产生了积极的贡献

这些不是微不足道的数字，我希望这是一个持续的趋势。

很多人表示，他们在开源项目中使用了我们的项目，这帮助他们在上岗前就快速上手。这对我们公司来说是一个巨大的胜利。

这是开源对我们公司有价值的重要原因之一。你需要能够清晰地表达这种价值。

#0：始终清晰地表达 FOSS 为您的公司带来的价值

总是会有成本和投入，因此要了解您的回报是什么。天真的意识形态走不了多远，你需要数据来支持持续发展。我们确信这有助于我们做得更好。它有助于我们保持技术的鲜活，证明架构决策的合理性，吸引更多人关注我们的代码。开源就像从敞开的窗户吹来的微风；它使事物保持新鲜。

但是，如果您将时间倒退一年，您会发现 three20 项目，该项目已停止... 我们的 PHP SDK... 已弃用。我们的 Memecache 分支，描述为“test”，提交消息为“5”、“6”和“7”...

*观众笑声*

这就是“扔过墙”综合征。我很遗憾地说，我们对此负有责任，而且这几乎比根本不做更糟糕。

您需要继续关心您发布的东西，否则您怎么能期望别人关心它们呢？

#1：使用您自己的开源

继续使用您发布的版本至关重要。不要创建内部分支，保持代码新鲜，继续致力于它。如果您不这样做，社区会注意到的。吃你自己的狗粮。

有时您必须将您的开源代码与内部封闭/专有工具集成。这通常意味着您创建插件或适配器，并做出使您的项目更好的架构决策。Presto，我们需要它与开放和内部数据库集成。我们有一个强大的插件架构，以及用于开放数据库的插件，以及用于我们内部数据库的插件。

然而，去年我们做得不太好。我们决定重组我们的团队，并整理我们的内部事务。那时，我们的 Web 团队在 JSConf 上开源了 React。React 是近年来 JavaScript 世界中最令人兴奋的项目之一，社区反响热烈。它提醒了 Facebook 的我们，我们知道如何发布伟大的项目。这项倡议来自开发人员自身。内部没有推广团队；他们直接来自工程师。

#2：分散项目所有权

确保工程师是唯一的保管人。外部工程师直接与内部工程师合作。没有单一的整体结构。当我们考虑重启时，我们需要弄清楚我们已经拥有什么，并控制投资组合。

我们需要回答 3 个关键问题

我们拥有哪些项目？
谁在贡献？
它们的健康状况如何？

大多数都在 Github 上。Github 当然有一个很棒的 API，因此我们编写了一个脚本（用 Hack 语言编写）来访问和枚举项目，并获取

每个存储库
每次提交
每个拉取请求
每个问题

因此，我们存储了所有这些数据，并将其放入 MySQL。

我喜欢 Github，但我发现使用 SQL 来过滤正在发生的事情更容易。我们发现了一些需要解决的问题。我们意识到我们可以一遍又一遍地执行此导入过程，并查看趋势如何随时间演变。我现在是 Github API 限制机制的世界级专家之一，我们已经使其高效运行。所有这些都是为了实现两件事：检测和发布。

#3：投资于检测

我们现在拥有时间序列数据，可以创建指标。这是 Argus，显示了随着时间推移的关注者总数。多达 10 万名关注者，每分钟轮询一次，我们可以随着时间推移进行观察，并且可以找到 GitHub 没有的拐点。我们发布了一个名为 Shimmer 的 iOS 库，然后对其进行了调整，这些激增可以在投资 iOS 社区后看到。能够监控和发布数据和进展，表明我们是有纪律的，并且可以通过经验数据获得尊重。

我们关注超过 35 个指标。

五个最重要的指标

平均关注者数量
每个存储库的 Fork 数量
平均拉取请求年龄
平均问题年龄
外部提交数量

#4：投资于工具

主要是内部工具，以帮助团队运行项目。这些是内部仪表板，公司每个人都可见。每个人都知道我们在内部关注的指标。“大型”视图显示所有项目，哪些项目做得好/不好，您可以向下钻取并查看每个项目的所有者。他们被明确定义为一名员工，并且可以直接分配任务。我可以催促他们，而且，如果他们离职（就像 Tornado 那样），我们可以为该项目找到新的管理者。对于 Tornado，我们将所有权转移给了社区。我们让工程师通过 oAuth 将他们的 Facebook 个人资料与 Github 个人资料关联起来。然后我们可以跟踪谁在贡献，无论是内部人员还是外部人员。这个工作流程解锁了关于正在发生的事情的大量有价值的数据。

#5：建立所有权

不要让项目成为孤儿，或随风飘荡。我们可以显示范围限定为项目或团队的图表/指标。各个团队经常为自己设定季度/半年度目标。这种社会压力有助于项目做得更好。

#6：良好行为的游戏化

我们现在有团队在竞争。React 和 iOS pop 项目的关注者数量大致相同，并且存在一场争夺最多关注者的太空竞赛。在不直接管理项目的情况下，您可以影响项目。我们不希望工程师与律师纠缠不清，浪费时间。我们希望他们有纪律地去做。

这项技术对 Facebook 的核心程度如何？
谁将使用它，它对谁有用，它的价值有多大？
已经存在哪些与这项技术类似的东西？
该项目中有任何新颖之处吗？
它是否包含第三方，包括第三方开源？
谁将维护该项目，接受贡献并与社区联络？
项目应该在哪里/如何分发？
公开版本日期是什么时候？

我们有一个非常强大的许可模板，我们坚持 BSD，偶尔使用 Apache 或 Boost，而我们考虑其他许可的唯一原因是目标社区具有使用该许可的强烈文化。我们不会强加社区不熟悉的许可。

#6.5：明智地选择您的律师

我们有一个 linter 来确保许可标头都在那里，并且一切都准备就绪，在一个私有存储库中。然后我们在周中发布，在 Twitter 上发布，进行 Facebook 开源社交媒体宣传，然后将其发布到代码博客。然后社交媒体的魔力就生效了，我们在第一天就获得了良好的势头。我们有一个由 600-700 名员工组成的内部小组对 FOSS 感兴趣。

每周五，马克都会在下午 4 点召集所有人进行问答。在会议开始时，马克会谈论新的应用程序/产品/版本。他开始在这些会议上宣布我们的 OSS 项目，您可以想象这有多么鼓舞人心。知道 CEO 了解一个项目，并向全公司宣布它。很多项目都来自基础设施团队，这对他们来说是一个巨大的推动力。在马克谈论这些项目之后，我对它们的兴趣大增。

#7：发布只是零步

您必须知道如何继续保持它的成功。我查看一段时间内的关注者数量。我们可以看到第一周的兴趣高峰，以及随着时间推移的逐渐下降。重要的是后半段的梯度，而不仅仅是第一天发生的事情。

一些特殊情况

fb-flo 和 origami 打破了这条曲线；flo 在 JavaScript 会议上发布，使其社区扩大了两倍；面对面的公关极大地促进了 FOSS 的成功
KVO Controller 进行了为期两周的间隔，并在每次会议后都看到了强劲的增长；熟能生巧
我们的高潮是 Pop 的发布，它超越了一切；第一天获得了 4,000 名关注者，第一周获得了 6,000 名关注者，现在远远超过 7,000 名

显然，我们从声誉中获益，但成功建立在之前 iOS 项目成功的基础之上。Pop 在发布前进行了为期两周的封闭测试。一开始，我们就获得了强劲的增长。我们的封闭测试是最好的拥护者，帮助了早期的增长。iOS 社区的反响强烈。

我们鼓励主要项目拥有自己的网站。我们的设计团队为 Origami 构建了完整的网站。这表明您关心并照顾您的项目。

我们有 IRC、Facebook 群组/页面、聚会和黑客马拉松。这一切都很重要；而且都有效。

我们有一项技术，称为社区综述。React.js 团队将收集所有提及、所有项目、所有演示/演示文稿，然后将其展示给社区的其他成员，而不仅仅是在 Facebook 内部。这增加了额外的真实性。

外部提交的头几个星期至关重要！在第一天，您会收到大量 PR，大多数将是文档中的错别字修复。这不是错误，它表明人们感到舒适。

#8：留下线索

文档、未实现的功能、待办事项。随着项目的进行，它们会改变自己的命运。有很多路径：快照、上游、Flythenest、弃用、重启。

快照：通常是只读的，学术练习；创建许多快照是为了获得上游 FBThrift 是一个很好的例子

上游：我们与 Twitter 和 Linkedin 合作，以在上游 WebscaleSQL 中进行更改

Flythenest：项目继续发展成为“它自己的东西”；我们的一些主要项目将具有此特点，然后我们最终将像其他人一样“只是一个用户”

弃用：项目服务于有用的目的，并完成

重启：项目重新开始

#9：了解 OSS 项目生命周期

我们在过去几个月发布了 65 个新项目。大约每周 2.5 个项目。这更多的是关于质量而不是数量，但每个项目都有一个目标。项目类型多种多样；移动、基础设施和编程语言。所有这些都非常广泛。

指标	2013 年 6 月	2014 年 7 月
存储库总数	129	202
关注者	50.1K	97.6K
Fork	11.8K	20.7K
拉取请求	1400（502 天）	1973（208 天）
问题	404（323 天）	427（186 天）
提交	30.7K	42.4K