The following views are personal and based on my experience working in and around open source and the financial services industry the last five years. They do not represent the views of any employer or client of mine, past or present.

The Fintech Open Source Foundation (FINOS) quarterly board meeting is this week.

Below are six suggestions for the board, FINOS community, and wider community of developers, product managers, program leads, etc. working at the intersection of financial services and open source.

They are:

More detail about each of these is below if you’d like to grab a cup of coffee and dig in …

Identify Strategic Themes and Double-Down on a Critical Few Set of Projects

FINOS is an industry (i.e., financial services) focused foundation. While there are open source projects that have grown out of financial services companies to have broad cross-industry applicability – pandas, developed by Wes McKinney when he was at AQR and which he continues to maintain today, and Eclipse Collections, originally created by Don Raab, now at BNY Mellon, being two such examples – a principle utility of FINOS is the ability to connect product teams working on common industry-specific use cases to collaborate through open source methods and code.

I recommend that the board deliberate to identify a targeted set of themes – 3 would be ideal, 5 at most – of shared strategic criticality and which represent differentiated sets of use cases within financial services. This would be a fundamentally much more lightweight structure than the old programs model from the FINOS early days or even the categorization on the landscape. Rather this would be more a statement of a few top priority areas, for which open source has utility, that resonate to the CIO/CTO level of FINOS members.

Ideally, in each of these areas there should be 1-2 FINOS projects already incubating or active, around which the board and wider community would further rally (more on that in a second). In the case of themes where FINOS does not have a current offering, rather than start something from scratch, with an empty repo, which has had mixed success, I’d suggest looking for other projects in the Linux Foundation and wider open source community around upon which to build financial services specific extensions and features.

Here are some candidate themes, and potential related flagship projects

• Big Data, Data Engineering, and AI/ML
  • Legend
    
• Next-generation Financial Desktops
  • Perspective
  • FDC3
    
• Trading Technologies, Front to Back, and (System-to-system) interop/exchange
  • Financial Objects and security reference data projects
  • ISDA CDM work
  • Morphir
  • MessageML, Symphony WDK, and similar projects
    
• Payments
  
• Blockchain and Tokenization
  While there is some applause for the relative lack of blockchain activity happening in FINOS, there is also lots of interesting blockchain work happening right now in the industry around areas such as fixed income issuance and settlement. CEOs of companies like BlackRock are talking publicly about tokenization’s utility. FINOS took a run at a Distributed Ledger Technology (DLT) program in 2018 and it didn’t quite get traction, but the core technology has developed a lot since then, and it now has more in-production use cases, including and especially in financial services.

• Regulatory and Reporting
  How can open source and open standards help reduce the regulatory burden for financial services organizations, both financial reporting as well as reporting related to SBOMs, vulnerabilities, licenses, etc. for IT and engineering audits? Enterprises can and should think about how they streamline and standardize how they do financial reporting and engineering/SBOM/tech stack risk reporting for regulators and auditors.

As to the afore mentioned “rally”, this would take the form of:

• The original contributors and/or current maintainers, with support from FINOS and the larger Linux Foundation as needed, re-commit resources to what are effectively product marketing roadmaps to further attract and retain consumers and contributors to these projects. Get the hygiene around these projects in great shape — documentation, public roadmaps, roadshow and conference presentation plans, support and mailing list response procedures, SDKs and reference implementations, etc.
  
• In turn, and with an eye towards cross-pollination, each organization in FINOS should “pinky promise” to evaluate at least 3-4 projects in the FINOS catalog, with a goal that every member is consuming at least one project in FINOS that their own organization did not originally contribute. If this proves too hard – if each member can’t find at least one FINOS project that is useful enough for to them to implement and use – than a more fundamental question about the FINOS project portfolio, or even the value of FINOS hosting projects on its own at at all, should be asked, though I don’t think that’s where things are yet. As stated so well by friend of FINOS Jono Bacon Monday on LinkedIn, building a community around a software product (or catalog of projects) starts first with shared consumption.

