Historically banks have been hesitant to adopt open source software (i.e. software where source code is shared and made freely available). With traditional vendors like IBM, TIBCO, Oracle… strongly positioned in this industry, the move
to open source has been slow. In recent years, forced by a rapidly changing business, banks are transforming their IT organizations considerably, adopting new technologies and methodologies like Cloud, microservices, Open APIs, DevOps, Agile and also Open
Source (often these different adoptions enforce each other).
The Open Source movement has already reached a certain level of maturity. While 5-10 years ago, Open Source was still considered something of computer-nerds, idealists and small start-ups, today it has become mainstream. The recent acquisitions
of open-source companies by large established corporate tech-vendors is the best proof of this evolution:
SalesForce bought MuleSoft for $6.5 billion in March 2018
Microsoft bought GitHub for $7.5 billion in October 2018.
IBM purchased Red Hat for $34 billion in 2019
At the same time these incumbent tech players are adopting a true open source strategy themselves. E.g. Microsoft, initially one of the most has adopted an open source strategy, since Satya Nadella became CEO in 2014, e.g.
Edge: the Edge browser is switching to the Google based open source Chromium platform
.NET framework: the full .NET framework was open-sourced on Git-Hub
Windows 10: built on open-source Progressive Web App technology
Windows 11: analysts speculate that the NT kernel would be (gradually) replaced by the Linux kernel
Azure platform: the most used operating system on Microsoft Azure is not Windows Server, but rather Linux
Open-source contribution: Microsoft has become the largest contributor to open source in the world (considerably more active that the second most active contributor, Google), with 20,000 Microsoft employees on GitHub and over 2,000 open-source
Nonetheless a consolidation movement in the open source space is still required. With thousands of different projects, usually only maintained by 1 company, it is difficult to speak of a real open-source community or ecosystem. A larger
adoption of open-source software (both in usage and is contributing back) by large corporates together with a consolidation, will result in a smaller number of projects, but with larger communities.
Even though bank leaders are becoming convinced that leveraging open source technology is the future, banks will not transform over night to open source adepts. Just like introducing all other new technologies and methodologies, embracing
open source software requires a cultural shift in the whole organization, which takes time and intensive change management.
The adoption will evolve according to two axes:
According to the first axe, the organization should evolve from Using open source up to Opening its own proprietary software:
Use: banks should adopt a strategy to give preference to open source software, where possible. This can be full solutions or open source components, which the bank glues together into the target custom-built application.
Contribute: the intensive usage of open source will surely lead to the identification of bugs and the implementation of valuable features on top of the open source software. Instead of building a quick-and-dirty patch, banks should learn
to build a more generic and well-designed solution, which can be contributed back to the open source community. This will not only improve the bank’s corporate image, but will also allow the bank to profit from the testing and future extensions applied by
the community on this implementation, ultimately improving future maintenance.
Open: the final step is to open the existing proprietary software of the bank. This is the most complex, as it is the most time intensive (all tentacles to other systems of the bank need to be nicely decoupled), most risky for the bank (banks
fear that their code will be scrutinized in public, thus resulting in a brand risk and fear that potential security issues become exposed) and most difficult to convince all bank leaders (fear of giving away competitive advantage, i.e. the secret sauce).
The second axe is the type of open source product, which overlaps with the level of abstraction. Banks should first gain experience with low-level abstraction open source software, like databases (e.g. MySQL, Mongo DB, Cassandra and Postgres),
middleware (e.g. WSO2, Kafka, Apache Camel, Envoy, Istio…), operating systems (e.g. Linux and Kubernetes)… Gradually they should move up the stack to higher level of abstractions, like business process (e.g. jBPM) and task management tools, to finally use
also open source for the financial core processes themselves (e.g. Cyclos, Mifos X / Apache Fineract, MyBanco, Jainam Software, OpenCBS, OpenBankProject, Cobis, OpenBankIT, Mojaloop). Ultimately all software of a bank should have at its core open-source software,
with the exception of solutions exclusively offered via SaaS.
This evolution has definitely started already. Almost all banks are already using multiple open-source software solutions. Many banks are furthermore preferring open-source software over proprietary software, in vendor selection processes
for new software. Especially the argument of avoiding vendor lock-in is used to defend this choice. Additionally, a growing number of banks is already contributing to existing open source projects or even open sourcing their own software, e.g.
Open source has been one of the core elements in Capital One’s (one of the largest credit card companies in the US) digital transformation journey over the past 6 years.
Goldman Sachs recently decided to open source its proprietary data modeling program Alloy
J.P. Morgan Chase released code on GitHub for multiple initiatives, e.g. its Quorum blockchain project.
Deutsche Bank open-sourced multiple projects, like Plexus Interop (from its electronic trading platform Autobahn) or Waltz (IT estate management)
The move of some banks to open-source proprietary software seems strange at first sight, as software has become more and more a competitive edge of a bank. Nonetheless banks have a lot to gain in using (adopting) open source and contributing to it:
Even though these advantages are hard to ignore, it’s not all rosy. It is therefore no wonder, there is still a lot of reluctance against open source, specifically against contributing and opening proprietary software.
Contractual and legal: a variety of different open-source software license models exist. Using open source can therefore be a serious challenge to ensure compliance with all terms and conditions of the license model. Such uncertainty can
be a huge constraint for a large bank. Luckily more and more tools appear on the market (e.g. FOSSA, DejaCode, WhiteSource, Code Janitor), which allow to monitor and follow-up the compliance on open-source licenses.
Support: banks fear a lack of support in case of issues when using open source. For many open-source tools, commercial firms are offering corporate support, resolving this limitation. If not, the bank IT teams should engage with the open-source
community to resolve an issue. Although this is more complex than raising an incident to the support desk of an IT vendor, such engagement will often lead to a faster and better resolution of the issue.
Compliance and security: while ultimately open-sourcing code will lead to more secure software, when first publishing your source code on the internet, there is a risk that criminals can find loopholes in the code.
Give away competitive advantage: although this is definitely true for differentiating services, the majority of internal banking software is commodity software, which doesn’t provide any differentiation. Open sourcing these applications
can free up resources to work on real value-added services.
Brand risk: banks fear that open-sourcing bad software can do more harm than well, with regards to corporate branding.
If banks massively adopt open-source, one can wonder if Fintechs offering innovative software services to banks are not doomed to fail. Luckily Fintechs have already evolved from an annual license model to more modern models of partnerships.
With the adoption of the cloud and elastically-scalable hardware and the notion of "a user" becoming more and more vague (due to multi-channel architectures and the rise of Open APIs), the concept of paying an annual license for corporate software has become
difficult to defend and negotiate (licenses based on number of servers/CPUs or number of named/concurrent users have become obsolete). Instead software licenses costs are being replaced by different partnership models, like:
PaaS (Platform as a Service), SaaS (Software as a Service) and Baas (Business as a Service) models
"Open core" models (also called Dual-licensing), where the core of the software is delivered for free and open-source, while tooling specifically for large corporations are license based
Support model: pay a party for access to a support desk and providing updates on when new versions should be installed
Realize profits from a service model, e.g. training services, implementation services, customizations to the open source software at request of the bank…
Fostering such an open ecosystem of Fintechs and banks will ultimately lead to better products and services for everyone. Banks must realize that technology is at the heart of their business. They should therefore try to copy the success
formulas of the large tech-giants, i.e. attracting the best people, leveraging existing software, flat organizational structures and methodologies supporting rapid change (like DevOps, Agile…). Adopting an open source strategy can be a strong
lever to reach this goal.