NatWest

Joining this episode is James McLeod, Open Source Program Lead at NatWest Group. He looks back on his career journey, from his role at the Linux Foundation, his efforts in scaling the FINOS project, to the creation of London.js. Reflecting on the many lessons throughout his professional life, James stressed the importance of proper data documentation and education to make open source more accessible to the public. He also explained what it takes for engineers to fully embrace their roles in the wider digital ecosystem, making open source an essential platform for career advancement and development.

---

Clock-Changing Bugs

Welcome back, everybody. I don't know about wherever you guys are listening from, but we're in the Northern Hemisphere in the UK here, which means the clocks have just gone back. Just to give everyone a bit of a time point, so that is the end of October. I despise the clocks going back for a number of reasons, but also because you get a really interesting class of bug that can occur when clocks go back. I'm going to welcome my guest, James McLeod. Welcome, James, and ask, before you introduce yourself, what is the most spurious clock-changing bug that you've experienced in your career?

Ben, thank you so much for inviting me onto the podcast. It's great to be here with everybody. That's actually a really good question. It's normally about this time of year when you catch the winter colds. It coincides with kids being on a half term and either coming in from the cold from school or going back to school. I think it's probably COVID around this time of year, if I'm going to be honest with you. That depends if we're talking about software-related bugs with the clocks going back.

I've hit a couple in my career where algorithms had been written assuming that time is always going forwards. There's a one-hour period of every year in the UK, at least, where that ceases to be the case.

I do have an example. It's probably less about algorithms, but it's more about open source and how you bring people together across multiple time zones. When I started leading and directing communities as part of the Linux Foundation, it was actually the first time that I'd started working with people outside of the UK, not necessarily in a firm. When I was working inside an enterprise, everybody kept to the same schedule, and everybody was revolving around the same instance of Google Calendar. As soon as you started moving outside of the enterprise into the more community-driven meetings, you found that if you didn't synchronize your calendars to a specific time zone, either people in New York would start arriving on calls an hour earlier or an hour later.

Maybe even maintaining a cause where you're bringing teams together in order to develop a specific project, they just wouldn't coordinate. It just wasn't necessarily an algorithmic issue, but it was a coordination issue. It was like, how do we anchor to a set time zone? When we put all of our meetings in, whether it's within the FinOS calendar or the CNCF calendar, everyone's targeting that one time zone. Everybody's calendars synchronize either backwards together. It was an absolute community nightmare.

It's funny. I did some consulting work for British Airways quite a while ago. If you ever mentioned anything outside of UTC in terms of a point in time, you were immediately taken aside and told this isn't how this organization works. Zulu is how they affectionately refer to it in that organization. You're, like, firmly thrashed, actually, because so much of that organization is what you can imagine. That was an interesting scenario, but I've hit a couple of bugs that have had entire platforms lock up because they weren't expecting time to go backwards, which, when you first consider it, is a seemingly reasonable assumption.

I've seen examples, probably not when it comes to systems experiencing unusual behaviors. I watched a TikTok the other day where a doctor was explaining that you could have two babies being born around the same period of actual time, one before the clocks. The one that's born after the clocks change is actually born an hour before the one that was. I can absolutely imagine if we don't standardize within our software from top to bottom, front end all the way through to the server, we're going to get all sorts of abnormal behaviors. I'm hoping that we're beyond that. I remember Y2K. I think if anything's going to teach us about dates and times and clocks, I'm pretty sure it's going to be Y2K, which a lot of people wouldn't remember.

‍

Career Journey

I started working in 1997. The consultancy I was working for was making fortunes doing that work. The thing that frustrates me is I wish that they would legislate against the clocks changing. I think there's talk in Europe about doing it. The frustrating thing is that they'd have to announce it probably 3 or 4 years before it actually happened because all of those systems that have automated clock changes would need to get patched. As I get older, I notice that things are getting dark at 4:30, becoming quite depressing. Anyway, let's talk about that. Do you want to just give a brief introduction about yourself, your career, and where you first touched open-source technology?

