 Hello and welcome to our panel from the InnerSource Special Interest Group here at FinNOS. We're delighted to be with you here today, though unfortunately not in person, but some of our colleagues are today. So us three, unfortunately, can't be there. But we are delighted to be here virtually to actually share some of our experiences. So to give a brief introduction, my name is Claire Dyn. I work with InnerSource Commons, and I'm the Secretary of the InnerSource Cigats at FinNOS. I'm here joined today with Gil Yehuda from US Bank, who is Head of Open Source Engineering Technology at US Bank, and Arthur Molson, who is a distinguished engineer at Capital One. And we are all members of the FinNOS InnerSource Special Interest Group, and we're here to share some stories. So Gil, I'm going to start with you. Perhaps you can tell us a little bit about how US Bank has come to InnerSource and where you are on your journey. Thank you, Claire, and thank you all for showing up and being here. We're on a large and sort of enterprise-wide journey around technology modernization holistically, really looking at the way we use technology, leverage technology, purchase technology, and most importantly, build technology. And the building technology is the newer part of this. So as we're looking at modernization, we're looking at cloud computing, we're looking at open source, which brought me into the picture as really an open source practitioner, but InnerSource is a very close, I call it the first cousin of open source. They're so close. And we run into InnerSource challenges in the organization as well. The organization was largely designed around a software development model that was fairly traditional. InnerSource challenges that and says, wait, there are opportunities to do things better. And we're looking at those opportunities internally. And in particular, we're looking at those projects that lend themselves most naturally to InnerSource. So there's a collection of those that are sort of typical in organizations like shared libraries, UI components, build scripts, you know, patterns that you would use maybe for your microservices where you don't want multiple teams to use the same thing. And if multiple teams can't see the same code, it's very hard for them to do the same thing. And then just saying, well, why can't I see your code? That brings the InnerSource question that raises it and that brought us together internally to form an initiative to answer that question. What do you mean you can't see that code? Let's figure out how to make that work and then deal with all of the follow-up challenges that organizations face when they go about doing this. That's brilliant. Thank you, Gil. And Arthur, I'm going to come to you next because Gil has been describing this great organizational-wide effort. I know in Capital One, the journey started to maybe look slight different. And you yourself have a good story about where you came to InnerSource as well in Capital One. And perhaps you can share that with us. Yeah, for sure. So I guess Gil is coming at it from like an organizational level. And from my perspective, how I've experienced it is really from the bottom where we built a very successful InnerSource project within Capital One. And that really helped put the spotlight on the value and importance of InnerSource within Capital One in general. I think that I was a bit lucky I joined a bit later, but I believe when Capital One moved to using GitHub Enterprise, there's probably a very explicit decision made to keep repositories open by default. So I think that kind of helped foster this community, but there wasn't maybe as much as an intention focusing on InnerSource as happened after several successful projects and platforms took off within the organization. And then there's a focus now on how can we foster more InnerSource and more contributions. So in our area, and I think this is maybe an important point that we could touch on, a great opportunity for organizations to start fostering InnerSource is by focusing on the cross lines of business horizontal tech, which is often DevOps and how do we build our apps? How do we get them deployed into Gil's point, to the cloud or within the data center? Those are often fertile grounds for building InnerSource communities. And that's actually where I come from as well is that DevOps community. But at this point, Capital One's quite mature in its InnerSource process where there's lots of organizations within the company that are sharing code, building some of our largest platforms together with cross-binder business contributions. That's brilliant. Thank you so much, Arthur. Now, we're here at an InnerSource panel and you'd expect maybe that we might delve a little bit more into the kind of benefits but we thought it might be nice to actually go directly to some of the biggest challenges that we faced in your implementations of InnerSource because that gives people a realistic view of what this journey might involve. And we know some of those might be structural and some of those might be psychological. So I'm gonna come to you now and ask you what has been like some of those blockers and challenges you faced as you're thinking about adopting InnerSource within your organization? Again, Gil, maybe I'll start with you. Sure, sure. Thank you. Yeah, the challenge is real. Humans have this amazing dichotomy. We are very adaptable to change and yet we resist change. Which is odd because we're actually quite good at it. We just don't like doing it. And InnerSource, at least in our organization and I think many traditional organizations is a change. It's a change of behavior from a sort of a traditional model where you swim in your lane and information is provided to you on a need-to-know basis and there's this separation of concerns and all of these catchwords that evoke a certain sense of, you see what you see and you don't see what you don't and that's actually beneficial to the organization. There's a different modality of thinking about sharing information in general and specifically source code, which takes a different approach. It's share what should be shared, leverage the opportunity, hide obviously protected things that should be hidden but source code shouldn't contain that many things that are hidden. Source code isn't particularly good for secrets. So the notion that well, what if there's a secret there? Well, no, there shouldn't have been a secret there. Fix that problem first and then you'll see that the majority of the source code is shareable. So some of the challenges that we have have to do with, first of all, understanding just how deep sharing happens in source code management. For some people, inner source sounded like a buzzword. It's like, we're going to do agile, we're going to do inner source and it's like something you do, right? And the something you do is something you sort of deflect. It's like you do because somebody told you to and you sort of salute to the flag that we do it this way but you don't really understand it. We're trying to get past that surface understanding of inner source and not talk about it like we're doing inner source but speak very practically about where is the source code that I depend upon and how do I make the change to it? And what we find is that the vast majority of our technology is based on thousands of libraries of open source libraries that are available in public and on top of that, hundreds of internal libraries or a smaller number. So you have this vast, vast platform of thousands of open source available libraries of code and then a smaller layer of internal and then somebody at the top responsible for something saying, well, I don't want to share my code because people will see what I do and they'll just change this whole support model. And I'm thinking like the entirety of your project is dependent upon thousands of code, thousands of projects that you don't control that are already publicly available. Like most of that I can make changes to fundamentally by just going out to GitHub and internally that thin veneer that's all dependent on there. So the notion that you're protecting your code by not sharing it is foiled by the reality that your code, that what you call yours as if you've possess it is something that you actually control. You don't, it has these deep dependencies in this entire network that we all leverage. And if we could wrap our model, our development model around a healthier view of this being a shared, a common pool asset and as a common pool asset, much like I don't litter in the park because we all use the park, as a common pool asset, we all benefit from these platforms, some of them open source, some of them internally developed and then if there's something that truly private, sure of that, but that's gonna be a thin veneer relative to everything. Getting that notion across has been the challenge for us, but we're getting there. Very good, excellent. And I love the whole idea. I mean, first of all, I think we can all agree that that common's approach in terms of us all collaborating gets us to innovation faster and all the rest of it. But I love as well that sometimes the inner source really kind of relies on you doing the good thing anyway, like for example, not putting secrets in your source code assuming that no one will see them if you don't have to or like things like documentation which we should all be doing anyway. So it kind of nudges you in the way of doing software development in a better way anyway, which is really, really great. Arthur, what about you? What have been the big challenges from your perspective? Yeah, I think to Gil's point, you don't litter in the park, it really comes to a shared understanding of how it works, right? And I think that's where within Capital One, probably the bigger blockers or the challenges are really arising and scaling it, right? So I think that even if you're bought in as an organization, how do I make an inner source project one that scales, that can easily accept the contributions from across the organization that has all of those to Claire's point, the foundational pieces that make it a good inner source project are actually very similar to the foundations of what makes it a good open source project, right? Clear documentation, instructions on how to contribute, good pipelines and high test coverage, right? Making it easy to create code changes, contribute them, and then what's the contribution and review process look like, right? And making sure that that's standardized and clear for people across the organization for anybody who wants to contribute to your platform. And I think that's where Capital One and probably many organizations could benefit from learning from large open source organizations, how they run their projects and how can we share that knowledge specifically? Cause I think for many of those projects, they've built that up organically, right? Like, hey, issue triage, this is really like, we have a thousand issues, how do we triage this into ones that actually make sense that aren't an issue anymore, et cetera, right? How do we prioritize them? And I think many open source projects have kind of stumbled into good ways of managing it. I think that we can really benefit from how can we talk about this more explicitly and then make those tools, make those processes well known in the inner source community as well so that they can scale large inner source projects. Thanks, Arthur. And you know, can I say as well, I mean, you know, the whole inner source set of principles, as you say, you know, it's about learning about how open source methods and practices and learning from that place. But I'll also say it's been just wonderful over the last few months to actually see how even sharing together that we've been able to discuss in the special interest group in the inner source special interest group how we can take those practices and what makes sense in a regulated environment. I'm looking at Gil's little sign behind his head there. But you know, which bits make most sense in that regulated environment and indeed which, you know, how the different financial institutions might be implementing those and to learn from each other in that respect because that has been an incredibly valuable piece of this thing's work. So thanks for that. Yeah, I think that's been brilliant. Can I touch as well now because I know when we were doing some prep around this, we were talking not just about this kind of like the organizational approach and thinking about the processes and how we scale them and things like that. But we were also talking about some of the kind of psychology behind the things that make things different from an individual perspective and the idea of this idea of excessive ownership culture kind of came up, right? And I just love this because it really, as Gil said earlier, it's about how even though we're good at this, it's hard for all of us. And these little things, always these niggly things kind of rear their heads in so many ways. So Gil, maybe I'll ask you to comment on that as well because it's an interesting one. Sure, I'll touch upon this. We use terms in strange ways. We talk about ownership, we talk about things that are mine. Fibonacci doesn't own those numbers, right? They call the Fibonacci numbers, but he doesn't own them, right? Ownership is a weird word. We think about property ownership as being that, which I can exclude you from. So if I own my car, I can tell you whether you can get into it or not because it's mine. Code algorithms that define things operate differently with respect to ownership structure and we try to apply physical ownership. What we often mean is like responsibility. We say I'm responsible for this and I'm responsible for this is different than own. Like I'm responsible for my children. Does that mean I don't own them? Like I can't sell them on the marketplace. I have a certain responsibility, at least I shouldn't be able to. So I have a certain responsibility to ensure the code quality. And if I provide some code for somebody else, I certainly want to make sure that nobody ruins that code. And when we have these conversations internally and say, well, I'm not sure I should be able to accept code from a random employee, that might ruin my code. I have to support it. And I say, well, remember, your code is based on this open source project and they've addressed that internal, they've addressed that as well. I mean, there are tens of thousands of developers out there who want to get their code into that project, to put something on the resume. And yet they use all types of systems, automation, tests, in order to ensure that what gets into the code is actually good. Maybe rather than having you with a gruff appearance and a strongly worded policy, let's have some really good test cases. Let's throw some automation and use that to moderate what gets into our code because that's going to scale better. And having those conversations, they end up being a technical thing, like let's have a good pipeline, but they start off as a, but this is mine and what bad things might happen if I let other people into it. It's like, okay, let's address, actually you address what bad things might happen. And then let's talk about what good things might happen and then optimize for the good things. Yeah, I think that fear of what could go wrong as well can be a big part of that. Arthur, any experiences from that perspective? Yeah, I think that that's one of those areas that as an engineer, as you become more senior and you mature, you start to recognize, because like earlier on in our careers, we have this kind of attachments to the code that we wrote, right? It represents us and your kind of self-worth almost is attached to the way that you write your own code. But I think that as you mature as an engineer through your career, you start to recognize that actually code is really a means to an end, right? We're trying to solve a business problem and the business problems that are solved the best are the ones that are solved with people from different perspectives and different ideas. And so by making your project inner source and open to those ideas, the value of the code is how well it solves the problem and problems are solved best with more people, with more eyes, with more ideas. And so that's really why I think you do need to get past that excessive ownership culture. And again, it's not easy to do, right? I think to your point, Gil. And even within Capital One as a mature organization, we have areas where they aren't open for contribution. And again, I think that some of that fear is around, hey, I have the code structured in a specific way. Sometimes it's around support, as you mentioned as well. So how do I support these major changes? And again, I think this is where to reiterate we can learn from the open source community and how they handle those changes, as you were saying as well, to try to change that culture. But culture always takes longer to change, right? And I think the best way that I've seen it is to start small, start in specific areas, and see experiments, and then start to roll that out. And honestly, the really good ideas start to spread on their own organically within an organization. I love that. I love that approach. Thank you so much, Arthur. Well, we're coming to the end of our part, our virtual part. That was quick, wasn't it? Time flies when you're having fun. But we're sad to be leaving you and we're sad not to be there in person with you in London. But we'll hand you over to our very capable colleagues to take this conversation from here and to have more discussions on the topic of inner source. But before we leave, I just wanna say a big thank you to Gil Yehuda and Arthur Moulton. Thank you so much for joining us here again today. And a big call out to everyone in the audience to come join us in the Inner Source Special Interest Group because we would love to see you there. But with that, we'll say goodbye and hand you back to those in person over in London. Goodbye, Nairn. Bye. Good job, Claire. I already saw that once, but I thought it was pretty good. So it wasn't hard to listen to it again. I'm Denise Cooper and I'm the chair of the Inner Source Commons Foundation InnerSourceCommons.org is where you find us if you were wondering. Claire, who was leading the last session is stuck in Ireland, she can't leave right now. She's the executive director. And everybody else that's talking today is somebody that's a member of the Special Interest Group that we founded at Phoenix because James, who's in the audience here, came and told us that he thought there was enough interest based on our contributions to the Open Source Readiness work that you guys have heard a lot about in the last couple hours. So we were doing Inner Source, not Open Source every other month, was it? Yeah, and we were getting a lot of audience and he said, I think you could be a Special Interest Group. So we pulled that together very quickly and we've already done our first piece of work. So you guys have heard a lot about the maturity model that's coming out of the Open Source Readiness but we have one as well for Inner Source that's been pretty much done for a while now. And that's worth having a look at. And we're working on our next piece of work within the Inner Source SIG to try to better tool for fintech companies that have regulatory frameworks they have to work within. So that's a little update on where we're at with Inner Source Commons. The one other thing I wanna say before we get into the conversation is we have a summit of our own coming up in November. Up until last year we did several summits a year and last year we did one with Asia, our first with Asia and got so many more people than we've ever seen in one of these before. And simul translation into Mandarin which was really interesting as well. But we're seeing governments are coming to us saying we need to learn about Open Source and we understand this is the way to do that. Also, so it's sort of burgeoning. So anyway, that summit will include fintech panels and specific sort of special interest group related content. So if you have the CFP just closed but if you have something you'd love to see discussed it's worth sending a note to Claire to make sure that we get it in. Okay, so I'd like to introduce the people that are on this part of the panel. Here's Richard, Richard say what you do. Hi Richard, I'm Richard. I work at Code Think as a consultant and I have a background in cybersecurity and my general experience is with the business owners. So it's like managers and that sort of thing and it's how it's a lot of it is at least from my job at the moment with security and safety as my areas. A lot of it is fundamentally how do you get an organization to Open Source to the point where they're contributing in the open or consuming in the open. And what I've found is in the source is a path to do that. And that's why I was interested in the in the source group. It's because fundamentally what you're doing is you're doing Open Source behind a firewall. You're doing it within your own organization. And once you are at that point where you've decided you want to do this, the steps that you need to take, which is the policy and the procedures and the structures around in a source, you can apply those same structures and systems to an Open Source. And it makes fundamentally the main conversations of having a with security teams where they don't want to know, they don't want to engage, they don't want to listen to anything that you have to say from that perspective. But if you, in terms of putting content out into the world or bringing it in, but fundamentally you are, they're way more open to the conversation if you're having a conversation along the lines of, well, I've got these two teams and there's code that I can share across both of them because fundamentally it's the same function or the same problem that they're trying to solve. So breaking barriers within an organization I've always felt is a very good step in that direction. Yeah, thank you so much. And Graham? Sure, I'm Graham. I'm Innovation Director at Scott Logic. We're also a consultancy. So I've spent about 15 years working with financial services organizations. And I joined the group because a lot of my career has been in UX design, in UI design, and the idea of a common look and feel on applications is always desirable in financial services. Everyone wants that, but then it's always interesting to understand, well, how do we technically achieve that rather than just decide these are the three colors you'll use on everything? And a lot of the work I've done where we've created those common look and feel pieces has been typically siloed to a particular business unit in an organization. And I want to understand from the group, well, okay, how do you get beyond that? How does this become an organizational thing rather than the business unit? I found particularly in financial services the business units are more siloed than I've seen anywhere else in any other sector. And so the challenges of moving beyond those boundaries are interesting. And I guess the question I've repeatedly posed to the group is, well, how do we define these different degrees of openness? Because we talk about open source and we talk about inner source, and inner source even as a term is relatively new to quite a lot of organizations. But then what's the difference between inner source within a business unit versus an organization? And we just lack some of that lexicon that's needed to talk about, to talk across the organization for what are the degrees of openness that we want to support and explore? We don't have an answer yet, do we? Yeah, no, we don't have an answer yet, but we do have the maturity model which sort of starts to talk about different levels that normal companies go through. Written mostly by sort of mega-corps who have the will and the ability to do that. So I'm not sure that it's perfectly applicable to smaller organizations or individual business units, but we're gonna find out as we try to apply it, right? So what would you two say were the thing that is most contributing to siloing in the companies that you're seeing since you're from outside them technically? What does it look like to you? It's an element of how the finances run in these organizations, right? The way the budgets and the reward and everything, it's exceptionally hierarchical, it's very tree-based, and a lot of it boils down to individual contribution rather than collective contribution, and I think that has created a culture whereby, well, back to the ownership piece, it's like, well, that's mine, and therefore anything associated with that is me. And a lot of good open-source-inter-source practices around collaboration, and you can't just point the finger at an individual and say, well, that was you, and that was you, it is something more collective. So to me, that cultural element is the biggest problem. Yeah, in a lot of companies that's called matrixed management where every penny is tied to a cost center, and cost centers are per employee usually. Yeah, it's an interesting, I mean, to my eyes, that looks like the accountant's getting too far into the management of the company. I mean, it's banks, so that makes sense that the accountant would have a leg up there, but I think that a really strong case could be made that at this point they're causing more harm in terms of lack of innovation than they are providing service by making the accounting super clean, right? Absolutely, I mean, it feels in the organizations like they want to get away from that. They just don't. Yeah, I think everybody except the accountant wants to get away from that. That's right. Yeah, anything to add to that, Richard? Yeah, for me, I think the security is a huge issue in terms of, I mean, siloing individual business units off is a major thing, and they're like, well, this is the code within this business unit, and I refuse to give that. So the two pillars there, I think, are business ownership and why would a security team take that risk of exposing my code to more people than the organization? Yeah, you know, I've told this story a few times, but I'm gonna tell it again. I ran into, our code is the secret sauce of the company situation in the last fintech that I worked for, and I happened to work for the chief architect. So I asked him to do an audit of the code because he has the right to look at anybody's code, and he came back and said, that code's crap. That's what they're actually hiding. So, right? That's, I think, much more prevalent in those you can't see my stuff groups, and I suspect that there will eventually be kind of a rising tide of CTOs needing to know instead of just taking their word for it. And I think from a cultural perspective, it was mentioned on the video, the whole idea of ownership and that control. I think a lot of that isn't really, I wanna own this code as my code. I think a lot of that is my ego is tied to this code, and now I'm publishing it to the entire organization or huge parts of it. So, I mean, but you have to, I guess, convince engineers to let that go in the perspective of this is a work in progress. This works right now. Let me put it out there. It was always the hardest thing to teach, released early and release often. It's very hard to teach even to open source developers. And it's a human thing. Oh my God, my code's gonna be inspected by everybody. I better make it really good. What they don't realize is it's just as effective to write real comments that say things like, yeah, I know this bit's a bit crafty. I'm working on it now, but I wanted to get it out for comment or whatever. It's a different way to work. I think there's a huge history there as well because when organizations like Microsoft in the very early days, you had the CEO, you would get a personal email from Bill Gates. Yeah, that happened. The quality of your code. And imagine if you're that engineer and you're risking that type of feedback from literally anybody in the entire organization. And so I think that's a huge hurdle to get over. And you have to, I think from the very beginning, you have to encourage your engineers to go, it's everybody's, this is a shared asset. Right, that you think is yours. Yeah. It's an interesting switch. I'm interested in a conversation with you guys because it's a drag to sit and listen to people talk to each other. So if somebody has a question, a burning question about any of these topics, we're here to talk to you. And you're gonna indicate that by raising your hand. Yeah, James. So I'm involved in UX and design. Do you think in a source can say, engage design teams who are non-technical, but might be repeating themselves by providing design patterns, time and time again? That's a great idea. You need to restate the question. Yeah, so this was a question about whether design teams could be involved in a source. And I think it's a critical part of it. I think it's actually creates this positive feedback cycle. I mean, there's a few organizations outside financial services who create tools that hook straight back into the design tools and actually render the React components back in as design units in Big More Sketch or whatever. Creating that cycle, getting design and development and test and all the disciplines around technology closer together, working on the same thing is critical. I have a constant argument, and Tamar here, he's actually the next team at Schologic. Well, I always say that it doesn't matter what our design document says. It's what's in the code. It's what's deployed. That is the design. And so our work should be getting as close as possible to that and creating design libraries. And design libraries not in a design document, but in a living, breathing code base is far more valuable to the organization and all these teams. It's far more impactful in terms of defining a shared look and feel than anything else. But a lot of organizations are managing to do it at the most atomic level. Some colors, some fonts, some really basic stuff. But what about deeper, almost design philosophies and design approaches? That's not the domain of a designer. Actually, these are things that anyone devising or shaping a product can pick up on. And there are patterns there that good designers start to explain and share with the organization. So it is no longer just a code concern. There's a thought process concern that's actually part of Inner Source. And that's, to me, again, is why it's interesting. Inner Source talks nominally just about the code and the code being shared, but it's not. There's so much more in there. You haven't been around for the bus schedule conversation. One of the things that we did to try to make Inner Source real across the whole company was, you know, in Silicon Valley, people get bused from San Francisco because people don't want to live in Silicon Valley. The cool kids don't anyway. And so they run these buses and then they take you back in the evening, right? And everybody hates the buses in San Francisco, but they're a feature of our lives now. And the bus schedule that was published by the company that I'm talking about was unintelligible if you actually were trying to use the bus because it was being run by admins who never left Silicon Valley and had never been to San Francisco and didn't really understand what they were describing. So there was a lot of frustration. We just Inner Source the bus schedules and the people who actually used the buses could make changes that were meaningful and everybody was happy. So you can use Inner Source to collectively build anything. And it's actually, in my opinion, a good idea to find a few non-technical ways to tie people in because they're more likely to not be nervous about those check-ins, right? So that they can see how it all works before they put their jewels in. Yes, right? So this thing like egos is gonna be difficult across a larger organization. So you Inner Source the component, but how do you make sure that the government's around, hey, I wanna have this feature get in, I suppose, again, and bought into another product that gets bought this and then bought? How do you affect you feel if that one has a $20,000 build? Yeah, so the rules of Inner Source that I talk about are based on the Apache way because I've been Apache member a long time. And I feel like they solved a lot of these problems of collective development, right? Especially across competing concerns. So they have this concept of trusted committer and we talk about that at Inner Source Commons a lot. That's your gatekeeper and your mentor for any new contribution that's coming from some other group. And ideally it's a rolling responsibility because when people get paid to write code and especially at the top of their game, they're getting rewarded for their excellent code writing, then they don't wanna spend time doing other shit. So give them a rolling responsibility so it's only a couple weeks at a time or a week at a time that they review other people's code rather than write their own, right? But usually they're also the people who are kind of the pseudo architects of how things are put together. And part of our experience was we had a lot of monolithic code and a lot of interest in microservices but lack of understanding which part of the baby they were gonna cut off to make that microservice. Like it really felt that way. But after they had explained it to somebody who was relatively new, they could suddenly see where those divisions ought to be if only to create more security for localized changes in just one little module, right? But having that person, those people who are doing trusted committership, at least initially, be pretty senior people in the overall scheme of things, again on a rolling basis, and have it be their job to mentor, and this is the switch, get them to realize that while they're sitting in that chair, they're measured on how effective they are at getting code in, not keeping it away, but actually getting it in, not rewriting it, but actually helping that engineer understand what to do to get it to be mergeable. And if you can make that intrinsic reward of the project, then pretty soon they understand that the ego shift is about how good you are at teaching the code, how good you are at mentoring the code. And it's not easy, it's not for everybody. You can figure out really fast who doesn't belong doing that. But the people that take the time find it very rewarding. And sometimes even if you have the wizard problem, like all of our developers are wizards and they don't like to give away their secrets, right? Sometimes you can appeal to them and it's usually on an individual basis, especially if they're towards the end of their career, like what do you want your legacy to be? Don't you want somebody to know this code well enough to carry on when you aren't doing it anymore? You know, right? And you can often get them to pair or effectively mentor people and they're often surprised. They usually come in with a bias about their capabilities versus everybody else's and they're often quite surprised and they start saying things like, we should hire that guy because they picked it up so quickly, you know? So that all of that is great for leveling away that excessive ego stuff. And some of them are never gonna get there because it was fed for so long that way. I guess it's that notion of your lines of business like a business is computing to this thing and then there's lots of code but if there's a competing architectural decision there, then who gets to manage and govern that to make sure that that's possible? Yeah, this is why we suggest that you have an ESPO or a part of your ESPO dedicated to Inner Source to resolve those conflicts. And it almost becomes like you're the team psychologist. Right? And it doesn't have to be... John, you're next. It doesn't have to be a big team. It can be a very small team managing the Inner Source, like collectively managing Inner Source within your organization. I think in the early days, I think Microsoft had 2,500 people or something like that and they had I think a team of four for the Inner Source to manage the Inner Source. Yeah, there's a team of one in IBM that's got 7,000 engineers effectively doing Inner Source. So it doesn't have to be because it's really the trust of committers doing the work. The person in the office is just resolving conflicts and greasing the skids. So John, you get the next question, I think. Is everybody liking the question format? Yeah, I'll get you after if we get time. Go. Do you think it's better to say... I do. I think that you should start with a small proof that it works. And I think if you don't capture the value that that experiment created and sell that upstream, you're missing a trick. You have to do that over and over again. Run the little experiment. And the last chapter of adopting Inner Source talks about how to do this. Create a hypothesis, run the experiment, do an honest evaluation at the end of whether the hypothesis was correct, figure out what value you just created, rinse and repeat, find somebody else to do it with. And ideally your first couple should be the host and guest sides of the transaction or the owner and the Inner Source person should both be motivated to have that work. If you can find that, that's ideal. I mean, I've certainly noticed often these things are happening anyway. So it's a case of identifying where it's already happening and attaching those experiments to them because good development practices usually ask for some of these kind of behaviors to be part of it. Yeah. Sooner or later, your CEO is gonna notice or your CTO and they're gonna want you to do it for the whole company. So the other piece of advice I have is as you're doing the little experiments, hire somebody that knows how to message. It's usually not something that we're good at as engineers. And get them to start building the case right then so that when you get to scale, you already know how to blast out that message. Oh, thank you very much. We didn't get any time stuff. We'll go outside if there's somebody that had a burning question that they didn't get to. Thank you very much, Don. Thank you. Good job. Thank you. Thanks everybody. Thank you.