Banks have become involved in open source in a variety of different ways. It typically starts with utilizing software with a fully permissive license for their own institutional purposes. From there, they may move to sponsoring and contributing resources to communities that maintain the codebase of open source tools relevant to them. They also contribute indirectly, by keeping ever-increasing numbers of engineers gainfully employed in their growing technology teams, allowing them to participate in the ecosystem in their spare time.
In recent years we have seen a number of banks take the final step of open sourcing their proprietary software. Examples include Goldman Sachs’ data modelling program Alloy, Capital One’s Cloud Custodian AWS resource management tool and various Deutsche Bank projects, such as the Waltz solution for IT estate management and the Plexus Interop code from its Autobahn electronic trading platform.
Changing motivations
Initially, banks began open sourcing their proprietary software largely in an effort to be more attractive to technologists. Technology was moving up the business agenda and an arms race for talent was unfolding. In particular, bulge-bracket banks such as JPMorgan, Goldman Sachs, and Morgan Stanley – as well as a few smaller, forward-thinking outliers, such as Capital One – recognized that they needed to demonstrate a genuine commitment to open source to attract top technology talent away from Silicon Valley, as well as from their competitors.
As open source has been more widely adopted and integrated within these firms, they have also benefited from extracting more out of their existing workforce. Open source projects have allowed engineers across the organization to flexibly contribute to the business outside of and alongside their day-to-day workstreams. Meanwhile, when working with the open source community, the core developers on the project can be upskilled via exposure to the latest developments and approaches.
In addition to creating opportunities for individuals to enhance and better harness their skills, open sourcing has helped foster organizational innovation and thereby contribute to improvements in technology standards in the banking sector. Through open source, banks can see how their formerly proprietary software is used by other institutions and then implement these approaches internally. This represents a significant departure from viewing open source purely as a recruiting tool.
A recent trend which highlights the increasing maturity of open source in the banking sector is the partial migration of industry standards groups and consortia towards a more open source model. For example, the Fintech Open Source Foundation (FINOS) has looked to accelerate collaboration and innovation in financial services by supporting firms to adopt open source software, standards and best practices. Consequently, this has opened the door for smaller firms to also contribute to the open source community.
Open source projects have allowed engineers across the organization to flexibly contribute to the business outside of and alongside their day-to-day workstreams.
As an extension of that, larger firms are now devoting their own unilateral projects to influence the open source agenda more directly. Examples like Goldman’s Alloy being outsourced through FINOS show the possibility of firms a new role in influencing standards in the industry, reducing the resources needed to reconcile data across entities and therefore reducing their own costs in integrating with counterparties.
Careful consideration required
The convergence between the banking industry and the open source community is only likely to continue. We expect this will drive further technological innovation, as well as the deeper integration of open source into the industry, with a more eclectic mix of stakeholders contributing to the community.
But contributing to the open source community is not risk-free and banks must consider certain challenges, particularly when it comes to open sourcing their propriety software. The immediate and obvious challenge a bank faces is how to resource and budget for the internal team tasked with developing or adapting the code it intends to make publicly available. As a starting point, even settling on the parameters of the project will invariably be a contentious and unwieldy process inviting a wide range of conflicting opinions.
Once a bank has identified a subset of ideas to focus on and invest in, it faces a choice between allowing a wider group of its developers to contribute on a more ad-hoc, part-time basis or relying solely on a tighter group tasked with working on the project full-time. The former option is undoubtedly more aligned with the open source ethos but requires regular on- and offboarding and a finely tuned process for reviewing and integrating submissions. The latter approach ensures greater product continuity but reduces the contribution of other developers right from the outset. It is also rigid from a resourcing perspective since the developers dedicated to the project will be unavailable for other needs.
The question of the governance of the software poses a similar problem. If the goal is to garner interest and input from a large number of external contributors post-publication, striking the right balance between centralized and federated permissioning structures is crucial to minimizing operational risk. On the one hand, the bank will need to reserve some fundamental competencies, such as infrastructure or supported languages, to the ecosystem’s designated core developers. The financial services industry’s intensive compliance regimes also create significant downside risk in the event of certain information leaking into the open-sourced code. On the other, the governance bylaws need to avoid a top-down, heavy-duty process that constrains maintainers and can create a disconnect between the core developers and the everyday external users, defeating the entire purpose of the project.
Altogether, that’s a potentially intimidating workload to grapple with before being able to put code into the public domain. And when the organization has no clear sense of either the cost and licensing models or the software development lifecycle, but is risking creating a new cost center that doesn’t necessarily deliver primary business value, those challenges can defeat an open source project before it gets off the ground.
These challenges notwithstanding, the overall direction of travel is clear – open source software in financial services is maturing and continues to be an area of focus and investment. As standards bodies assert greater influence and established industry players reap more benefits, open source will become more deeply integrated in the banking sector.