Introduction to Open Source Readiness

Rob Moffat - FINOS

Presentation by Rob Moffat to FINOS Members Meeting on June 15 2023.

Hi Everyone!

Thanks for having me today to talk about the FINOS Open Source Readiness project. So my job here at FINOS is a technical architect but I mainly work on two projects or “strategic initiatives” at FINOS - one being Open Source Readiness, the other being FDC3, which I’m sure you’ll be hearing a lot about this afternoon from other speakers, so I won’t dwell on it here.

Before we get into this, I’m going to give a bit of my personal background here too, because this is actually really relevant to what I want to say about Open Source Readiness, or OSR.

The first job I had in banking was with Deutsche Bank, back in early 2000’s. I then worked for several years at RBS - in credit and market risk. I took a few years out of banking when my children were really young and then came back and worked at Credit Suisse as a contractor for a few years.

While I was there I was working on Back Testing, which is kind of a way of checking that your risk methodology works. As a part of that, I got involved in an open source project called Concordion, which was a tool for building tests and I was able to extend this to use for Back Testing risk models.

But I had to write this in my own time, outside of the bank and then during my day job, consume the software within the bank. So credit suisse was getting a good deal here.

After I worked there I was pretty burnt out of risk and so I took a job at HSBC helping to build bots on this new fangled chat platform called Symphony, and it was at a Symphony meetup that I first met Gab and Mao from FINOS.

I built some nice bots at HSBC and a Symphony App where you could search for and read HSBC research.

But after that, I went back to Deutsche Bank again because they were rolling out Symphony and wanted me to head up their Bot practice.

And what I found was, a lot of the code I’d written for HSBC I ended up writing again at DB! But this time, I worked with the DB staff and was able to Open Source that code so that other people could benefit from it. And that code now exists as a FINOS project called…

Shortly after that, my job at DB was relocated to India, so along with a bunch of other Symphony experts, I was let go. Which was cool because I’d been planning to take a sabbatical anyway.

But Open Source doesn’t sleep, so even on my sabbatical I carried on attending FINOS meetings on Spring Bot, along with the staff from DB.

Now the interesting thing is: Spring Bot is still going, We’ve had lots of improvements. It now supports bots across Symphony and Microsoft Teams. The same bots work in both places.

Also, Symphony themselves have stepped up their game and open sourced lots of new bot libraries to FINOS too.

And the Symphony team are now starting to collaborate with FINOS and DB on Spring Bot.

None of this would have happened if this was a DB-internal project. It would probably be abandoned by now.

So, although Spring Bot is super niche, it has benefitted from being Open Source. And, DB have benefitted from open sourcing it.

So let’s talk for a minute about my oher project at FINOS - FDC3, which is an open source standard concerned with getting applications from different teams or even different vendors to work, or, interoperate together on a user’s desktop. As you heard in Gab’s earlier keynote, there’s a lot going on in FDC3 - lots of interesting work happening. But I think the biggest problem we have in FDC3, is what I call the iceberg problem.

We have a small tip of very visible maintainers, some of whom are here today, who turn up to everything, are really vocal in the community, contribute enormously through standards discussions and open source projects like FDC3 Sail. This vocal group is mainly independent people and vendors.

But we have this massive silent majority of developers and users across some pretty enormous institutions who use FDC3 in their day to day jobs. In some banks they have hundreds of FDC3 applications.

But we never hear from these people. Unlike me at DB, they are simply prevented for various reasons from engaging with open source in any meaningful way. They just consume.

And that’s a problem for projects like FDC3 because you need contributors to keep the project moving forward and keep it alive.

So, why is that?

Let’s look at the reasons.

Ok, so first reason is that it’s against the rules at most banks. I remember being at one of my previous banking jobs - not giving any names - and overhearing a conversation between some senior managers where they discussed how an employee had emailed some code to his personal address. It was like,

“Well, he did it on purpose, but he just wanted to work on it at home”

“But, it contravenes the policy, so we are definitely going to sack him”

And, they had trainings and a town hall to reiterate the rules and their consequences.

And these rules exist because banks want to protect their intellectual property. And they’re secretive organisations. They have lots of very confidential, personal information and so these rules are there to provide every protection for that.

