Skip Navigation
Resources Blog Wicked Good Development Episode 21: James McLeod shares his ...

Wicked Good Development Episode 21: James McLeod shares his journey to FINOS

Wicked Good Development is dedicated to the future of open source. This space is to learn about the latest in the developer community and talk shop with open source software innovators and experts in the industry.

This session features open source war stories from James McLeod, Director of Community for FINOS.

After years in FinTech as a bank software developer, James McLeod now works to create impactful open source technology and communities. He works closely with contributors from the world's largest investment banks and cloud providers on a daily basis, providing experiences and insights we're excited to share with our listeners.

Listen to the episode

 

Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm

Show notes

Hosts

Panelists

Relevant links

Transcript

Kadi Grigg (00:00)
Hi, my name's Kadi Grigg, and welcome to another episode of Wick Good Development, where we talk shop with OSS innovators, experts in the industry, and dig into what's happening in the developer community.

Eddie Knight (00:10)
And I'm Eddie Knight. This is my first time co-hosting with you, Kadi, so I'm very privileged to have a familiar face on. James and I have been working together for about two years in open source communities, and recently we got to see each other in Dublin. James, could you introduce yourself and tell us a little bit about the perspective that you're bringing?

James McLeod (00:30)
Yeah, absolutely. Thank you both for inviting me on the podcast today. So I'm James McLeod FINOS Director of Community. FINOS is the FinTech Open Source Foundation, and we are part of the Linux Foundation. I'm sure you know many of your listeners would've heard of the Linux Foundation through projects like Kubernetes and Node and GraphQL. FINOS is actually the financial services vertical of the Linux Foundation. And so we support and we collaborate and we bring together lots of different banks technology companies and consultancies around financial services. So that's what we do in a nutshell. So we're working within a very deeply regulated industry within open source.

Kadi Grigg (01:19)
Let's dive in. So James, before we get into what FINOS is and what they do, can you give us a little bit of background of what your open source journey has really been and how you ended up at FINOS?

James McLeod (01:33)
Yeah. Wow. So really, I mean, my entire career has kind of directed itself into open source. It's a bit of a long story. I mean, I wasn't always an open source developer. I started developing using Microsoft products. My very first language that I learned, and the very first suite of tools that I used was Visual Studio for C++. Then that developed into using C# and .NET through the .NET framework. But slowly over time throughout the 2000's and into the 2010's, you've got a lot of JavaScript libraries that started to really enhance the user journey and user experience on the front end. And so you had libraries like jQuery, which were contributed that really did engage within the DOM of the browser.

James McLeod (02:29)
And it kind of allowed you to extend kind of people's usability of e-commerce and other platforms. So, whereas before I was writing predominantly like service side and also database code, jQuery it may not be used now, and it probably isn't so much, but it really did allow us to kind of engage with the user at the point in which they were interacting with their applications. And it was through kind of using all of these different open source tools primarily through JavaScript that opened my eyes to the world of developing, using open source and then using Angular and using React. And moving through all of that type of open source development that when I was developing in that world, I then started working within consultancies, admittedly with teams who actually spanned the globe.

James McLeod (03:34)
And so it wasn't just me working with people in the office around me, it was me working with other developers in the US, in India, and in different places. And we needed to educate each other on how to do things. And so my world of open source which predominantly my eyes were open through JavaScript then became how do we communicate, how do we learn, how do we share and solve the problem of how do we actually develop projects across multiple regions? And so I started using tools and mechanisms like brown bag sessions, starting meetups, getting together on WebEx, and now it's Zoom, screen sharing, communicating then I was introduced to GitHub and it just kind of like exploded from there. So that's kind of like my accelerated journey in the beginning. Like 20 years ago, I wouldn't have even thought about open source, but it's just the way that the industry developed and the way it engaged with the kind of team leadership within me, it kind of just resonated with that servant leader type approach that I'd like to have within the open source community.

Eddie Knight (04:54)
So, James, you really cut your teeth on lower-level languages compared to JavaScript where you ended up. And as we were talking and I was kind of thinking about things, I realized that if I go downtown in any city around the world and I throw a rock, wherever it lands, it's gonna be within arms reach of a JavaScript developer somewhere. It's an extremely popular language. It's an extremely versatile language. It's an extremely widely used language, especially if you include type script. It's just used everywhere. Javascript, JavaScript, JavaScript. And something else that stands out to me is that JavaScript developers are very community-based.

James McLeod (05:37)
Mm-Hmm.