Yeah, absolutely. I'm James McLeod. I'm the open-source program lead in NatWest Group. As you've heard, talking about Y2K, I've been part of the industry for a pretty long time. I don't know whether people see the video, but I've got a long grey beard to provide as evidence to that fact. I graduated as a software engineer and went through all of the various different senior career steps leading up to becoming a director. I started my career not only in Y2K issues but actually in proprietary software. I started developing using Microsoft, loving the products. It was absolutely amazing. Visual Studio for C++ was absolutely amazing.

I've gone off rails on this podcast many a time lamenting Visual Studio and VB6. Let's not do that. Change the subject.

I just wanted to illustrate that was pre-open source, as we know it.

It was.

Very much so. Unless we fast forward just a little bit and get into Linux. Anyway, from a career point of view, I followed that path through .NET, probably up until around 2010, where I remember developing. Previously, everything was on the server, even the way that your websites were rendered, and information was being passed from the front end to the back end through HTTP or HTTPS.

There was a real shift in the way that things were developed as browsers developed, and you could actually run more complex applications on the front end. JavaScript wasn't just for validating forms, which it was pretty much at that point. I think my first introduction into open source was probably around the jQuery point, where that hit the scene, and you could start hitting the DOM in some really interesting ways that prior to that weren't necessarily heard of unless you were doing it to the DOM specifically. You had an intention to do that.

With jQuery being an open-source project, which is actually part of, and has been part of, the Linux Foundation for a while, that introduced me to this whole JavaScript front-to-back end. You could actually pass things all the way through your stack as JSON and even stop using relational SQL and start using NoSQL databases. With the introduction of Node.js, and then the transition away from jQuery, probably into Backbone at that point, it started shifting the narrative from “When's MSDN going to arrive?” “What’s the CDs?” “What's going to be included in tech?” I think it was TechNet.

That's right. Let's unpack that a little bit for those not as old as myself or James. Interestingly, when I started work in 1997, I was in IT consultancy. There was no internet on that LAN in that organization. There was no internet, and there was email, but you couldn't get the web. If you opened a web browser, everything was closed off. I remember there were a couple of fax lines, so all the phones were digital. You had to unplug the fax to plug your laptop modem, which came on a big PCMCIA card, and plug that into the fax machine. Then you could get a 33.6 kilobit internet connection, so you could actually work.

A lot of people my age, and James, you graduated a couple of years later than me, started their careers. Obviously, there was no Google, there was very little internet. I'd forgotten about that. Your organization would have a subscription to the Microsoft Developer Network. You'd get, what was it, like every six months or every year, a ton of CDs, dozens. They would have SQL Server on there. All sorts of stuff, like I remember Visual Source Safe blowing my mind. You'd wait for them. All the documentation came on those as well. Your update cycle was basically waiting for those CDs, wasn't it?

It was. It was every six months you had a visit from Microsoft. They were bringing you gifts. For me, it was a bit of an exciting time. It was the equivalent of being able to go onto GitHub, clone a repo, and get something up and running in Kubernetes. It was like a containerized experience, but in the early 2000s but then, because we weren't being handheld around a proprietary product, with all of this information being given to us on CDs and maybe online as the world moved forward, we had to think about how we actually taught each other.

When you go from a proprietary world, where everything is given to you, into an open-source world, where everything is being developed by people across the globe, the documentation and the education are also decentralized as well. As part of that transition for me, from proprietary software engineer to open-source engineer, it was like a massive paradigm shift. I remember it around the 2010 era, going from an introverted software engineer to becoming a more awkwardly introverted software engineer, who had to go out and find people in order to get help and help each other along. That's it, then. That was a bit of a verbose answer. That's my transition from one state into another.

