去年11月份CNBC的一则新闻,报道了华尔街巨头高盛要把自己投入了14年研发的一个技术平台Alloy以及专门为这个平台所设计的语言,免费、开源共享给华尔街的其他机构。去年更早的时候,高盛也声称把自己的一些交易与风控相关代码贡献到GitHub(竞争对手摩根大通则已经把一个与区块链相关的技术quorum开源到GitHub)。
高盛在开源技术这件事情上,貌似是认真的。除了加入开源界出名的开源组织Eclipse基金会,2015年高盛即参与到容器技术企业化的进程中(那还是docker这类技术刚刚开始为人知的时候),2017年起陆续把一些技术开源到GitHub上,他们甚至把自己的一个Java技术框架采用了Apache 2.0的宽松软件许可(一个对开源社区非常友好的许可证)贡献出来。
不夸张的说,开源软件改变世界– 不管在一个App里面还是在一套交易系统中,都“借力”着不计其数的开源代码库、开源工具。现在谁敢说自己的软件是一行一行代码从零开始构建?正如高盛的技术负责人Don Duet所说,从技术角度看“开源渗透到我们所做的一切事情中”。
为什么搞金融科技需要借力开源、参与开源?本人以过去的几段从业经历在此贡献五毛钱意见。
在Morgan Stanley。那是IT只有不到千人、还坐落在7大道750号、工程师们还在使用Sun和HP工作站的年头。Morgan Stanley有自己的基础设施团队去研发跨操作系统(Solaris、AIX、HPUX、Windows)的UI开发框架Morgan Stanley Toolkit(简称MSToolkit)、第一代Web应用服务器Netscape的插件、还有其他很多看上去和证券业务没有什么直接关系的但是支撑着上层业务的很酷的技术,设计水平在那个时代比起专业软件公司不逞多让。事实上那个时代大型的金融机构研发自己的交易中间件、图计算引擎甚至专门性的计算机语言,并非罕见。
可以说,在利润的驱动下,能够帮助赚到钱的技术有可能被投资作核心竞争力。比起稍后的那些互联网新贵技术公司,华尔街的IT一点都不落后。可是,尴尬的地方在于,这些封闭的、仅内部使用的技术,很容易失去生命力:资助某个技术的一些业务项目如果被砍掉,这个技术很可能也完蛋;市场不好,这类技术遭裁切也是首当其冲。受众太少、应用场景太窄,让这些技术很快丧失先发优势。
在雅虎研究院。和很多巨型互联网企业一样,雅虎里面什么技术都自成体系,对象存储、消息中间件、内部的wiki、JavaScript的开发框架、移动端开发工具、Web服务器、甚至类似Linux里的包管理与分发工具… 这些技术可能在早期是很先进的因为互联网上找不到等价物,可是随着网上开源运动的发展,这些封闭的技术越来越变得非主流,新加入的人往往抓狂。长期呆在封闭技术环境里的人,也很容易被工具洗脑,不知道外面的世界,离开了这个环境出去找工作,面试一问三不知。而这些技术最终也被内部的人摒弃、走向消亡,大家更愿意融入到开源世界中。雅虎身后还存在的技术是Hadoop,这个影响了整个大数据领域发展的技术,证明开源软件的生命力强、活过它的发明者。
在国内证券公司。个人一向认为软件的逻辑架构一定要清晰的体现出分层,对实现成“一大坨”深恶痛绝。举两个例子:第一个是在研发经纪业务所需用到的社交化客户关系管理与服务平台时,涉及到即时通讯工具、规则引擎这样的基础设施,因为一开始的时候场景非常简单,那么我们是“举手之劳”的重新发明车轮直接把它们做到系统里面当作业务功能的一部分?还是明确的把它们当作通用模块解耦出来?如果当作独立模块,是自研?还是采用第三方的方案?当时的实际情况就是,没有合适的第三方技术(那是微信还出来没多久的、移动端IM尚算新生事物的年代),自己研发,很可能挖了一个大坑,未来难以养专门团队维护;直接当做满足短期业务需求的应用功能来做,则导致延展性前瞻性灵活性非常差、技术上无任何优雅性可言。
另一个更容易理解的例子是交易系统,要把交易系统的基础做扎实,显然我们必须有经过交易场景反复论证抽象、高度通用、考虑周全的消息中间件,互联网上的开源消息中间件往往不是为证券业务设计的,不是不能用就是用起来极其别扭。自主研发?你得有足够强的团队、有长期维护优化的决心、有业务部门的“赞助”、有公司在IT战略上的支持。否则肯定干不下去。所谓“自研”的交易系统,不少会因为“土法炼钢”的基础技术层不过关不专业而失败。
不仅是业务应用导向的金融机构,包括科技公司在内,在研发自己的科技产品的过程中,都不可避免需要涉及到各种基础技术框架、技术库、底层工具,这些东西往往是“鸡肋”,自研的话,有点“不务正业”,而且你的团队往往在这些方面非常不专业,长期来看也维护不了。高盛走的开源道路,其实是节省成本、借力打力。
券商和银行们的IT研发,“正业”肯定是支持业务创新、做能产生差异化竞争的应用软件。在这个过程中,应该“有所为、有所不为”:基础设施和通用技术框架,尽量借力第三方,业务相关的逻辑,尽量自己开发。可是现实世界没有这么理想。
采用第三方的封闭技术,你可能得纠结这几个问题:传统大厂的技术非常封闭,他们没有开放接口(那是生财工具– 要一个收一个的钱),他们的古老技术架构也无法承载插件化的订制,他们不响应你的个性化诉求,用起来很不爽;小公司的技术你不放心,怕他们改变产品方向甚至终止产品线,或者可能被收购合并甚至关门大吉。总之,基于闭源的技术你害怕被“绑架”。
自研,你也可能纠结这几个问题:一些与业务非直接相关的底层技术,自己的团队不是缺乏专业性去驾驭就是无法专心专注去做好,一旦展开,等于给自己挖坑,还得经常面对成本预算方面的质疑;采用开源技术,又往往没有符合行业特性、针对金融场景直接可用的选择,学习掌握进行改造的成本高(一旦自行改造,很可能又掉进长期维护的坑)。
除非你是高盛,在一些业务场景需要用到一些基础技术而市场上却没有选择的情况下,自行研发,然后共享到开源社区让同业甚至业外技术人员共同维护与利用,避免了“胎死腹中”的命运。
很多机构采购系统喜欢要源代码– 针对大厂就跟他们买、针对小公司就跟他们拿。但个人认为这并无什么意义。
首先,“买断源代码”这种做法真的非常、非常过时。源代码不是固化的、“买断”之后就不变的,因为厂商可能在未来不断升级、不断修复缺陷、不断优化,你买一个“快照”一样的东西,基于它东改西改,很快和原厂的版本分离,厂商无法替你维护,你也享受不到他们在服务行业过程中的优化重构、升级换代。
其次,“买代码”这种事情,相当部分花的是冤枉钱,其实自己并没有资源或者能力去维护,也就是买个“保险”吧。
就算真的要源代码,也不是“买断”,而是买服务 – 例如获得厂商部分公共代码库的访问权,在服务合同时间范围内随时可以抽取最新的代码并可以通过厂商提供的工具、指引能自己进行构建,并且万一自己修改后还可以提交回开发商的代码库供其合并,一句话,就是用源代码版本管理工具及最佳实践管理好行业级、跨机构的互助。
当然,一些开发商也没有这种源代码交付与管理的能力。你要“买断”?打一个压缩包,作为电邮附件给你发过去,或者找个网盘临时共享一下,或者用QQ发送一下… 之后这份代码就和主库彻底告别,再也无法同步。
越来越多的软件公司,商业模式架设在开源生态之上。以向金融机构提供基础性软件技术的企业,是适合这么做的。怎样算“基础性软件技术”?就是具有行业通用性和针对性、满足金融业务应用需求共性、从众多金融机构的商业场景中总结抽象出来的基础技术层,它往往首先面向金融机构的IT研发人员,供其进行订制和二次开发以支撑更上层的业务应用。以我们公司的即时通讯技术为例,它可私有化部署、配备合规存储与举证引擎、客户端SDK化可随意嵌入到任何银行和券商App中、提供数以百计的接口与事件供金融业务应用的融合,它本身还是一个开发平台。这就是针对行业需求量身定做的基础技术。
基础技术适合开源,是一种新的软件生产协作模式,它有以下的商业竞争优势:
构建在开源之上的软件公司,研发是社区化的协作,不仅有自己的研发人员主导,也有客户开发人员的参与(例如提报缺陷甚至直接修复和提交代码合并),甚至有认同这个技术的互联网技术粉丝的主动加盟。
销售方式也发生改变,机构更多是从网上获得关于产品的信息、口碑、案例,随时通过社区或者其他社交频道与软件公司发起交流。销售人员可以在线陪伴运行demo、双向互动。而软件的体验门槛非常低,例如我们就采用双license制,社区版免费并采用非商业化许可证,而企业版则采用Copyleft(“著佐权”,见下一篇文章的介绍)许可证或者商业软件许可证。社区版能够让金融机构以最低门槛实现POC的原型验证甚至直接使用于商业用途。
交付方面,源代码我们通过开发者社区交付,部分代码对互联网开放,任何人直接从GitHub可以获得;部分对机构客户开放,通过开发者社区可以访问源代码库,拖取被授权获得的分支。而软件系统的成品,全部都是基于云原生的技术架构、100%容器化,用户通过镜像仓库拉取镜像进行自动化部署。这好像是一家汽车制造商的零件仓库,组装工人(IT)一按按钮(跑一个脚本),即把相关的车门、车胎、座椅、方向盘、发动机、外壳等等下载并自动组装。
开源的商业模式有多种,包括open-core 和hybrid等等,我们将在下期《开源商业模式促进金融业科技生态的发展》中分享,探讨一下开源技术如何能在金融行业落地和促进金融科技发展。
关于金融科技领域的开源,您有什么想法?可留言和我们探讨
作者:梁启鸿
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。