 Katie, am I good to go? Okay, cool. My notes here. All right, can everyone hear me okay? Great. So thank you all for coming. I think I'm the last person standing between now and drinks. So I appreciate you all coming. So first of all, my name is Rob Underwood. I am the lead, the global lead for open source at Goldman Sachs. And we presented last year at the open source summit about our plans to launch an Ospo. It was pretty nascent at the time. And we wanted to kind of come back and do a readout on the progress to date. So first of all, a few things I wanted to say was, I'm also a Linux Foundation alum. I used to work at Finno. So I was the chief development officer and I just wanted to shout out to Jim and Mike, Mike, Brian, and really all of the leadership team. They're just the fabulous organization. Thanks for having us and putting on such a wonderful event. Secondly, happy pride to everyone who's celebrating. The best I could do today were socks. So I have my rainbow socks on. So happy pride to everyone. I'm Brooklyn Rob on Twitter, so give me a follow. I'll talk a little bit about our Twitter handle, which is GS developer for our engineering group. So if you've not checked out our Twitter handle, it's GS developer. So I'm just gonna bring up my notes here. So a little bit about me and where I'm from. So I live in Brooklyn. I'm originally from Maine. I root for Boston sports teams. I'm into fish and CrossFit, if you wanna talk about those things. Career-wise, I'm not going too far back, but I was in the valley at Pandesik and then I did 12 and a half years at Silicon Valley in management consulting. Did some disaster recovery, civic hacking, which got me connected to the open source community. Was the chief technology officer for a graduate school. Got into computer science education. Hey, Brian. And then from there got connected to financial services and some of the open source efforts. So first of all, I wanted to quickly just, highlight what is Goldman Sachs, right? So you sort of hear about these investment banks and I don't know if it's always clear. So I'm not gonna get into a big overview of what we are, but we operate a number of different divisions. I work in the engineering division, but then we have a global markets division, which is maybe what you imagine when you think of a trading floor. We have investment banking, which does M&A and IPOs and does advisory services. We have a global investment research group. We have our asset management and wealth group and then we have our Marcus consumer bank, which some of you may be familiar with. So we have a lot of different types of things that we do. So again, I was saying we have GS developers or Twitter handle and then definitely check out our new, we have a new open source page, GS.com, four slash open source, which will provide you an overview of some of the stuff that I'm gonna talk about here. And then finally, I'll talk a little bit more about our blog in a second. developer.gs.com is our blog, so check that out. We have, I would say probably it's been, the blog is in live since September. We probably have about 30 or 40 at least post pretty deep technical topics there. So definitely check it out. All right, so we, as is our style at Goldman, we did a memo back in April of 2021 to talk about why open source is important to us and to lay out our strategy. And I can take absolutely no credit for that memo. My boss, Rohan and my awesome colleague, Vella were the ones who wrote that, but they had a great line, which has become our mantra, which is Goldman Sachs runs on open source. And it's really true and it's true for lots of financial services organizations. And I think sometimes in an open source community, there's a perception that the financial services sector may not do as much open source, but we actually do a lot and we use a lot and we consume a lot and we contribute ever more. So that's an important part of it. So yes, we consume a lot of open source code throughout our software bill of materials. We participate and lead external open source working groups and steering committees. A good example is we are, my colleague, Fee leads the financial objects project within Finnows working at the models using kind of at the very top of the OSI model, working on using open source and open source standards to define derivatives models with organizations like ISDA, the International Swaps and Derivatives Association. So we do that. Our engineers contribute to open source on behalf of Goldman as part of their day job. And that's the real focus of our open source program office is contribution. We also focus on consumption as well, but that's our real focus. Our engineers are permitted to work on personal and passion projects done for fun on the side and for skill development. And this has been an interesting thing we've been working on in the first year is coming up with those rules of the road for that. So many developers have outside projects and we want to make sure that there's a way for them to stay engaged with those. Our engineers can speak at conferences. I'm an example of that. And our engineers write public blog posts. So some of the, I'm not saying everyone, but some of the preconceptions that people may come that if you work at a place like Goldman, you can't do this or are not necessarily true. So again, our open source program office was chartered in April, 2021 by this memo. Again, we sort of run by memo by our engineering division of leadership and it was launched in April, 2021. So we're coming up on just under a year now. So what are our goals? Our goals are, and we also use OKR. So these are basically our objectives for the year. We want to promote and support more open source consumption and contribution by GS developers. We want to position open source consumption and contribution to drive talent, attraction and retention. So we think that open source communities and being involved in these communities is a great way to find talent and attract them. We want to build and expand our capabilities to generate insights about open source activity at the firm in our industry and within the technology ecosystem. We want to establish ourselves as a leader in open source, capable of setting the direction of projects, initiatives and consortia building code and standards strategic to our firm. And we want to earn a seat at the table and the way you earn a seat at the table in open source communities by your contribution by your sweat equity. So that's the way we want to do it. And we want to increase our visibility in the open source community and build further awareness. So what are some critical success factors to all of this? So I wrote a few down here that I wanted to focus on and so first of all, I'd say, and this is not necessarily something that anyone can assume in their organization, but I think it's difficult to launch an open source program office without strong executive sponsorship. And we are really lucky from Rohan Deshpande who's our managing director for open source, Scott Weinstein in the Slavin, John Madzin, Ilya Gazinski, Alinda Neal, our chief data officer, Nima Rafael who sponsored the open sourcing of legend and then up to our CISO, Matt Chung, our CTO, Atte, and then our co-CIOs, George and Marco, have really provided super strong support for open source. And so that is probably the biggest critical success factor is you, and I'll talk about the impetus for why in a second, but that's really important. And then you have to have a strong open source team. And again, we're all in a place right now where we're fighting for top talent, and we are very blessed in our open source program office. I'll give a shout out to Vicky, Cam, Kay, Yona, and Priya, and Bella who presented earlier today. You just have to have a great team and that's the key part of the success. I have great peer coaches, Jonathan Will, Sarah, Alex, Matt, other folks. So that's the people side of it. And then another critical success factor that I just can't highlight enough is especially in a regulated industry, like financial services, I spend a lot of my time every day with our compliance folks, our legal folks, our executive office, our tech risk folks. Again, they roll up to our CISO. Assuring them, talking through regulatory concerns, legal concerns, things we need to think about in terms of the way we operate in the public. And so my advice and a critical success factor is be a collaborator, not a disrupter in terms of building your open source program office, at least if you work in a regulated industry. Those relationships that you build with your legal colleagues and your compliance colleagues are really important. And my experience has been that they want to work with us and they wanna make this happen. So sharp elbows don't work. Collaboration is the name of the game. So what are we working on this year? So our number one priority I think this year, safe to say, is our contribution management platform. And let me just talk a little bit about that for a second. So because of the environment in which we work in, we need to be careful about, I think anyone probably needs to be careful, but we need to be careful about leaking intellectual property and it's more than just intellectual property. It could be leaking anything that you don't wanna leak. So we have an intellectual property control. And when I say a control, I mean like an actual audit control where we need to have a review and think of it as a code review, but we have to have a code review internally before a pull request leaves our network. And so that tooling is important and we're currently kind of refactoring that. So that's a big focus for us this year. We're working on our reporting and our dashboarding capability. The Linux Foundation, I was saying to a little bit or later somebody that the Linux Foundation provides some really wonderful visualizations for projects that are contributed to the Linux Foundation. We have contributed a couple projects through FENOS, the Linux Foundation. So we have those reports, but we wanna also be able to report on the projects we have in our Goldman Sachs GitHub.com for our Goldman Sachs. So working on that as well, but also generating operational reports, compliance reports and insights for our executive leadership is also really important. We also, you'll see that on the gs.com for such open source page, we've included some metrics there and we wanna probably in the future potentially think about ways in which to accelerate the sharing of some of those numbers as well. But right now our focus is really on our internal measurement and building some of that reporting. We are really working on internal awareness events to build interest in open source contribution. So this yes you can, yes we do, is the mantra we're using within gs with our own engineers, right? So there's a lot of engineers still who don't yet know or aren't aware of the fact that they can contribute. So helping spread the word. Training documentation, I can't say enough on how important that is. My colleague Kay is working on our training and documentation and organizational strategy and that's really important. We require everyone who wants to contribute on behalf of Goldman to do some basically a boot camp for open source and some internal training that they all have to take. So keeping that fresh is important. We've been working on an open source playbook, which are instructions on how to open source a project. So I think it's like 20 steps, but it's a real variety of things that need to be done from getting initial support, putting together the business case, figuring out how you're going to build a community, but also then real more technical stuff, the license, thinking about how do you properly modulize and generalize and abstract code, right? You take a big code base, maybe it's been maintained for five years internally to our firm, now we need to make it, get it to a form where we can actually present it to the world. So getting all that code readiness stuff is a big part of our training. I mentioned our personal side project guidelines are something we've been focused on. We've also, and I have to say just hats off to the to-do group they've been incredible to work with. So if you're not part of the to-do group, I would encourage you to think about that. But in addition to the connections we have with the to-do group, we've also been creating ambassadorships with other organizations in our, and that itself requires some compliance stuff we have to go through as well. But with other organizations in our industry and other organizations beyond our industry where we can say, hey, are you seeing any interesting, cool new open source projects? Are you about to, are you open sourcing something? Did you open source something last month that we should be looking at, hey, we're about to open source this? We'll give you a heads up when it's public so you can take a look at it. Contributor, license management and simplification. So this is, if there's one takeaway, if there's one sort of thing I'd say the industry can improve on, this is it, CLA's, oh gosh, CLA's. When we onboard a new developer and we want to get her onto the CLA for maybe a couple projects in the Linux Foundation family and then maybe one with Google and then one with Microsoft and then one with Trinno and one with Apache, it's all over the board. Everyone has a different process for getting onto CLA's. Some people use ICLA's. Some foundations use, have CLA's with a schedule A but then they also use an ICLA because their tooling only can enforce the ICLA's. So we're spending time on that but if you're in the open source community and you can simplify CLA's, please do. We'd love to get that cycle time to onboard new developers down. We respond, we are, our open source program office is effectively a support function and a consulting function and internal consulting function of sorts. So we get tickets, really they're JIRA items with questions about contribution, support, requests and our SLA that we try to achieve is five days on that. And then we are responsible for open source licenses in terms of the policies. So our kind of a red, yellow, green and then if there are exceptions or particular use cases where we may be able to allow something to be used, we help consult with our legal team on that. And then the actual sort of mechanism of that lies with our CI, CD and overall STLC teams. So what are some projects of interest to us? So this is, I built this, my colleague Vicky and I built this slide and then we ultimately use this as a mockup for what you'll see on the GS.com for source open source page. But I just want to give you a flavor of kind of some of the things that we're working on and thinking about. So some of the projects that we've open sourced, I'll talk about a couple of these in a second, into our GitHub org. So we sort of self-managed these. GS-Quant, Belladoma, which is an ORM, JDMN, there's a few more there, let me check them out. Then there's the projects that we've contributed, that we've open sourced and contributed to foundations and for which two of the three were still the primary maintainers of. Legend, which we contributed to Finos. I was involved with that when I was with Finos and then kind of that's what led me over to GS. Ketchit, which we did last year, which is a secret scanner, so to look for secrets that may have inadvertently gotten into your code before you check it in. And then Eclipse Collections, which used to be called GS Collections, which we've open sourced into the Eclipse Foundation. And then I just wanted to share a couple of the projects that we contribute to, Kong, Trinno, Janice Grapp, there's a bunch more. So those are the ones that we're focused on. And then we have tens of thousands of open source projects we use in our software bill of materials that we care about. So this is our GitHub presence. github.com, four slash Goldman Sachs. I'm sure everyone here spends a lot of time on GitHub, so I don't think you need a big orientation on that. But you can find our projects there. We have a little read me on the top where we talk a little bit about the projects that we've contributed to the foundations. And so that's another thing we had to sort of work through, which is sort of getting that one stop shop for everything we've done, right? So we continue to invest a lot of time and energy from our chief data officer, Nima Raphael, down on Legend, which is this data modeling, governance, lineage, really sweet of products that we open sourced a couple of years ago, but it doesn't show up from a discoverability standpoint. It doesn't show up on our GitHub anymore because we contributed it to Finno. So our work around was, again, this open source page, which I alluded to, and then working on the read me, but some of these mechanical things, I think another thing is be focused on the details, right? There are operational and details, things that you need to be concerned with, and that was, this is a good example, like I think it took me a half hour to put this read me together and post it, but it turned out to be a pretty big win because now we had that discoverability so that people are like, wait, I thought Goldman Sachs did legend, but I don't see legend here, and now they see legend here. So it's just sometimes stuff like that that we have to focus on. Developer.gs.com, forward slash blog. This was a big undertaking, and there was 20, probably 30 different people who were involved in getting this off the ground, and this has been really great. Us getting our sea legs and getting more comfortable with talking about deep technical topics, which is really from Marco and George out there down, the vision for this is to be a deep technical blog. I'm not saying that once in a while you won't see a blog post that's a little bit more, just say, hey, we did this cool thing, but most of the posts here, and the theme of the blog is deep tech, deep engineering, and giving our engineers an opportunity to showcase their stuff and talk publicly has just been really powerful. And this was done in part to support our open source effort, and the open source program office was definitely one of the driving forces behind it, but it really supports all of engineering and a lot of the other things that we're working on. So definitely check that out. Another thing we've done in this first year of having our open source program office is we launched an open source page. Again, I've alluded to it a couple of times. GS.com, four slash open source. Again, just saying what we're doing out publicly, right? This is what we're doing, this is what we're contributing to, these are the news and happenings. Again, it might not seem like much, but it's been really important, and it's also really important internally. Maybe it's more important internally because for our own engineers internally, it demonstrates our comfort, our pride really, in the engineering work that happens within the firm. And so it's been great, and the collaboration just across the organization and support for these efforts has been just fantastic. Again, it might not seem like much, but we launched a Twitter handle, GS developer. But again, being able to tweet out, talk about things that we're doing, that's kind of new. And so that's been kind of really important for us as well, and that supports the blog as well. Another thing that we've been really focused on the first year, and maybe this reflects a little bit our legacy as an investment bank is we are thinking more and more about our foundations as a portfolio. Effectively, I think investment portfolio would be too strong a word, but we're looking at the aggregate money we spend on foundations and looking at what's the ROI that we're getting out of our involvement, both in terms of the checks we're writing and the labor that we're investing. And is there more we can do to support some of these foundations and some of these efforts as well? So I won't go through all these, a number of these foundations are within the Linux Foundation family, some of them are not, but we're continuing to look at new foundations we can get involved with. We joined OpenSSF last year, for example. And we're really excited by the portfolio of foundations and how we can continue to get engaged. One thing I would say is I wrote down a couple kind of key takeaways here and another key takeaway I wanted to mention here is I think comparatively we found it easier to encourage people to contribute code than to participate in working groups. And I think there could be a couple of reasons. The pandemic maybe, although nearly all working groups are virtual and were before the pandemic, but sort of getting people to sort of step out of their day to day work writing code and to say, oh, I'm gonna now go on to a Zoom call with some strangers and talk about standards or a project, that's been comparatively hard. I'm not saying it's not happening, but that's been a little bit harder to do and something that we're continuing to work on and focus on. And so I mentioned that here because we, I think when you commit to being part of OpenSSF, for example, it's not just a commitment of writing a check, it's a commitment of the time and the labor and the effort, right, or PHINFs or any of these Eclipse Foundation, right? So if you're gonna commit financial resources, I mean, maybe you just wanna put the logo on your splash page and you want them to put your logo on everyone can say, I mean, and that's fine. I mean, that exists, like buying pixel real estate via a Foundation membership is something that people do. But I think to be a truly authentic member of these foundations is to be involved in their steering committees, their SIGs and their efforts. And so thinking about how we can incent and mobilize our teams to get involved in the mission and work of these foundations is something that we continue to be focused on. I wanted to take a few minutes to talk a little bit about, I won't go through all of this because some of this is pretty detailed and I know we only have a few more minutes, but I wanna talk a little bit, a couple of the projects that we've open sourced. So GSQuant is in our Goldman Sachs org. It's a Python toolkit for quantitative finance. Go check it out. It's really cool. It was built by our, I mentioned our global markets division and there's some really interesting Jupyter notebooks there you can check out. Here's a few of them. So you can go look at them, check them out, contribute if you'd like, but that's a real focus project for us. And I guess maybe let me pause there and I talked a little bit before about why are we doing open source, right? And so one of our Kosiaios talks about, I think you mentioned this in one of our blog posts, Marco said, developers are building the future of finance. And there's another sort of strategic tenant which we talked about at the firm, which is developers as customers, thinking about developers as being customers of Goldman Sachs. In last year, you may be aware, we launched at re-invent the new financial cloud for data. And then just last week, our chief data officer Nima made a big announcement about some of the stuff we're doing with Snowflake. So we're really thinking about developers as customers and so open source is part of that and it's part of that strategy. And because to meet developers where they are is to meet them in open source repos and to meet them in open source projects. And so we need to authentically be part of those communities. We also have on that some, our nine engineering tenants and open source is also a powerful vehicle to express really all nine of them. But two in particular, keep learning and express humanity. And the human factor of open source and the ability to always be learning are two elements of why open source is really important to us. And so that's kind of what this is about and why we're all here. I mentioned Ketchit. Ketchit is our, again it's a secret scanner, API key scanner that we contributed to Finos. So take a look at it, contribute to it, use it, improve it. One of the things I'm excited about with the Ketchit contribution is that this was contributed from our tech risk organization, which is closely part of our overall engineering family. Part of our overall engineering family. But the tech risks folks are also the folks that we have to work with a lot on some of our policies for open source contribution. But they are also open source contributors, which is really exciting and powerful. So that's fantastic. So I mentioned legend just quickly. We are for this past year of the Ospo, we've been continuing to really focus on how we can help continue to expand legend. And I think legend also provides a good model for how this all can and probably should work. So I don't think open source program offices can be all things to all people and do all open source work within, especially a large organization like Goldman Sachs. So when someone says, hey, we wanna open source a project, in this case it was our data engineering team, they need to take on primary responsibilities for continuing to maintain and build up that community. And our data engineering team has done just that. And then we are the, I don't know, there's a vet middler who said, wind beneath your wings, where the wind beneath their wings? I was gonna try to work in a fish quote, but I ended up with that middler. But we are the wind beneath their wings of the folks who are open sourcing their projects. And so this is a little bit about legend. If you wanna see legend, it's legend.finnose.org. That's a screenshot of a press release. There's a hosted through Finnose, we've provided a hosted modeling platform. Again, so folks can actually use legend to actually do modeling, to do public modeling. This is how the aforementioned financial objects group is doing its derivatives modeling. They're able to model these derivatives out in the public using open source, using a public modeling tool. So that's all pretty cool. So here's a few of our resources. I won't go through all this, but that's some of the stuff up there you can take a look at. And that's all I have for material. Let me just make sure I will take a few questions, but there were just a few final things I just wanted to make sure I left you with. So did I mention contributor license agreements? Did I mention contributor license agreements? Okay, cool, I just want to make sure. If I didn't mention that, I wanted to make sure I mentioned that. So CLAs and ICLAs and DCOs and figuring out how we can make it easier for folks to rapidly get onboarded to all of the CLAs and ICLAs that they need to be part of in order to contribute across the foundations and organizations is a key thing. We're thinking a lot about licensing. Again, we do have responsibility for open source license consumption. So looking at different scenarios, not just looking at the presentation earlier today was fantastic from this very podium about licensing, but also thinking about some of the licensing scenarios for I'm gonna use this package as this license and then I'm gonna contribute to this other library that I'm gonna use in combination with it and then I'm gonna put it on a hosted platform. Am I like those sort of combinations and those algorithms of scenarios, if you will? Looking at that is something we were thinking a lot about and eager to see what comes from the community on that. Again, I mentioned participation. We are excited to encourage even more of our developers to get involved in working groups. That's a big focus for us encouraging folks to go to conferences, attend meetups, just be part of the community. And then finally, I'd say another thing that I think we're focused on is, I mean, I think this is common to developers generally, but looking at ways to get developers to think about looking at open source, I guess, alternatives for lack of a better term before they go and build something themselves. There's a ton of stuff just in the financial services ecosystem being developed that we need to be thinking of that we could be looking at. And so really that discoverability of other things before you go and build it yourself is something that we're continuing to work on. So thank you, everyone, Brian, everyone for having us here. It's fantastic to be here and it's great to be in person. It's a little hot. I did suggest to the Linux Foundation, I'm from Kennebemport, Maine, I did suggest that if you wanna do your conference on the coast of Maine, it's lovely in July. There's fishes playing in a couple of weeks. There's lots of good things about Maine, but it's lovely to be here in Texas as well. So with that, I will take a few questions and thank you again. Yeah. Thank you. All right, so thank you. And kudos for one year of open source. Thank you. That's fantastic. We are currently Fannie Mae spitting up their Ospo. One year in, so I'm gonna bother you a little bit after this. I will not hold you all up, because I know it's hard. And I would be misrepresenting it to say we've not been doing open source only for one year. We've been doing open source for much longer than that, we've been attributing for much longer than that, but having a formal open source program office is one year, so yeah. Okay, so that helps my next question. I was gonna say, so kudos to you for being able to get three projects in one year incubated into a foundation. And I'm like, how did you do that? No, no. I'm close to two and a half to just get two in with my other companies. So if this falls out of the scope of this session, I definitely wanna know how you did that, especially in financial regulated companies. So that's huge, so that's all I had to say, so. I would say, we did do one, we did catch it. And I would say, there was a book a few years ago called The Checklist Manifest, though. I'm sure the author would not want me to discourage you from going out and checking it out, but the big idea of the book effectively is make a checklist. So, but there's lots of good stuff there, but writing it down and having a checklist and going through open sourcing a few times, and just really just writing it all down and having that, and it doesn't need to be fancy, right? It need only be just check boxes and a Confluence page, right? But just keep it simple and having that available and using it and improving it. I mean, one of the things that I really, there's a lot of things I love about working at Goldman, but one of the things is people are always thinking about how can we improve this? And there's almost sort of a native iterative development or iterative, almost everything we do, we go and we do a retrospective, okay, so we just did this, how can we do this better? And so that iterative nature of things, so open source something and then really like, okay, how can we really do this better? What did we miss? And then the other thing is I'm a big fan of critical path analysis and pert charts. We use the working backwards methodology, right? So work backwards from, write your press release or faux press release, work backwards from that and then figure out, okay, so the day before the press release I need to have this ready, and the day before that I need to have this ready, and the day before that, then again, it's really just a pert chart or critical path analysis, but that sort of approach I think can be really helpful. You're gonna see Fish in August, where you can see him? Oh, great, great, good, good, all right. Well, I know there's at least one other fishhead in the audience I won't disclose. Oh, there he is, hey, yeah, okay. That's great, that's great. So what would you say has been your biggest, your biggest institutional difficulty from moving into actually having an off spell? Our biggest institutional difficulty? Yeah, what has been hardest to do? Well, I guess this is not a throw away, but I think what hasn't been the hardest in the first year but was the necessary precondition was the impetus for needing to do this in the first place, meaning we knew we had this strategy and plan to start launching new products like the financial cloud and we knew we had a strategic intent to embrace developers as customers. And so I would say it was probably the biggest challenge was a challenge that maybe existed before I came along, which was having that really, and I just can't say it enough. Having that support from our CIOs down, our project is the open source program office, the strategic initiative for the firm, it's having that support is really that I think that, so I won't say that was the most difficult thing, but that was like, without that, I don't know if any of this would have been really possible. I think we really needed that support because I would say there are, on any given day, there are things that pop up and when you have executive sponsors that will help move mountains to make it possible and make it happen, that's really, that's really what it is. I mean, there's all sorts of little things I'd say. I mean, I think all of the different licenses and license combinations and scenarios that I alluded to earlier, I mean, those are, it seems like the complexity there is getting higher still, but I think, again, I wouldn't frame it as a difficulty, I'd frame it as, it could have been a difficulty if not for that, yeah. Hey, Rob. Hey, what's up? So just curious, for the projects that you contribute to. Yep. What is the kind of decision-making, matrix that you have, like, is that something where a developer says, I wanna ship this patch upstream and then you kinda do it patch by patch or it's like this project is strategic and we wanna contribute to this regularly and then it's kind of up to the developer how much they contribute. That's a great question. That's a great question. And then we're shifting on that, so that's great. So, historically, the choice of I wanna start contributing patches to XYZ project was largely just left to the individual developers. We had and still have developers who are contributing to projects on behalf of Goldman that we ourselves don't actually consume. We are, that is changing and I alluded to the reporting and analysis stuff that were, I don't wanna report that we're further ahead than we're not, we're still early days on this, but we're starting to look more at, okay, so let's parade out this, right, 80, 20, right? So, these are the 20% of the projects that we really care about the most, right? They represent 80% of the activity and really important. How do we get involved in those projects, right? And so, in the wake of some of the things that happened over the winter in the open source community, we're definitely starting to look more at, okay, so how can we identify projects that we really rely on and are there interventions that we can provide to those projects, right? Should we be contributing more time or more patches to this project because we really rely on it and we think it could use some more contribution or stuff like that, but that's a great framing of it because that's changing. We're trying to be, because there is only so much time in the given day that aggregate our engineering teams are gonna be contributing to open source, right? So, directing that strategically would be a good thing to do, right? Any other questions? Yeah, we are back, that's right, that's true. Alternate strategies or projects that they can fund to add to their portfolio that might come under open source, like funding a DAO, for instance, for open source development? I don't know that we think about it or thought about it that way. I mean, we're a big bank, right? So there may be, I just don't know on that. The conceptually that makes some sense, right? And I think that open source is certainly an area on that, but we, yeah, but I think thinking about it the different ways in which we can fund the ecosystem, foundations being but one, we also have a bug bounty program, I think things like that, those are different ways to sort of thinking about that, yeah, for sure. Yeah, and that's a technical approach, but perhaps your influence could bubble up to some selections at the portfolio level. Okay, thank you.