When you go from a proprietary world where everything is given to you, to an open-source world where everything is developed by people across the globe, you have to make some major adjustments.

You've had an interesting career. There's some agency life in there as well. You were tweeting from 2009 to 2017, and then you went into UK banking. NatWest, for those that don't know, is a large consumer and business bank with a number of sub-brands as well. It's one of the big five in the UK.

That's right. People would know it as a retail bank, but it does also have capital markets attached to it as well, and because it's a group, just in the same way as Lloyd's Banking Group is a group, as Ben said, it does actually contain lots of different brands within it. People may have a banking relationship with NatWest, but from one of our different brands. As you pointed out, I have had a varied career as well that's gone from working at a tech startup when I first graduated, dabbling in the gaming industry at one point, and then moving into the BBC and ITV for a couple of stints, and then moving into consultancy on a brand stream rather than the banking stream. It's really interesting, so there is a reason for that. I went to university at a place that was very 50/50 creative straight technology. That really mattered, and I was always hanging out with designers, and my engagement around software has always been with the customer on the front end and how we can actually engage with people and bring them through.

That probably translates into the reason why I'm really interested in open source as well but because I was on a very fun degree, and because the people who I was in all of my various different lectures with and doing work together were designers and had a very creative feel about them. I thought, “I'm going to go into the gaming industry.” That resonates with the type of person who I am, but in order to get into there, I had to pick up my first role, which was in telecommunications. I maneuvered myself into working for 1 or 2 gaming companies, not as a games developer, but it was more e-commerce related. From there, it was around the time when Macromedia Flash, funnily enough, was creating all of the interaction on the front end. If you needed high-fidelity front end in your browser, people were using Flash because you couldn't do it using JavaScript and the canvas we have within HTML and JavaScript.

I started working for ITV on I'm a Celebrity Get Me Out of Here, just doing live video streams and really figuring out how to engage the customer in a really fun way. I was in my early 20s. Thinking about my career beyond having fun wasn't in the front of my mind. I just wanted to go out and do some really great stuff, and that then pulled me into the consultancy industry, where I started working for brands like Starbucks and Duracell and Ray-Ban and a few others, Fiesta and Land Rover, on some real interactive types of development. Still very consumer-engaging.

Also, it was the growth of social media. A lot of the work that I did engaged customers through social media campaigns. It was around the time when engineering teams weren't necessarily around one table. My career went from everyone sitting together in one room to everyone being distributed across regions, and that really intrigued me. I started developing e-commerce systems for big consumer brands, where I would be in the UK and the development team would be across Europe and also across India. Just in the same way as my open-source hat that I wear brings me together with people, it also allows me to manage teams across time zones. That was my first entry point into that, managing consumer e-commerce and consumer brands' campaigns with people all over the world.

Technology was evolving, as well as the way that we work together across regions. We started using automation. We started engaging using GitHub and using open source. People were looking for efficiencies in the way that we communicated. Rather than everyone being together around a single telephone, talking to each other in the morning and then at the end of the day, people started working asynchronously using issues and pull requests and merge requests.

Somebody said, “Do you fancy joining the banking industry?” because there's a whole digital transformation program going on, and they need some new ideas. That sounds like a challenge. That's where there was a jumping point between how all of this fun, customer-engaging work that I was doing, that came in parallel with the changes in the way that we engage with people across multiple different time zones and regions, came into the banking industry that was going from very manual engineering into something that needs to be more asynchronous, more lean, more efficient, and more automated. That's what brings me into open source, really, within the financial services industry.

FINOS And the Linux Foundation

You also spent four years working at the Linux Foundation as well as communications director at FinOS. Do you want to talk a little bit about that experience? I'm really interested to know how it was working within an organization like that and what your goals were within that role? Because I've always found these foundations curious, the same with the CNCF and stuff. Never quite sure if they're large or small. Just talk a little bit about what your role was, and I'm especially interested to know what targets you had within that role.

