Picture a boardroom at one of the world’s largest banks. The CTO is walking through the latest platform architecture. Kubernetes for orchestration. Kafka for event streaming. PostgreSQL on the data layer. TensorFlow running the ML models. Every critical piece of the stack is open source, and nobody in the room disputes that it has made things better, faster, cheaper. Then a hand goes up. “What are we doing to contribute back?”
Silence.
I keep coming back to that moment because it captures something true about where financial services stands with open source in 2025. The consumption story is settled. Nearly everyone agrees this stuff works. But the contribution story? That one is barely getting started, and the longer the gap persists, the more dangerous it becomes.
Consensus Without Conviction:
The latest industry data is unambiguous. Ninety-three percent of respondents say open source improves software quality. Eighty-seven percent agree it delivers real business value. Eighty-four percent believe it is critical to the future of financial services (FINOS & Linux Foundation Research, 2025). These are not niche opinions from a developer subculture. This is the mainstream view.
And still, the gap between appreciation and action is staggering. Nearly one in five organizations report saving more than a million dollars a year from open source. That kind of number typically gets a standing ovation in any cost review meeting. But when the conversation shifts from “how much are we saving?” to “how much should we invest back?”, the enthusiasm evaporates.
Why? Because financial services is, at its core, a risk management business. And open source, for all its proven utility, still sits in an uncomfortable gray zone on most risk registers. Over half of survey respondents flag security vulnerabilities as their top concern. Close behind, at 48%, is the lack of ongoing maintenance. Both worries are fair. But they also beg a question that most institutions would rather not answer: if no one funds the maintenance, who exactly is doing the securing?
The Free Rider Problem No One Wants to Name:
Let’s be direct about something. Open source is free in the same way a public park is free. Somebody built it. Somebody maintains it. Somebody pays for that, whether through corporate sponsorship, volunteer labor, or foundation grants. The fact that you can walk in without a ticket does not mean it costs nothing to exist.
A Harvard Business School study put some hard numbers behind this intuition. Researchers estimated that the demand-side value of widely used open source software sits at roughly $8.8 trillion, and that companies worldwide would need to spend 3.5 times more on software if open source simply vanished (Hoffmann et al., 2024). That is not a rounding error. It is a dependency of civilizational scale, maintained by a community that most of its beneficiaries barely acknowledge.
To be fair, financial institutions are making structural moves. Sixty-four percent of large firms have stood up an Open Source Program Office. Sixty-seven percent have affiliated with open source organizations. These are real steps. An OSPO is not window dressing; it means someone inside the organization is thinking about policy, governance, licensing, and community engagement in a coordinated way.
But standing up an OSPO and actually contributing at scale are different things entirely. When you ask firms why contribution lags, two answers come back with metronomic consistency: 48% say there is no clear ROI, and 48% point to legal and licensing headaches.
The legal concern, while often overstated, at least has a concrete shape. Lawyers can work through licensing questions; it just takes time and willingness. The ROI objection is more interesting because it reveals a deeper conceptual problem. Traditional ROI calculations are transactional. You spend money, you get a thing, you measure the thing’s value. Open source contribution does not work that way. Its returns are systemic: influencing the trajectory of projects your competitors also depend on, reducing the odds of the next catastrophic vulnerability, earning credibility in communities where architectural decisions get made. Those returns are real. They are also nearly impossible to capture on a single line in a quarterly report, which is why they need to be championed at the executive level, not delegated to engineering.
What Actually Drives the People Who Do Contribute:
Here is what I find encouraging. When you look at the firms and individuals who do contribute actively, their reasons are not the ones you would hear in a strategy deck. The top motivations are giving back to the community, influencing critical projects, and reducing technical debt. That last one is the sleeper.
Technical debt in financial services is enormous, and a surprising amount of it is self-inflicted through poor open source hygiene. Every internal fork that drifts from the upstream project. Every patch you apply locally instead of pushing back to the community. Every major version you skip because the upgrade path is too tangled. It all compounds. Three years later, you are maintaining a bespoke version of something that the rest of the world has moved on from, and your team is spending cycles on plumbing work instead of building things that matter.
Contributing upstream is not charity. It is an engineering discipline. It keeps your implementation aligned with the community, reduces your maintenance surface, and, not incidentally, gives your engineers visibility and credibility in the ecosystems they work in every day. The firms that treat open source contribution as a line item to be minimized are the same ones drowning in technical debt five years later and blaming the technology.
Open Source as AI Infrastructure:
Everything I have described so far was already true when open source was mainly about databases, container runtimes, and messaging systems. The arrival of generative AI has raised the stakes considerably.
When financial services professionals are asked which open source components have the greatest impact on AI development, the top three answers are standards (56%), models (54%), and frameworks (52%). Think about what that means. The industry is not just using open source tools to build AI. It is building AI on top of open source foundations. The models themselves, the frameworks for training and deploying them, and the standards governing their use are all rooted in the open ecosystem. Trying to go fully proprietary on AI at this point is like trying to build a house without using lumber.
Theoretically possible, but expensive to the point of absurdity.
And yet, 49% of respondents say they expect GenAI’s biggest impact to be on internal developer productivity, compared to just 23% who see it primarily improving client-facing services. The industry is, in effect, pointing AI inward. That is a reasonable starting position, but it carries a specific implication: the quality and reliability of the open source AI toolchain is not an abstract concern. It directly affects the people writing the code that runs your trading platforms, your risk engines, your compliance systems. Getting this wrong is not a theoretical risk.
Hilary Carter of the Linux Foundation put it well when she noted that financial services has moved from “cautious experimentation” to a “full-fledged strategic practice woven into the operating fabric” of the sector (FINOS, 2025). That shift is welcome. But a practice woven into your operating fabric is also one you cannot afford to neglect. If the open source AI ecosystem deteriorates because the biggest consumers are not contributing, the consequences will not be hypothetical. They will show up in production.
The ROI Timeline and What It Actually Tells Us:
Forty-four percent of organizations expect to see ROI from GenAI within two to five years. Another 18% say they are already there. Both numbers deserve scrutiny.
A two-to-five-year ROI window in AI is practically a geological epoch. The models available in 2027 will be dramatically different from the ones organizations are piloting today. Any institution that treats its current AI stack as a fixed investment rather than a rapidly evolving capability will find itself re-platforming sooner than it planned. Meanwhile, the 18% already seeing returns have a compounding advantage. They are learning faster, iterating faster, and building organizational knowledge that their slower peers will struggle to replicate.
The firms best positioned to ride this wave are the ones most embedded in the open source communities building the next generation of AI tooling. Not because open source is always the best option for every component, but because proximity to the ecosystem gives you early signal. You see what standards are forming. You know which frameworks are gaining traction. You have relationships with the people building the tools that will matter in 2028. You cannot buy that kind of insight after the fact.
Collaboration as Competitive Advantage:
One finding that keeps nagging at me. When asked where open source delivers the most value, over half of respondents point to open collaboration on industry standards. Not speed. Not cost. Standards.
In hindsight, this makes perfect sense. Financial services spends an extraordinary amount of money on regulatory compliance, and a significant chunk of that spending goes toward reconciling incompatible systems, formats, and protocols across institutions. Shared open source standards reduce that friction. They create a common language. And, crucially, they shift competitive dynamics away from “who built the better plumbing” and toward “who serves the customer better”, which is where competition should be anyway.
The AI governance angle makes this even more urgent. The Log4j crisis offers an instructive parallel. In 2022, the U.S. Cyber Safety Review Board classified the vulnerability as “endemic,” warning that unpatched instances would remain in systems for a decade or more, and called out the fact that the open source community was “under-equipped” to handle security at scale (Cyber Safety Review Board, 2022). The FTC followed up with an unusually direct warning: companies that failed to remediate known open source vulnerabilities could face legal action (Federal Trade Commission, 2022). That was not a gentle suggestion. It was a signal that the regulatory environment around open source maintenance is tightening, and institutions that ignore it are accumulating legal as well as technical risk.
As AI governance frameworks take shape around the world, financial services has a narrow window to lead. Institutions that contribute to open standards and governance models now will help write the rules. The rest will simply have to follow them.
The Strategic Imperative:
I want to be clear about what I am arguing here, because it is easy to mistake this for idealism. I am not saying financial institutions should contribute to open source because it is the right thing to do, although it is. I am saying they should contribute because the alternative is untenable.
The old playbook, where you consumed open source quietly, kept your head down, and managed risk through isolation, worked when open source was a nice-to-have. It does not work when open source is the substrate of your entire technology strategy, your AI ambitions, and your compliance infrastructure. At that level of dependency, refusing to invest in the commons is not prudent risk management. It is the risk.
The organizations that get this right will do more than save money on software. They will shape the standards that govern their industry. They will influence the AI frameworks their competitors use. They will have a say in how security, governance, and interoperability evolve across the sector. That is not a technology decision. That is a strategic one.
So the next time someone raises a hand in a boardroom and asks about contribution, maybe the answer should not be silence. Maybe it should be: “What are we risking by staying quiet?”
Right now, the honest answer is: quite a lot.
References:
- Cyber Safety Review Board. (2022). Review of the December 2021 Log4j event. U.S. Department of Homeland Security. https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
- Federal Trade Commission. (2022, January 4). FTC warns companies to remediate Log4j security vulnerability. https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2022/01/ftc-warns-companies-remediate-log4j-security-vulnerability
- FINOS & Linux Foundation Research. (2025). The 2025 state of open source in financial services. https://www.linuxfoundation.org/hubfs/Research%20Reports/05_FINOS_2025_Report.pdf
- Hoffmann, M., Nagle, F., & Zhou, Y. (2024). The value of open source software (Harvard Business School Working Paper No. 24-038).
- Cover Image Source: Shaker.AI
Top comments (0)