By the way, another example of this is generally speaking, social media sites are all blocked by firewalls in banks. Again, this is to stop staff wasting time on Insta all day long but that’s kind of a happy accident - the main reason is to stop people accidentally or deliberately copy-pasting private data onto the internet,

GitHub might not be people’s first example of a social media site, but it kind of is. It’s a community where people follow each other, exchange messages, you have stars instead of likes, but it’s close enough that this is blocked too, or made read-only.

So, as well as banks inventing their own rules, they also are regulated industries. So they have lots of rules to follow from governments. And they get big fines if they don’t obey them.

One law is that all electronic communications must be recorded for auditing for five years. This means, banks have certain systems (like Symphony chat) which they approve for communications because they are able to keep the 5-year record.

But this rules out a lot of ways of engaging with open source projects - like GitHub, Slack, Google Docs and so on, The way compliance has been implemented prevents open source happening.

So probably a lot of people heard about the fines in 2022 that many firms got for not following those rules. This is actually an excerpt from the Open Source Readiness site where we have been documenting all of the different compliance rules that might apply to open source.

And I’ll show that in a bit.

There are so many rules and regulations that banks have to follow. I worked in RIsk for many years and there were always new regulations coming out to follow. Just complying with these rules is hard work - vast numbers of staff are involved in making sure they avoid getting fines like these.

And when you have so many people in the organisation figuring out how to stop other people from doing things, you end up with a very “closed” culture, one which avoids risk.

Culture is hard to pin down- it’s kind of the unwritten rules and ways of behaving. And it changes slowly, usually.

I think it’s fair to say that even though banks do a bit of open source, they don’t have an “open source culture”, unlike say…

So, Google really goes in hard on open source and uses it successfully. When they realised that apple was way ahead with the iPhone, but they wanted a piece of the mobile market, they came up with Android - an open source mobile operating system.

Same for Chrome - there were various browsers like Mozilla and Internet Explorer which had good market share. But Chrome came along and was mostly open source, and is now super popular.

Then Google realised Amazon was getting ahead with AWS, and they wanted to be a cloud computing provider. They couldn’t compete with AWS’ closed ecosystem so they created an open one around Kubernetes, and given all the stories Mao has been telling me about KubeCon in Amsterdam last week, that seems to be working out really well for them.

Google gets open source.

I was trying to get an idea of whether there were more people working in big tech or finance this morning, so I tried googling it, and then I tried using Wolfram Alpha and in the end I gave up and asked Chat GPT.

So here’s today’s obligatory reference to Chat GPT in a presentation. This is its idea of how many employees work for various finance organisations.

It had no idea of how many of them work as software engineers. I am guessing that for each of these it’s at least in the region of tens of thousands.

… and here’s the same thing for big tech. Again, at somewhere like Amazon, a lot of people are going to be in operations. But I think this is similar?

Apparently, the contribution of big tech to GDP is about 8%, and for finance it’s 21%. So I guess my point is that there are not finance firms that are even trying to be strategic about open source in the same way as Google, or Netflix, Amazon or Facebook for that matter.

One final point on this is, Apple have just announced a new savings account with something like 4% interest. They’ve partnered with Goldman Sachs to do this. Now, Apple could run a savings account, but they don’t want to!

They don’t want all these rules and compliance. And they want to keep their culture of being a bunch of west coast hippies or whatever. Not risk-averse secretive bankers. I think.

So, the goal of OSR, and one of the goals of FINOS and one of my goals is - how can we fix that problem? How can we unlock the innovation potential of finance organisations and allow them to to go from benefiting from open source in the tiny way that DB did with me to benefitting from doing open source in the same way as Google with all these blockbuster projects.

I don’t believe that people working in banks are any less innovative, or intelligent, or less technically gifted than people in big tech - they just don’t have the opportunity.

So, how are we going about this?

First, in order to solve this problem, we have to understand it. This means understanding all the rules, laws, issues and so on, and documenting them. The FINOS OSR Special Interest Group is a group that gets together every couple of weeks and discusses this stuff, with a view to documenting it.

So, our OSR Special Interest Group is one of many expert sources who is working on the problem. And we get together and every couple of weeks advance the state of what we’re calling the Body of Knowledge.

We have articles on Licenses, CLAs, Compliance Policy, Contribution Policy, Different Roles of staff involved with open source - we’ve basically broken down the whole space into different articles which we’re beavering away on.

