A Little Primer on Why the Silicon Valley Bank Thing Matters

The following views are personal and based on my experience working in and around technology, venture capital, and the financial services industry. They do not represent the views of any employer or client of mine, past or present.

(2023-3-11 4:48pm ET Update: This two part (part 1 and part 2) Twitter space with VC Bill Ackman among others may also be of interest; he also discussed as the start of part 2 and idea about creating a consortium of VCs to address all this).

(2023-3-11 3:24pm ET Update: the “All In” podcast from this week goes much deeper into what’s below as well as other related issues.)

(2023-3-12 9:00pm ET Update: The Federal Reserve, US Treasury, and FDIC issued a statement, and concurrently the Fed announced a new program, the Bank Term Funding Program, to back stop SVB depositors. I have made some updates, in italics, to what I wrote below Saturday to reflect this latest development.)


Since we’ve all moved on from generative A/I explainers to venture capital explainers, I thought I’d do a VERY simple explainer for my non-tech, non-VC, non-investment banking friends about why this Silicon Valley Bank (“SVB”) thing is a big deal.

1. Organizations with large endowments – think universities like Harvard and pension/retirement funds as well as family offices – usually invest most of their money in relatively safe investments. Most of them also take a small %, usually single digits, and invest it in higher risk investments .

2. A primary, though not only, vehicle through which they do their higher risk (and hopefully high reward investments) is by investing in venture capital (VC). Specifically they write a check for, say, $10M to a VC and become a Limited Partner (LP) into one of a VC firm’s funds constructed and offered by a VC firm (here’s a list of First Round Capital’s funds for example; note nearly all these funds are open only to high net worth individuals and institutions). A fund essentially represents a group of a VC firm’s investments during a period of time (and a specific year’s investments are sometimes called a “vintage”) as well as potentially a specific investment strategy/focus (e.g., a VC firm may also offer a fund up that is just focused on, say, AI/ML or biotech).

3. The general partners (GPs) of the VC firm — think folks like Ben Horowitz at A16Z or Jason Calacanis — then make investments to entrepreneurs (startup founder/CEOs). So, for example, to make the math easy, Jason Calacanis might in his most recent (hypothetical) $100m fund have 10 LPs that invest $10M each ($100M total) and with that $100m he, as the GP, will write, say, 20 checks of $5M ($100M) each to 20 different startups (again, I’m simplifying the math). The VCs get paid (usually) by the “2 and 20” also common in hedge funds and private equity (VC effectively being a flavor of PE though not all VCs like being grouped in like that) — they charge a 2% management fee to those LPs and keep 20% of any investment return. That 20% may be realized a decade or more later (e.g., when, say, 1 of those 20 companies has a multibillion dollar IPO after a decade of the company being built and growing, while the other 19 have failed and gone out of business — VC business model is built on 1-2 big winners, a few other decent exits, and most companies going to 0), which is also how long the LPs may need to wait (I am glossing over a ton of stuff here about how/when GPs may choose to distribute gains along the way; tl;dr is that the ROI for LPs is nearly always measured in years. These are long term investments).

4. When the entrepreneurs – the CEOs of a startup – get those $5M checks they have to deposit them in a bank of course. As has been widely reported in the press, >50% of those funds end up in Silicon Valley Bank as that is by far the most dominant bank in this space that provides startups with the core banking services any small business would recognize (checking, loans, etc). It is NOT just startups in California — SVB is (was) the dominant commercial (== checking, etc) bank for technology startups generally.

5. Then there was the triggering event, the failure of SVB. Why did it fail? That’s where a deeper, longer discussion of banking is required. I’d refer you to explainers like this one from Marc Rubinstein. You also may find yourself googling “It’s a Wonderful Life”, “Liquidity Coverage Ratio”, “Held to Maturity”, and “borrow short, lend long”. It’s this last phrase that is key. SVB “borrowed short” by taking deposits. At it’s simplest, banks make money by taking deposits and lending (or investing) those deposits to get a return. They may return to depositors a portion of that return (i.e., the small interest rate you get in your checking or savings account — btw, a side effect of all this is those rates may rise to encourage you to keep your deposits in banks rather than taking them and investing them in, say, t-bills yourself), but the amount the banks keep from the money they make with depositors money is how they make money.

As we now know, a significant portion of SVB’s depositors’ money (i.e., the startups capital they received through VCs that is ultimately the capital of LPs) had been invested in longer term fixed income such as US treasuries when, critically, interest rates were historically low. While these fixed income investments are considered very safe (compared with, say, the complex derivatives that were at the root of the 2008 banking crisis), they lost value, in current terms (“mark-to-market”) if they needed to be liquidated on short notice, as interest rates rose, which they did dramatically last year. This twitter thread from January goes into depth on what was going on.

Recall from Macro Econ 101 that when interest rates rise, prices (i.e., how much those bonds could be sold to someone else for — their “mark-to-market” value) of (previously issued) bonds at the now comparatively lower rates go down.

To provide a very simple example, if you bought a 2%, 1 year bond at $100 (pays you $2 at the end of one year), and then the very next day there are 4%, 1 year bonds for sale at $100 (that pay $4 a year), no one is likely to want to buy your 2% bond for $100. How much would you be able to sell that bond for? Probably $50 (actually just a tad more, given the pay out will be one day earlier, but I digress). Why $50? Now that there are 4% bonds in the market, by paying you $50 for that exiting bond, they’d realize that same 4% rate given $2 is 4% of $50.