I think we need to also answer the question of what actually brought me into that role. Prior to working in the Linux Foundation, I spent time as an engineering lead in Lloyds Banking Group. As an engineering lead in Lloyds Banking Group, I was part of their engineering transformation program, where all of the engineers within Lloyds were distributed across the UK. It's an absolutely massive enterprise. Plus, also, there were people who were engineering internationally as well because of my open-source background, running meetups and bringing people together, we thought, as part of that engineering transformation initiative, we would also create communities.

I wasn't the only person within Lloyds doing this. There are other people there. They've got some great community leads within the bank. What we needed to do was bring people together around their engineering disciplines where maybe they hadn't met before, and figure things out across the top to tail of the UK, where people were siloed previously in just 1, 2, or 3 feature teams together. That got me into certain conferences to talk about that effort.

The purpose of speaking at conferences is that you're talking to industry and you're also talking to the enterprise that you're working within as well because it has great reach. Through all of that type of work, I actually met the Linux Foundation at an event. I was invited to come and join them because open source and financial services didn't really meet because of the regulatory, it's not necessarily a stipulation. I think it's more of a belief that banks can't get involved in open source.

‍

I was on the open-source circuit running a meetup and talking about this stuff. They said, “We would like you to join FINOS.” At that point, FinOS was actually an independent non-profit, not part of the LF. I joined FinOS when it was not part of the LF. FinOS is the FinTech Open Source Foundation. We were acquired by the Linux Foundation maybe a year later. We became part of the wider Linux Foundation family with CNCF, Hyperledger, Node.js Foundation, Open Source Security Foundation, and others. That's my move into there.

I've always been a very community-engineering-orientated person. I've been running LondonJS, which I'm sure we'll talk about later, for a long time. Knowing that the Linux Foundation is super niche, if you're talking about inner circles of people in open source and a place to learn, the Linux Foundation is a place to learn. I thought, “I'm going to give it a shot.” I'm never going to get the opportunity to do the thing that I love within the Linux Foundation and be able to learn from them in order to really hone my craft.

I joined FinOS as the director of community, which was an engineering role, but it was bringing maintainers and engineers together around FinOS projects. That also introduced me to the wider Linux Foundation engineering team that I was also part of as well. I was there to scale it, bring more people in, build more projects, get them consumed and adopted. Also, maybe look at the way that people are actually working together. It's not necessarily an organic scrum, but there is process that welcomes people in. Also, in the way that projects are actually run as well. There was a lot more to it than that, but I'm sure that'll come out in the conversations that we have, Ben. I don't want to be hogging the mic for too long.

Does FinOS actually see engineers and teams across different competing organizations working together on things? Is that the panacea for them to understand? Because a lot of other industries and verticals have gone through that process. Tech realized that there's a huge amount of benefit from open sourcing, like mega frameworks, like React or Kubernetes or whatever. Do you think the penny's dropped in financial services in that regard, or do you think there's still some way to go?

I think that it has. There are lots of different types of projects that you can have. Within an open-source organization, you can have the projects where you are creating a system. Within FinOS, there's a project called Waltz that was contributed into FinOS by Deutsche Bank, and has been contributed into as well by NatWest. The purpose of that project, it's like a software project written in JavaScript, I believe, with maybe, I think, they moved towards Vue on the front end, is basically there to gather information about your information architecture and all of the libraries and other assets that are contained within your enterprise. You can see where different parts of your engineering system join together. It tells you about certificates and when certificates are about to expire.

Just like the world around you, you can only see as far as you can see, you can't necessarily see over the horizon. Waltz is a very crowdsourcing way to really get a map of the way that your architecture's joined together within your organization. It's very popular. It's been a really good contribution to FinOS. It's also been very helpful to other organizations, but that is a software project, it's almost like a monolith that you bring in. The other types of projects, which are actually really valuable, are standards. Within FinOS, they have a project called FTC3, which is an interoperability standard that defines how financial objects are actually passed, primarily across a trading desktop, between competitive organizational software.