Eddie Knight (05:38)
There are meetups absolutely all over the world. And I'm curious about what your involvement is in that.

James McLeod (05:47)
<Laugh>. Yeah.

Eddie Knight (05:48)
I know that you've been part of a London meetup group. Could you tell us a little bit about that? What that's been like for you?

James McLeod (05:57)
Yeah absolutely. So I started a meet up back in 2013 around Angular. I have to admit I was asked if I would like to do it. I always kind of thought that I would like to start a meet up, but I didn't know how to do it. And there was an angular community around London at the time who needed a home. And so I worked with, in the consultancy that I was working at at the time, and they agreed to give them a space. It was literally just a meeting room where you'll get half a dozen people together in order to sit down and collaborate and share things. But there was just something about people coming together around a specific library or tool sharing code over a projector and just really kind of like feeling the buzz of people feeding back and helping each other. And then you kind of get a bit of a dopamine rush so I don't kind of partake in extreme sports, but-

Eddie Knight (07:07)
Maybe not extreme sports, but you run a lot, like look at your LinkedIn profile, you just constantly run.

James McLeod (07:13)
I do. So, yeah. But I wouldn't call that extreme. I would call that just keeping fit.

Eddie Knight (07:20)
Fair enough.

James McLeod (07:20)
There's something about having a meetup that you start where you have three developers at the very first meeting and then seeing more people come. It's almost like a universe thing where one something, a meteorite kind of like in space through saying gravity attracts more objects to it. And before you've got a planet, it's like the formation of the solar system. If you can provide value to people who join, then word of mouth and social media scene brings people together. And so the very first meetup was that Angular JS meetup that we ran way, way back 10 years ago nearly. And that became really popular. At the time Angular was popular, it kind of lost popularity, not necessarily because of Angular itself, but I think the JavaScript community around open source was learning how you actually kind of pass through different versions and keep the project alive.

James McLeod (08:29)
Angular went through some pretty kind of disruptive breaking changes, which basically kind of disrupted the community, and it kind of pulled the rug from beneath everybody's confidence. But then I moved on to a bigger project within the same consultancy, and we landed on React. Now the interesting thing is that there weren't that many Reactors, no developers around at the time. It was kind of I dunno what the version of React was, but a decision had been made by the bank who I was working for to use React, but there weren't any React developers in London. There weren't any React developers, even joining the team from different places across Europe, the US, and India. And so we needed to find a mechanism to bring everyone together in order to learn, and share, and grow our own experiences.

James McLeod (09:23)
And so that's where the Angular meetup turned into a React meetup, and we were using it as an internal method for growing ourselves. But we just did it in the open. And so we invited everybody else to join as well. And that meet up went from being an internal kind of educational method to growing into a React meet up called React: Bring Your Own Project, React London: Bring Your Own Project. And at the time where just post COVID, I think there was about 1,500 developers, all members of this meetup. COVID totally disrupted it. And we nearly threw in the towel, if I'm gonna be honest. It was such a struggle kind of doing another Zoom call for like a community meetup, and then also trying to bring people together through COVID where there were social distancing rules and loads of regulation.

James McLeod (10:21)
But quite recently a couple of new contributors, a couple of new organizers wanted to join the group. And they said, "You fancy giving it another punt?" And I said, "Yeah, it'd be really good." But we're not really using React that much anymore. Our careers have evolved into other things. I said "Do you fancy diversifying?" and just creating a broader JavaScript meetup. And so then we created London JS, and last night we had our first London JS meetup in Netflix, in London. The community kind of, we carried across the React London: Bring Your Own Project community into it. We spoke to the members and said, "We're gonna be a React meet up, but Java, we are going to become a JavaScript meet up, but React is JavaScript." They said, fine. And so we've got like 2,200 members, and it was totally sold out. So we sold 150 tickets for free. People didn't have to pay. You literally kind of put your name down and we had 170 people on the wait list. And it was absolutely amazing, so meetups are an absolute entry point to open source, it's all part the same thing. And I'll wait for another question cause I can talk about this subject all day long.

Kadi Grigg (11:47)
Yeah. So, and honestly, some of the stuff you were talking about just gave me, I don't know if whiplash is the right word or not. But I used to sell to banks, and honestly, when I started my career in development, I was selling COBOL development and mainframe solutions and working in banking, I knew it was like heavily prevalent. So when you talk about like this education journey that you've gone on, what is being done today or has been done to really bridge the gap between mainframe and all this new open source technology? I mean, are you still stuck on it, or are we now in a place where it's more of sharing ideation and, and those types of things?