This diagram above reflects the structure of the OSR microsite at osr.finos.org.

Let’s start with risks: we’ve talked about Data Leakage Risk and the Legal Risk of not complying with the law, but also Staff Risk, Reputational Risk, Operational Risk, Strategic Risk.

And then regulations - we’ve talked about Electronic Communications but there are Sanctions, Cross Border Laws, Accountancy Laws, Anti Money Laundering. It might seem surprising but these do intersect with open source contribution!

So those risks and laws affect the shape of the organisation: the roles of staff and the activities they perform. From CTOs to OSPOs, Security Teams, Compliance, Legal.. They are all touched by open source. They have to do things like software inventory, license compliance management, drafting policies, training, Data Leakage Prevention and so on.

We have a section on training that people might take and a section on different artifacts to do with open source, like licenses, CLAs, DCOs, Patents, Policies, SBOMs and so on.

Certification and Maturity Levels I will talk about in an upcoming slide.

This is a view of our open Pull Requests on GitHub. We’ve got stuff being worked on from Brittany Istines from FannyMae, Peter Smuillovics from Morgan Stanley, Pooi Chong from Llloyds and Cara Delia from RedHat.

There are lots of articles here which appear to be by me - I am essentially “Ghost Writing” these with help from people like Rhyddian Olds at Citi, Mark Hoare at Deutsche, Andy Smith from Discover, William Rothwell and Chris Stevenson from UBS, Phillip Holleran and colleagues from GitHub and so on. This actually seems to be quite an effective way of working.

Then during our twice-monthly meetings, we review them and discuss what needs to be added, and we find out how it differs in other places. We have some pretty opinionated people on our calls.

So, we know that firms are starting to do open source in a small way. Deutsche, Citi, UBS, JP Morgan, Morgan Stanley and so on - they’re all dipping their toes and

contributing projects to FINOS.

But one of the things we’re finding out in OSR is they’re all approaching it in a different way - the way to do compliant open source development at Citi is very different to Morgan Stanley.

We want to figure out some best practices and share them with people.

What we want to get to with OSR is this:

On the left hand side we have our experts spread out working on open source in finance. In the middle, we have the body of knowledge, embedded in the OSR website. And we want to distill all of those different approaches, and document them here, and come up with best practices.

The important thing in this diagram is authority: those people on the left give us the authority to say what the stuff on the right should look like.

But after that, we should be able to provide training materials and guides:

How do you create an open source compliance policy that meets all the laws?

How do you make sure your staff are correctly trained? Can we certify staff to say they know what they’re doing?

What should the organisational structure look like? What roles do you need? What committees? Who are the decision makers?

We should also be able to certify individuals. “John knows how to contribute to open source in a bank in a compliant manner” and we give him a badge he can share on LinkedIn.

Finally - and eventually - on the top right, we’re looking at certifications of organisations, based on our maturity model.

So, at the beginning of the year, we broke down the whole topic. We had some help here: Thomas Steenbergen had built a mind-map which was useful input, and people like Rhyddian Olds had done some deeping thinking about all this. And the OSR SIG Leads came in with their own ideas.

Having done that, we divided this bag of talking points into articles in each section of that Information Architecture diagram I showed earlier. And then we got to work drafting them, discussing them and adding them to our Body of Knowledge.

And so this is where we are- there are a few bit left to do, and there’s probably some duplication going on here. But after four or five months we’ve basically covered nearly the whole of our original breakdown.

So I’m going to touch on a few bits now so that you can get a feel for this.

So, here we have the introductory page, with our information architecture on it, and all the articles in categories on the left hand side.

This is an example of an artifact page - it explains what CLAs and DCOs are. There are links to useful resources from all around the internet. The idea of “artifacts” is that they are structures around the open source code that you’ll need to deal with or set up.

Next, here are the risks we’ve broken down all the risks that apply to consuming or contributing to open source.

So, as I said before my background is risk management software in banks. And in 2019 I wrote a book called “Risk-First Software Development”, which is available on Amazon. £18.39.

But the idea of the book is to break down software development and look at it in terms of all the risks that affect it. Now, there have been broadly two responses to this from the developers I talk to. One set of developers say, yes, Rob, obviously. All work is some kind of risk management. And so they don’t care. And then the other group of developers are people who resent me dissecting what they see as an art form. Nevertheless, I stand by this analysis and so it was really heart warming for me when Rhyddian Olds (who you saw earlier) said that setting up an Open Source policy at Citi was all about managing risk.