I don't know if you've ever seen pictures inside Wall Street or in the London Stock Exchange of traders with multiple different monitors, and there's lots of charts and graphs and information and tickers that they're looking at. It might be a Getty image, but actually, the scenario is true. There are traders there with lots of information, but each of those panels are pieces of real estate that are provided by lots of different competing firms. The information that they draw from is generally unified, and it's actually really useful if it can be passed from one competing piece of software to the next.

The way that standards, and specifically in the FTC3 scenario, help is that the standard defines how the information is packaged and passed, even between competing vendors who are reliant on each other to pass that information from one to the other. They can compete on the value or the engagement of their software outside of that standard. There are lots of scenarios. Outside of FTC3, there's the common domain model, which defines how financial objects look and are constructed, maybe in your information architecture and taxonomy.

If the financial services industry adheres to that, everyone's describing things in similar ways. There's no additional effort needed passing information around because everyone's standardized, even if the data that is held within those structures is competing. Having those types of standards is actually really important. FinOS has a couple, CDM and FTC3 are a couple that I can think of. There's another one called Calm, which is the way that architectures are described using, I'm going to say something like JSON, but it might be different.

A structured data format.

Rather than using Vimeo diagrams, it's like architecture as code rather than having lots of lines and arrows. You can ingest it and do stuff with it.

Setting Standards

Specifically, what aspects of those standards are being discussed and ratified in an open-source manner? What's the benefit from that as opposed to what would have happened, like pre-FinOS? What would have happened there? There wouldn't have been a standard, or it would have taken a lot longer to become the de facto?

You would have had, if you're lucky, maybe some APIs opened up where you could call for something through that API. Maybe the way that the data is passed to you doesn't quite conform with the way that you are describing that data, a little bit like what we were talking about at the top of this around date formats. If people can standardize on one particular way of passing data around, it means that you don't have to transform things, and the margins of error reduce.

Previously, people would be calling for information and then transforming it in some way into the way that they use that data. I don't know if errors were being made, I assume maybe some errors might have been made in the way that the data is being represented once it's been transformed from one format to another. Hopefully, if it's not that, maybe it's reducing friction but definitely, data has been transformed from one to the next.

It could be that some use cases that people would have thought would be really valuable might not have been possible. People talk about buy side and sell side banks working together, but I know that it hasn't necessarily always been possible to get data from a buy side into a sell side for whatever reason. I don't know. I've not really worked in a scenario where it wouldn't be possible, but I know the FTC3 and the common domain model have made it a lot easier for those types of organizations to engage and interact now. It could be from the small, how do I transform this piece of information, to the big, we've just removed a load of blockers and silos that allows things to happen.

London.js

Just moving on to LondonJS. It's been interesting. You've been involved in bringing people together for what sounds like most of your career. Do you want to talk about what things you've learned in terms of how to successfully do that? For people who are thinking about trying to start a local community group or something? What are the three most valuable lessons you've learned running something like a large one of those in London?

The first one is just bring people together no matter where it is. I think you can start out thinking that you're going to start a meetup and you're going to have 100 people turn up. You could throw the dice and that could happen, but generally, you'll start a meetup and maybe three people will turn up. That's what happened when we first started. We weren't always LondonJS. We started as a React meetup. When we were learning React together, I think it was me plus a couple of people who I knew came together to do it.

What we decided was that we would keep the meetup going and almost enact that there were 100 people there. It's going to sound really weird. It was almost like we were play-acting. Even if five people were there, we would do our decks. We would present, we would demonstrate the same value as we would do to an audience that was bigger. We would keep on going. It's almost like we would practice whilst the audiences were small. Iterate and iterate and iterate, and ask people to invite a friend the next time.