James McLeod (12:24)
Yeah. Well, I'm so happy that you brought up the mainframe because that is one of my secret, kind of like passions under the hood. It's a little bit embarrassing, really, but the thing that I absolutely love is that mainframe has actually got one of these reputations for being COBOL, and being a technology that people develop upon inside a dusty cupboard. In a data center somewhere, some hardened Cold War bunker, that nobody can actually get into. Like what was it, Captain America, when they go down and see all of these tapes and old machines in a dusty cold war bunker. But it's not like that anymore.

Kadi Grigg (13:09)
You have someone down in that bunker though, who has the sign that's like, you can't spell COBOL without cool, just waiting for someone.

James McLeod (13:16)
Yeah, exactly.

Eddie Knight (13:19)
So I saw a tweet yesterday, I think it was in German. I had to hit the little translate button. It was from a COBAL developer who said that he got a bug report from a client, and he went to the respective part of the code base, and he found a co a comment in the code from 30 years prior. It was written by his mother.

James McLeod (13:40)
Really passing the bat down the generations. Gosh, wait for your son. Yeah, wait for your son to grow up to fix a bug in your code. That's hilarious.

Eddie Knight (13:52)
Yeah. That's not how inheritance works in programming.

James McLeod (13:56)
Oh, that is hilarious. Yeah.

Eddie Knight (13:59)
So tell us about COBOL. You brought it up, you brought it up.

James McLeod (14:02)
Yeah, absolutely.

Eddie Knight (14:03)
Do tell.

James McLeod (14:04)
So within FINOS, you kind of talking about the foundation. We also run another meetup called it's like The Open Source Meetup, and we run it around the UK and it just so happens that we have a meetup in Edinburgh where Lloyds Banking Group, who I actually–so I'll be open about it. I used to work for them. So I've got a load of friends and ex-colleagues of mine who are still doing great work. They're not pH members but they are still, transforming themselves within the UK. But they have been working with Red Hat who are female members. And so, already Adrian Hammond and the team, they've been kind of working hard on a project that both you and and I work on. But a guy from who, I won't mention, well, I will, it's in the open, a guy called Reg Wilkinson, because it's out there, it's on YouTube.

Eddie Knight (15:02)
So for context, sometimes it's actually hard to remember when you're under NDA or when you've agreed to not say somebody's name. It's a whole new rule for me.

James McLeod (15:13)
And Reg won't mind. I mean, he loves it. And he's on YouTube talking about it. So you can look it up. It's on–so Scott Logic, you're a member of ours, and we partner on this meetup, and they released Reggie's talk. And the whole thing about Reggie's talk is that Reg is actually a mainframe developer. He's like an engineering lead within the Lloyds Banking Group. IBM Z Series Center of Excellence. And they realize that, there's I mean, COBOL is used everywhere still, but it's probably not the primary go-to, language of people coming out of university anymore or people who want to work in the cloud it just isn't. So they need to–so banks everywhere need to solve this problem. It's like, the mainframe, it's very reliable.

James McLeod (16:04)
The resilience of the mainframe is absolutely unbelievable. If you think about all of your financial transactions, whether it's a payment, whether it's a credit card, whatever the transaction is. Whether it's where all of your personal information and loan data and mortgages are kept, it's all kept on the mainframe still. So with the Red Hat team, who we have a great relationship, they actually worked using OpenShift to containerize applications on the mainframe because what you need to be able to do to increase efficiency across, cloud computing is kind of write things in one place and be able to use it kind of in multiple different places. And if you think about the mainframe, it's probably kind of like the furthest away that you could get from an engineering team.

James McLeod (17:05)
It's kind of like a production system within a bank. A lot of the hybrid cloud and cloud applications that are written are fully accessible to engineers because they are used in some production systems, but a lot of it is used for engineering and things that don't hold systems of records, for main banking applications. But by using OpenShift, which is containerized, it's a containerization platform like Kubernetes, they have been able to get that running on an IBM Z mainframe. So they can take applications that are written by, engineers elsewhere and run it anywhere using Kubernetes on OpenShift. Which is brilliant because it then kind of dispels the myth that the mainframe is something that's dying actually. In fact, the mainframe is something that's coming back to life.

