写点什么

LinkedIn 开源成功的秘密

  • 2016-06-20
  • 本文字数:2979 字

    阅读完需:约 10 分钟

开源就是不断的奉献自己,除非它将你的业务先毁掉。但是,有太多的人先入为主,将各种偏见灌输给你,诸如:开源有“毒”,开源根本无法赚钱之类的。这个时候,你只需要默默的,转身看看那些成功的利用开源的公司即可。

互联网的巨头,即使如 LinkenIn,也是开源的“专家”,让我们先过一遍 LinkedIn 的 GitHub 账户, 竟然是一家发布了 75 个开源项目的公司。而且其中有一些已经是获得巨大成功的项目了,有众多的开发者和公司参与开发和使用。是的,没错,这就是 LinkedIn,外表光鲜的互联网公司,主营的业务是招聘,标榜自己是“将全世界的专家联系起来,让他们更具生产力,并变得更加的成功。”

最近被各大公司释放开源项目的新闻刷屏,Google 刚刚开源了人工智能项目、FaceBook 开源机器学习项目 等等,几乎每周都有这些 IT “大鳄”们发布新的开源项目,令人目接不暇。 LinkedIn 也不甘示弱,近期又开源了其旗下项目 Amdry ,这是一款对象存储系统。其实,LinkedIn 已经悄然建立了一个世界级的开发者团队,和开源社区紧密联系,从开源中获益、也反馈给社区。近来 LinkedIn 的工程副总裁 Igor Perisic 接受了 InfoWorld Matt Asay 的采访。让我们来了解下 LinkedIn 是如何让开源在公司中成功运转的。

将代码开放仅仅是个开始

任何人都可以将自己的代码开放,事实上,类似 Sourceforge 上的很多项目经年累月的都是只有很少的开发者,(80% 的项目只有两个人或更少的开发者)若是有人加入的话,那真是让人兴奋不已。即使是某个项目有多个贡献者,但是绝大多数的项目有超过6 个月的时间没有更新。

事实上,仅仅从 LinkedIn 开源了75 个项目这个角度来说,并没有多大的意义,因为一个开源项目的意义在于能够在多大程度上引起社区的兴趣来,而这也是 LinkedIn 的开源故事的魅力所在。

正如 Perisic 所说:“数字通常只是表面的、虚的标杆,我们认为社区采用量才是成功的关键指标。” 举例来说, Pinot REST.li ,前者是一个实时的分布式的 OLAP 数据存储,LinkedIn 用来交付可扩展的实时分析,后者是一 REST 的框架,在 GitHub 上都是超过一千个 Star 和 Fork 超过 200 的项目。

另外,一个开源项目最好的健康指标就是代码仓库的贡献者数量和最后的更新时间,这两个指标随着时间的推移,也会为项目带来更多的贡献者以及更加频繁的更新,形成一个正循环。但是对于社区来说,这还不够。能够得到业界标准的承认,才是 LinkedIn 的开源工作所取得的成绩,比如得到 Apache 基金会的承认。

LinkedIn 有多个项目被 Apache 基金会当选为其顶级项目,诸如 Kafka Samza 、 以及 Helix 。还有其它项目,如分布式键值存储系统 - Voldemort 正在变得流行起来。REST.li 就不用说了,已经是非常受欢迎的开发框架了。总体而言,LinkenIn 通过在开源的努力已经在开源项目上赢得了开发者的认同。

开源现在已经是一个被滥用的词汇了,举例来说,太多的公司所发布的代码是对自己有用的,然后希望出现大规模的社区围绕着它来进行,然后希望这个项目对自己的公司更加的有用处。其实,开源基金会也是遵循着同样的如此的以自我为中心的逻辑,所谓的开放治理其实是一种伪装,不过依然是由单一的厂商控制最终的产出罢了。

当然,LinkedIn 也不是第一天就明白成为开源社区的典范的美德的。正如 Perisic 所描述的那样:“从早期的失败中,我们学到的重要的一课就是你不可以将一个项目扔给社区,然后就不再创新了。还有另外重要的就是,一个开源项目的成功与否取决于你如何参与到社区中来。”