We would find mechanisms for keeping the community involved as well. We came up with a rule that, it wasn't a hard rule, it was a very soft rule. Everything in London.js is actually really soft rather than hard, fast rules. We wanted it to be a meetup for the community and for people to learn. That also included public speaking as well. If a member of the community said, "I'd really like to learn how to present," we would always invite them in to do that and say, "Come up with something that you want to present and maybe we'll give you a lightning talk so you can come, do it, try it out, and learn something new."

It was a very community feel. We always said, it doesn't matter if you fail, live demos go wrong, and everybody in the community here is there to support you. It's really important that the community feels like they're part of it, rather than a meetup which is there for the heroes. I think the reason that I felt like that is because sometimes the open-source community is actually really difficult to get into. You can feel that there's a bit of imposter syndrome that goes with it.

Sometimes, the open-source community is difficult to get into. You can feel the imposter syndrome that goes with it.

Breaking The Boundaries

I think there's more than a bit. I think I've noticed that. It's like you see the output of some people who are probably the 0.01% on GitHub or whatever, and you look at their code, and it's just like savant genius-level code. Then you look at what they've created, and they've done like five things that you've heard of, and then another three that you haven't but look really cool. There's only a very small number of those people on GitHub, but because of the nature of what it is, you look at those people and they're your yardstick. I think probably, for the other 99% of the people involving themselves in open source, apart from the psychopaths, they probably all have a healthy dose of it. I do think it's a really important thing to call out. How did you go about trying to break that door down?

Sometimes it takes a little while to find your niche within the open-source community. I thought, I really recognized where I had my own personal fears, but I also knew that I was really compelled to do it. I knew that I wanted to be an open-source contributor, but there was something holding me back from being able to do it. I think it was the imposter syndrome, as you described, because there's loads of amazing people contributing great things that everybody uses. I found that quite compelling.

I thought, if I'm finding it difficult entering those communities, because at that point React was being developed by Facebook or Meta, and it was very difficult to get in on that because they were maintaining it and their barrier to entry was actually really high because their standards are really high, as you can imagine, I thought, I'm going to create my own answer to this problem and start my own meetup, where I can teach myself how to engage with others and teach myself how to bring people together and start feeling confident about what it is that I'm doing.

Recognizing that other people are probably feeling the same, I just started learning using that iterative approach, rather than trying to muscle in or get accepted into somebody else's community. I'll just start my own, and if people like it, they like it. If they don't, they don't. It went from there. I was looking around the various different JavaScript communities. I was looking at React. I was looking at Docusaurus. There were some various other React-related projects that were being maintained from the West Coast. I think React was probably the only one that was really London-based. Everything else was coming out of San Francisco. That didn't really help me until I really found my niche within financial services.

I don't know what it was. There was just something there. I can relate to it around engineering transformation. I think what the message is, keep on persisting, because if you go on that exploration, you will find where your community lies, and it may not be in the place where you think it is. You've just got to keep looking for it. If I answer the top three for building a meetup, I would say, start it, and it doesn't matter where it is. It can be around the table of a pub, but actually, we asked the place where I was working if we could use a room, and they said yeah, so we did it in there.

Keep the meetup going no matter how many people arrive, and always pretend that you are presenting to a larger audience. The third one is make sure there is a community meetup. It's not for you to download onto people. It's for you to invite people in and for them to get involved. Maybe get a couple of other organizers and start spreading it around and inviting other people to share on it.

I went to LondonJS six weeks ago for the first time. I was lazy. It was literally down the road from my office. The one thing that struck me immediately when I walked through the door, it wasn't just young white guys there. There were a lot of students. There were a lot of people from different ethnic backgrounds and stuff. It was immediately noticeable. You go to these things and it's 98% young white guys. How did you do that? Did you bake a lot of thinking into things around that initially that have then started to show up in that experience?