Eddie Knight (18:00)
Actually, James, I want your input on something. I was talking with a colleague, a former colleague recently who I keep in touch with. And he mentioned that the bank he currently works in and does infrastructure for is building a new data center in the south of the United States. And we were kind of talking about that, and at some point during the conversation, he, he said that he thinks it'll be probably 10 years before banks fully move over to the cloud. And this just, this really stood out to me because on one hand he's saying, we're building a new data center–mainframes, like we were just talking about. And then on the other hand, he's got this opinion, just as one engineer. One engineer's opinion is that everything is moving towards the cloud within the next 10 years, it'll be 100% cloud. And that seems to be like a stark contrast. So just getting another person's opinion to add to the fire. What do you think, James?

James McLeod (19:06)
Wow, you're putting me into a bit of a controversial spot. Right, so I think that there's always gonna be room for the mainframe. I think it's gonna be around. It's not necessarily that I'm advocating that. So I'm not saying that, we need to keep the mainframe. I'm not kind of protesting outside cloud service provider offices by saying this. All I'm saying is that it's a proven technology. It segments data so the context between your data and somebody else's is physically kind of separated. And there's lots of it around and if you think about the real estate of a bank, just one bank and the reliance that they have on the mainframe, and then you multiply that across the entire financial services industry, the amount of mainframe computing that there is out there would be really, really hard to migrate off of the mainframe and then into, into the cloud. I mean, it's gonna be a massive task. So, he's probably right. 10 years. If the plan is to migrate out of the mainframe and into the cloud, it probably will take 10 years. When you think about the complexity of all of those applications and what you would need to un-knit and actually transfer across, because there's gonna be interdependencies, there's gonna be data there's gonna be certain regulations and configurations of the cloud that's needed in order for the regulators to say yes.

Eddie Knight (20:45)
But you, you, you are saying that we're going that direction of 100% cloud. It's just a matter of how we're gonna get there and how long it's gonna take.

James McLeod (20:55)
So my thoughts, I think it's kind of like an accessibility thing, right? So I think that it's not necessarily about protesting about the mainframe, I think it's about embracing it and bringing it into your hybrid kind of real estate. So like what the Red Hat team and Lloyds were doing rather than segmenting it and having a different context, which is all about, I am a COBOL developer, I work on the mainframe versus I am a JavaScript developer and I work in the cloud. Or in that way say, cool versus legacy. It's about how can you actually make it more accessible? How can you work with the providers of mainframe because there are massive providers of mainframe to enable containerization on there enable accessibility on it, get the applications that we are running as engineers running on there making it more, accessible to the infrastructure teams who need to run it. So you have choice, open source is about choice. Why not make mainframe a choice? It could just be an end point for the delivery of your application. In that case, it's just part of the cloud, it's part of your internal cloud real estate.

Eddie Knight (22:24)
I think too often technologists fall into a trap of app modernization leads to cloud. Because so often we talk about these cloud adoption journeys, and the first step is we need to do this app modernization. But in order for us to do that cloud transformation, we gotta do the ad modernization. We gotta set up our new infrastructure. We gotta codify things that previously might have been manual. So we've got our modern apps, we've got our infrastructure is code, and then we've got our cloud journey has really taken off and really started. But that the mistake, the pitfall, is in saying that app modernization is simply a step to the cloud, instead of saying that we can benefit from app modernization regardless of where we're deploying.

Kadi Grigg (23:26)

I'm just–so I couldn't help but ask that because I used to work at Micro Focus, so I was just like genuinely curious about that on how you bridge the gap between the two, because I know there's a lot of overlap. But at the same time, it is, like you said, where it often seems kind of like an antagonistic between legacy and modernization.

James McLeod (23:42)
Yeah, totally agree.

Eddie Knight (23:43)
Okay, James, so we know you now integrated in the open source communities, and all the work that you're doing with the meetups and the JavaScript, but you're also telling us these stories of the lower level development working on code that's getting deployed directly to mainframes. We're having two very, very different conversations here. So could you tie these together, like help us understand how you got from there to here?

James McLeod (24:10):
Yeah, I can. Absolutely. So what you were saying about, so I've lived in the world where cloud migration has been about, picking up things that exist off the mainframe and sticking it in the cloud. That was kind of like the first strategic goal. Just take what you've got, put it somewhere else and sometimes you need to kind of go through these different experiences in order to find out what that means because, there is gonna be a consequence of that action. And a lot of the consequence has been probably the anti-digital transformation consequence. It has increased costs, reduced efficiency and slow down as you get to know the platform, which is like the anti of what cloud migration is supposed to be.