So this is the key –> As interest rates rose, the current market value of SVB’s bond portfolio, which represented a large chunk of their depositors’ money, declined to such a point that it was no longer clear that the current value of those bonds could cover all of SVB’s deposits. Their “lend long” bond value was less than their “borrow short” deposits which need to be returned to depositors (in the form of, say, an ATM withdrawal) at a moment’s notice. (It also appears that SVB may not have sufficient hedged their bond investments, but that’s way beyond scope of this piece).

6. With SVB failed, these entrepreneurs and startups can’t (couldn’t) access to some or all of that $5M they had deposited in SVB — that money they had received from through VC’s GPs and which really originally came from those LPs like universities and retirement plans. (If a CEO withdrew all of her company’s $5M before this week they are ok of course. Ditto if they did not use SVB.) Key things to keep in mind — that money in SVB is really at the end of the day university and pension fund (i.e., VC LPs) money.

7. This is where the FDIC comes in. The FDIC backstops the first $250K. From there, what happens to the rest of what was deposited (if it was not withdrawn over the last couple days) is the open question that startups and their VCs are working through this very morning. This link from the FDIC is the primary source to read on what the FDIC is doing — read this FIRST. “Insured deposit” means a company’s deposits (up to) $250K. “Uninsured deposits” mean everything there and above for which the FDIC on its site says “Uninsured depositors will receive a receivership certificate for the remaining amount of their uninsured funds”. (Note this was written before the announcement Sunday evening of the Bank Term Funding Program)

8. What’s a “receivership certificate”? It’s basically a piece of paper that says “we need to figure this all out and when we do you may get some or all of that uninsured deposit.” How much, and when, is TBD.

9. So, for many startups, especially if they had all their money in SVB (i.e., all of that $5M check they got from a VC which originally came from the LPs), and had withdrawn nothing prior to the run, the only money they can count on is the $250K (“All depositors will have full access to their insured deposits no later than Monday morning, March 13, 2023”)

10. If over the weekend, someone acquires (had acquired) SVB, this situation with the deposits may end up remedied and the entrepreneurs will have access to all of their deposits (e.g., the full $5M in the hypothetical above). Of course, there are still the SVB employees, many of whom, depending on how an acquisition goes, may be out of job. And depending on how the acquisition is done, those who own stock in SVB (technically its’ parent org, SVB Financial Group), which was traded on the NASDAQ, may lose some or all of their money. Nonetheless, there is general consensus that someone buying some or all of SVB over the weekend is the best case (again, I’m simplifying a lot here and I’m not getting into creditor priority in liquidation which I’ll let my former colleagues from Deloitte and KPMG opine on.)

10. In the short term the issue facing startup CEOs is (was) having funds to make payroll and continuing to run their business (and this, the payroll and jobs implications, was why there was so much pressure for action over the weekend). There are reports of companies that had planned layoffs and now can’t do those layoffs as they don’t have access to the funds to pay severance event — a real chicken and egg. This puts these startups, and their employees, in an extremely precarious situation. The afore mentioned receivership certificates may end up converting back to 100% of the original deposit, but in the short term a receivership certificate cannot be used to make payroll (unless someone is willing to accept these certificates as collateral, which would assume the lender has a high degree of confidence things will be worked out. Again, the best hope is SVB gets bought).

11. So now there’s all these startups, not just in California, but around the US and world, that are stuck. Employees may not be able to get paid, which in turns means those individuals may not be able to pay their own mortgages, bills, etc. This might also accelerate the failure of these startups, leading to more tech layoffs, in turn impacting the wider economy. This also slows the innovation happening at these startups of course.

12. And on the other side of this stream of capital the LPs like universities are now rightfully concerned that their investments, which flowed through the VCs’ funds to startup CEOs/CFOs and were sitting as cash deposits in SVB, may have been lost, either wholly or in part (there are hedge funds bidding on them this weekend to the tune of 60 to 80 cents on the dollar). Again, greatly simplifying –> if an LP invested $10M in a VC fund, and figuring half the entrepreneurs used SVB, up to $5M of their investment may be in question right now. That was a high risk investment to begin with, but this is likely not the type of bad ending for which they accounted – to quote VC Bill Ackman in a Saturday Twitter space, “People (LPs) want to take the risk they intended to take.”

13. Meanwhile VCs (i.e., GPs and their teams) right now need to be focused almost exclusively on helping their portfolio figure this all out, and likely are not going to be able to dedicate much time or capital to new investments for new startups for the foreseeable future.

14. tl;dr is that given the amount of capital involved, the multiple institutions and industries involved, this whole situation could impact the larger economy. This is the “second and third order effects”.

Retirement Plan (LP) -> Venture Capital Fund -> GPs of VC firm write Series A check to entrepreneur -> check gets deposited into SVB -> SVB invests those funds into bonds -> Depositors need those funds back to run payroll but the value of the bonds has fallen such that there wasn’t enough to cover all deposit withdrawals needed to run payrolls to startup employees.

I have greatly simplified A LOT here. Again, target audience is not my friends in VC, tech, and investment banking but my family and friends back home in Maine.

I hope this was useful.

(Disclaimer again: I’m writing this as an individual and speak for no organization or company. This is also not investment advice and should not be construed as such. This is just for education purposes.)

Thoughts Ahead of the Q1 2023 FINOS Board Meeting

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.