拥抱开源

拼搏现实的明天。 2022-05-10 00:58 191阅读 0赞

\#\#引子：我用开源的技术方案去竞标

大约是4年前，我们要去浙江移动去竞标一个项目，产品中需要一个流程引擎负责工作流的运转，竞标会上针对这个流程引擎的实现方案展开了激烈的讨论。

\* 我们给出的引擎是开源的activiti，成本主要在对activiti的调研研究和二次开发上，报价只有几十万。

\* 另一个厂商给出的引擎是自己开发的一个产品，成本主要是买该该产品的服务（它还不是个SaaS系统，需要在本地安装的那种），报价高达300多万。

最终的结果，我们败了，客户不相信开源产品的稳定性，也不信任我们有那个能力可以把它研究透，所以宁肯多花几百万也要买一个出现问题一个电话可以找人搞定的方案。

这件事情对我打击很大，我觉得国人对开源还是存在着种种误区，幸运的是后来一份工作老板是开源产品的拥护者，我每天的工作就是找到适合企业的开源产品并应用到生产。

\#\#开源的优势

\#\#\#1 快速响应

售后响应速率太慢可能是所有服务消费者吐槽最多的话题。对于软件行业也一样，特别是那种预付费的服务，你可能得到最多的反馈是“我们内部先评估一下”、“已经在走流程了”、“这个确定是我们的问题，下个版本中会解决”、“有什么最新的进展我们会第一时间通知您”这种废话，每每收到这种反馈心里肯定是一万只羊驼。如果采用开源技术，有自己的技术团队在负责，那就可以通过KPI考核、找他们领导吵架、甚至做在他们身边看着他修复等办法来解决，总之命运掌握在了自己的手上，不再是隔着邮件或电话看供应商的脸色了。

\#\#\#2 免费

免费意味着成本的降低，特别是复用性很高的技术免费带来的利润上的收益是不可估量的。举个简单的例子，假如你搭建了一套几十个普通实例的OpenStack，一年可以企业节约几十万。当然这里只是从费用的维度来夸大了开源的优点，现阶段公有云的服务质量还是远远高于私有云的。

\#\#\#3 试错成本

试错成本对一个系统架构来说非常的重要。当你对某个服务节点的技术选型不是太确定的时候，最好的办法就是多使用几种技术。如果是开源的组件，只需要安排技术人员安装配置后用过就能知道是不是适合自己，而商用的产品需要去联系供应商、不见得有试用版本、对产品的评估只能通过网上资料调研和供应商忽悠。

如果初期选定了某个开源产品或组件，在使用过程中发现不合适或者出现了更好的替代品，可以毫不犹豫零成本的过渡到新技术；但如果已经买了商业版的服务，就会有种食之无味弃之可惜的感觉了，很可能因为投资回报率的角度继续使用老技术，等待合同期结束后再考虑新方案。

\#\#\#4 活跃的社区

如果一个开源技术有很高的社区活跃度，那么它的功能就会越稳定，技术革新就会越快。社区活跃度高，说明很多的人在使用这项技术，也就会带来更多的应用场景的生产级别的测试，就会发现和修复更多的bug。由于每个使用者的应用场景可能有所不同，就会抽象出更标准的接口，大家把支持自己应用场景的代码提交回github，版本的迭代又会带来更多的功能。这样就形成了一个良性循环，用的人越多，而且大家都把自己的部分反馈回社区，那么这项开源技术的影响力就会越滚越大。

\#\#\#5 摆脱供应商束缚

举个我自己的例子，我们采购了IBM WebSphere 7.X版本的服务，为了与该服务对接我们客户也做了一部分定制开发。一年之后IBM推出了WebSphere8.X的版本，服务接口发生了变动，我们先前的客户端代码不能对接到新的版本中来，为了保证生产的稳定性，我们选择了保守治疗的方案，继续使用7.X的版本。又过了一年，IBM官方正式通知我们不再支持7.X服务，此时摆在我们面前的只有两条路，第一：被迫升级到8.X，客户端代码想办法重新开发。第二：下车，不再与其合作，换其它平行的产品。但是无论哪种选择我们都是输家，因为这个过程中生产环境面领着巨大的不确定性。

\#\#开源的劣势

\#\#\#1 技术门槛高

使用开源的前提是必须要有一直过硬的技术团队，因为开源意味着你没有售后服务，一旦出现问题全靠自己的团队去解决。按照门槛由低到高，技术团队主要负责以下任务：