James McLeod (25:05)
So the great thing about open source is that it's not necessarily just about contributing code into existing repositories. It's about people come together to figure things out. And also the great thing about the cloud is that it's also accessible to everybody, so you don't have to be, a chief technical officer, buying a physical server in a data center, giving that to your team, and everybody just uploading all of their code, without any form of accountability to, what you are uploading because you own the server and, there's no other costs, kind of like involved. So what we now realize through those digital transformation efforts of picking everything up and migrating it across in one big bulk migration is that it's costly.

James McLeod (26:00)
What we now know about, the cloud, and one of the true benefits is that if you engineer all of your code correctly, and if you are writing kind of like very small units, you can actually really control costs. And because of the accessibility of cloud, you can give access to all of that, to the engineers on the ground. So not only are they learning how to develop applications, but they're also learning about what the impact of writing those applications correctly is in terms of cost. So it gives people a real 360 degree view of the entire impact of software engineering within the software engineering industry, and also the environmental impact. So the more kind of consumption of power you are using, the more impact it has on the environment. So within open source, because it's an open forum as well as an open space for people to collaborate in code, we can start talking about all of these different things. So we have a project where you're, a maintainer of that, and you provide a really great leading view on that group where we are building, infrastructures code, and we're using Terraform in order to construct services, within cloud service providers.

Eddie Knight (27:34)
Yeah. That's the biggest of our three pillars right now that we're focusing on.

James McLeod (27:39)
And so this is where it kind of like comes back to, people understanding the outcomes of people's actions in order to bring, costs down in order to be more efficient in order to write applications, like you were saying. So, cloud native first to do things properly rather than just pick things up and chuck, very inefficient applications onto a very expensive piece of cloud computing hardware. And so yeah, we're kind of like in that spot now with iNOS where people are asking the intricate kind of like questions rather than the big how do you contribute a pull request into a repay, which is really that's really exciting. Yeah, yeah. Five years ago we were at that point open source if you breathe there you were worried that somebody would reprimand you for even talking about it. We're beyond that point now where open source is here, and now we're talking about efficiencies.

Eddie Knight (28:44)
So how did we get here from the point that you were just talking about a minute ago where we'd get scolded for even talking about open source? How did we get to this point where we are today?

James McLeod (28:55)
Yeah, so we are lucky within FINOS. So let me start by saying that I joined FINOS, after FINOS was created, so it already existed. I'm not kind of like one of the first employees, within the foundation. I'm not gonna say that I've pioneered change, because change was already working its way through. But we are lucky that within FINOS a lot of the founding banks had pioneering engineering executives within the banks who knew kind of like the the pros of consuming open source and contributing to it, and really did fight within–inside their banks–to open themselves up using different policies in order to partake in conversations. So that's the first thing will your compliance team allow you to come onto a call and introduce yourself as a banking and engineer from a specific bank?

James McLeod (30:04)
Even that is a hurdle to jump. But there was like a, a collection of banks very big capital markets, banks that founded FINOS and so helped push this through from the front it wasn't an entire ground up exercise. I mean, when I was trying to get Lloyds into open source, we had air cover but we also needed to push very hard from the ground up in order for that air cover to recognize the advantages. But they were listening to us, which was like-

Eddie Knight (30:44)
Air cover like executive support.

James McLeod (30:47)
Yeah, absolutely. I mean, you need it because banks can be very hierarchical. I mean, it's great working in non-hierarchical organizations where the CTO is contributing, into a team the same way as somebody who's fresh out of university or a bootcamp is contributing. But there's hierarchies within banks. It's the way that they've been formed. They've been in the UK we've got banks that have been formed over hundreds of years and so you've got all of that culture and so you need people in leadership roles to kind of give you the support that you need within FINOS. Those people who provide that air cover and support and can open things up are the people who, founded FINOS. And so both them, and Gab, and the FINOS team were able to work together to communicate the benefits, but also enable the benefits through these platinum banks that we have within the foundation. And then the rest of it is by doing it highlighting it, doing more of it, and growing it that way. It's not easy. But over time, these things form, and things change once people start seeing and realizing the benefits.

Eddie Knight (32:09)
So now that we've got legal out of the way, cause we've got our executive support, there's more streamlining–there's processes and procedures. Is there anything left that complicates the process that makes it hard for bankers to contribute?