Perisic 进一步解释,这也就是意味着,最为艰难的工作是在将刚刚将代码开源后的那一段时间,举个例子来说,LinkedIn 现在所总结的获得社区的反馈非常的重要,以及确保项目的目标是容易理解的。这都是经历了很多才学到的。不过,只为重要的还是团队的决定,如果你没有准备好将正在进行的工作开源的话,最好是先不要将之开源了。

何苦呢?

这里就有很多人提出了疑问了,既然开放代码已经困难重重了,再加上来自社区增长的压力,何必这么折腾了呢?Perisic 进一步点出了其中的奥义,虽然开源对于 LinkedIn 来说有让价值在外部流动的好处,但是最重要的一个缘由还是开源社区能够影响到工程师。

Perisic 说道:“我们发现,在开源了项目之后的第一个结果竟然是我们开发者撰写出了质量更好的代码。将代码放在自家的门后,只会成为鼓励大家偷懒、马虎,开源之后,则不一样,这样会激励开发者们,使他们更加的细心。开源之后改进尤为明显的有,文档也有人写了、代码也更容易让人阅读了、而且非常注重每一次的测试结果。”

将代码开放以后,也就意味着开发者们要接受批评--非常公开的批评。用 Perisic 的话就是:“当一位开发者将某一段代码公开以后,也就是将自己的声誉放在了网上,其本质上是一种类似同行评审。这样就让开发者们能够激励自己,将他们的代码写的更好、撰写更完善的文档、以及对于可重用性的重视。”

Perisic 又说道:“当然,开源也不仅仅是有利于代码质量。它也能够确保开发人员的视野不至于太过于狭隘,总是盯着自己眼前那点事。在一个开源项目下工作,也就意味着一起共事的不仅仅是自己身边的同事,而且还有来自其它公司的开发者,这会帮助大家对于技术、业务方向的发展趋势有一定的意识,而且可以帮助他们学习如何评估其他开发者的输入。在这个多元的世界中,开发人员应该学习如何更加高效的来领导自己的团队。”

最后,Perisic 指出:”从公司的角度来看, 这也有助于发展你的品牌工程, 这证明在吸引新的人才和留住现有员工方面非常的有好处。”

“种”下你的代码,让它茁壮成长

Perisic 非常认真的说:“我认为在创建一个项目并将之开源,应该像你的内部组织一样去花时间用心去做。而且发布什么样类型的代码也是有讲究的,是蛮重要的事情。这就是为什么有一些项目无法发展出强大社区的重要原因之一,因为所发布的项目是孤立的。孤立的代码可能就是那些仅仅只是对本公司业务有用的代码,如果它对于外部其它公司没有任何用处的话,那么它失败的可能性就会很大。”

但是有的时候,最好还是在现有的项目上去投入资源和人员,即使它们可能还没有获得大家公认的高度。独立的开源项目是伟大的,但是如果它是在 Apache 的羽翼下而且也蛮有意义,那就不要犹豫了。如果已有的社区的开发者们渴望使用它,那就更不用有所犹豫了,赶紧将之开源!

既然这样,那么问题又来了,当来自 LinkedIn 外部的代码对于 LinkedIn 毫无用处的时候是怎么处理的?Perisic 是这么回答的:“你不能只是将项目放弃就不管了,你应该为原来选择你的用户提供相应的替代和迁移的途径。” 这里举个例子,LinkedIn 曾经放弃了一个叫做 Camus 的项目,这个项目的功能是用于将数据从 Kafka 导入 HDFS 的一个管道实现,放弃归放弃,但是 LinkedIn 另外开发了一个叫做 Gobblin 的项目,LinkedIn 新的数据感应框架,也可以实现 Camus 的功能,只是更加的完善,LinkedIn 此时做的决策就是,为 Camus 的用户提供迁移的路径。

