A personal perspective by Nick Veenhof

For years, I watched the financial sector approach open source with caution. Given the strict regulatory and security requirements, this was understandable. The primary goal was to manage risk, and many firms were concerned about relying on code they didn't develop internally.

However, it's clear we have reached a tipping point. Open source is no longer just accepted; it’s now seen as a core engine for innovation. The data supports this: a recent report shows that 85.4% of financial services firms are increasing their use of open source, with nearly 60% reporting a significant increase. The question is no longer if  firms should use open source, but how they can use it most effectively.

This widespread adoption has created a new challenge. As firms build critical systems on open-source foundations, they become dependent on projects whose roadmaps they don't influence. To truly harness the power of open source and mitigate this dependency risk, firms must evolve. They need to transition from being consumers to becoming contributors. This shift is already happening: recent analysis shows a positive trend in contributions from financial services professionals, with commits to open source repositories up 75% since 2021, highlighting a new strategic focus.

Part 2: The Business Case for Becoming a Contributor

A question I often get is, "Why should my team contribute back?" My answer is that it’s a powerful business strategy with a clear return on investment. While cost savings were an early driver, today’s business case is built on more strategic goals like improving development speed and accessing innovation.

One of the strongest arguments is the direct impact on efficiency. Research shows that companies actively contributing to an open-source project they use can become up to two times more efficient in how they use that software. This advantage comes from a deeper understanding of the software’s architecture. When your engineers move from just using an API to understanding the "engine behind" the product, they are better equipped to optimize and integrate it.

Furthermore, contributing gives you a level of influence that is impossible as a passive user. A great example I often share is from the automotive company Scania. They needed support for a feature in GitLab that wasn't on our immediate roadmap. Through a collaborative contribution model, they were able to get the feature built and released, directly addressing a critical business need. For a financial institution, this could mean accelerating a new security protocol or a key compliance feature.

Finally, as James and I discussed, an active contribution strategy is a significant advantage in attracting talent. The industry faces a challenge in finding "end-to-end experts," and these top professionals are drawn to organizations where they can do challenging work and build a public profile by contributing to major open-source projects.

Part 3: A Practical Path to Contribution: The Co-Create Model

Recognizing that the path to contribution can be difficult, my team at GitLab developed what we call the Co-Create model. The idea is simple but effective: instead of leaving customers to navigate the complexities of contribution on their own, we partner with them directly.

Here’s how it works: we send one of our engineers to work side-by-side with a customer's team for a week, much like a focused hackathon. The goal is to get one or two meaningful contributions successfully merged by the end of the week. I’ve seen firsthand how motivating this is for an engineer. As James stated in our talk, it was an intense five days at NatWest of education and partnership that resulted in NatWest addressing specific use cases to improve their ability to make contributions. Seeing your own code go live in a product used by millions is a "powerful moment" that turns frustration into a real sense of accomplishment.

This experience builds the confidence and knowledge needed for sustained, independent contribution. The Co-Create model provides a structured and measurable way for institutions to overcome contribution barriers and start realizing the strategic benefits of becoming a maker.

Part 4: Enabling Secure Contribution at Scale

Of course, in any conversation with a financial institution, the topic of security and compliance comes up immediately. The core question isn't just how to contribute, but how to do so securely and at scale, without slowing down development. A problem shared by the entire industry requires a community-driven solution—we need shared, transparent "guardrails, not guesswork" to make this possible.

Solving this challenge requires a two-part approach. First, we need collaboratively built digital infrastructure that automates security and compliance checks directly into the developer workflow. A key example of this is the GitProxy project hosted by the Fintech Open Source Foundation (FINOS). Originally contributed by Citi, GitProxy acts as a secure intermediary layer that enforces pre-defined controls—like security scans or policy checks—before any code leaves a firm's internal network. What makes this so powerful is that it’s a co-created tool, with firms like NatWest and RBC also contributing to its development. Instead of each firm building its own proprietary solution, they are pooling their expertise to create a single, robust tool that benefits everyone.

However, experience shows us that tools alone are not enough. The second part of the solution is guided, hands-on enablement, which significantly accelerates contribution enablement across an organization. This is where programs like Co-Create come in. A tool like GitProxy provides a secure pathway for contribution, and a program like Co-Create complements this providing the skills, confidence, and direct support needed to walk that path successfully. It helps engineers understand not just the "what" of the security controls, but the "how" and "why" behind them, integrating secure practices into their development habits. By combining community-built tools with collaborative enablement, we can create an ecosystem where secure contribution becomes the default, not the exception.

The differences between the old path to contribution and this new, guided path are clear:

Part 5: Conclusion: An Invitation to Co-Create

The financial services industry is at a pivotal moment. The conversation has moved beyond if  we should use open source to how we can best create value with it. Becoming a maker of open source improves efficiency, accelerates innovation, and provides more control over the technologies that are essential to modern finance.

The primary barriers—the difficulty and concerns related to contributing in a regulated environment—are being addressed through collaborative efforts like the Co-Create model and community-driven tools like GitProxy. The goal is to build a more robust and innovative technology foundation that benefits the entire ecosystem.

The future of financial technology is being actively built, in the open. If you’re ready to move from consumer to contributor, GitLab is here to help.   Contact us at contributors@gitlab.com or at https://about.gitlab.com/community/co-create/ to learn more about how GitLab Co-Create can accelerate your contribution roadmap. Let's build the future of Open Source in finance together.