亮网络解锁器,解锁网络数据的无限可能 了解详情
写点什么

为什么开源适合 LinkedIn

  • 2015-06-23
  • 本文字数:2413 字

    阅读完需:约 8 分钟

开源软件不再局限于解决小问题、底层问题,否则也不会有公司花代价去创建开源软件。如今,创建、部署开源软件的社区日渐成熟,他们代表着世界上最大的几个技术公司。为什么有此变化?为什么公司应该把一些精力花在开源软件上?为何要开源?

初衷就是开源软件能使你的工程师变得更强。随着他们的作品呈献给整个社区,他们的技艺也在精进。

他们能写出更好的软件

为别人工作,比起为自己公司工作,更能写出好软件,这听起来有点矛盾,但事实上却很有道理。当开发人员写一个“内部”软件的时候,他们倾向于在一些环节上偷工减料——我也是如此——尤其是在文档、代码的可读性和可重用性,以及编写完善的测试用例方面。但开源社区有多种选择,如果你的代码太晦涩,他们不会有耐心去搞明白它究竟在干什么。而公司内部则没得选。

在开源项目中,开发人员的名字会和他们创建的软件绑在一起,整个社区都在审视他们。这就好像给网上的代码和声誉配上一张面孔,每个人都能看到他们的设计取向和 bug。这大大激发了他们去完善自己的软件。开发人员都希望自己的名字和设计精良的美好事物联系在一起。

每个优秀的工程师永远在不停地学习,他们想跟上自己专业领域的发展步伐。直面那些自己公司之外的开发社区,能帮助他们看到最新的趋势,以及帮助他们学会如何利用社区带来的价值。而且,如果他们自己是一个开源项目的所有人,他们的“技术领导”技能也能得到长足的进步,因为他们必须要选择接受或拒绝来自社区的补丁。一个成功的项目,应该是贡献者齐聚,各种观点争鸣的社区。但不是所有的问题都有更简洁更好的技术解决方案的。他们必须决定选择什么,放弃什么,这很难,但在这种困难中,他们锻炼了新的技能。很多开源项目的留言板上充斥着偏激言论,口水战经常处于一触即发的边缘。

从公司的角度看,它能帮助打造“研发品牌”

研发品牌意味着一种公司特有的开发能力的烙印,就好像给产品贴个标签,上面写着“这是我们制造的”。打造这种品牌有很多方法。开源是一种很好的和其他开发者共享代码的方式。它可能无法完全揭示一个公司的内部运作机制,但肯定能展现出跟这个项目相关的各个方面。这也是资深员工给应聘者的一个展示窗口,一个企业向未来雇员发出的明确信号,即,如果他们来这儿工作,不仅能获得个人技能的提升,并且能充分利用那些他们喜欢的软件系统,而不用重新发明它们。

当然,在那么多支持的观点之外,也有一个反对的声音,那就是,开源并不适用于所有公司,也无法解决所有问题。

不要因为缺少人力而开源

在早期这是个常见的错误观点。这个观点的逻辑是,如果我有一个优秀的项目需要额外的帮助,那么开源它会吸引全世界的开发者为它做贡献。这是错误的,原因有二:如果项目成功了,它会从外部社区收到无数的需求,需要耗费额外的精力和时间把代码写出来,而这些需求很有可能跟公司创立这个项目的初衷相悖。如果项目没有成功,前期花了大量的资源去包装它就全部白费了。而且,要判断为项目写代码和提交补丁的个人或社区的能力好坏也很困难。毕竟在外部世界什么都有可能。要做出成功的开源项目,需要投入大量的时间来开发、监管和培育。

不要为了开源而开源

这个问题我通常称之为:“做个好公民”,多做做功课。在创立任何项目前,做个好公民,调查一下是否已经有社区在致力于开发类似的解决方案了。然后花点精力去评估一下,是否给已有的项目贡献代码会更好?通常,使用现有的项目并做出自己的贡献,价值远胜于重复发明轮子。

把糟糕的项目拿出去开源,会产生负面影响。人们审视这个项目后会疑惑,既然已经有了一个很棒的开源解决方案,为什么这个工程师或团队还要搞出这么一个水平低劣的东西来。这对于上面所说各种开源的好处,都是一种伤害。

如何创建成功的开源项目