James McLeod (32:24)
Yeah, I mean there are there's still barriers. Namely the scale, the size of the banks. I remember being part of a massive bank where you think you're pioneering change and everybody knows about it, and then you realize that actually, your field of view. So, the landscape of the bank from what you see is limited. Because you've got engineers everywhere, either globally or across the United States, and there are CIOs, there are different divisions. There are different regions. Globally you think that you are making, yeah, you think that you're making massive headway, and then you realize that there's another team over there who has no visibility. But that's also where open source really helps because you can also be a beacon on the outside of your bank that everybody can see. So you're not trying to change things from the inside. You are kind of reflecting the change on the outside, and you can use platforms like podcasts, and conferences, and YouTube, webinars and stuff to communicate to everybody.

Kadi Grigg (33:41)
So I think that's a good point. I know we're coming up on time. So for those that are kind of new to this space, James, where would you recommend them start looking for interaction with other like-minded people, where they can sharpen their skills and ask these questions? Because at the end of the day, it is a little overwhelming right? In when you're kind of exploring these topics and finding the right partners or the right ideas that you should be following. So how do people get involved?

James McLeod (34:09)
Yeah, that is a really good question. So the very first place to go is our website, so finos.org, so it's a very friendly, business orientated website that will direct you to loads of different materials. So we have our news and events plus also we have a community calendar, where if there are project teams doing work, you can figure out the next time they're having a call. So you can jump on there. So finos.org will give you access to all of that. We have another website called the FINOS landscape, so landscape.finos.org. They'll give you a view of all of the different projects that we have within the foundation. So whether it's a code project, whether it's a special interest group or whether it's a standard, you can find all of these things on the landscape, on the FINOS landscape. Then on December the 8th in New York City, we've got the Open Source Finance Forum, which is one of two of our annual conferences that we run. We've already done our London one, which was in the summer this year.

Eddie Knight (35:20)
Actually, check this out. I've got the sticker right here.

James McLeod (35:22)
Yeah, absolutely. There we go. And the New York one is on the 8th of December. And one of the FINOS member benefits: so if your firm is a member of FINOS, you get a certain amount of tickets allocated to your firm. And so if you can get hold of one of those through your firm, you don't have to pay. You can just come and in September this year when we ran our London conference in London, we had over 300 people pass through the conference. We were expecting more than that in New York because it just, so, it's like a greater concentration of engineers in that area. And so that's a really great place to come and meet the FINOS team and all of the other banks, who are part of FINOS and doing open source.

Eddie Knight (36:11)
Actually, I'm really sad. I went to the Open Source and Finance Forum last year, so it had a different name at that time. I went last year and I was excited to come again this year because I saw the pictures. The venue that you guys have reserved for that is really, really, really cool looking. It's over near the World Trade Center area of New York, Manhattan. And I saw those pictures and I was just super, super, super bummed because I've got better things happening that week. We're actually expecting my first born–baby boy supposed to be coming that week if all goes according to plan unless he comes earlier. But that's what I'm gonna be doing instead of joining you guys that week.

James McLeod (37:01)
I certainly hope that you do have your baby. And that should be the better thing about that week, if I'm gonna be honest with you.

Kadi Grigg (37:08)
No kidding.

James McLeod (37:11)
We'll take some photos of the conference.

Eddie Knight (37:13)
Thanks guys. Thanks.

Eddie Knight (37:16)
But we would be remiss if we didn't mention the podcast that Gris hosts.

James McLeod (37:20)
Yeah, so that is the Open Source in Finance podcast that you'll be able to find across Spotify in different podcasting providers. We also run webinars that we record and put on the FINOS resource center. So: https://resources.finos.org/ There's just loads of different things that you can get involved. Just Google FINOS and you are bound to find one of us. We're on Twitter and LinkedIn, so FINOS Foundation on Twitter, and we've got a LinkedIn page that we just keep updated all of the time.

Kadi Grigg (37:56)
Well James, thank you so much. We'll make sure we post all the links to FINOS.org, the calendar, resources, landscape, so everyone at home can check it out. But thank you so much for taking the time to sit and chat with Eddie and I today.

Eddie Knight (38:08)
Yeah, it was a blast, James.

James McLeod (38:10)
Thank you very much for inviting me. I've really enjoyed being part of your podcast. Thank you.

Picture of Kadi Grigg

Written by Kadi Grigg

Kadi is passionate about the DevOps / DevSecOps community since her days of working with COBOL development and Mainframe solutions. At Sonatype, she collaborates with developers and security researchers and hosts Wicked Good Development, a podcast about the future of open source. When she's not ...