为什么说企业采用开源的阻力来自工程师?

我常常在思考,为什么采用开源会失败?失败的是如此彻底,以至于连一丁点的翻身机会都找不到。利用开源做商业版本的、利用开源做项目的、利用开源做教育的、利用开源做社区的、利用开源做会议的......围绕某个开源项目或技术可以做很多事情,但是大多以宣告失败而告终。从欧美先进国家的一片创新与革新的面貌不同的是,本土依旧在拾人牙慧为主,并没有发展出相对应的生态。

引子

LC3 又来北京了,Linus 也信守承诺,如约而至。去年我参会之后,写下了《开源软件正在吞噬世界————LinuxCon中国首秀感想录》 一文,学到了很多。今年,我就不再撰写什么见闻录了,而是以演讲者的身份做了一次分享。以下是根据我自己的演讲所整理而成。

正式开始之前

我们先来看一个日常的例子,这在北京这座超大城市里很常见。正如我给大家展示的这张照片一样,是我每天都会看到的一个场景。

这张图是我在每天上班经过的地方随手拍的,大量的非正常停放自行车,将人行道堵塞。据说这是新四大发明,但我宁愿称之为社会的照妖镜。我心里一直有个疑问,这些停车的人都是谁?是我身边的人吗?如果不是的话,那么共享单车的受用人群就不是公共交通的上班族,按照这个推论可知,让这些事情发生的就是身边的人。

为什么会产生这样的情况?它让我不由的想到了开源在本土的发展状况,我个人的职业经历让我了解开源、也是从开源中渐渐成长起来的,作为一名开源布道师,深刻感觉到那种不能进步的痛。于是将自己思考了很久的一个阶段性的观察分享给大家。

关于我

还是给大家介绍一下我本人,虽然本土关注开源方法论/文化方面的人很少,但是依旧是一个隐性的主题。网络唯一ID:适兕(kuosi),我给自己标榜为开源信徒,理由有三:

  1. 开源花了20年的时间,证明了其强大的进化能力。
  2. 开源正在成为整个现代经济社会的基石。
  3. 未来的开源,不仅局限于软件,它会成为重要的创新方式和生产方式。

我也是开源之道的主要作者,开源之道是以撰写或翻译有关开源的方法论、文化、现象等内容的博客,也开了微信的公众号,大家可以搜索关注。

目前在一家云计算服务提供商:青云QingCloud 做产品经理。同时也是开源社执委会成员兼首席编辑,个人履历就不多讲了,拥有十多年开发和管理经验。

申明: 本文以及演讲不代表任何青云的观点,仅代表个人。

关于标题中“采用”的一点解释

使用: 可以套用一句话:“凡有水井处,兼用开源软件。” 开源已经无处不在了。不过,本次演讲谈到的是 采用,是指那些和开源社区形成良性互动,以供应链和生态系统的视角看待开源项目,将开源视为重要的合作伙伴,并提高到战略地位、在人才竞争、加速业务上市等形成优势的企业或个人。

陈述一些事实

任何事情都需要以对比的眼光来看,我所陈述的这些都有相应的对照,开源的成功已经是事实,如果非得要数据,大家不妨看看开源之道所撰写的一系列文章。

开源在本土发展的情况并不好,让我们不妨来数一数:基于Linux的商业发行版已经消亡、基于OpenStack的商业发行版正在转型、没有一家非盈利性的基金会、自身发起的开源项目占据整个市场非常的渺小、开源在大学简直是一片荒芜之地、卓越项目中的优秀华人工程师屈指可数,和从业人数完全不成比例…….

以及到处都是搭便车(吃大亏)的公司,听众如果不行的话,可以找IT相关公司的JD即可。

几个维度来说明,工程师才是障碍