\* 1）    产品的安装和配置

\* 2）    自定义部分的设计与实现

\* 3）      生产环境紧急bug的修复

\* 4）      安全隐患和潜在风险的评估

建议你的团队至少要达到第三级，也就是说生产一旦出现严重的bug，技术团队可以在最短的时间内修复，可能不是最优的解决方案，但是一定要保证生产环境正常稳定的运作。

\#\#\#2 不适合国情

为什么很多在研发和设计人员看似很美好的技术在国内都推广不起来？这是由我国国情决定的。

老外开发的东西，本质上就是制定一套规则，只要按照我的这个规则配置，就可以解决你的问题。而我国这种甲方乙方的传统观念，是不允许有规则存在的，你们乙方不要跟我说你产品的使用规则是什么，我是甲方给了你钱你就得按照我想要的规则来实现。

从这一点来看，我们在选择使用某个开源产品前第一个要确定的问题就是：你是否有设计的决策权，如果没有话，开源的推动就会显得很痛苦。

\#\#\#3 免费

在开源的优势里已经提到过免费，它是一把双刃剑，免费也同样是开源的一大缺点。举个最极端的例子，你选择某个开源产品存在巨大的安全隐患，被不法分子利用并造成了巨大的经济损失，这种情况下唯一能做的是就等待或者自己把安全漏洞修复，损失的钱是不可能要的回来了。因为没有严格的法律上的约束，开源项目的质量和安全程度很大程度上取决于开发者的素质和心情， 反之商业产品这一点就会好很多，因为有法律合同的约束，他们在开发和设计的时候就必须把因产品质量放在首位，一旦造成重大损失可能要赔个倾家荡产。

\#\#\#4 网络障碍

长期混迹于开源的朋友会发现一个哭笑不得的情况，在安装和配置某个开源项目时你90%的精力都在跟咱们的墙做斗争。虽然github没有被屏蔽，但是开源产品安装过程中用到的依赖、插件、第三方工具、操作系统软件包等很有可能存储在awss3、google storage、国外交付仓库等，这部分经常会被墙住。整个安装过程就是不断的connect timeout、review相关的脚本或者代码、配置http、socker甚至是JVM层的代理，举步维艰的愚公移“墙”。凿墙的过程使得客户体验变差，降低了我们对开源产品的友好度

\#\#\#5 细节考虑不周到

如下两个例子：

\* 国外的AWS域名与国内的AWS域名是不一样的，而且很多国外的功能在国内是被阉割过的。

\* 老外的代码几乎不用考虑编码的问题，而我们拿到后需要想办法解决中文乱码的bug。

\#\#从开源中能获得什么

\#\#\#1 设计思想

开发人员的设计思想往往是固化的，但是在github上学习别人的项目可以扩展自己的眼界，了解到别人的设计思路是什么样的，有没有自己值得借鉴的地方。

\#\#\#2 技术细节

Review别人的代码你会学会别人在用的annotation、依赖包、编码思想、甚至新的语言（我第一次接触groovy就是通过github上一个开源项目）。包括你向github提交过程中老外也会提出对commit message、PR等的一些要求，这些细节都是自己可以运用到以后工作中去的。

\#\#\#3 社区知名度

5年以上开发经验的研发人员再去找工作，往往会开到招聘单位要求你提供github和博客的账号，这说明国内对中高等人才越来越看中你的社区活跃性和知名度，维护好自己的博客多学习github上开源知识也将称为你简历上的硬实力。

\#\#\#4 更多的朋友

我始终觉得程序员都是单纯可爱的，你在github上与来自世界各地的研发人员一起协作，总会遇到一些志同道合的朋友。与他们保持联系，会成为你未来职业道路上的好伙伴。

\#\#\#5 锻炼英文

据我个人估计开源社区中90%都是老外，中国人在开源社区的活跃度并不高，无论是官网阅读、API详解、与作者的沟通等，只能靠别人的母语来搞定了。

\#\#兴趣是动力

如果你也想开始自己的开源之旅，请一定要先找到自己喜欢的方向和项目，因为开源完全靠的是情怀，是你心甘情愿不求回报的去做这件事情。你的开源项目就像是女神，你觉得她设计的那么完美，代码写得那么美丽，虽然你也知道女神终究不属于你，顶多当你的代码被merge吸收时女神会朝你微笑一下，你仍愿意每天晚上默默为她付出，不图回报。