从高盛的技术“开源”看金融业软件发展未来

随着《规范金融业开源技术应用与发展的意见》一文落地，本文将基于「凡泰极客」的经验和大家聊聊阐述为什么金融科技需要借力开源、参与开源？

编者记：近日，随着央行等五部门发布的一篇《关于规范金融业开源技术应用与发展的意见》，就规范金融机构合理应用开源技术，提高应用水平和自主可控能力，促进开源技术健康可持续发展进行工作布局。

《意见》中，也鼓励金融机构将开源技术应用纳入自身信息化发展规划，加强对开源技术应用的组织管理和统筹协调，建立健全开源技术应用管理制度体系，制定合理的开源技术应用策略；鼓励金融机构提升自身对开源技术的评估能力、合规审查能力、应急处置能力、供应链管理能力等；鼓励金融机构积极参与开源生态建设，加强与产学研交流合作力度，加入开源社会组织等。

本文是凡泰极客（FinoGeeks）联合创始人、前广发证券 IT 董事总经理兼首席架构师、前雅虎北京研究院首席架构师梁启鸿，在 2020 年所著的一篇关于金融行业与技术开源的思考汇总，与各位进行分享。

2019 年 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研发的痛点

券商和银行们的 IT 研发，“正业”肯定是支持业务创新、做能产生差异化竞争的应用软件。在这个过程中，应该“有所为、有所不为”：基础设施和通用技术框架，尽量借力第三方，业务相关的逻辑，尽量自己开发。

可是现实世界没有这么理想。

采用第三方的封闭技术，你可能得纠结这几个问题：

传统大厂的技术非常封闭，他们没有开放接口（那是生财工具– 要一个收一个的钱）； 他们的古老技术架构也无法承载插件化的订制； 他们不响应你的个性化诉求，用起来很不爽； 小公司的技术你不放心，怕他们改变产品方向甚至终止产品线，或者可能被收购合并甚至关门大吉。总之，基于闭源的技术你害怕被“绑架”。

自研，你也可能纠结这几个问题：

一些与业务非直接相关的底层技术，自己的团队不是缺乏专业性去驾驭就是无法专心专注去做好； 一旦展开，等于给自己挖坑，还得经常面对成本预算方面的质疑； 采用开源技术，又往往没有符合行业特性、针对金融场景直接可用的选择； 学习掌握进行改造的成本高（一旦自行改造，很可能又掉进长期维护的坑）。

除非你是高盛，在一些业务场景需要用到一些基础技术而市场上却没有选择的情况下，自行研发，然后共享到开源社区让同业甚至业外技术人员共同维护与利用，避免了“胎死腹中”的命运。

采购闭源软件时买源代码并没有什么大用

很多机构采购系统喜欢要源代码 – 针对大厂就跟他们买、针对小公司就跟他们拿。但个人认为这并无什么意义。

首先，“买断源代码”这种做法真的非常、非常过时。

源代码不是固化的、“买断”之后就不变的，因为厂商可能在未来不断升级、不断修复缺陷、不断优化，你买一个“快照”一样的东西，基于它东改西改，很快和原厂的版本分离，厂商无法替你维护，你也享受不到他们在服务行业过程中的优化重构、升级换代。

其次，“买代码”这种事情，相当部分花的是冤枉钱，其实自己并没有资源或者能力去维护，也就是买个“保险”吧。

就算真的要源代码，也不是“买断”，而是买服务 – 例如获得厂商部分公共代码库的访问权，在服务合同时间范围内随时可以抽取最新的代码并可以通过厂商提供的工具、指引能自己进行构建，并且万一自己修改后还可以提交回开发商的代码库供其合并，一句话，就是用源代码版本管理工具及最佳实践管理好行业级、跨机构的互助。

当然，一些开发商也没有这种源代码交付与管理的能力。

你要“买断”？打一个压缩包，作为电邮附件给你发过去，或者找个网盘临时共享一下，或者用 QQ 发送一下… 

之后这份代码就和主库彻底告别，再也无法同步。

改变软件的研发、销售与交付方式

越来越多的软件公司，商业模式架设在开源生态之上。如果以向金融机构提供基础性软件技术的企业，是适合这么做的。

怎样算“基础性软件技术”？就是具有行业通用性和针对性、满足金融业务应用需求共性、从众多金融机构的商业场景中总结抽象出来的基础技术层，它往往首先面向金融机构的 IT 研发人员，供其进行订制和二次开发以支撑更上层的业务应用。

以我们公司当前的小程序技术为例，它可私有化部署、配备安全沙箱、客户端 SDK 化可随意嵌入到任何银行和券商的 App 中，它本身还是一个开发平台。这就是针对行业需求量身定做的基础技术。

基础技术适合开源，是一种新的软件生产协作模式，它有以下的商业竞争优势：

通过开源社区，吸引和利用优秀人才。 最具前景、最有用的开源项目往往能吸引到最顶级工程师。这其实是一种“杠杆”的利用，也能促进开源产品在社区的快速迭代 有助于获客。 如上文所述，很多金融机构采购系统的时候也想获得源代码，这背后的逻辑是担心厂商封闭，让自己不能订制；以及对被某个技术“绑架”的防范 – 万一它忽然终止存在又无法被轻易替换，而分分钟和钱挂钩的业务系统却构建在它的基础之上，这个风险太大。处于敏感位置的基础技术，如即时通讯工具，其源代码开放可审计，也让一些机构对信息安全、数据隐私保护方面放心。开源在现在已经成为一种信心保障 有助于建立商业生态。 通过知识产权的开放，让客户以较低门槛采纳，逐渐形成市场规模，并形成社区、建立上下游的合作伙伴，有机会成为 de facto standard （事实上的标准）。Kafka 就是一个好例子，不知不觉中很多金融机构就已经采用了它，技术人员甚至以它的技术概念作为词汇表描述问题与方案

构建在开源之上的软件公司，研发是社区化的协作，不仅有自己的研发人员主导，也有客户开发人员的参与（例如提报缺陷甚至直接修复和提交代码合并），甚至有认同这个技术的互联网技术粉丝的主动加盟。

销售方式也发生改变，机构更多是从网上获得关于产品的信息、口碑、案例，随时通过社区或者其他社交频道与软件公司发起交流。销售人员可以在线陪伴运行 demo、双向互动。

而软件的体验门槛非常低，例如我们就采用双 license 制，社区版免费并采用非商业化许可证，而企业版则采用 Copyleft（“著佐权”，见下一篇文章的介绍）许可证或者商业软件许可证。社区版能够让金融机构以最低门槛实现 POC 的原型验证甚至直接使用于商业用途。

交付方面，源代码我们通过开发者社区交付，部分代码对互联网开放，任何人直接从 GitHub 可以获得；部分对机构客户开放，通过开发者社区可以访问源代码库，拖取被授权获得的分支。

而软件系统的成品，全部都是基于云原生的技术架构、100% 容器化，用户通过镜像仓库拉取镜像进行自动化部署。这好像是一家汽车制造商的零件仓库，组装工人（IT）一按按钮（跑一个脚本），即把相关的车门、车胎、座椅、方向盘、发动机、外壳等等-并自动组装。

开源的商业模式有多种，包括 open-core 和 hybrid 等等，我们将在下期 《开源商业模式促进金融业科技生态的发展》 中分享，探讨一下开源技术如何能在金融行业落地和促进金融科技发展。

本文转载至 FinClip 博客。