人类进入文明的标志之一,就是极少相信因果关系,而是倾向于相关性,开始明白影响事物的发展方向的因素有很多。而这就是科学的真谛,需要我们不断的努力,抽丝剥茧,找出最后的真相。我本人绝不敢说这次分享就是某些结论,而是个人的经历和观察,企业采用开源,个人拥抱开源,其中缘由有很多,选择的不同,导致路径不同,也就导致结果不同。

而我窃以为,其中最大的障碍来自于工程师本身。开源之道会谈到更多的内容,但归根结底仍然是人的问题。以下是我收集到的论据。

文化

文化上的内容,可以说的有很多,但是今天我这里不会提那么的多,但是偶尔的一、两条拿出来唠叨唠叨,大家应该会没有什么意见。

  1. 崇尚权威,这一点很多人都论述过,如果你迷信权威,那么新技术几乎没有什么出头之日,而开源的发展,往往一开始就是和权威相冲突的,Linux和Minix、Apache和NCSA……本土的文化和母亲教育,是和这一点非常有关的。
  2. 读书人窃书,不是偷。开源的前提是尊重知识产权,Copyright也好,CopyLeft也罢,要承认别人的劳动成果和付出。法律是一切的前提。而本土的环境视盗版为天经地义、理所当然。这也是一直以来难以将开源与免费讲清楚的重大障碍。
  3. 没有负反馈。也就是说这是一个追求表面和谐的糟粕文化,没有批评、没有反驳,叫好声一片。你几乎找不到哪里有批评的声音,这点在企业中也是非常的常见。
  4. 师夷长技以制夷。这是一句耽误了很多年的毒药,没有文化上的改变,技术本身不过是些皮毛罢了。
  5. 集体主义,你那个单位的?微信群要标注姓名+公司的。举办MeetUp以公司的名义进行筹划。

人性的弱点

利用开源项目,尤其是成熟的开源项目,非常的容易出结果,甚至短时间内就可以做出非常大的成绩,攻克一个从无到有的难关。然而这里名就会产生一些人性的不光彩的一面:

  1. 虚荣, 每个人都希望成为大神,被同行认可,被尊重和敬重。开源的成绩,会让人产生一定的误区,就是被喜欢夸奖的老板热捧,这个时候就要非常的小心了。
  2. 自大, 当你解决了一个问题的时候,可能很快就会忘记自己是站在巨人的肩膀上,短时间的小成功,会遮蔽工程师的双眼,自视无所不能。
  3. 及时兑现, 人在无法看清未来会发生什么的情况下,会选择及时兑现当下的回报,哪怕是未来的承诺更多。这一点尤其发生在开源项目的贡献上,企业也是一样的。

工程上的短见

开源的项目,尤其是一些成功的开源项目,如Kernel、Apache等,均是经过多年,由来自全球数千人所开发,如果是按照金钱来衡量的话,如Kernel,是70多个亿美金。然后,很多企业或个人,就在没有融入的前提下,直接就开始做成下游项目,以“蚂蚁憾大象”的方式进行开发或定制。这是一种非常自大的行为。

另外就是没有做上游优先,将软件工程中开销最大的维护成本落在了自己的公司或团队的身上,随着时间的流逝,这个窟窿会越来越大。这也就是常见的“刻舟求剑”式的Fork,其实说刻舟求剑,很多人不愿意承认,因为没有人愿意承认自己是犯低级错误的。最为常见的理由就是,”上游的每个Release,我们都能及时的使用,虽然我们没有参与日常的讨论、补丁更新”,而这恰恰就是问题之所在。这里时间原因我就不多说什么了,就套用去年的图灵奖得主John L.Hennessy 和David A.Patterson 对技术的描述:

尽管技术的进步是连续性的,但只有当技术积累到一定程度,为新功能的出现做好准备时,才会产生跳跃性的、不连续的影响。 ——《计算机体系结构量化研究方法》P14

刻舟求剑式的放大自己,用静态的思维去看待开源项目的进展,而忽略时间和全球参与的力量。

缺乏认知和视野

