 Welcome to our panel. A new era emerging and evolving open source program offices. So I am Don Foster. I will be your moderator today. I am the director of open source community strategy at VMware. Today we're going to talk with our panel of experts on a few different topics. So we're kicking it off by looking at the to do group survey. So I know that that'll be covered in more detail in other talks at OspoCon. But we're going to give our take on a couple of things and then really just talk about how some of the things in the survey give us ideas for how we can help other people improve their open source program offices. So with that, I'm going to turn it over to our panel and we'll start with Dwayne if you want to just introduce yourself. Hi, my name is Dwayne O'Brien. I'm the head of open source indeed.com the job site, the world's number one job site. I've been here for four years prior to that I ran operations for PayPal's open source programs office super excited to be here. Thanks. Okay, turn it over to Nithya. You want me to go next. Yeah, just go ahead and introduce yourself. Okay, so it's wonderful to see all of you today, Nithya Ruff. I run the open source program office at Comcast. We are a global media and technology company. And it's really good to be here to talk about Ospo Matters. Thanks, Don. I'll introduce myself, but if you are watching this recording from home or in the audience, like drop in the chat. Introduce yourself because there's probably a bunch of you in the audience have Ospo experience too. And we'd love to start a conversation. Thank you, Stormy Peters. I happened to be in the right place at the right time about 20 years ago and started one of the very first Ospo's at Hewlett Packard. Everyone was very concerned that we were going to accidentally give away HPX. So I got to learn a lot about open source and got to help a lot of companies and a lot of organizations figure out how to work with open source software communities, which are my favorite people to work with. I am at Microsoft where I lead Microsoft's open source programs office. And I hope to talk to you a little bit in a little bit about how Ospo's have evolved over that time and where we're at at Microsoft. Perfect. Thanks everybody. So the next thing we're going to talk about, we're just going to talk quickly about a few things in the survey that stood out for various people. So I think we'll start with Stormy. What was one thing that stood out to you from the to-do group survey this year? So I would have actually said it's how the things correlate, which is not one thing, but many things. But the one thing is that one of the very first questions is like, what percentage of the companies were technology companies and that number has gone way down. So that means that lots of companies that aren't software companies now have Ospo's, which is really fascinating and bringing a ton of other changes with it. You can see a number of companies that are providing training to their employees on how to contribute to open source software has gone way down, probably because those new companies haven't gotten there yet. So I know we're going to talk about all that, but to me it's how one factor can affect all the other factors. And what does that mean and how do we help all those companies? Yeah, that's really interesting. And that's also one of the things I really like about the survey is there is you can just look at it in so many different ways. And this survey did kind of stand out as being a little bit different in the way that you mentioned. How about you, Nithya? What stood out for you for the survey? I think there were two things that stood out. One is what Stormi is referring to. There's a really good mix of other industries joining and starting open source program offices, particularly I'm interested in universities in the public sector joining and becoming open source savvy. I, for instance, over the last year have joined the RIT open source advisory board, and also University of California Santa Cruz, and universities have an interesting approach to open source. It's not just education, but it's also how do we create bridges between universities and companies. I'll talk more about it later, but that's fascinating to me. The second fascinating thing was that the value from foundations and open source community seems to have dropped for companies. And I wonder if that's because we are living in a virtual world and being physically connected in a conference, you see the value from the conference and from engagement, and when you're virtual maybe you're not seeing that as vividly. Yeah, those are great points. I do think it's interesting to see newer types of organizations embracing open source program offices. And like you said, a lot of things are virtual and different right now, so it's interesting to see how things are evolving. How about you, Dwayne? What stood out for you from the survey? It's a little strange, but the thing that I've kind of latched on to at least, you know, as I was running up for prep to this talk, is the size of the organizations that have participated in the survey. With 23% of them have 50 or fewer people, right? And those of us on the panel today, including you, Dawn, we work in large organizations, we work in staffed open source program offices, we might have teams of our own that we have built and so on. But there are a lot of people who are interested in the output of this survey that had 50 or fewer people in our organization, so the odds of them being able to have a single person responsible for only open source are very low. And so as they build out their practices, as they try to centralize their practices, what does it mean to help those kinds of organizations and how can we make sure that we're making the things that we have learned while running our offices portable and applicable to smaller businesses as well? Yeah, that's a really good point because we're all using open source. It doesn't matter whether you work for the huge multinational company or, you know, a really small company, the chances that you're using open source and needing a program office to handle certain things like compliance and things like that, for example, it's really important. So Storma, you've been working in open source program offices for over 20 years. Can you talk about how OSPOS have evolved over that time? Yeah, I think it's fascinating. And I think with all the new people joining, like all the new companies creating OSPOS, so joining the OSPOS world, I think we're really seeing the different ways that OSPOS evolve. And I think there's two tangents, actually. One is just the science of how to do open source programs offices has evolved over time. So back when we first started doing open source 20-something years ago, licenses were like brand new, these open source licenses, and everybody was an expert on licenses, whether you were a developer or an attorney, like you knew all about open source licenses and you could explain them to other people. Now they're still very important, but they're not what takes up everybody's time. There's been like enough time and enough knowledge shared that we don't spend as much time worrying about them or evaluating them. So that's what all OSPOS have evolved. But I also think individual OSPOS evolve over time. So when you first, if you're a company that does not have an open source programs office and you start one, the very first thing you need to do is figure out what open source programs are, what software you're using. So you always start with this audit process. And then you get to which licenses is my organization okay with. And then you get to, can we contribute back? And can we open source things? And eventually you get to important steps like making sure you have training for your employees so that they can contribute back well, or having best practices for them. There are two ways we've evolved. And in the first way, the science of OSPOS evolving. Hopefully, as Dwayne said earlier, we're sharing enough knowledge that these new companies coming on board can jump to where we are and not have to like relive through all of our mistakes. So the second way is also fascinating. Like, how does an OSPOS grow from the very beginning when one person sees the need to being a company-wide processor evolve best practice? Yeah, one of the things that I found interesting is that the conversation has completely changed. So back in 2000, 2001, all of the conversations were convincing people that open source wasn't scary and that it was okay to use. No, it's just a given. You don't even have those conversations anymore. People still do ask, how do I convince my management that we should create an OSPOS? Like, not so much like that open source is okay, but how do I convince my management that investing is okay? Stormy, I'm reminded of the OSCON book that I found a couple years ago that had one of your first talks at OSCON. It was from the early 2000s. And the title of the talk was, how can I convince my manager it's okay to use open source and how far we've come since then? I still have those slides. I should dig them up. It'd be funny. We have come a long way, haven't we? It's creating a structure around open source and articulating the value of why someone should invest in an open source program office is becoming important, the metrics and the impact to the organization. I think an interesting thing about the evolution of OSPOS as well, it came to mind, Stormy, when you were talking, we're to the point now that large organizations who have had successive open source program offices running them. It's almost this process of an archaeological expedition to find the artifacts from the previous OSPO. What kind of efforts were going on now? Someone going into HPE now to start a new open source program office has several iterations of an open source program office to go through and dig and find those cultural artifacts and how they impacted. That's definitely something we didn't have 20 years ago. We were all out there in the wild. Until now, each company has developed their own tooling too. I remember working with the IT department at HPE to develop an approval process so that the open source program office could approve things. We had an attorney and a developer and all these different expertises. In Microsoft, we also have a really robust tooling that now goes to the point where, you know, for developer, they can download anything they want, they try it out. If they put it in the build process, we automatically detect that software in the build process. We automatically figure out what the licenses by using clearly defined. We kick off a legal review only if it's needed. So like all the tooling that we've developed and all the OSPOS are coming together now to try to share that best practices and tooling. I like that that we would be sharing more of the tooling. I agree with you that we've been forced to kind of create tooling very specific to our companies. And this is another area that we should really be collaborating on and leveraging and reusing compliance tooling versus duplicating that work. And there's a number of open source efforts. So we've we've open source tools that we found useful like pretty clearly defined to clearly figure out which licenses is associated with the component because it's not always clear in the GitHub repo. We've open sourced some of our GitHub tools for managing large organizations and, you know, integrating it with your identity. There's also the to do the to do group branches in Europe has developed a whole bunch of Ospo tooling that's all open source and online, you know, all out there for all of us to to use and participate. So yeah, I think I think there's definitely an ongoing effort there. And we're getting the great places. Yeah, that's great. So, so let's transition a little bit, Nithya. So you've led up and source program offices, both a tech company, while you were at sand desk and now for an end user company at Comcast. Can you talk a little bit about how the needs for an Ospo were similar or different in those environments and what are some of the unique challenges. I think you bring up an important part point. Don that you really need to understand the business of your company and where the value is in your company right and the open source office really needs to align and match and support that it cannot be diverse from the business of the company. So at sand desk because we were a hardware and software company customers actually cared about the kind of open source you used in your products. Customers wanted to know that they would not be locked into a certain proprietary product right that you used. So when we created a storage system, for example, we specifically message that we were based on set. And that we were also very active in the self community, because customers wanted to know that you had a seat at the table and that you could do things in self that they needed, you know, having done, and that they could you know shift to another system if they needed to. And our credentials were about what value we added on top of open source and why they need to buy, you know, this entire system that we had created both open source as well as, you know, what value we brought. So the value line became really, really important. And it was easy to convince that particular division which was self based that they needed to be active in the community that they needed to, you know, contribute back to the community. And they would have to be highly engaged and upstream and things like that. But in a services company where open source is a means to an end you're really building a highly engaging customer interface for entertainment or for managing your internet, for example. Customers, our customers don't care what open source I use. They only care that you are bringing the latest and greatest innovation to them. So sometimes it's harder to convince my team to contribute back to open source because they want to move on and work on features and functions that customers will pay us for versus upstreaming a component. They are so short term oriented sometimes that they don't think about the debt that they would have to pay towards the end. In some cases, it's easier for me to ask them to contribute back to open source because we don't sell the product based on open source so, you know, it's easier to say to them, hey, this is not a, you know, business critical thing, you can go back and contribute to open source. In a services company like I am in now, we really care about how is it helping us get to customers faster time to market, cost of getting development done and developing features. It's not about, you know, how are we different than the open source product that we are based on etc. I'm looking at my notes to say, I never talked to my Comcast customers about open source but I do talk to my developers about our open source culture because to attract developers to the company, open source becomes extremely important and showing the impact of open source on my business has been harder in an end user company as opposed to product company. In product company, the line seems to be shorter. In the case of an end user company, how do I show that a certain feature in the Xfinity operating system, you know, was because of open source or we increased revenue or things of that nature. So it's slightly different but the important takeaway is you have to understand the business of your company and how open source plays a role in that. Yeah, and you make a really good point about attracting and retaining talent. I think that's something that that we all struggle with because open source developers are pretty high demand for sure. Go ahead, Stormi. I was going to say any developer wants to use the latest tools and doesn't want to reinvent the wheel and wants to work with an awesome community. So it's very attractive to any developers who worked with the open source software community or used open source software to want to continue to do that. So I think it's important for companies to figure out how to enable them to use that work that already exists. What are you doing? I'm thinking about that point you made Nithya about, and I'll resay it here, the average Xfinity customer doesn't care very much about what open source was used to get internet into their home, right, or what was used to get media into their home. Similarly, the average job seeker doesn't care what open source was used to get a job in front of them or to apply or to apply to a job. Stormi, I think Microsoft is the outlier here because you do kind of a lot of everything, right? And so there are certainly folks in the Microsoft ecosystem or customers in the Microsoft ecosystem or customers of Microsoft who care a lot less about what open source was used to bring them their solution. And there are customers who feel very strongly about the role of open source and delivering solutions to them. And I wonder what that looks like from your perspective. The distance between the open source that we help our companies use and the customers who end up benefiting from our company's offerings. Yeah, so the Microsoft mission is to help individuals and organizations achieve more. And so I think open source is a really important part of that. It's important internally that we build on the work of others to enable others and that we provide those components and toolboxes so others can build on them. So open source to me is a really important way of accomplishing that mission. What your question your comment make me think of is we actually had had several customers who came to us and said, we need to know that the open source software you're using that you're using it in a compliant way that the stuff that you are giving us is compliant and that you know all the open source software that's in there that you're doing the right thing by it that you're writing by all those licenses. So, some of my colleagues at Microsoft work with the Linux Foundation and others to create the open chain process by which we described the process by compliance process. And then you can say when you're open chain compliance, then your downstream customers know that you are doing the right thing with open source software. So that directly came out of a customer request, because we were like to give them what they need, we would have to give them like an encyclopedia worth of papers to show them all the licenses and what we did to make sure that we were compliant with them. And you're really building trust you're building trust that you are managing your open source effectively, and you're not transferring risk over to your customers. And you're also saving them time and money as you said, in not having to do the compliance process all over again you're kind of giving them a head start with what they're using. But yeah Dwayne brings up a really good point it's different aspects of the business kind of deal with open source in different ways. So when I was at Sandisk, the division that was based on open source had a very different approach to open source was highly critical. Whereas the consumer division which did the USB sticks and things of that nature, all they cared about was is, does the USB work with the interfaces in the, you know, main operating system in the, in the laptop. So it was just a means to, you know, make sure that the product worked, but they never encouraged their teams to contribute or, you know, be involved. All right Dwayne the next questions for you. So we received quite a few responses to the survey this year from non software companies and companies that don't yet have open source program offices which you mentioned that earlier. Can you talk about what this might mean about the maturity of open source as a whole and the open source practices within companies. Yeah, I, we were talking about the survey results sort of like reviewing them ahead of the panel and this, this sort of observation started from the place of looking at what the survey had to say about contributions and there were a lot of people who looked in the most recent results as if the percentage of companies that were contributing back to their open source, the sources to use had dropped somewhat statistically significantly. You know, if we look at, you know, maturity models and describe organizational capabilities for for open source and any given organization on the far end. You have organizations that that don't use any kind of open source and I struggled to think of what they are sometimes called at the farm stand right like I could go out and sell zucchini from from my from my home farm and maybe not use open source long as they didn't own a tractor or something that and then on the far other end of that spectrum you have organizations that are partnering with other large organizations to deliver significant open source projects to the community. Right and and all along the middle of it there you have this range of folks who are, maybe they know that they're using it but they're not contributing back to it they they are using it and they're contributing small, making small contributions back. They might be releasing their own open source projects but there's not a lot of community support for them. Maybe they're co leading projects with other organizations as well, all along the spectrum, you have this range of organizational capabilities that represent where a company is. So, I wondered, and I still wonder if, if seeing some spread in that in that in that spectrum seeing some organizations that just aren't really giving back if that's an indicator that we've succeeded in making open source easy to consume. And if we as a community and as a practice have made it so easy for developers to take in open source and use it to build product or build their next, their next project that there's a little too much distance between the pain the designers of that project feel and the end users right and I come back to the food metaphor, it's similar to getting too far from the food that you eat right like if, if, if you never see how how food is grown or you never see how your food is raised. There's a just it's easy to kind of ignore some of the practices that might go on there so you know is that spread in the maturity is that an indicator that we've that we've succeeded wildly in that open source is so easy to use now that you don't have to know where it comes from. That's, that's a very interesting point. I'm also wondering if, you know, to your point about maturity curves, it's, it's that you do it in phases you first consume, then you kind of create compliance processes because you have to, you have to understand you know which licenses your organization is willing to accept and not. And then, maybe after a few years is when you kind of get to the point where you say, oh my gosh, I built up a lot of technical debt in what I've done, and I do need to kind of make sure that these are upstreamed. The things that I often hear from some of our developers is it is still a lot of heavy lifting to upstream patches. You've got to take time to package it and work with the community and make sure that they accept it and socialize it and so on and so forth. And then they may not be a chance that it gets accepted so I wonder if you know solving that problem is also important you know making it easy to contribute back just as easy as it is to consume. So we've talked a lot about about this gap between companies using open source and contributing back upstream so stormy, maybe you could provide some advice to help people convince their management that they should be contributing to some of these open source projects that they use. I should start a career and convincing your management to do things, since I'm still on this on this thread. I think there's a couple of things that prevents people from contributing upstream and both Nithya and Duane have mentioned several of them. But I think the first one is really a fear is kind of like public speaking. It's really hard the first time to go up there and stand in front of this group of people and say something and be articulate and you know you're going to be nervous and you know it's not going to come out the way you meant. I think people have the exact same fear when it comes to putting their code out there. It's, and so they, they spend a lot of time making it perfect or they just don't make any time to do it. So there's kind of that imposter syndrome and I think you can, I think you can tackle that one with a lot of training and a lot of mentorship and people sharing their experiences. So we found, we have open source workshops at Microsoft and we found that bringing in other people who've gone through the same experience to talk and be in small groups with people is actually way better than just lecturing them and giving them a bunch of pointers. So I think that fears the first one like just knowing that you can and getting through the first one. The second aspect I think is convincing your manager that they should give you time to do it, or convincing teams that they should take the time to do it because as Nithya said it takes a lot of time to contribute back upstream and you get the time back, because then you're not on this like forked version of software that you have to like maintain yourself, but it's an upfront cost that you're not always sure you're actually going to get return on your investment and it just takes time and knowledge. So I think, and so what we've done to that is both tell teams and managers explain to them how to get the time back, but also making sure that in the review process for your developers, that they get rewarded for contributing back that they get that they get kudos for for having contributed to the work of others. So the two places I'd start looking, if I was looking to try to encourage people to contribute back for, but I don't think, I think we're all still working on that. And that, and that last piece, the making sure the developers are recognized and rewarded for upgrading those those fixes and in particular the thing you said to tell me about you. Otherwise you get stuck on a fork, right, that you've done internally. One of the problems I think that we have is that on the whole teams that feel pain from that fork aren't necessarily aware of it. Sometimes describe it as like you're chewing around a bad tooth, you've got a tooth that's sensitive or broken filling or something like that. And maybe you've had it a while, so long that you don't notice that you've been kind of working around this problem. So if you go to a team who is primarily focused on developing product and say this fork is out of date, it's something that needs to get up to date. If it's not going to help them bring something to the customer faster, it's difficult sometimes for them to understand why they should spend time on it. Unless you can capture how much time and energy you're spending trying to work around this problem. Here are the features that we are not able to get because we can't update because we're on this weird fork, right. Sorry, go ahead please. No, no, go ahead. I was just going to build on that to say that one of the the levers that has really helped Dwayne is security and partnering with our security team. They immediately understand that being on a forked version means that you're on an older version that means you're not patched from a security perspective. And so we've been kind of partnering with our security organization, which often has a bigger stick than we do to kind of incent teams or to use a stick if you will to get them to upstream or be on the later version. And the other point I think Dwayne that you were starting to head that direction I just wanted to point out that I think when when people first when developers first encounter inner source and open source like there's this body of code out there. I think the first response that a developer new to this world has is, oh wow, that's my, that's going to get me started. Like so I need a function that does this. Oh, there's one there I'm just going to take it. And I'm just going to start, you know, I'm going to put it in my code, and I'm going to develop all around it. And it's no longer that project and they never thought it would stay that project they just were looking for something to get them started, save them a couple hours of time today. And that's not something that they were going to use from somebody else long term. And then that's where they end up, you know, it's not useful at all. Except for that to save that two hours in the beginning. So, Nithya you mentioned earlier that we've been seeing open source program offices, popping up in non corporate environments like universities and governments, can you talk about why open source program offices are important in those settings. Yes, and I think universities were some of the first ones to start looking at us pose. They approached it, perhaps from an education perspective like Brandeis and others saying, we need to offer curriculum around open source development in our engineering departments. You know, organizations like RIT moved it up a notch and said, maybe we need an Ospo so that we can coordinate open source work across the rest of the university. It's not just about curriculum, it's not just about open source software. It is hardware, it is open data, it's open research and so on and so forth and really educate the rest of the university on how to use open source methods and exploration and transparency in the work that they did. And then there are organizations like cross which is the Center for Research and open source software at the University of California Santa Cruz which said, we had this very successful project in SEF which Sage Wild created and Sage then made it wildly successful from a commercial perspective to the point where you know it's part of Red Hat and it's adopted by so many companies. And so I saw it as a bridge to between universities and companies and creating more software from universities that are commercially viable and, you know, usable and sustainable and also thereby, you know, teaching students to be highly successful and it's a bridge between their student work and company work, right? And so I think universities were some of the first ones to adopt it. I'm seeing a huge adoption of course in governments and you have everything from the European Union's open source strategy document that was published to the US government having an open source strategy, the city of Paris, and go and see it as not just saving money but to be more transparent, build trust with their citizens and stakeholders, and to really allow stakeholders an opportunity to influence how they serve them. Really digital transformation is the reason, right? Even governments are digitally transforming and delivering digital services to their customers and open source allows them to do it faster, cheaper, better, but also more apparently build trust, collaborate with their customers, collaborate and really enable industries in their jurisdiction, enable partnership with universities like I think Johns Hopkins is doing in Baltimore trying to improve the city of Baltimore and the state of Baltimore services. So it's fascinating, it's awesome to see how all of these organizations are doing more open source and doing it in an intentional and structured and programmatic way like OSPOS allow you to do. Yeah, I feel like that's the big difference because it's not like governments and universities are new to open source. I think it's a structure of, you know, putting it into an open source program office that's the bit that feels like it's changed over the past few years. Exactly, and it's sorry Dwayne, I think it's an indication of maturity right Dwayne, I mean to your point about maturity curves. It truly says that and they've seen companies do it and they're leveraging what works for them or doesn't work for them. They are different creatures and different needs. So they're kind of creating their own definition if you will of what OSPOS is. And that was sort of the point that I was going to chime in with that the there's, there's a lot that can be learned from open source program offices that can have been running the commercial space but universities and municipalities have very different motivations that they need to work in very different motivations for doing it. And so there's some things that you can take out some best practices you can take out of how we've run open source program offices, and in our organizations, but we don't have to, we don't have opportunities like the quadrillion of students that are coming through and our large groups of students that are coming through and working on computer science projects that we could mobilize and point towards specific initiatives, and we don't have things like technology transfer and and trying to make sure that the things that we build have an impact on the real world there's just the motivations are so different there. And then when you step into the municipal space and you look at the procurement process that's involved in like if you don't like buying things in your company try buying things in the state. Right. Try buying things at the federal level like there there are our whole processes there that we just don't have experience with or at least to the degree we don't have those problems so there's a lot that can be learned but some of those problems are so different that they do need to evolve their own set of best practices because just specifically because those spaces are so different for each other. There's one more point I wanted to make which is if all of us create open source offices across different types of organizations, it becomes a common language if you will, and a lingua franca to kind of work across businesses to governments governments to universities universities to businesses. So it creates these bridges, which I love, because it creates this common structure common language, and all of us in open source are really the representatives from our companies into the open source community. So it really allows us to collaborate better. And the other additional way that governments are different than corporations is that they have a bunch of companies that they care about in their organization in their, and in their entities in their country or their region that they also care about. Because as I mean, like Don said they've been doing open source for a long time or using it, because I remember talking to like United Nations European Union, like 15 years ago, and at that time their main concern was not like how do we use it, like how do we make sure that our, our member organizations and countries are going to be successful in this new worlds of new technology world and how do I make sure that they're using open source like how do I give them that knowledge. So they have like all our problems plus a bunch more and then our problems again. You hit it on the nail, Starmie. I saw a really fascinating report on measuring the GDP impact from open source and how it allows, you know, countries to grow their economies by enabling open source and kind of reasing the skids for open source for their companies to your point, and create digital sovereignty right kind of company countries are also very concerned about becoming less dependent upon others in some ways and encouraging more creation in their own countries. And Dwayne, you worked in both open source program offices and inner source environments, can you talk a little bit how these two efforts are related or where they're different. Sure, and I'll provide some context for for folks as well. And the time that I've been in indeed my focus has been solely on open source and the time that I was at PayPal, I peered into the organization that also was running inner source was involved in that initiative. From the side and then toward the end was it was directly involved in the initiative so I was very familiar with the the program that was being run there and at the time. Although the the thing that inner source describes is is not new inner source as a term and as sort of the exploding practice that we've seen over the last few years was was was very new. So like, suddenly we have this word for it it's inner source this is what we're calling it right and so I think it makes a lot of sense for your organizations open source and inner source programs to roll up together. Because the techniques and the ways that you go about solving problems you use a lot of the same tools right you are you are relying heavily on the ability to grow collaboration at a project you take a lot of the best practices from how to run an open source project you apply them to how you are going to build proprietary software right and so you're making sure that if a developer shows up to your project, whether it's an open source project or new source project. There's clear documentation on what they need to do to get involved as a contributor there's clear documentation on what the expectations should be from the from the maintainers of that project, or maybe in some cases, you know who the the project are, which is usually an easy question to answer in open source in proprietary software or software that's just being built in your own organization. Not always easy unless you unless you're starting to apply your source principle so there's a lot of the similarity between the principles, but the problems that you're trying to solve are very different. Most open source projects start because a developer has a problem and they're trying to scratch a ditch and they solve the problem for themselves and they share the code with the community. If you're if you're starting an inner source practice in particular, you might have all kinds of reasons for doing it and you're trying to break down silos or at least break holes in the silos and people can reach through and collaborate across them effectively. Or you might recognize that you're a you're a team that is responsible for developing a piece of technology that is in super high demand in your organization and you're getting more inbound feature requests than you can do as a team. And you want to enable the ability for people to self serve into these extra requests that they can get things done for themselves, you know, longer the blocker. Those tend not to be large concerns in the open source community. You generally don't open source something because you can't write features fast enough, right? Or because you're trying to put holes in a silo there's some similarities I guess there between silo busting and maybe disrupting, you know, releasing open source technology because you want to disrupt somebody else's effort but the problem spaces are very different and the motivations are very different behind why you do them. I would say it's even harder to do sometimes because there are such organizational inertias but it comes to how budgets are structured, how people are insented to work within their department lines. And, you know, it becomes harder to motivate teams to actually and discoverability I must bring up discoverability because it's sometimes even hard to know in a very large organization who's working on something similar that you could leverage or use or contribute to or extend and you're duplicating that work and you're kind of creating yet another, you know, library that does the same thing. So solving for cultural and organizational changes is so much more important in inner source. Before you get to the point where you can actually start seeing collaboration happen and silos busted. So it, I agree with Dwayne, the motivations are different, but it is such a huge transformation inside the organization once you start doing it. And you kind of start seeing that you can build more common platforms you can build more collaboration across the organization and reuse and things like that. Yeah, the other challenge to inner source I think is like open source has been around for a while, and we might not all agree exactly on what it is or how it works but we pretty much agree on how it works right like, you know what code you're allowed to grab you if what to expect from that team, you can go and look and see if it's been active or not if they're going to like take your maybe they'll take your pull request or maybe nobody's touched it in five years. I think internally that's much harder. When you're starting out like everyone has a very different definition of inner source I found so some people think it means like codes there that you can copy and paste into your code. So some people think that means you're going to provide binaries that meet all of their accessibility security and compliance requirements. And so setting those, those norms, hopefully we'll set them across the industry but even setting them inside organization is tough in the beginning. We've almost reached the end of our time. I wanted to ask if anybody has any just quick final thoughts last words that you'd like to get out there. If you are at the conference, or you're in front of your computer, please introduce yourself to other people in the audience, feel free to reach out to us. Like, one of the really fun things about open source and really fun things about open source programs offices is that we all talk to each other and we share what we're doing. And there's always someone to ask a question of there's always someone to commiserate with you and something. So take, take the next two minutes and figure out how you're going to meet somebody either in the audience, or one of us. I wouldn't have said it better. I would also say that, you know, organizations like the to do group Osco plus plus, etc, are specifically there to help collaborate across organizations. And as Sami said, none of this is proprietary we want to help you start your open source office, want to help you with lessons learned. So please do leverage the resources that are there online as well as in person. When you see us. I love getting to go last year because it's fantastic. We started with this survey and some observations about the survey and one of those big observations that were there were a lot of new people who were starting or interested in starting open source program offices. And so, in that context, stormy your call to introduce yourself get to know people, I think is is so important. The organizations like the to do group Osco plus plus and the one that the eclipse foundation is spinning up in Europe. All have the same goal of the providing a space where people who are working in open source program offices can share best practices and learn from each other. And everyone on this call has everyone on this on this on this panel has at some point in the last few years, how to sit down with me and shared something they knew one to one. Right. And, and that is such an important part of figuring out where you want to go if you're interested in starting an open source program office. We, we get better at this because we talk to each other because we introduce ourselves to each other we talk about the problems that we're having. And we definitely benefit from the experience of the people who've come before us so. If you are represented in that survey as someone who is thinking about starting in particular if you're thinking about starting and you've got less than 50 people in your organization and you don't have the ability to hire someone full time to open source program office because you're just not big enough. The people who are already doing it are just a tremendous resource and very, very willing to be open and generous with our time so reach out and ask questions we're here to help. Yeah, and I want to plug the to do groups slack because that is a great place to ask questions, especially if you're new to creating an open source program office and that's open to the public you don't have to be a to do group members join the slack. Thank you so much, Dwayne, Nithya and star me. This was, I think a great panel. This was a lot of fun and thank you to the audience and everyone who came to listen to us. Thank you Don for putting us all together. Thank you, thank you Dr foster. Thanks everybody. Bye.