And he then went ahead and broke down those risks.

So, we documented them all on here - there’s still some work to do on this, especially around supply chain security risks.

If you’re going to build a compliant open source function within your organisation, you need to be aware of all the existing regulations that are out there governing firm behaviour in finance. These are the guardrails that you have to work within. You can’t just start “doing open source” if it contravenes existing bank policy, which is likely built on top of regulation. So, we’re trying to map all this out within the SIG - this is another active area of discussion.

Tomorrow, there is a talk by Jamie Slome from Citi about how they tackled this problem which, for people coming tomorrow I strongly recommend you attending if you’re interested in this.

So one of the things we’re trying to formalize is a maturity model for firms engagement with open source. Luckily for us, there’s some pre-existing work in this area. Last year FINOS and Wipro built a tool called the OSMM - Open Source Maturity Model, which is a questionnaire to get firms thinking about how they do open source.

But meanwhile, the OSPO Alliance published a model called the “Good Governance Initiative” which has a maturity model in 5 levels, and also our colleagues at the TODO group published a similar 5-level maturity model.

So, rather than try and invent a new one, we’ve synthesized this description which is consistent with the TODO and OSPO Alliance models, which means we’re not re-inventing the wheel.

The SIG is still coming together on names for the different levels, but it breaks down like this:

(Describe levels)

Next steps for this: we’re going to add checklists right into the Body of Knowledge so that you can check your maturity level and eventually probably next year FINOS has a goal to create some kind of organisational certification around this too.

So another part of the Body of Knowledge that the SIG has worked really hard on is breaking down the different personas of people involved in open source. We describe what they care about, who they interact with, how their job intersects with open source and how to engage with them.

Again, if you are a member coming tomorrow, Cara Delia is running a round-table discussion workshopping some of these personas which should be really interesting - hopefully we’ll drive out some really interesting techniques for engaging with these different people and building consensus around driving open source forwards.

A lot of the meat of the Body of Knowledge is in the activities. This is taking those levels of the body of knowledge and splitting them into different activities and explaining what you have to do to be at that maturity level.

So for example, to reach Level 2 maturity, you have to be consuming open source in a way compliant with poilcy and regulation. So you can see in this screenshot here on the left the activities relating to that - such as building a software inventory, taking care of license management, supply chain security, training and so on.

We’ve still got a few articles to write here if anyone wants to help.

Finally, we’re also trying to catalog useful training materials. So you can see here we’re listing out different training that exists already in the Linux Foundation. Eventually, we’re going to get to the point of recommending different trainings for different roles. So, what training should a CEO, CTO, Developer take from the catalog.

And, as Gab said earlier, we’re going to fill in any gaps by building trainings to cover finance-specific topics that aren’t already covered.

And hopefully after taking those training courses, you’ll be able to take FINOS-branded certifications to prove you know what you’re talking about.

So, if we get this maturity model working, and we have developer certifications, we can start to publicise the story that Open Source is big thing that is happening in finance, and not just around the edges.

There should be a virtuous circle around people and organisations getting certified and open source projects being donated to FINOS. We can create FOMO, too.

First, we know that developers are picky about where they work, and working on open source is a deal breaker for lots of them. Banks worry about attracting talent. This is where Staff Risk comes in.

Second, as we saw with Google, there are strategic benefits from doing open source. Finance is a competitive arena. If someone in thee industry figures out how to “do a google”, everyone else will get left behind. This is a big, obvious strategic risk.

Third, banks worry about dependencies - especially since Log4Shell. Not being involved in the development of key strategic open source projects is a big risk for them. What if a project they really care about gets abandoned? They can’t take up maintenance unless they’re doing open source!

They can’t address this Dependency Risk without contributing to open source.

Ok, so that about wraps it up and gives you an idea of what OSR is up to for this year. We’d love to have you involved. Do you have a view on any of this stuff? Want to write an article? Review a PR? Or just show up to a meeting and tell us how it is, please do that.

I am also collecting names for our Beta certification program. If you want to get FINOS Open Source certified ahead of everyone else and for free, then come talk to me and I’ll add you to the list or hit up this QR code here.

Thanks for listening, any questions?

Made with Keynote Extractor.