在“人定胜天”的环境中,喜欢先定好时间,然后再来进行项目。而这往往也是开源在企业当中最大的阻力。因为是人为的规定了项目的周期,工程师会以项目的截止日期当做至高的目标,因为那是KPI的保证,只能提前,不能落后。落后的话,可能会影响到当年的年终奖。

于是,一场忘却上游的疯狂的“大跃进”工程如火如荼的开始了,更加夸张的是老板一般会搞搞仪式感,誓师大会、封闭开发、上山修行之类的。然后出来之后,就成了自主知识产权,跃居世界同行前列。

此类工程的吊诡之处在于“内部观点”和“外部观点”之分。这是2017届诺贝尔经济学奖得主——理查德.泰勒先生及其同行研究的结果。当你置身其中的时候,总是会将自己和团队的能力、协作放大。而实际上,历史上这样的项目成功的几率非常之小。

开源是一个可以迅速“传染”的现象,它实现的技术栈也是具有“染缸”效应的,一旦搭上开源这条船,基本上就会逐渐的被开源所吞噬,这个我会专门撰文来进行进一步的描述:LAMP组合,到各式各样的数据库等,但是,即使这样,很大一部分人,仍然会孤立的看待某个具体的项目,举个大家常见的例子,就是现在很多公司纷纷在GitHub上建个账号,放上代码即使完成了开源。开源,它仍然是以解决具体的问题而存在的,它必须是组合现有的很多项目来完成,比如CI/CD 的组合,(git + jenkins+ Ansible+Kubernetes)等。而理解这一点,尤其是对开源做营销来说太关键。

思维误区

以眼前的团队和实力,去评估整个上游的进度。互联网所带来的社区力量,常常超出我们的自我直觉,尤其是那些被广为人知的、背后有大厂和基金会推动的项目,当然尤其是那些能够解决实际问题的项目,实力往往非常的雄厚,如Kubernetes、Docker、Apache Hadoop、Apache Kafka等等,是超越任何一家单个公司的工程力量的。

还有一个常见的错误的说法:认为贡献上游是在浪费时间,这其实是一个悖论,从上游fork了一项巨大的工程,然后埋头开始做,光是消化都需要时间的。更不要说创新了。等到下游发布的时候,上游已经是另外一片光景了。贡献上游恰恰是逃避惩罚的最佳方式。

著名诺贝尔经济学奖得主丹尼尔•卡尼曼曾在其畅销书《思考,快与慢》中说道:

完全认识到自己无知的专家可能会被更自信、更能获得病人信任的竞争者取代。对不确定性的无偏见评价是理性的基石,但这并不是个人或机构想要的。在危机中,极度的不确定会造成严重后果,而且在风险高的时候承认自己只是在猜测的做法特别不易被接受。所以,假装知道通常是首选的解决方式。

所以,会出现一种很常见的奇怪现象:贬低自己,认为贡献开源必须具有超能力。社区需要你做任何事,包括学习。

该如何解决?

以上内容,绝无任何的指责之意,只是笔者多年以来的观察和实践,趟过的坑和走过的路多了起来之后的一点感悟。解决之道仍然在摸索中,而这从来不是一个一蹴而就的过程,而是要经过长时间的磨炼和积累,或许才有半点希望。因为实际的历史证明,这是一个漫长的过程。

关注开源之道

开源之道,旨在探讨围绕开源的一切内容:技术本身、商业模式、文化、心理、认知、现象等等一系列内容,目标是希望利用开源强大起来,而不论这个主体是工程师,还是某个经济团体。希望所有人都能够从中获益,让明天更加的美好!

一切都应从自己的认知开始,保持初心,努力的寻找真相!开源之道亦在探索当中。

提高认知

要从开源这一现象来探求其本质,开源本身就是自由的妥协,天生青睐于商业,是符合经济规律的,只有从工程师文化、从商业、人才战略、上市时间、快速试错和迭代、创新等角度来看待开源的益处,审时度势,了解众多的开源失败和成功的案例,方能摆清开源的位置,而不是想当然的做法。

