Supporting mature open source projects - the role for the finance sector

When the United Nations celebrated its 70th anniversary, US Secretary General Madeline Albright commented that the UN was one of those institutions that was necessary to how the world evolved, stating "If the UN did not exist, we would have to invent it." This references Voltaire's comment on the existence of God. But what does all this philosophical musing have to do with open source software?

According to analysis by Black Duck, 97 percent of all applications include open source components. Of those components, many of them are mature open source projects. While some of them are maintained and supported effectively, some are not; many rely on very small teams of volunteers that give up their time to implement code fixes or add more functionality. This reliance on volunteers is problematic - while open source software is available for anyone to use for any purpose, it can also mean that the 'bystander effect' creeps in. When something is everyone's responsibility, it becomes no-one's responsibility. We are currently without a long term model for open source software maintenance that can survive for years, even decades, yet those software projects are still used widely in production.

The webcomic XKCD summed this up as the entire edifice of the Internet being reliant on one small open source project supported by one person in Nebraska. One example of this in action is XML parsers. These projects make it possible to understand the data in documents and sort that data so it can be passed to other applications. Without XML parsing, communicating between different applications or services involves more work for developers.

These low level projects make it easier to build new digital services. But as they become mature projects, it is harder to attract and retain people with the right skills to maintain them. The prime example of this is libxml2, which is pre-installed in multiple operating systems including Linux, Android, iOS, macOS and ChromeOS, as well as in Microsoft's Edge browser and databases like PostgreSQL. At the same time, the sole maintainer has announced that he is stepping down from the project.

This demonstrates the potential problem around open source software maintenance. As XML has gone from being a cutting edge technology to one that is taken for granted, the financial support has dwindled and made it harder to get resources that can be dedicated to long-term maintenance. And it is not just libxml2 or the C and C++ XML projects - a lot of XML libraries have few or no maintainers to keep them going. Yet XML is still very much with us - it is written into multiple standards. As an example, SQL/XML is part of the SQL:2003 standard. 

XML is also at the heart of various financial reporting standards that specify XML schemas. It's this specific requirement that provides a potential path for long-term support.

Building long term support for mature open source projects

Ideally, any open source project would have multiple maintainers in place that can support fixes and pull requests. For a project that has been finished from a feature perspective, the workload is more about making changes that are needed rather than adding new functionality. In this case, the role of the maintainer should require a limited time commitment rather than needing full time resources. In the Rust community, the Rust XML libraries have successfully attracted maintainers from the community - as they already used and relied on those libraries in their work, the new maintainers were willing to step in when a change was needed. 

This provides a pathway that other XML projects can follow. More specifically, there is an opportunity for companies in the finance and banking industries to get involved. XML is essential in banking and finance because of the role that it plays in data exchange and reporting. Without reliable and supported XML parsers, this process is slower and more expensive to run. Alongside this, any organisation involved in payments has a requirement under PCI compliance to run supported code. The cost to remove a library like libxml2 from their code bases would be significant, as it would involve auditing applications to see where the library was installed, then removing or replacing that project with another library. Compared to this wholesale change project, the cost to provide support for libraries like libxml2 is miniscule.

However, the challenge here is how to organise this effort. For individual banks, providing that resource when none of your competitors are involved might be hard to get through, despite the obvious economic benefit. Instead, it is important to look at how collective action can work instead. FINOS provides a community for the world's largest banks and financial services companies to collaborate around new approaches and projects that can help them adopt open source and innovative technologies. As part of its FINOS Labs initiative, a new project called InterchangeKit has started - this provides an opportunity for those that rely on XML to contribute time and resources to ensure that their libraries are supported. 

InterchangeKit should provide support for multiple XML libraries across different languages - from the likes of libxml2 through to libexpat, Xerxes C++ and others. The goal is to reduce the load on any one maintainer, while ensuring that there is a long-term and viable support mechanism for all the libraries involved. The InterchangeKit project has started by looking at what are the most commonly used functions in libxml2 - the project has a view on the ones that are most commonly used in open source projects like PostgreSQL, but now needs insight from the banks and financial institutions themselves on which functions they use most often too.

This project is right at the start of development and looking for contributors. Alongside supporting a mix of different mature XML libraries, the project will also look at building a memory-safe alternative for XML parsing in Rust. This should provide an opportunity to attract more younger developers that want to get involved in a project around Rust too, as well as being useful for those developers that have huge amounts of experience in C and XML based on what they work on. 

Maintenance around open source projects is a challenge. Getting people to care about mature projects can be difficult, so finding those developers that have the right skills, insights and support from their companies to get involved is the best potential approach. Banks will need to support XML based on their compliance needs, so they have an interest to get this done and to spread the load too. Collectively, we need that model for long-term project support, we have had to invent it.