Yeah. It hasn't always been like this. I'm not going to pretend from day zero we've always been fully inclusive. We've always invited people in no matter who you are, where you're from, and no matter what your gender or orientation is. We've always been very inclusive and very welcoming, even from the mid-2014 or 2015 when it started. Even then, we found that the real path into software engineering was a graduate route. We found that it would generally be guys who were showing up at the meetups predominantly. We did have women in tech there, but the population was generally men. Around COVID, COVID was devastating for most meetups anyway. We managed to keep the lights on somehow. I don't know how. It was really hard. The motivations were really difficult. The two-meter distancing really hurt us. There was a real switch in COVID.

Number one, over COVID, I was at the Linux Foundation. We were very mindful about how we brought people into our events. Within FinOS, we really did have a 50/50 gender DEI mix within the team. It brought to life how valuable having a team around you that is to diversity of thought and everything else that you do. That imprinted itself on me because, even though we were working remotely, we were working together very closely because they were basically the people who you engage with daily. It was COVID. We were talking to each other as colleagues and also as friends. When we came out of lockdown and LondonJS started, there was a real switch in the way that people were learning. There are a lot more boot campers coming into the JavaScript community. There are people who are learning or switching careers, going from knowing that they didn't feel fulfilled in their current career and they wanted to try something new. That whole coming out of university as a graduate into a career had swapped.

We have a huge community of people who have come up with lots of different ways to educate themselves around JavaScript into LondonJS, wanting to know how they can move forward, and it's absolutely amazing. I don't know if that's because of COVID or whether it would have happened anyway, but the way that people are introducing themselves into engineering and development is a lot different to the way that it was maybe 5 or 6 years ago. It really does back towards one of the strengths of open source because that's one of the inclusivity drivers around open source. We invite people in, and we educate and get people involved in things. When we are organizing speakers and the agenda around LondonJS, we often, and where we can, try to have a non-technical talk. We'll be talking about a personal experience.

Generally, it's not always women. We had one around self-help, and it was actually for men, issues that affect men in the same way as you would have people talking about issues that affect women. We generally have something that's outside of JavaScript or something that has enabled somebody to do something. It's a real D, E, and I driver.

I do think it's interesting. I hadn't considered this with regards to COVID, but I do remember it being noticeable, especially when you were hiring engineers in London, maybe starting 7 or 8 years ago, where you were starting to get a very small sample of CVs from folk who had gone through a bootcamp. I think open source was transformative there because, obviously, maybe they've been working in a completely unrelated field, but then you'd see they've started this open source project or contributed some portion of code to an existing one.

You don't need to pass an interview to get a pull request merged, over a certain level of quality and whatnot. It's interesting around COVID whether, I think possibly, that has accelerated things because it's not out of the ordinary to get a CV from someone who maybe hasn't had any formal training in computer science or software engineering or electronic engineering, or maybe even maths or physics or something. They haven't had a professional job as an engineer in any way either, but they've got a GitHub that sings. If you're trying to hire someone, that immediately leaps off the page. I think that's great actually. It seems unparalleled in any other industry, the fact that you can do that, and you literally, all you need is a laptop, an internet connection, and some time and commitment, is great.

I noticed at the LondonJS event that I've attended, a lot of really enthusiastic people who'd just finished courses or degrees and were looking to get their first job or whatever. I think sometimes they fall into the trap of being an intellectual whipping contest, who can talk about the most hardcore esoteric engineering thing in the weirdest language that most people have never heard of and all this stuff, which is, for 90%, 80% of people, the opposite of what you want to spend an evening hearing about.

Open source isn't a solitary thing. I think you can come into it thinking, “I'm going to be working on my own in a dark bedroom with my curtains closed, raising a pull request against a solitary repo,” but it's not like that at all. It's actually a good way to set a level amongst peers that may be either more experienced or less experienced than yourselves. LondonJS is one example, but if you go on to any of the working groups that are advertised on FinOS or the Linux Foundation, where people are coming together on Zoom, it's a good way for you to mingle with executives as well as other engineers and share ideas amongst that community.

