Six things financial services technical leaders need to consider around open source software

At a recent meeting of technical leaders in the financial services community, we hosted a rich and vibrant discussion around the role of open source in their community. There was a wide ranging consensus and a number of key areas of focus emerged. The broader context is that businesses in general are increasingly moving to an open source first model for a number of reasons, not least amongst them the desire to quickly develop solutions to business or technical problems that these platforms enable. Many have a wide array of open source applications and code in use already, both at the infrastructure and application layers and in development frameworks and GitHub repositories.

Where FS organisations are rushing to develop or build new applications or services for customers, comply with growing amounts of industry regulation, or simply striving to meet the needs of the Information Generation with digital, mobile, socially-enabled tools and support, the application developer and infrastructure teams within those organisations come under increasing pressure.

Here were the six key themes that emerged in discussion:

1. New governance frameworks and policies are required for open source platforms. Unlike traditional app/dev environments, open source platforms necessarily move at a greater pace and with a very different model for iteration and improvement. Traditional governance and security for these environments would limit the benefits of agility you might hope to get from going down this path. From security, to support, to indemnity, the challenges of managing open source code in an enterprise context requires a different set of considerations
2. The ‘packaged’ open source model deserves consideration: whilst a packaged version of an open source platform from a vendor brings significant benefits – of documentation, versioning, integration points, feature road-maps, support and beyond – there is a trade off in terms of lag between new community releases and new packaged releases that FS technical leaders are wary of. Proper evaluation is needed – with true open source projects there is total visibility (and community engagement in) resolving bugs and adding functionality. Once a vendor puts its wrap on a set of code, this transparency is lost to some degree.
3. The culture and mindset of the app/dev team must be hungry. The mindset for opensource development is one of entrepreneurial hunger. It’s one of identifying problems and building solutions. More conventional teams might live in denial of these possibilities and prefer to look at the limitations and capabilities of traditional environments, rather than see those limitations as problems that can be solved with code in an open-source context.
4. A greater context of collaboration is required within the app/dev, security and infrastructure teams: with technical delivery for what might be classified within the ‘open source’ umbrella split across a potentially diverse set of teams; desktop, servers, applications, analytics, security, etc., greater collaboration between the teams is needed to ensure the security and effectiveness of the approach. If the cost of short-term agility is a long-term cost burden for maintenance, then the books may not balance. By working together, however, a more complete set of benefits can be delivered.
5. There is more external consulting support for open source emerging every year: as open source platforms from Linux, to Cassandra, to Hadoop grow in sophistication and as potential applications grow in data-rich, application hungry financial services businesses, more traditional outsourcers and IT consultancies are developing specialist propositions around supporting businesses with their apps in these environments. This provides a degree of assurance and resilience to those who need it.
6. Open source community contributions and the talent conundrum: To attract talent to the developer pool in FS, organisations need to be contributing to the open source community. But some organisations can’t allow their developers to do this, due to concerns about giving away intellectual property or exposing the possibility of breach that may emerge if they write up code that is potentially vulnerable. This is the challenge for financial services technology leaders – to find the best way to contribute to the community whilst maintaining integrity and compliance, such that they can win the best talent.

Are you a dev or an infrastructure manager in the financial services community? Be great to get your thoughts on some of the other themes and challenges you face in evangelising (or fighting off) open source in your own context, and your feelings about the situation.