 Hello, everybody. My name is Maria. Welcome to our talk. I hope you guys are not too sleepy after lunch. So let me do a pre-talk poll. Do we have any developers in the audience? Okay. Awesome. And have any of you guys contributed to open source in the last year? Okay. Did any of you guys tell your boss that you contributed to open source? Okay. Okay. We got some good risk adverse people in the audience. Perfect. So our talk is going to be about navigating open source contributions in the financial industry. And yes, this title is based on the Tina Turner movie. Angela did deserve that Oscar. You can argue with the wall. So just a little bit about who we are. I'm Maria. I'm a developer advocate. And I am the contributor experience special interest group lead at Spinnaker. And both Matt and our Marvel fans and dog parents. My dog is on the bottom left. His name is Malcolm X. This is a picture of him sleeping, which he rarely does anymore. Matt. My name is Matt Goagley. I'm an associate software engineer at JP Morgan Chase. I've been working on a Spinnaker project since I joined. I'm also now on the technical oversight committee for Spinnaker. And my dog is down on the bottom right. She's called Thea. All right. So today we're just going to be talking about four main things. We're going to be talking about the community perspective for open source contributions. JP Morgan Chase and open source, the enterprise perspective and managing risk when it comes to open source contributions. So I'm going to tell you about the community perspective because I am not an enterprise employee or person. So I can only tell you about the community perspective. So these are three main reasons on why do open source communities need financial enterprises. So number one is star power. So financial institutions have a huge pool of talented engineers that we need as open source communities to keep them running. We need the best and the brightest with their ideas, their passion to be to fuel open source because at its core it's about community. And we want rock stars like Matt on our side. Additionally, with their experience, they're able to mentor lots of new people who are in the open source community because a lot of people use open source contributions as their first step to getting into tech. So having that mentorship and that expertise guiding them along the way will make open source communities stronger. Number two, complex use cases. So one interesting thing about the financial industry is that they have a unique problem of needing security, scalability, speed and compliance all at once. And that's a really rare thing. And it forces open source communities to be able to handle that. And if they, and through that complexity, the open source communities are able to grow and be resilient in this ever changing landscape. And number three, developers like Cloud and banks always for the past, I don't know, 100 years have been a very strong place to put your name on. So by having a name like JP Morgan or Morgan Stanley behind your open source project, you can attract more developers to that pool of people and get more people contributing to your open source project. So here's just a little Spinnaker 101. Spinnaker came out of Netflix in 2015. Oh my gosh, that's a long time ago. 2015. It's an open source continuous delivery software. So for my non technical audience members, just it means automating the deployment step of the software delivery life cycle. And it's a cloud agnostic open source software. So I'd like to put it Spinnaker is like an airfire. You can just throw anything in there and it works. So that's one of the reasons why JP Morgan uses that. So just the Spinnaker community at a glance. So since 2015, it's now being used by over 50 organizations globally. It has over 14,000 Slack members and it's up to 10 million deployments a month, which is a lot of deployments. Cool. So just a quick introduction to my journey with open source and Spinnaker. So I joined JP Morgan back in 2019. As I said, I've been working on the Spinnaker project since then. Back in June 2021, I got approval to contribute to the Spinnaker project open source. And since then, it says here 300 plus contributions. I have no idea how many it actually is. But code, pull request reviews and issue triage in the Spinnaker project. Also kind of the main the main thing I've been doing is working on issues that we've identified internally in JPMC. So obviously, as Maria said, financial enterprises bring a lot of unique use cases to open source projects. And it's not necessarily the case that Netflix were thinking about what JP Morgan Chase might use Spinnaker for back in 2013 or whenever they started working on it. So a lot of what I've been doing since then is working on issues that we found regarding scale and so on internally. This year back in June, I was voted the most valuable contributor for 2022. And in September, I was appointed to the technical oversight committee for Spinnaker. So just a really quick 10,000 feet whistle stop tour of JP Morgan Chase and open source. So for those that don't know, JPMC are on the board of Finos. I'm also a Plaster member. So we have a couple of employees who are on the board. I can see one in the audience right now. So we we have a lot of open source projects. So I'd encourage you to check out at JP Morgan Chase on GitHub. One example I wanted to highlight is one that we actually donated to Finos, which is called Perspective. Perspective is basically a front end kind of component that handles the analytics data visualization. So that was donated. And it was born out of JPMC. And just in general, JPMC have been a long time supporter of open source. So where does Spinnaker fit into JPMC? So as Maria mentioned, Spinnaker is a continuous delivery platform. A lot of banks and companies, JP Morgan including are included are looking at public cloud as the future of platform for deploying applications. And because Spinnaker is cloud agnostic, we've really positioned it as the key tool for deploying to public cloud. Obviously, given the number of applications in JP Morgan, that's quite a big undertaking. So scale is really what we're focused on with Spinnaker. And our key objective really is to reduce deployment times for developers and reduce risk, right? So, you know, historically developers would commit all their changes and then they'd have to go through the whole approval process of being allowed to release everything. They have to get a change record. They have to justify what they're doing. They've got to evidence all their testing, all that kind of stuff. And it's all manual, right? And it takes forever. So that really stops developers from wanting to do changes for minor things, right? So if I've changed one line in my application, I'm not going to bother going and opening a change record, getting all the approvals for it and sign off just to release that one thing because it's complete waste of time. So instead, what I'd do is I'd bunch up all of my changes into one big change and then I'd release it. And then it would break and I'd have to roll it back and start again from the beginning, right? So what we want to do with Spinnaker and continuous delivery in general is encourage developers to release changes smaller, right? So we want developers to make one line code change and they would commit it and it goes end to end to production. They don't have to touch it at all, ideally. And if there's an issue, it rolls back automatically. No developer insight required. And that's really what this last bullet point is, improving safety through built-in deployment strategies, right? So Spinnaker supports various different deployment strategies natively. So blue, green, canary, rolling deployments, all that kind of thing. And we really want to leverage that within JPMC to reduce risk. So what's the enterprise perspective on contributing to open source? Well, there's quite a few key benefits, right, of having your developers able to contribute. Sorry, one thing. And there's a difference between using open source and contributing. So before we continue, so a lot of enterprises already use open source software, but they're not really actively contributing to the project. They're just sort of like, I'm going to use Spinnaker because it looks cool. And we're not going to do anything to improve the code changes. But what we're asking people and enterprises to do is to actually be a part of that development cycle. So just that clarification. Definitely. So, like, as I said, the key benefits for contributing to open source are kind of on this slide, right? But the most obvious one is that you're not relying on the open source community as a whole to fix things that you've found or implement new features that you want for your company, right? You have to remember that a lot of these communities are made up entirely of volunteers. They often work on the evenings and the weekends to develop these things. So if you're a huge company, huge bank rocks up with a GitHub issue saying we want X, Y and Z, it's presumptuous to assume that they're going to deliver that anytime soon, if at all. So by having your developers approved to contribute back, they can put it into their own hands, right? They can build what your company needs without relying on third parties. You also get a deeper understanding of how the tech works, right? So the Spinnaker team at JPMC, Spinnaker is quite a large system to operate. It has multiple different services. They're all interconnected. They all communicate with each other, and it can be difficult at times to figure out what exactly has gone wrong when something goes wrong. So by having people who are familiar with the code base and open source, they're more confident to dig into issues in GitHub, dig through the code, try and figure out where something might have broken. And that means we can give feedback to our users a lot quicker if something goes wrong, right? And then there's also the obvious, you know, these large open source communities, they've got thousands of people working on them. If your company is contributing to open source, that gets your name out there, and it means you have exposure to recruit from that pool of talent. Cool. So open source participation in a regulated environment like finance is an interesting one, right? What usually happens is leadership are very keen to encourage people to contribute to open source. They'll tell you that they want you to contribute to open source, and then you'll ask them, hey, I want to go and contribute to Spinnaker. And what usually happens is they'll say, great, now what? And you don't know, they don't know, and it kind of dies out there, right? Or they do know what you need to do next, but then the process is a mess, and it requires three months worth of approvals and form filling. Nobody can be bothered to do it, and it kind of fizzles out, and it never goes anywhere. So how do we solve this, right? So how do we manage, you know, the issues that Matt brought up? How do we manage risk? And first, let's see the data. So thank you so much, Finna, for your free data set. Thank you so much. You've helped me so much in this process. I don't have to gather this myself. So when asked, where do you think your employer should provide greater support to make additional investments to improve the use of open source in your organization? So the top two answers were based on training and the process of contributing and consuming open source software. So like Matt said, nobody really knows how we should handle it. And number two, like what do you think limits your employer's open source investments and discourages contribution? So the top two concerns were fear of leaking IP and legal and licensing concerns. So it's obviously in the back of people's minds that they're worried about, you know, privacy and security when it comes to open source contributions. So how do we fix that? So I mean the answer is kind of obvious, right? The answer is you need a streamlined robust process that any developer can follow that doesn't take months to complete because a developer's attention span is short. And if your process takes more than a few days or a few weeks, they're not going to bother. I know I certainly wouldn't So basically you need to develop a process where technical and legal experts are involved and it says low touch is possible for the person actually trying to apply, right? You want to abstract all of the different approvals and things away from the developer because the developer doesn't necessarily care about license agreements and contribution license agreements and IP and copyright and all that kind of thing, right? They just want to commit code to this project to fix the thing that's annoying them. So if you can develop a process where they can go and they can follow it step by step easily, then you're going to remove that barrier from entry, right? And the other thing is really guidelines on what is and isn't allowed, right? So one of the things Maria mentioned on the previous slide was people are worried about leaking IP or breaking the rules and then getting caught up in it, right? So you really need to be clear about what is and isn't allowed when you're contributing. So, you know, if there's a gray area, one of two things is going to happen, right? They're either going to go for it and not ask permission and then you'll have the consequences or they won't bother and neither of those is good, right? Because you want people to contribute. And as an example guideline for that, right? Self governance is kind of the obvious step, right? So internal code reviews. So rather than just letting your developers have free reign to push whatever they want to GitHub and open pull requests, it's probably a good idea to have like some policy where they need to get their code reviewed by team as they normally would in their normal day-to-day. Ideally that team member would also be approved to contribute to the project. Really is just a really basic safety buffer, right? So they're not pushing out random stuff that could cause issues. So, in conclusion, open source is here to say and it's up to you to keep up with the times and open source contributions can be done safely without risk to your company with relatively low lift and open source contribution will also allow you to have like a bigger say on like what goes on behind you know behind the doors, like if you really want a certain feature on it, it's up to you to jump in the front of the queue. And lastly, as we can all we've all learned today that open source will lead to increased developer productivity and large cost savings overall. So here's our call to action. Avoid ambiguity when you're talking to your developers about what they can and cannot do in open source and for developers start a conversation about what projects you're interested in so you can get this thing going and be you know preventative instead of reactionary and advocate for your ideal approval process. I'm not just saying this as a developer advocate title. Everybody has the power to you know make their ideal process and if you don't say anything close mouths don't get fed. And for managers, pull your development team on their interest in open source contributions so you can get this going and start a conversation with compliance about open source contribution approval processes. We actually had a great lunch with a compliance person so they're not scary. It's it's pretty simple and you can really start that process and if you make it once you're going to save a lot of time and heartache in the end. So after this you can reach out to us so if you're looking to improve your deployment process and start contributing to a trusted open source community you can come join us on Spinnaker Slack. If you have more questions about joining other open source communities that make more sense for your company you can follow me on Twitter or you can send us a ping on Spinnaker Slack. So any questions? Yeah I mean it definitely makes sense right? There's no risk of IP leakage if you're just doing like a version bump in your project. Where it gets difficult is how do you track what a change was right? So it's all very well the developer saying they're only going to make changes to POM files in this project. How do you actually make sure that that's all they're doing? Obviously in finance everything is audited so you know they'll get caught eventually but you want to be proactive about that right? You see that? That's open source at work. Thank you. Any other questions? That sounds like a question for the Finos data keepers and that could be a really interesting experience I can't even talk experiment but honestly I would like to say it like just in terms of like engineering hours and then you can translate it there so if you can think about like okay how much time would this feature take me to do in-house so like let's say it's like a you know it'll take me three months and then you can do the engineering hours and then you can compare it to okay just finding an open source project that already has it and then doing a fraction of those engineering hours to almost modifying it for your company so you can think of it that way to do dollar amounts. Yeah I mean like I don't track dollar amounts personally personally I try how much frustration it's reduced for me to being able to just fix something rather than reporting it and then waiting nine months for it to be fixed. I'm sure someone at JPMC is tracking that but that's somewhere way above where I to be worrying about that. One day I'll care. All right any other questions? Thank you. All right thank you everybody.