The Symphony Software Foundation’s mission is to foster the open development of software infrastructure shared by the financial services and fintech industries. And while even the last holdouts against open source in the software industry have at last embraced collaborative development—Microsoft recently joined the Linux Foundation—most financial services firms still approach open source with caution.

Their reluctance is not hard to explain. Financial services, more than most industries, deals in information with tremendous value—value that could be diminished or destroyed if the information became public. And firms increasingly embed or enact that information in their software systems.

From consumption to collaboration

No bank has excluded open source software entirely, of course, nor could they. But because banks mostly produce software for their own internal purposes, their engagement with open source is asymmetrical—they have effective policies for onboarding open source software into internal development projects, but treat outbound contributions as a rare and disfavored corner case.

As banks continue their evolution into software companies with investment strategies, this asymmetrical approach will become increasingly expensive and ultimately unsustainable. Most banks have steadily replaced expensive-to-maintain proprietary pieces of their IT infrastructure with open source components, calculating that the real value lies in the differentiating bits running on top.

But when it comes to the next step—participating in the development of that shared infrastructure—there are substantial gaps between firms. Some are relatively active collaborators in open source infrastructure and tools; others contribute sparingly, when a business need is urgent enough to overcome a baroque approval process; and many have yet to make their first external contribution.

The cost of isolation

The banks participating actively in external open source projects don’t necessarily have significantly different business needs from more closed institutions. Rather, they’re evaluating the cost of collaboration in a fundamentally different way.

It’s common and intuitive to conceive of open source contributions as a liability: the bank has developed valuable IP and is giving it away for free. Contributions are often described as “giving back to the community,” as though they’re thank-you gifts for all the free software the community has given the bank. Like tipping, it’s a nice thing to do, but gratuitous.

But while firms should support the community open source projects whose work they rely on, that’s not the only reason they contribute their improvements to those projects. They do it because isolation is expensive.

Proprietary customizations are costly to maintain. If a bank’s developers incorporate an open source component into an internal software project, they’ll usually need to customize the software in one way or another—maybe trivially, by fixing a minor bug, or maybe more significantly, by adding a useful new feature. In either case, it will typically be more expensive to keep the modifications proprietary than to contribute them back to the open source project.

That’s because the open source project will probably not remain static. As the project’s developers add new features, fix bugs, and refactor the code, the bank’s developers will have to continually work to incorporate their changes into the latest version of the software. The more the software changes, the more work will be required with each successive release. If instead the bank contributes those improvements back to the project, ongoing development will leave them intact, and the bank’s developers can spend their time on useful new work.

Isolation is also expensive because developers want to work on open source software. Many developers got their start programming by picking through code online, well before taking any formal programming classes—open source is part of their identity as developers and they want to work for companies that respect that. Developers also see open source contributions as critical to their professional development. Just as other employees speak at conferences, developers contribute to open source projects to participate in their professional community.