Why (and a little of how) use and then contribute back to open source in financial services

Let’s make this easy. Financial services firms (sell side banks, buy side firms, challenger banks, fintechs, and more) all use and consume open source software and standards. At larger corporations, non-technical users, but also many of the technologists may not even know they are part of this consumption of open source.

Some of the varied reasons why companies in financial services industry (FSI) would leverage open source software (OSS) might be:

• OSS in many cases is “free” to try out, and then use - reducing costs for 
• OSS by nature is positioned to be modifiable by developers
• Many OSS projects have communities of maintainers and developers that are able to guide, and sometimes support users / developers / companies that are “forking” the project for their own internal company use
• More eyeballs (multiple project maintainers and contributors) on code can make it more secure to use
• Decreased to no vendor lock-in 

The use and consumption of open source software and projects is just one side of the equation though. Financial services firms that get involved with open source projects, and opening their policies for their developers, technologists, and even “non-technical” employees to contribute back to open source, are starting to see huge dividends. The larger tech world and companies have been the beneficiaries of these open source contribution benefits, and financial services has really turned the corner in the past couple of years, even in such a regulated industry.

Financial service industry (FSI) firms could see these benefits and more by contributing back to open source. We’ll discuss all of these benefits more in upcoming articles and podcasts, but here are the highlights:

Access to (Better) Talent 

Developers that work in open source are used to their work being in the open. GitHub has become a natural resume for developers. Potential employers from FSI can see the developer’s code and assess their technical and innovative skills. These are also people that are on the cutting edge of tech, and so you want them involved with your organization.

Note - once you hire them, they will expect to want to keep working in the open whenever possible. Giving them space and time to work on open source projects as an employee of your FSI company continues to feed and fund their drive.

Reduction in Costs & Speed to Market Through Collaboration

Leveraging off an open source project by just using it and integrating it into your technology stack is great. As long as it helps your organization become more efficient and effective, there are natural benefits in cost reduction and speeding up your time to market.

Participating in these open source projects, and giving back to them allow your organization to further reduce costs and accelerate your speed to market. Your direct involvement of funding an FTE (full time employee) to contribute or help maintain a project allows your organization to show real use cases where this project can solve real problems. This helps to set direction of a project, and then the cost reduction and increased speed for your organization is a natural effect.

Shaping the Industry Future

A lot of what the financial services industry is contributing back to open source should be about shaping the industry’s future. For sell side banks, this could be around driving the shape of finance’s “operating system”. For buy side firms, this might mean influencing open data standards, mandates and APIs for all sell side players and vendors. For fintechs, this might be about learning from commercial open source leaders about how to best leverage the open core business model. No matter what though, shaping the future of the financial services industry, what is a very tech heavy industry now, can be accelerated by getting involved with, and contributing back to open source.

How financial services developers can produce a better product by leveraging collaborative development

As a financial services company open source contribution policies continue to mature, financial services developers and software engineers are increasingly getting involved with open source projects. These projects may be at the core of the technical architecture of the bank or buy side firm.

Build Better Software

As with any group striving to achieve the same goals, open source projects are run and contributed to by people that are solving a particular problem. Collaborative development allows for software projects to build better software, solving those problems. This collaborative approach leverages the problem solving of others, as well as learning from others' mistakes (and again allowing for lower costs and products to be produced faster).

Competitors Become Collaborators 

Open source projects, especially in financial services, are about working on the plumbing of the software, not enhanced features. Competitors, especially from a regulated industry must focus on non-IP (intellectual property) software. If it is the work that everyone already has to do, why not let the tide raise all boats - then these competitors can compete on higher quality products and/ or the user-facing side of the product. The benefits of sharing will continue to outweigh the the costs

How security and quality can be improved through open source

When you’re writing a book or an article, it’s important to get someone else to look at your work. Sure, maybe that is for a different perspective, but mainly to make sure that you sentences are readable, spelled correctly, and have correct grammar and punctuation.

Making software stronger and more secure is another inherent benefit of open source development. More eyeballs, viewing more code, testing more instances, fixing more bugs, makes open source software more secure.

If code is open for anyone to see, then the advantages continue to build on top of each other:

Open Source Code Tends to be Cleaner

Sloppy code is a prime target for errors and bad actors. Developing in the open drives developers to build cleaner code, not only for the project but for their reputation. That allows for coding standards to be part of a project - some of it is constructed as a rule of the community and some is just leading by example. Over time, this allows more people to understand and work on the code, because of the strong, clean code base that has been created in the community.

Back to Bad Actors and More Eyeballs

Even clean code will have vulnerabilities. It’s a fact. But the more eyeballs that pass over the code, and testing that is performed, then there will be more of a chance that these vulnerabilities are caught before a software release is allowed. Most of the open source software issues that you’ve heard of in the news, from Heartbleed, to Log4J can be attributed to not enough developers looking at it which became crippling to some companies because they happened to be smaller pieces of software that many companies based their own software upon. Bad actors seize upon those soft spaces in software that aren’t looked after.

(This might be the time that we plead that it is critical for companies to evaluate what open source software projects underlie their own critical software, either as components, or wholesale - and get involved with these projects so that you can help ensure their security, even if it is to just help your own company…)

Moral of This Story: Contributing to Open Source in Finance Translates to Easy Wins

More people.

More ideas.

More code.

More eyeballs.

More fixes.

More speed.

More opportunity.