这很不容易。老实说,LinkedIn 早期在这上面也是磕磕绊绊。我们早期学到的一个教训就是,开发团队不能为了开源,简单把代码丢给社区,然后就停止创新了。很多人认为只要一开源,社区会帮你带领这个项目继续前进,这种情况偶尔也会发生。但大多数情况下,你作为项目的缔造者,有责任保障它在开源的模式下继续发展好,并且你要尽可能多花时间在上面,就把它当作还是你公司内部的项目。

我们学到的另外一个教训是,多半的小型项目,应该集成到大型项目中去。LinkedIn 的第一批开源项目是一些小型的搜索组件,我们从自己基于“ Lucene ”项目的主搜索引擎之上创建了它们,但我们却没有和 Lucene 项目的开发者社区保持同步,大多数组件都没有集成到 Lucene 中,最终被丢弃——其实它们中的很多项目都很出色。Apache 社区则是一个极好的正面例子。单独的开源项目是不错,但是如果你能让这个项目抱上 Apache 这条大腿,那么请不要犹豫。一个成熟社区中的开发人员如果有激情去开创新的项目,成功率要高得多。

后来我们创建 Kafka 项目时,从过去所犯的错误中吸取了教训,明智地选择了投入资源,最终它成了我们的最佳开源项目。

最后,如果一个公司决定开源某个软件,他们必须要有心理准备,最后不得不跟这个项目分道扬镳。我第一次不得不给我的一个项目单独拉出分支的时候,感觉就像是杀死了自己的孩子。做出这个决定后,我整个周末都没睡好,感觉很惭愧……感觉自己像个叛徒。但是后来我明白了:一个项目一旦开源,它就有了自己的生命力。它很有可能演进成为一个你根本不想要的东西,并且不再和你的软件系统兼容。这一刻到来时,你别无选择,只能拉出分支单干了。这是一个自然现象,时不时会发生。你的孩子长大成人了,让大人重新过回他们自己的生活吧。

但这不应该把谁吓跑。开源是一件非常值得去做的事情,创建、管理、参与开源项目,其乐无穷。

查看英文原文: Why Open Source Works for LinkedIn


感谢郭蕾对本文的策划。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015-06-23 00:312222
用户头像

发布了 77 篇内容, 共 35.4 次阅读, 收获喜欢 25 次。

关注

评论

发布
暂无评论
发现更多内容

食堂就餐卡系统设计

极客李

作业1 餐卡系统设计

Geek_2e7dd7

食堂就餐卡系统设计

赵龙

虽则悲欢不尽相同

zhoo299

随笔

第01周命题作业-食堂就餐卡系统架构设计

Jaye

极客大学架构师训练营

学习总结

Geek_2e7dd7

平台化服务的基石:隔离与交互策略模型

孤岛旭日

企业架构 用户权限 权限系统

随遇而安的适配器模式 | Spring 中的适配器

大头星

Java spring 面试 设计模式 Java 25 周年

ARTS-week3

王钰淇

ARTS 打卡计划

食堂就餐卡系统设计

wyzwlj

极客大学架构师训练营

架构师训练营第一周学习总结

不谈

架构设计文档学习总结

jason

架构师思维

极客大学架构师训练营

重新定义失败

史方远

个人成长 随笔杂谈

食堂就餐卡系统设计

stardust20

架构训练营-第一课总结

第一周总结

芒夏

极客大学架构师训练营

ReentrantLock 公平锁和非公平锁源码分析

张sir

Java 多线程 Java 25 周年

食堂就餐卡系统架构设计

Cloud.

架构师训练营第一周总结

Cloud.

极客大学架构师训练营

Week 01 命题作业

卧石漾溪

极客大学架构师训练营

作业一:食堂就餐卡系统设计

Geek_36d3e5

架构训练营-食堂就餐卡管理系统

架构师训练营-第一课学习总结

King

学习 感悟 极客大学架构师训练营

架构师训练营 第一周 学习总结

一雄

学习 极客大学架构师训练营 第一周

C02-商业模式与架构设计

buoge

UML练习1-食堂就餐卡系统设计

一剑

如何成为一个架构师

_MISSYOURLOVE

极客大学架构师训练营

第三季已经起航,送你一份活动手册吧

赵新龙

写作 社群

架构师0期 | 架构师是怎样炼成的?

刁架构

极客大学架构师训练营

程序员如何破除「迷茫」

顿晓

学习 程序员 架构 迷茫

为什么开源适合LinkedIn_语言 & 开发_曹知渊_InfoQ精选文章