The overall point is that we need to jumpstart the flywheel of cross-contribution via cross-consumption. This was a priority in FINOS early days but harder to do then with comparatively fewer members and projects. Now, under Gab and rest of the team’s leadership, FINOS has a broader set of both members and projects from which to build cross-interest in each other’s projects.

Build an Open Source Catalog to Demonstrate Commercial Value

Financial services professionals working to build great products in banks and other financial services organizations, but with with less background in open source, could use some help navigating what open source projects can be used for what and how. Building on the success of the project expo at OSFF, I think there would be value in a library of case studies and examples of how open source projects, at least those beyond the “household names” like Linux and K8S, have been put to use within financial services. Unlike the expo though, this catalog should not be limited to just FINOS or even Linux Foundation projects, but instead be any open source project that a financial services firm might use. Extra points if the case studies can include how consumers went on to become contributors.

Another way to implement this might not be as a catalog, which requires an initial critical mass of projects, but perhaps as a Yelp style project review where open source project consumers could easily share back their experiences and lessons learned when deploying a particular open source component, perhaps as overlay to an initial set of project data from as sources such as libraries.io.

Open source should be a way for financial services companies to accelerate product delivery roadmaps. A better way to share the pros and cons of open source packages, especially in a financial services context, would help product managers and engineers especially to make informed decisions, and in turn help organizations realize more commercial value from open source.

Convene a Working Group around AI

Everyone has heard about ChatGPT and if your social feeds are like mine, they are filled with posts about A/I.

I think the board should consider starting an AI/ML working group to take on the following topics:

• Financial services specific considerations (e.g., IP considerations) when using AI-powered IDEs like GitHub co-pilot and ChatGPT infused repl.it.
• Open source licensing and its applicability (or lack thereof) to AI/ML. To highlight just one specific issue, among several, what counts as “modification” in an ML model? Is setting the weights in neural networks enough to trigger the modification criteria if an ML model’s maintainers have adopted AGPL as its license (as some have done on Hugging Face)? It’s not clear that using open source licenses for ML models may not be a round peg in a square hole.
• Underlying license and copyright issues related to underlying code bases and data sets on which AI/ML models are trained. Tools like The Stack built by bigcode on Hugging Face that allow one to search a code corpus for their own contributions are the types of tools and transparency of which we need more.
• How tools like ChatGPT can be used to quickly build initial scaffolds and working prototypes of new projects for financial services, and what additional data sets could be used in combination.

Bring Product Managers to the Table

I am inclined to wonder if participation – i.e., having “a seat at the table” to the distributed product management at the core of open source that happens in GitHub issues and on working group calls – may not be at least as valuable, if not more so, to financial services companies than code contribution by engineers.

I think the community can and should do more to encourage participation by product managers in FINOS and similar efforts, as it is the product managers that likely have the clearest and most comprehensive view of end-user use cases. Product managers are well positioned to provide input on requirements, roadmaps, and features. Along these lines, there also opportunities to help bridge the gap between internal product management tools and processes with their corollary systems in open source communities (e.g., GitHub Issues coupled with a project’s governance model).

Build Business Cases, Benchmarks, and KPIs

Can more be done by open source practitioners, and the open source community overall, to shore up the business case for open source? (By “open source” I mean everything above and beyond passive open source consumption — i.e., “active” consumption by leveraging tooling like the OpenSSF criticality score, referenced below; participation by product mangers and engineers in working groups; code contribution; and, financial sponsorship in the form of foundation memberships and project grants).

Unless corporate leadership can be shown EDITDA (or FCF) measurable IRR and ROI models to rationalize investments in open source (as defined above), I think open source may increasingly find itself buffeted by the waves of economic cycles, especially as technologies like AI/ML (which is not mutually exclusive to open source, but may end up treated as a distinct set of programs for corporate planning purposes) become the new hotness attracting attention, sponsorship, and budget dollars.

And so, given there is only so much budget to go around even in the most well capitalized of corporations, organizations pursuing open source strategies could use help with:

• Business model templates, preferably as IRR models
• Categorized lists of concrete, tangible business benefits, preferably those that other companies publicly acknowledge having realized. (These cannot be theoretical or aspirational).
• Guidance on how to set targets and key results goals.