从工程和经济上下功夫

要去从工程和经济的角度分析开源项目,根据自己的工程团队和商业目标,做切实可行的方法,避免诱惑,认清自我更加的重要。千万不要想着去控制某个开源项目,因为要求透明的文化,所以一旦控制就会被所有人嫌弃,要去影响,努力的提高自己的影响力才是王道。 在经济上,要算好成本、投入和产出、收益。千万不要把开源项目当免费来使用,这里面有着巨大的隐性成本。 开源项目不是“公共物品”。总有人为之买单,更何况软件项目是一个持续性的投入,没有一刀切的方式。 另外,开源项目也有惩罚机制,你所要做的就是不要被视为“搭便车”而受到惩罚。

改变和拥抱

作为公司要想采用开源,获得所有开源的好处,需要从根本上做出改变的态度和决心,如文化、流程、工具、甚至是人力资源管理。如果没有做好这些准备,请一定要远离开源,最后搞个不欢而散。请牢记下面三点内容:

  • 影响,而不是控制
  • 保证透明的决策和讨论
  • 去做领导者,而不是放任不管

技术仍然是最重要的

千万要记住,开源软件项目是为更为高效的解决问题而存在的,归根结底,它仍然是一个人为了解决问题而设计的一种途径,所以,无论怎么样,都要记得技术仍然是最为重要的部分,而技术部分要有所心理准备,开源的内容,由于缺少文档,只有代码,越发的显得枯燥,所以更需要工程师付出更多的决心和耐心去学习,参与开源要有延迟满足的心态。

即使是当下开源如此流行和被认可的时代,能够直接用开源换取经济报酬的情况也极为少见,更多的是只有自己付出了,劳动成果被他人看到了,才会出现工作的交易或者产品的交易,进而产生报酬。

几个典型的案例

接下来,我给大家分享几个常见的案例,也是我个人亲身经历过的失败案例,也是工程师为什么是障碍的一个佐证。这是我所经历的无数个细小琐碎的案例中的较为典型和直观的。

案例一

OpenStack也好,Kubernetes也罢,大家线下聚会的时候,都是以公司的名义来进行,(是的,我们的文化是不承认独立的人本身的,一定要有个实体的单位。这体现在生活中的每个细节中。)这样导致的结果就是,功利性太强,工程师往往是带着目的去做分享和演讲的,甚至会做一些违心的不是很务实的广告等。最后,线下聚会的质量下降,成为了营销、会虫聚会之地。

正确的组织方式,应该是以社区为背景,以独立的工程师个体为单位,尽可能的避免出现公司,以人与人的社交关系为主。要模糊等级、Title、公司等,一切都是构建在技术上的探讨。另外,作为背后的公司实体,也不应该强求工程师去做一些表面功夫。既然都是实在的、开源的,都是内行人的交流,就要实打实。

案例二

某家大型国企,为了鼓励大家提交上游代码,专门设置了奖金池,以鼓励工程师积极的向诸如Kernel、OpenStack、Python等上游提交贡献,结果多年下来,奖金无人问津。

这中间有个悖论,那就是在不耽误公司的项目的情况下,有效利用业余时间去参与社区。

正确的做法:将金钱置换为时间,工程师应该有公司鼓励的时间去参与上游。

案例三

佛系工程师,说是参与开源是一切都是水到渠成的事,到了某个阶段,就自然而然的去参与了。

结果:三年之后,依旧是搭便车。 每隔半年就从上游拉新的版本,放弃过程中修改的内容。

正确的做法:从一开始就参与到上游。Make things happening. 等待是没有用的,如果等待有用的话,人类早就移居火星了。Do it now!

结语

最后,我仍然以一句话送给大家:

“开源让中国与世界更加的同步!” ——吴晓敏(forrest大中华区VP)

开源不是让你建造一个孤岛般的平行世界,而是更多的参与和多样性,进而创造一个更加美好的世界。

谢谢大家!