总结以上所有,开源项目是需要付出巨大的时间来开发、精心培养、并时刻留意的。Perisic 非常明白其中的涵义,但是认为值得:“对于开源社区来说,再大的投入都是值得的,因为回报也是丰厚的。”


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-06-20 19:002741
用户头像

发布了 33 篇内容, 共 12.3 次阅读, 收获喜欢 13 次。

关注

评论 1 条评论

发布
用户头像
厉害
2018-12-12 21:43
回复
没有更多了
发现更多内容

Ti-Click:通过浏览器快速搭建 TiDB 在线实验室 | Ti-可立刻团队访谈

TiDB 社区干货传送门

关于TiDB数据脱敏的一些想法

TiDB 社区干货传送门

实践案例

使用 TiUP 安装部署 TiDB 集群实验流程

TiDB 社区干货传送门

版本升级 集群管理 管理与运维 安装 & 部署 扩/缩容

备份的 “算子下推”:TiDB BR 简介

TiDB 社区干货传送门

TiDB 底层架构 备份 & 恢复

有关 TiDB 升级的二三事——教你如何快乐升级

TiDB 社区干货传送门

版本升级

在TiDB中实现一个关键字——Parser篇

TiDB 社区干货传送门

TiDB 底层架构

PlacementRules in SQL 初试

TiDB 社区干货传送门

DBA之伤-truncate/drop

TiDB 社区干货传送门

TiDB BR 备份至 MinIO S3 实战

TiDB 社区干货传送门

管理与运维

TiSpark数据写入过程解析(源码解析)

TiDB 社区干货传送门

TiDB 底层架构

DM 分库分表 DDL “悲观协调” 模式介绍

TiDB 社区干货传送门

迁移 TiDB 底层架构

专栏技术文章发布指南&奖励

TiDB 社区干货传送门

社区活动

分布式数据库TiDB在百融云创的探索与实践

TiDB 社区干货传送门

实践案例

回顾下Hackathon中的TiCheck

TiDB 社区干货传送门

实践案例

5分钟搞定 MySQL 到 TiDB 的数据同步

TiDB 社区干货传送门

实践案例

Dumpling 导出表内并发优化

TiDB 社区干货传送门

性能调优 TiDB 底层架构 备份 & 恢复

TiCDC 4.0.15 初体验

TiDB 社区干货传送门

实践案例

TiDB 社区专栏:让技术人员成为更好的读者/作家

TiDB 社区干货传送门

新版本/特性发布 新版本/特性解读

TiDB在个推的落地实践 | 解决热点难题,提升性能超千倍

TiDB 社区干货传送门

性能调优

JOIN 查询的执行计划 比较

TiDB 社区干货传送门

性能调优 TiDB 底层架构

DM 分库分表 DDL “乐观协调”模式介绍

TiDB 社区干货传送门

迁移 TiDB 底层架构

大量 SET autocommit 导致的 TiDB Server CPU 高案例

TiDB 社区干货传送门

故障排查/诊断

TiDB4PG 之兼容 Gitlab

TiDB 社区干货传送门

x86和ARM混合部署下的两地三中心方案验证

TiDB 社区干货传送门

实践案例

TiDB架构浅析

TiDB 社区干货传送门

TiDB 底层架构

TiDB学习之路

TiDB 社区干货传送门

实践案例

带着问题读 TiDB 源码:Power BI Desktop 以 MySQL 驱动连接 TiDB 报错

TiDB 社区干货传送门

故障排查/诊断 TiDB 源码解读

关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事

TiDB 社区干货传送门

TiDB监控Prometheus磁盘内存问题

TiDB 社区干货传送门

故障排查/诊断

前缀索引在特殊场景下的优化尝试

TiDB 社区干货传送门

实践案例 TiDB 底层架构

探索TiDB Lightning源码来解决发现的bug

TiDB 社区干货传送门

TiDB 底层架构

LinkedIn 开源成功的秘密_InfoQ_李建盛_InfoQ精选文章