Along the lines of benchmarks, and as I’ve shared in TODO Group and FINOS Open Source Readiness meetings previously, the industry and open source community could benefit from a set of common KPIs, specifically a scorecard with shared definitions with which an organization can benchmark itself to 1) its sector (e.g., capital markets) and competitors/peers, 2) the financial services industry overall (retail banking, capital markets, asset managers, data providers, etc), and 3) open source overall (for which the Open Source Contributor Index is effectively one version). I suggested a few such KPIs in a GitHub issue several months ago. Compiling these benchmarks might be done as part of the Open Source Maturity Model (benchmarks and measures being useful context to maturity rubrics) and/or State of Open Source in Financial Services annual report. I’m hopeful the CHAOSS community could be a huge help here too.

Here’s a starting point of a few KPIs (some of which, at least in part, exist in part on LFX Insights) that I think could be the basis for a useful benchmarks. Trend lines – Month over Month, Quarter over Quarter – coupled with the ability to compare one’s own organization with its sector, industry, and open source ecosystem overall, is what would make these even more useful to executives.

• Active Contributor Ratio
  Active Contributors / Total Engineers (or potential contributors overall to include PMs, etc) in a given time period
  
  The first step to using this metric is a shared definition. One definition is the number of individuals who have proposed a pull request (which is a bundle of 1 to n many commits) in a given period. The Open Source Contributor Index (OSCI) by EPAM, by contrast, uses >10 discrete commits in a given time period.
  
  (Fictional) Example: A global asset manager has 15,000 engineers and 5,000 PMs, so a total addressable “market” of contributors of 20,000. 1,000 are active contributors to open source. Its active contribution rate is 5%.
  
  
• Count of contributions in a time period made by a given organization, sector, industry
  # of contributions
  
  Similarly the first step here is to define what counts as contribution. Is it just code contributions? Or other valuable forms of contribution like raising a GitHub issue?
  
  Useful drill downs might include:
  • Products/projects to which contributions are being made by company, sector, industry
  • Foundations that host the projects to which contributions are being made
  • Technology or domain areas of contributions (E.g., data management, blockchain)
  • Use cases and business domains
    
    
• Count of projects to which an organization, the sector, and the industry are actively contributing
  # of projects
  
  Potential drill downs:
  • % of projects to which contribution is being made that are in the Linux Foundation, FINOS, etc. Perhaps a pie chart of foundations that house the projects to which contribution is being made?
  • Ratio of number of projects to which an organization, sector, and industry is actively contributing that they also use in production over the total number of open source projects they use. This ratio would be useful to show how well aligned contribution is to overall open source consumption. This ratio could be further tweaked to include in the denominator just, say, the top 500 most used projects, which then help shows alignment of contribution to projects most used.
    (Total projects to which contribution is made – Projects to which contribution is made but that are not presently consumed in production) / Total open source projects/packages used in production
    
• % of pull requests to a FINOS (or any open source) project during a time period
  • that are made by the original contributing organization (e.g., % of pull requests made to Waltz by DB)
  • that are made by other FINOS members other than the original contributing organization (e.g,. % of pull requests made to Waltz by any other FINOS member than DB)
  • that are made by other LF members other than the original contributing organizations
  • that are made by contributors from non-financial services organizations
    
• Watcher, Star, and Fork counts across ..
  • Projects contributed (created and originated) …
    • by an org (e.g., Perspective, Quorum etc. for JPMC; GitProxy, Datahub, etc. for Citi, etc.)
    • by a sector (e.g., asset management)
    • by the industry
  • Projects to which an organization, sector, industry contributes
  • Projects an organization, sector, and industry consumes

While I doubt individual corporate performance will ever be public for, say, Morgan Stanley, to do a direct comp of any of these contribution metrics with, say, JPMC, I think it’s reasonable to expect executives who fund open source programs and associated foundation memberships to ask, and be able to get coherent answers to, questions which require industry context like:

• Are we contributing at a higher or lower rate than the sector, industry, and overall cross-industry average?
• How does our contribution activity overlap to the projects we most consume? How about for the sector and industry? (see discussion of interventions below)
• How does our consumption and contribution map to the foundations to which we provide financial support?
• How much contribution (traction) are we getting to projects we contributed from other FINOS members and wider industry participants? How about from top clients?
• Where are other industry participants, especially our clients, focusing their contribution activity?
• and an overarching, project discovery question, What open source projects are not on my radar that we should be looking at?

Just having a canonical top 10 or top 100 list of the open source packages most consumed by the financial services industry could be useful.

Bolster Connection Between Open Source Programs and Software Security and Supply Chain Programs

The criticality of open source package vulnerability detection and mitigation in open source continues to grow. Hence the 2021 White House Executive Order and the creation of OpenSSF.

As was suggested on Twitter Monday there can and should be more connective tissue between OpenSSF and the TODO Group, the latter being an incredible consortia of OSPOs in the Linux Foundation led by Ana Jimenez through which leading practices are shared about and among open source programs. I’d add FINOS to the mix. Why? Because open source programs, including and especially in financial services, should be well connected and supportive of software supply chain initiatives usually driven out of some combination of the CISO org, DevX, and CI/CD type groups. Additionally financial service firms have industry and regulatory specific requirements related to handling software security and performing incident disclosure.

The most concrete tie-in between open source consumption and usage security (“inbound”) with open source programs, which are often focused on contribution (“outbound”), is project and community health. Project health checks – which can include metrics such as PR review cycle time – are a useful early warning light that an open source project may have a statistically significant greater chance of containing heretofore unidentified critical (9.0+) vulnerabilities on the NVD scale. Recognizing their value in risk identification, project and community health metrics are being incorporated into the OpenSSF Criticality Score.

In addition to helping software security teams in banks to implement the OpenSSF criticality score among other forms of project health check reporting, open source program professionals are also well positioned to advise on the potential interventions a company might take when a particular project, especially one that’s commonly used or prevalent across transitive dependencies, starts to exceed specified risk thresholds. These interventions might include the following non-mutually exclusive actions:

• New or increased financial support for an at-risk open source project through
  • Support of the underlying foundation if they are part of one (especially via directed giving if that is an option)
  • Maintainer grants
• Increased code contribution by the firm’s own teams
• Hiring independent developers, perhaps via programs such as Major League Hacking, to build new features and fix bugs in an identified at-risk project
• Increased product direction and feedback by the firm’s own product managers and security professionals
• Especially if a project is no longer actively maintained, or its maintainers are no longer responsive to PRs, hard fork the project
• Evaluate alternatives, both open source and proprietary, that might take place of the at-risk project.

Evaluating the suitability and feasibility of these interventions is work open source programs should be well positioned to help CISO teams with, and an excellent way, in my view, for these programs to demonstrate further value.

Finally, providing all this information in an easily consumable way, with useful visualizations, to the CISO, CTO, and CIO levels of an organization, as well as any number of the business case metrics above, is itself a big area of improvement opportunity. For example, CISOs and CTOs should be able to readily call up a list of, say, the top 50 most used open source projects in their consolidated SBOM, with an overlay of 1) OpenSSF health score and 2) current enterprise engagement and support of these projects (i.e., the interventions above). Better still imagine bank leadership being able to call up such a dashboard in their preferred open source powered financial desktop of choice (perhaps with FDC3 integration with complementary tools) such that open source security reporting is a “first class citizen” among other executive level risk reporting, and as complement to existing FINOS-wide public visualizations available in LFX Insights.

Side note: Over the holiday, I got playing with an open source project in the Apache Software Foundation, DevLake, contributed by Merico, an open core company whose investors include OSS Capital, the VC firm that invests exclusively in open source companies; I think the DevLake project could provide some of the metrics and visualization building blocks. There’s also some great new stuff in the latest LFX Insights release. Lots to work from.

In conclusion …

I am really excited about all the great stuff happening in around FINOS, its incredible members, and the intersection of open source with financial services. I am still buzzing from the fantastic OSFF last month — some of us “old timers” (looking at you, Brad!) were remarking at how much the community has grown. Great stuff! Here’s to an awesome 2023!!

This post was not written by ChatGPT.