Executive Summary
- Open source has become a strategic pillar in financial services rather than just a cost-saving tactic: 93% of organizations surveyed say it improves software quality, and 87% report tangible business value from open source adoption.
- Open source governance is being formalized: about half of financial institutions now have a clear open source strategy, and nearly as many have established an OSPO (Open Source Program Office) to coordinate open source usage, contributions, and risk management.
- Internal policies for using and contributing to open source are increasingly permissive (only ~2% of firms still prohibit contributions outright), but their enforcement is inconsistent. Gaps and uncertainties – often due to unclear ROI or legal concerns – lead to uneven participation and can result in costly internal forks (divergent in-house code versions).
- Software supply chain security is a major concern: 52% of respondents cite vulnerabilities in open source components among their top issues, and 37% point to supply chain attacks. Practices like using SBOMs (Software Bill of Materials) are emerging to address these risks, but fewer than half of organizations currently produce SBOMs for their applications.
- There are wide maturity gaps between institutions: while leading firms have deeply integrated open source (dedicated OSPO, clear policies, active contributions, membership in foundations), a significant portion of the sector is still in early stages and has yet to implement formal open source programs.
- Leadership involvement is critical to open source strategy: technology executives (CTO, CIO) and OSPO leads are seen as key influencers driving open source initiatives, with their support helping to overcome cultural and organizational barriers.
- The main obstacles cited for open source adoption and contribution are the lack of a clearly established ROI and the complexity of legal issues (open source licensing, intellectual property). These factors – along with occasionally cumbersome internal processes – continue to make some institutions cautious, despite recognizing open source benefits.
From Cost Play to Strategic Imperative
In recent years, the financial services industry has shifted from treating open source as a peripheral experiment to embracing it as a core strategic component of technology and innovation. Today, virtually every bank, insurer, or asset manager uses open source software in some capacity, reflecting an understanding that open source is ubiquitous in modern IT. What began mainly as a quest for cost reduction (avoiding expensive proprietary licenses) has evolved into a broad value proposition: open source is now recognized for delivering higher software quality, faster innovation, and business agility. Surveys show that an overwhelming majority of financial organizations believe open source is critical to their future success – a sector known for being ROI-driven doesn’t adopt such practices unless the data supports it.
Crucially, financial institutions are not just passive consumers of open source; many are actively investing in open source capabilities. Whereas in the past “open source in finance” might have meant a bank quietly using Linux or Apache internally, today it encompasses industry-wide collaboration on shared platforms and standards. Major community-driven projects (for example, the FDC3 standard for interoperability or tools like GitProxy for secure code access) have been incorporated into the production environments of leading banks. The open source approach is enabling firms to mutualize efforts on non-differentiating technology (such as compliance tooling or reference data models), thereby reducing duplication and cost. Additionally, intangible benefits are increasingly acknowledged: open source involvement helps attract and retain top engineering talent, as developers value the learning and engagement that come from community participation. In short, the financial sector has reached the point where open source is viewed as a long-term strategic asset, delivering not just cost savings but also innovation, resilience, and competitive advantage in a heavily regulated, margin-conscious industry.
Open Source Usage and Contribution Policies
As open source adoption grew, financial institutions recognized the need for structured internal policies governing how open source is used (consumed) and contributed (shared back) by their teams. In terms of usage policies, the trend has been towards openness. By 2025, virtually all organizations in the sector allow their developers to use open source components in projects – formal studies indicate that 97% of firms explicitly permit open source consumption, with only a very small minority (around 1–2%) still forbidding it. This near-universal acceptance marks a significant change from a decade ago, when some banks had blanket bans due to misunderstanding open source or fear of security/legal issues. Now, it is broadly recognized that every organization is using open source in one form or another, whether they acknowledge it or not, and that prohibiting it outright is neither practical nor beneficial. Accordingly, many institutions have implemented guidelines or approval processes to ensure that open source components used in the enterprise meet certain criteria (e.g. acceptable licenses, active maintenance, no known critical vulnerabilities), rather than banning open source entirely.
When it comes to contribution policies – rules for contributing code or improvements back to open source projects – the industry is also moving in a permissive direction, albeit more cautiously. Only about 2% of financial organizations now say they flatly prohibit their employees from contributing to open source projects. The vast majority (approximately 98%) allow contributions in some capacity. This indicates a clear shift from earlier years when contributing code to external projects was often frowned upon or restricted. However, the specifics of how and when contributions are allowed can vary widely between institutions. In some cases, contributions are allowed but only on personal time or through personal accounts; in others, contributions on company time are permitted if certain approvals are obtained or if the project is on an approved list. A number of large banks have developed detailed contribution guidelines and approval workflows, ensuring that any code going out the door is properly reviewed for IP and compliance, and that contributing developers understand their obligations (such as not exposing confidential logic or data).
Because of these differing approaches, policy enforcement remains uneven across the sector. Many firms report that their open source contribution policies, while existent, are not consistently applied or are hampered by bureaucracy. For instance, developers might be technically allowed to contribute, but in practice the internal clearance process is so complex that it discourages them from doing so. In some companies, it has been observed that developers resort to using personal GitHub accounts or contributing anonymously to navigate around slow internal processes – a sign that policy implementation is not fully keeping pace with policy intent. The root causes of these inconsistencies often trace back to the two obstacles highlighted later: unclear ROI and legal concerns. If senior management is not convinced that contributing upstream has tangible benefits, or if legal departments remain overly cautious about licensing, then policies tend to err on the side of restriction or ambiguity.
One costly outcome of inconsistent contribution practices is the proliferation of internal forks (discussed in a dedicated section below). In summary, when developers face barriers to contribute their enhancements or fixes upstream, they may simply maintain their own internal version of the open source code – which leads to duplicate maintenance and technical debt. This underlines a key governance challenge: providing a clear, efficient framework for contributions so that employees are empowered to engage openly rather than working around the system. The sector is gradually addressing this by refining policies, educating staff on open source processes, and highlighting success stories where contributing back has paid off. The goal for many is to achieve a state where open source usage and contribution are normalized internal processes, as standard as any commercial software procurement or internal development, with all relevant stakeholders aware of and aligned with the rules.
Establishing Open Source Program Offices (OSPOs)
One of the most significant governance developments in financial services has been the rapid rise of Open Source Program Offices (OSPOs). An OSPO is a dedicated team or function within an organization that oversees and coordinates the institution’s open source strategy and activities. In the context of banks and other financial firms, OSPOs have emerged as the central hub for open source governance. According to recent industry findings, nearly half of all surveyed firms have an OSPO or similar initiative in place, up from only a small fraction just a few years ago. Among large, globally significant financial institutions, the adoption is even higher – almost two-thirds of major banks now report having established an OSPO.
The OSPO’s role is multifaceted. At a high level, it serves to ensure that open source engagement is strategic and consistent across the organization, rather than ad hoc or siloed. To do this, OSPOs typically take on responsibilities such as:
- Policy Development and Oversight: The OSPO defines the internal policies for open source usage and contributions, working closely with legal, compliance, and security departments. It might maintain approved lists of open source licenses, set the process for contributing code, and outline how open source components should be vetted and tracked.
- Compliance and Risk Management: OSPO staff help manage license compliance (e.g., making sure the company fulfills obligations when using copyleft-licensed code) and oversee tools/processes for identifying security vulnerabilities in open source components. They act as a bridge between technical teams and risk officers/regulators on open source issues.
- Internal Coordination and Advocacy: An OSPO connects various groups – developers, engineers, legal counsel, procurement, and management – to align them on open source initiatives. For example, if developers want to open source an internal project, the OSPO facilitates that by coordinating approvals and guiding the project through the release process. OSPOs also often run internal education programs, training engineers on open source best practices and the company’s procedures.
- External Engagement and Community Leadership: Many OSPOs act as the outward face of their organization in the open source community. They manage relationships with foundations (like FINOS or the Linux Foundation), represent the company in open source consortia, and even sponsor or contribute to key industry projects. By doing so, they ensure the firm has a voice in the direction of projects it cares about and stays ahead of industry trends.
The institutionalization of OSPOs indicates that open source is no longer a grassroots or side effort – it’s being embedded into corporate governance structures. In 2021, OSPOs in finance were mostly aspirational ideas; by 2025 they have become, as one report put it, a “structural norm.” This shift means that for many financial firms, issues like open source license compliance, community contribution, and third-party component tracking are handled systematically rather than informally. OSPOs typically report to senior leadership (for instance, under a CTO or CIO), signaling that open source strategy is part of the executive agenda.
Moreover, the presence of an OSPO often correlates with a company’s overall engagement level. Data shows that larger organizations with OSPOs tend to participate in more open source activities – contributing to projects, hosting their own open source repositories, attending community events – compared to those without. By consolidating open source knowledge and decision-making, OSPOs help large, complex enterprises act more coherently in the open source ecosystem. They effectively act as knowledge centers and control towers that keep open source efforts aligned with enterprise goals (ensuring, for example, that engineers contributing to external projects are doing so in areas that benefit the firm’s strategy).
For the financial sector, which values controlled processes, the OSPO concept has been a way to reconcile the ethos of open collaboration with internal requirements for risk management and accountability. Other industries are looking to this model as well – seeing how banks, despite heavy regulations, are managing to be active in open source by virtue of having a formal office to govern it. In summary, OSPOs have become a key instrument of open source governance, enabling financial institutions to harness the innovation of open communities while maintaining the oversight expected in their industry.
Managing Software Supply Chain Risks
The widespread use of open source software has brought software supply chain risk to the forefront of governance concerns in financial services. A software supply chain encompasses all the external code and dependencies that go into an organization’s software systems. With banks and financial firms integrating hundreds or thousands of open source libraries and tools into their applications, the integrity of those components is critically important.
Key risks identified include:
- Security Vulnerabilities: Open source components can contain security flaws (just like proprietary software). The high-profile Log4j/Log4Shell incident in late 2021, for example, revealed how a single vulnerability in a common open source logging library could threaten countless financial systems. In surveys, over half (52%) of financial organizations cite vulnerabilities in OSS components as a top concern. This implies that tracking known CVEs (Common Vulnerabilities and Exposures) and patching them promptly in open source dependencies is a major task.
- Supply Chain Attacks: These involve malicious actors targeting the upstream supply chain, for instance by injecting malware into open source packages or compromising a popular open source project. 37% of institutions point to supply chain attacks as a key concern, reflecting recent cases where trust in widely-used open source infrastructure was exploited (for example, attacks on package registries like npm/PyPI, or takeovers of unmaintained libraries by malicious contributors).
- Outdated or Unmaintained Components: If a bank relies on an open source component that isn’t actively maintained, it may accumulate unpatched vulnerabilities or compatibility issues. Part of supply chain management is ensuring the open source you depend on has a healthy community or else finding alternatives.
- License and Compliance Risks: While often viewed separately from security, license non-compliance (using open source code in violation of its terms) is another supply chain risk. For instance, inadvertently including a component under a strict copyleft license in a proprietary trading platform could legally oblige the firm to open source its own code – a scenario to avoid. Governance programs aim to prevent such situations by vetting licenses.
To manage these risks, financial firms are adopting a range of tools and practices. Many have deployed Software Composition Analysis (SCA) tools that automatically scan codebases to inventory open source components and flag known vulnerabilities or license issues. Approximately 46% of organizations report having formal processes to evaluate and select OSS components, and similar numbers use tooling to enforce policies. This means that nearly half the industry is actively monitoring what open source is in use and assessing it against risk criteria – a significant increase in diligence compared to just a few years prior.
Another emerging practice is incorporating security checks into the CI/CD pipeline: for example, when developers build an application, automated checks pull in the latest vulnerability database to ensure none of the included libraries are on a known-threat list. If a vulnerability is discovered post-deployment, firms with strong supply chain governance will have an established procedure to quickly identify affected applications (often leveraging the SBOM concept mentioned next) and apply patches or mitigations.
Threat intelligence and community engagement also play roles. Some banks participate in open source security initiatives (like the OpenSSF) or share information about threats to upstream projects they use. By staying connected to the community, they often get early warnings of security issues.
However, despite these efforts, the industry acknowledges a gap between awareness and action. It’s telling that while concerns about open source security are high, only 43% of organizations say they are actively producing SBOMs (an indicator we’ll discuss). This suggests that more than half are aware of risks but haven’t yet implemented some of the advanced practices to address them. Risk management maturity levels vary: a handful of banks have very sophisticated open source risk programs (with dedicated security analysts focusing on OSS, continuous monitoring of dependencies, etc.), whereas others are still working on creating basic inventories of what open source they have running.
Regulators have also started paying attention to software supply chain security. In the U.S., for example, federal guidelines and executive orders (outside the financial domain but affecting it indirectly) are pushing for SBOMs and greater transparency in software components for critical industries. Financial firms, always sensitive to regulatory expectations, interpret these signals as impetus to shore up their supply chain risk management. In Europe and other regions, operational resilience regulations are broadening to consider ICT third-party risk, which by extension covers open source components.
In summary, managing the open source supply chain is an active and evolving frontier for governance in financial services. Firms are investing in the capabilities to ensure that the open source software they rely on is secure, compliant, and trustworthy. It’s a significant undertaking – requiring processes to track a vast array of components – but given the potential impact of not doing so (security breaches, service outages, legal issues), it has become a governance priority.
Use of SBOMs (Software Bill of Materials)
A Software Bill of Materials (SBOM) is rapidly gaining recognition as a key tool for addressing supply chain transparency and security. An SBOM is essentially a comprehensive list or database of all the open source (and third-party) components, including their versions and licenses, that are present in a given application or system. It’s analogous to an ingredients list on a food product or a parts list for manufacturing – but for software. SBOMs enable organizations to answer the question: “What’s inside our software?” at a granular level.
In financial services, SBOM usage is still maturing, but momentum is building. Currently, just under half of institutions actively generate SBOMs for their internally developed software (around 43%, as noted above). This indicates that some leading firms have integrated SBOM creation into their build processes: for example, whenever a new version of an application is built, an SBOM is produced and stored, documenting all components. These SBOMs become invaluable when a new vulnerability emerges – the security team can search through SBOM data to identify which applications use the affected library and need patching.
Additionally, a number of organizations are beginning to require or consume SBOMs from their software vendors and open source suppliers. For instance, if a bank purchases a software solution or uses an open source platform, they might request an SBOM from the provider to understand the risk profile. Some industry bodies and regulators have signaled that SBOMs could become a standard expectation for critical software, which encourages financial firms to incorporate SBOM review into their procurement and risk assessment processes.
However, adoption is far from universal. A significant portion of respondents in studies indicated they either haven’t started with SBOMs or are unsure of their organization’s stance – highlighting a knowledge gap. For many, the concept of SBOM is relatively new and implementing it requires changes in tooling and mindset. There’s also the challenge of managing SBOM data: a large bank might generate thousands of SBOMs for various apps and versions, and needs a strategy to store, update, and query this information effectively.
Despite these challenges, the trajectory is clear: SBOMs are becoming an essential component of software governance. They directly address the “awareness” part of the gap between knowing and acting on supply chain risk. By having an SBOM, an institution gains full visibility into its software ingredients, which is the precursor to managing vulnerabilities or license issues in those ingredients.
SBOMs also foster cross-organization collaboration on security. For example, in industry forums or incident response groups, banks that use the same open source components can share SBOM insights to collectively tackle an emerging threat. As more organizations produce SBOMs, it could become common to exchange them under NDA when assessing third-party software or even to publish SBOMs for open source projects, contributing to a community knowledge base.
Regulatory and policy pushes are likely to further spur SBOM adoption. In some jurisdictions, legislation is underway (often inspired by the US’s approach) that would require critical infrastructure sectors – which include financial services – to maintain SBOMs for the software they use. Financial firms are proactively moving in this direction to stay ahead of any mandates.
In conclusion, while currently less than half of financial institutions utilize SBOMs thoroughly, the industry recognizes SBOMs as best practice for open source risk governance. We can expect a continued uptick in SBOM adoption. Over the next couple of years, creating and managing SBOMs may well become as routine as maintaining asset inventories or access logs – a standard part of the IT governance checklist that helps ensure the integrity and security of complex software environments.
Differences in Maturity Between Institutions
Not all financial institutions are at the same stage of open source adoption and governance – in fact, the maturity spectrum is quite broad. Some organizations are trailblazers with well-established open source programs, while others are only just beginning to dip their toes in the water. This divergence is evident in survey data and industry observations:
At one end, there are open source leaders – often large international banks or forward-looking fintech companies – that have embedded open source into their culture and operations. These organizations typically have multiple years of experience with open source, formal strategies and policies, dedicated resources (like OSPOs and open source evangelists), and a track record of participating in or even leading major open source projects. For example, they might have contributed significant code to external projects, open-sourced some of their own tools, and be active members of bodies like FINOS or the Apache Foundation.
At the other end, a considerable minority of institutions remain in an early or exploratory stage. Recent survey results revealed that about 14% of traditional financial institutions acknowledged having taken none of the listed “maturity actions” related to open source (such as defining a strategy, implementing policies, joining collaborative forums, etc.). Essentially, these institutions have yet to formally address open source governance – perhaps they use open source here and there, but without any overarching plan or management. Interestingly, among fintech respondents (generally smaller, tech-native firms), only about 3% reported having done nothing on open source; the vast majority had at least some engagement. This suggests that while fintech startups are usually more inherently open source-friendly, virtually all of them do something with open source, whereas a segment of traditional banks still lags with no organized efforts.
Differences in maturity also manifest between larger vs. smaller players. Larger institutions, by virtue of scale and necessity, often score higher on open source engagement metrics. As noted, roughly 55% of incumbent financial firms (like big banks) have implemented an OSPO, compared to around 38% of fintech firms. Similarly, large banks are more likely to have a clearly defined open source strategy than smaller ones. Scale brings resources and also complexity – a bank with tens of thousands of IT staff needs formal governance to manage open source use, whereas a 50-person fintech might operate more informally. That said, smaller fintechs often have a cultural head start: their development teams might be more accustomed to open source tools and methods from the outset, even if they lack formal policies. So, in some aspects (like adopting cutting-edge open source tech or contributing to developer-driven projects), fintechs can be ahead, whereas in governance structure (like OSPOs, policies) big banks lead.
Geography and market focus can introduce further variance. For instance, European banks have been highly active in collaborative open source efforts around standards and regulatory compliance tools (sometimes spurred by EU-level initiatives), whereas some regional banks in other parts of the world might be slower to collaborate externally. Investment banks and trading firms may prioritize open source differently than retail banks or insurance companies, depending on where they see value and acceptable risk.
Another angle of maturity is internal consistency. Within large diversified financial groups, certain departments (often those focused on technology or data) might be very mature in open source usage, while others (perhaps more customer-facing or legacy IT areas) are not. This internal gap often necessitates a company-wide approach – one role of corporate OSPOs is to uplift lagging divisions and spread best practices uniformly.
Addressing the maturity gap is a recognized challenge in the industry. Leading firms sometimes share their experiences to help raise the general level – for example, through FINOS working groups or public case studies where they detail how they built their open source governance. There’s also an understanding that as open source becomes a norm, clients and partners may start expecting a certain level of competence. A bank that is significantly behind the curve might face talent attraction issues (developers increasingly want to work in open source-friendly environments) or even security exposure if they’re not following emerging best practices. Therefore, sector-wide initiatives – like open source readiness programs – aim to bring lower-maturity institutions up to speed.
In summary, while the financial services industry as a whole has made great strides in open source adoption, maturity levels differ widely. Some institutions are acting as pathfinders, demonstrating how to do open source responsibly and beneficially, while others are still observing from the sidelines or moving slowly. The trend, however, is that the laggards are gradually catching up, propelled by peer examples, market pressure, and the inevitability of open source’s role in modern software development.
Impact of Internal Forking Practices
In the open source world, a “fork” occurs when developers take the source code from an open project and start a separate development path, creating an independent version. Internally, companies sometimes fork open source code to tailor it to their needs, but if not managed carefully, these internal forks can have significant downsides. Financial institutions have learned this through experience, and it has become an important governance consideration.
Why do internal forks happen? Often, it’s due to a misalignment between the company’s immediate needs and the pace or direction of the open source project. For example, imagine a bank uses an open source library that lacks a feature the bank critically requires. Ideally, the bank’s developers would implement the feature and contribute it back upstream. But perhaps due to tight deadlines, regulatory constraints, or internal policy hurdles, they find it faster or more feasible to modify the library internally and use that custom version. Now the bank has effectively “forked” that library – they’re running a variant that the upstream project doesn’t have. Similarly, internal forks can occur when an open source project is too slow to issue a needed bugfix, or when internal policy forbids contributing fixes outward, forcing developers to maintain fixes in-house.
The impact of maintaining internal forks is mostly negative in the long run. Firstly, it creates a maintenance burden: once you diverge from the main line of development, you have to manually track and merge any new updates or patches from the original project into your fork (if you choose to keep it updated at all). This is labor-intensive and easy to fall behind on. Many internal forks end up several versions out-of-date, which means the institution could miss critical security patches or improvements made upstream. If the open source project moves in a different architectural direction, the fork might become incompatible or very difficult to reconcile later.
Secondly, internal forks often lead to duplicated effort and increased technical debt. Instead of collaborating with the community to improve one common codebase, the firm is now duplicating work – maintaining its own version, possibly fixing issues that others are also fixing in parallel in the official version. Over time, the fork may need dedicated internal developers just to manage those differences, which is a cost that could be avoided through upstream collaboration.
There’s also a risk dimension: a forked codebase that isn’t visible to outside contributors loses the benefit of community review and contributions. If the community discovers a bug or vulnerability in the original project, that fix might not automatically apply to the fork if the fork’s code has changed. The organization thus becomes solely responsible for auditing and securing its custom version – essentially forfeiting one of open source’s strengths (collective oversight).
Furthermore, internal forks can signal a missed opportunity. If a financial firm implements a great enhancement internally but never shares it, the rest of the industry doesn’t benefit, and the company doesn’t earn any goodwill or influence from it. In sectors like finance, where certain needs (e.g. regulatory compliance tooling) are common, keeping improvements siloed can mean everyone spends resources to solve the same problem in isolation.
Industry surveys and expert commentary underscore that many internal forks are unintentional, arising not because institutions want to hoard their changes, but because governance processes have not yet caught up to facilitate timely contributions. When policies are unclear or approval cycles are too lengthy, developers will do what’s necessary to deliver for their business – which can mean forking a project and moving on.
To mitigate the proliferation of internal forks, the recommended governance approach is twofold: improve internal contribution processes and strategically prioritize contributions. Improving processes means making it easier and faster for developers to contribute fixes or enhancements upstream – for example, having pre-approved legal guidelines for contributing, management support for dedicating some engineering time to community interactions, and so on. When developers see that contributing a patch upstream is no more onerous than maintaining it internally, they are more likely to choose the upstream route, benefiting everyone.
Strategic prioritization involves focusing contribution efforts on the open source components that are most crucial to the firm’s operations. It might not be feasible to contribute to every single project a bank uses (given hundreds of dependencies), but by identifying the key projects (perhaps a trading engine library, or a data standard, or a DevOps tool heavily used), the institution can invest in engaging with those communities. By contributing to and influencing those, the need for internal divergence is reduced. One banking OSPO head noted that this approach – contribute where it matters most – helps avoid unnecessary forks and simultaneously strengthens the external projects that the bank relies on.
In conclusion, internal forks illustrate the interplay between policy and practice. They are a symptom that something in the governance or engagement model isn’t fully effective. Financial institutions are learning that while an internal fork may solve a short-term problem, it often introduces long-term overhead and risk. Thus, modern open source governance in finance strives to create the conditions where internal forks are minimized – where the default behavior is to collaborate in the open, merging changes back to the community so that the institution and the community remain on a unified codebase whenever possible.
Role of Leadership in OSS Strategy
The influence of leadership – both executive and technical – in driving open source adoption cannot be overstated. In the context of financial services, which are hierarchical and risk-aware organizations, the tone and priorities set at the top levels (board, C-suite) directly affect how enthusiastically open source initiatives are pursued and resourced.
Survey data indicates that the most influential roles for shaping an organization’s open source strategy are the Chief Technology Officer (CTO), dedicated open source program leaders (such as OSPO heads or similar open source-specific roles), and the developer community within the firm. Approximately 69% of respondents identified CTOs as key champions for open source, 63% pointed to OSPO leads or open source program managers, and 60% mentioned developers themselves as influential. Following these, roles like Chief Information Security Officers (CISOs) and Chief Information Officers (CIOs) were also cited, though to a lesser extent, and external stakeholders like regulators were near the bottom of the influence list. This tells us that open source adoption is largely an internally driven movement – it succeeds when internal leadership prioritizes it.
A visionary CTO or technology leader can have a catalytic effect. For example, if a CTO publicly emphasizes the importance of contributing to open source and sets expectations or targets for their teams (such as releasing a certain number of internal projects, or participating in foundational initiatives), it legitimizes open source work within the company. Management support can translate to tangible actions: allocating funding for an OSPO, adjusting KPIs to recognize engineering contributions to open source, or mandating the use of open source solutions where appropriate. Leadership can also bridge communication between traditionally separate units – for instance, encouraging Legal and Compliance departments to partner with Engineering in developing balanced open source policies, rather than defaulting to restrictive stances out of fear.
Conversely, a lack of clear leadership support is often cited as an impediment. Around one-third of organizations noted that a lack of leadership or ownership of the open source agenda internally was a barrier for them. In practical terms, this could mean that no single executive is responsible for open source outcomes – it might be everyone’s second priority and thus no one’s primary focus. Without someone championing it, open source efforts can stall, budgets may not be allocated, and teams might revert to business-as-usual (which could favor proprietary approaches or very locked-down policies). This scenario underscores why having a designated OSPO (with an executive sponsor) is helpful: it establishes ownership.
Cultural change in organizations also flows from the top. In many banks, earlier skepticism towards open source (worries about security, quality, etc.) needed to be addressed by leaders willing to update the narrative. When high-level executives acknowledge that “open source gives us better quality and innovation” or share success stories of using and contributing to open projects, it gradually shifts the culture to be more accepting. Leadership can encourage a mindset where engineers don’t feel they have to hide the fact that they’re using open source, but instead can be proud of contributing and sharing.
Another important leadership role is in aligning open source with business strategy. Board members and senior executives are primarily concerned with business outcomes – market growth, cost optimization, innovation in products, compliance adherence, and so on. For open source to thrive, leaders articulate how open source supports those goals: e.g., “By collaborating on open source standards, we can reduce compliance costs industry-wide,” or “Using open source helps us accelerate our digital transformation and attract top talent.” When framed in these terms, open source moves from a grassroots tech experiment to a boardroom-supported initiative.
It’s also notable that leadership includes not just executives but thought leaders within the technical staff. Senior engineers or architects who advocate for open source can drive bottom-up change, especially if their management listens to them. In fact, in some firms the journey started with passionate developers and was later recognized and amplified by executives.
Finally, leadership in the context of industry-wide efforts is also relevant. Financial institutions often act in concert – for example, several banks might jointly back an open source project through a foundation. When CEOs or CTOs of multiple banks publicly endorse a collaborative open source endeavor, it sends a powerful message and often secures the initiative’s success (through funding or contribution commitments). Leaders can thus influence not just their own organization’s stance, but also catalyze broader industry cooperation, which is critical in areas like establishing open standards.
In summary, strong leadership engagement can accelerate open source adoption, ensure it gets the necessary resources, and embed it into the company’s strategic roadmap. Lack of leadership can conversely leave open source stuck in a limbo of partial adoption and unrealized potential. As financial services increasingly recognize open source as a strategic asset, leadership roles – from C-suite champions to OSPO heads – have become central to orchestrating and sustaining open source success.
Persistent Obstacles: ROI and Legal Considerations
Despite substantial progress in open source uptake, financial institutions still face persistent obstacles that slow down or complicate their open source efforts. Foremost among these are concerns about return on investment (ROI) and legal/licensing issues. These were the two most commonly cited challenges in industry surveys, each identified by about 48% of respondents as limiting factors for contributing to open source.
ROI Uncertainty: Financial firms, by their nature, rigorously evaluate initiatives in terms of ROI. Open source contribution, however, often yields benefits that are indirect or hard to quantify in the short term. While it’s relatively straightforward to calculate savings from using open source (e.g., avoiding license fees, accelerating development by using existing code), calculating the ROI of, say, having developers spend work hours contributing to external projects is trickier. Executives might ask: How does contributing bug fixes or new features to an open source project translate into profit or cost savings for us? The value may come in forms like reduced future maintenance (because the project is healthier), influence over project direction, reputation gains, or developer skill enhancement – all real but not easily reduced to dollars on a spreadsheet.
Many institutions report that this lack of clear, immediate ROI makes it challenging to justify open source work internally. Particularly at firms where budgets are tight or headcount is controlled, managers want to ensure that every hour spent is delivering tangible value to the company’s bottom line or strategic goals. If contributing to open source is seen as altruistic or peripheral, it may be de-prioritized. Indeed, unclear ROI was often named as a reason why higher management doesn’t green-light more extensive open source engagement.
Addressing the ROI question has become an area of focus. Some organizations are developing metrics to capture the business value of open source contributions – for example, tracking how community involvement leads to finding and fixing issues faster (thereby avoiding potential downtime costs), or how participation in standard-setting projects may save compliance costs later. Others point out the talent angle: engineers often consider the ability to contribute to open source as a factor in job satisfaction; firms that allow it may attract better talent, which in the long run has direct business benefits (more innovation, lower turnover costs). As one CIO insightfully put it, “The ROI of open source isn’t only in dollars – it’s in speed, collaboration, and learning.” That suggests broadening the definition of ROI to include these dimensions.
Legal and Licensing Complexity: In the tightly-regulated world of finance, legal departments are highly influential, and they traditionally err on the side of caution. Open source brings a web of licenses (MIT, Apache, GPL, AGPL, etc.), each with its own conditions. Financial institutions must ensure they comply with these licenses – for instance, providing proper attribution, not inadvertently combining code in a way that violates license terms, and being aware of copyleft implications that might require source disclosure. The complexity can be daunting, especially when an application might incorporate hundreds of open source components under dozens of different licenses.
48% of organizations cited legal/licensing concerns as a key hurdle. This encompasses a range of issues: fear of open source license non-compliance (and the potential litigation or requirement to open source proprietary code that could follow), concerns about patent risks (some companies worry that by using or contributing to open source, they might expose themselves to patent infringement claims or lose the ability to enforce their own patents), and the aforementioned IP leakage worries – the risk that contributing code could inadvertently reveal proprietary algorithms or sensitive business logic.
There’s also the matter of regulatory compliance. While regulators in finance do not explicitly restrict open source, firms must still comply with data protection, operational risk, and outsourcing rules. Some legal teams interpret contributing to or relying on external open source as a form of outsourcing or third-party dependency, which then must be assessed for risk. Questions arise such as: Who is accountable if an open source component fails and causes a business outage? Can the firm demonstrate to auditors that it has control over the software it’s using if that software is community-developed? These are not unsolvable issues, but they add to the perception of open source as a potential legal quagmire if not managed well.
To overcome legal hurdles, many institutions have invested in legal expertise and frameworks around open source. They develop an internal open source policy that clearly delineates what is allowed and what isn’t (for example, many banks forbid using open source with certain restrictive licenses in products, or require a legal review before any new open source library is introduced). For contributions, they might have guidelines such as requiring contributors to only contribute code that was developed in-house and approved for release, and to sign a Contributor License Agreement (CLA) if the target project requires it. Some have dedicated counsel who specialize in open source matters and can quickly advise on license questions or vet open source use in contracts.
However, all these precautions can also slow things down. It’s a balancing act: being thorough in legal review vs. being agile in engineering. Organizations are gradually finding that balance, often by standardizing processes – for example, maintaining a pre-approved list of open source licenses and components that engineers can use without needing case-by-case approvals, which streamlines development while staying within safe bounds.
Besides ROI and legal concerns, other obstacles mentioned include governance challenges (internal bureaucracy, lack of clarity on who owns open source initiatives as discussed), and cultural resistance (some stakeholders might still have a “not-invented-here” mentality or doubt the quality of open source). Additionally, compliance and audit teams sometimes present obstacles if they are unfamiliar with open source, since anything unconventional can raise flags in those circles.
Encouragingly, the awareness of these obstacles is the first step to addressing them. The financial open source community is actively sharing strategies to demonstrate ROI – for instance, developing case studies where a collaborative project saved everyone time and money – and to simplify legal processes – like templates and best practices for open source policies that any bank can adopt. Executive leadership (again, crucial here) can help by explicitly acknowledging these issues and dedicating resources to solve them (e.g., funding a metrics program for ROI, or training legal teams on open source specifics).
In summary, unclear ROI and legal complexity remain the two most prominent speed bumps on the road to full open source integration in financial services. They are not trivial problems: ROI gets to the heart of business justification, and legal touches the fundamental need for risk control in finance. Yet, they are being actively worked on and gradually diminished through better frameworks, education, and success stories. Many in the industry underscore that tackling these obstacles is essential for open source to realize its full value potential in the sector.
My conclusion
The financial services sector’s journey with open source has reached a pivotal stage. What was once tentative experimentation has matured into a strategic commitment. As we have seen, open source brings concrete benefits – higher quality software, faster innovation cycles, cost efficiencies, enhanced collaboration, and the ability to influence shared technology foundations. These are outcomes highly prized in a competitive, regulated industry. However, realizing them at scale requires robust governance mechanisms to address the unique challenges that open source introduces.
Today, those governance building blocks are largely in place. Many financial institutions have implemented open source policies and guidelines, stood up OSPOs to centralize expertise, invested in supply chain security practices, and begun fostering cultures that see open source contribution as an asset rather than a liability. The collective data shows an industry that is “all-in” on open source – a majority view it as critical to their future – and increasingly adept at managing it.
Yet, the gap between awareness and full execution has not completely closed. To bridge it, firms will need to continue strengthening a few key areas:
- Enterprise-wide Adoption and Consistency: Spreading best practices throughout all divisions and ensuring even the less tech-centric parts of the organization understand and support open source efforts.
- Risk Mitigation and Transparency: Scaling up initiatives like SBOMs, automated security scanning, and clear license compliance processes so that using open source becomes as safe and routine as using any enterprise software, thus maintaining regulator and stakeholder confidence.
- Contribution Frameworks: Evolving contribution policies from ad hoc permissions to standardized, streamlined frameworks that make participation in open source communities a normal extension of developers’ work. This will reduce fragmentation (like internal forks) and strengthen the projects the industry relies on.
- Leadership and Culture: Keeping executive sponsorship strong and nurturing a culture of collaboration and knowledge sharing. As new challenges emerge (for example, the rise of open source in AI, which brings its own governance questions), leadership will need to adapt and stay committed to openness as a strategic principle.
Importantly, the financial services example serves as a reference point beyond its own industry. If highly regulated, security-conscious banks can adopt open source widely and responsibly, it suggests that other sectors can follow suit using similar governance approaches. Financial firms have shown that rigor and openness can coexist – that you can be compliant and secure while still engaging with open communities and leveraging open innovation.
In conclusion, open source in financial services is not a passing trend; it has become ingrained in the fabric of how technology is developed and shared in the sector. The focus now is on refining the governance that underpins this new way of working – ensuring policies, structures, and mindsets are optimized so that the industry can fully harvest the benefits of open source while controlling the risks. The trajectory is clearly upward and “openward.” As financial institutions continue to collaborate and invest in open source, they are poised to not only improve their own technology and services but also to help shape the next generation of common infrastructure that many industries will stand upon. In the words of one industry leader, openness is evolving from a risk to be managed into a capability to be scaled – and governance is the means to scale it successfully.
Sources
- https://www.finos.org/state-of-open-source-in-financial-services
- https://www.linuxfoundation.org/blog/banking-on-collaboration-the-2025-state-of-open-source-in-financial-services