Open source is a good way to level set among your peers. They may be either more or less experienced than yourself.

The alternative to that is trying to rock up at the door and knock on it, or try and get an appointment into somebody's calendar. Just being able to work together or communicate with each other in a meetup, on a working group call, or asynchronously in a GitHub issue or on a pull request in the comments, it just brings opinion together, and you leave grade and hierarchy at the door. That allows you to network, and that's how you build connections and get an inroad into your next career. I can speak for a long time on DE&I. It's actually something that I've got a lot of opinions about, that open source is a great way to bring people in. But we also need to offer the opportunity to people as well, not allow people to be in technology poverty. That's a different conversation, but open source allows the entry. We've just got to allow people to see it, welcome people in, or give them the tools to be able to join.

Do you think that the tooling around that is getting better, or do you think it could be improved in that context?

I think that when you've got workspaces that are linked to containers that are being run through GitHub and, say, GitLab, I think that that does open it up. Rather than people needing a certain spec of machine in order to run a certain IDE or environment, if you can push that into the cloud so everything that you're running is thin, I think that opens it up. I also work with a couple of people in Uganda and Ghana, where actually it's connectivity to the internet that is the biggest issue. There are lots of different points of view on this. I do think that technology in general is starting to answer those questions. Dev workspaces and code spaces, maybe even, I don't know how Co-pilot or GitLab Duo would answer that question, but containers for sure, and the cloud for sure.

Episode Wrap-up

Cool. Just curious to know, as we wrap up, have you got any specific goals that you're looking to achieve next year? What's in your head at the moment?

Yeah. Scaling the open-source program office at NatWest. I'm bringing a couple of principal engineers into the team, which is really exciting. Then, being able to engage more externally in the open-source environment and bring more engineers from NatWest out into the open to be contributing into not just FinOS, but maybe across the wider spectrum of open source as well. Every financial services institution has safety on the forefront of our minds. Engaging in maybe some of the security working groups or the security projects and bringing what we've learned into the open, and what others have learned back into the bank, that is also there as well. Being a security-first, open-source contributing and consuming team.

‍

Interesting. From the context of FinOS, the security aspect is something that I still think a lot of projects don't address. For completely understandable reasons, almost always for the reasons of time and money, they see it as a light add-on at the end if you can manage it. But I actually do think the tooling around that is getting much better, like with Flagsmith, waking up, seeing that there's a severe vulnerability in a library dependency that the platform has. Thirty minutes before, Dependabot’s done a pull request, tested all your code, everything's green, there are no spec changes.

You can just bring it in, deploy into production, and do that before you've even got out of bed. Thinking about how things were when we were getting the MSDN CDs, which might've meant getting in your car and going somewhere at the most extreme level, there's definitely things getting better there. I think when security is at the level of a core fundamental in the same way that latency is or performance is, that's when I’ll feel a bit more comfortable as it is. But it feels like there will be six global headline-level events next year, like it's nailed on.

I think the way to mitigate against that is for all engineers to understand their relationship with open source and maybe the wider engineering ecosystem. It's not necessarily just about the code that you're writing in your IDEs, but it's also what your connection is to the wider ecosystem of engineering, what that can be to you and what you can do to it. Talking about Dependabot, understanding the software bill of materials, and how that is described, and how you can traverse it, but then how you can describe your own software using the standards that are provided across OpenChain, and also across SPDX maybe. That's what I'm going to be doing, really immersing ourselves in that. All of the engineers that surround me, for them to be really thinking about that as well.

That's great to hear. James, thanks so much for your time. It's been a fascinating hour. Look forward to maybe bumping into you and having a beer and a slice of medium-temperature pizza sometime next year.

Nice one, Ben. Thank you for inviting me. It's been a great pleasure.

Awesome. Thanks.

Next Steps

• London.js
• FINOS
• FINOS episode on The Craft of Open Source

‍