 Welcome, everyone. Thank you for coming to my talk about whether your OSPO helps or hinders contributions. Today, I'm going to talk about how your OSPO can avoid being the office of no, and instead become a strategic partner with the various teams across your organization that are involved in open source projects. I'll also talk about how your OSPO's policies and procedures can help your employees contribute to open source projects or hinder them in ways that maybe you don't expect. I'll spend some time on the individual company and community triad, along with how your OSPO can help people navigate these complex relationships. And then the last section will have some tips for being a good corporate citizen, and then we'll wrap it up with links to resources and a few final thoughts. And these slides are already posted on sketch. So for anybody that wants the links or things later. I'll start by briefly telling you a bit about me. So I have been in the technology industry for well over 20 years, working mostly on open source from within companies like Puppet, Intel, and now at VMware, I'm responsible for our open source community strategy within the open source program office. I'm also on the steering committee for the Linux Foundations to Do Group. I'm a board member of Open UK. I'm a governing board member and maintainer for the Linux Foundations Chaos Project. I'm co-chair of the CNCF Contributor Strategy Technical Advisory Group. And I also went back to school a few years ago and managed to get a PhD, where I researched how people collaborate in the Linux kernel. A lot of people in this room are kind of with me on that journey. I did a lot of presentations during the PhD program. But today, that's not what we're going to talk about. We'll talk about that later a little bit. But we'll start by talking about how your OSPO can become a strategic partner jointly with the other teams that are involved in open source projects within your organization. OSPO's the take a strategic approach to open source can really help your whole organization align various open source efforts across teams and across products to demonstrate the value of the open source work happening throughout the whole organization. It's important to be able to align your strategies and plans for your open source contributions with the overall business goals of your company. If your open source engagements don't support the overall strategies of your organization, you'll drastically reduce the chance of becoming successful. So by taking some time and effort to make sure you support the overall corporate strategy, then it's going to be much easier to justify continuing these efforts during the next planning cycle for your organization. On the other hand, when your goals are not clearly aligned with the overall strategy, people will look at the open source participation as something that they can just cut or stop resourcing. So this will help you make the case of senior management and company executives who aren't likely to be involved in the low level details and explaining how your open source contributions support the goals of the company can help the exact team understand the importance of the work. For many of us, our organizations use so many open source projects that it's really easy to get distracted and just not know where to focus. It can help to think about which open source projects are strategic in some way for your company. Maybe there are some projects that your operations team uses to run some of your critical business infrastructure. Are there development or deployment tools that impact your ability to release the products that generate revenue for your organization? Is there other software that's important in some way for your ability to deliver customer facing products or services? And all of these questions can help you think about where to focus your OSPOS efforts and where you can partner with OSPOS stakeholders. So VMware, I curate a list of our most strategic projects across the entire company. We work closely with our various business units to make sure that we have the right projects on that list. And right now the list has 18 VMware originated open source projects and then another 14 third party projects. And those projects get more attention from the open source program office than the many other projects. And we collaborate with project owners and stakeholders to do high level health assessments and suggest improvements. We also make connections between product strategies and open source contributions to help align contributors from different business units as they work together and help them understand why a particular project is important to each of them to avoid contributors from one organization accidentally doing something that causes issues for another team publicly in an open source project. And then for everything else, we focus on scalable efforts using best practices guides, automation, a Slack channel for general open source Q&A, training regular meetups with presentations and discussions and then anything else we can think of to help our employees do the right thing in open source in a way that scales across the hundreds or thousands of open source projects we're involved in. I see a lot of people getting hung up on what I would call vanity metrics or popularity metrics. So while stars and forks might be super exciting, they don't actually provide any insight into project health or indicate areas of improvement. So it's often up to us in the Ospo to partner with other teams within the organization to help them find better ways to measure project health so they can improve their projects. Project health metrics can help us understand which specific areas of a project are less healthy so we can make improvements and then measure the impact of the changes we just made. And equally important is that project health metrics also help indicate where maybe you don't need to make changes. If some area of your project is healthy and already doing well, you're better off focusing on other areas where you can make improvements. What makes all of this so challenging is that every project is a little bit different and interpretation of the metrics will vary by the project. And this is something that your Ospo can help your teams navigate. So at VMware, we actually have over 10,000 open source project repositories spread out over several dozen separate GitHub organizations. We also have hundreds or thousands of contributors, maintainers, product managers, engineering managers and others who care about the health of specific open source projects. So the dashboards we drive from the open source program office, the metrics dashboards had to be simple enough that absolutely anybody could use them. So I built something very simple using Augur from the Chaos project. However, we have quite a few of those strategic projects that I just talked about. And those require more detailed metrics. So we often consult with other teams as they build out more detailed solutions for their projects. We have teams using Viturgia, which is based on Chaos's Grimoire Lab tools. And we have other teams who are doing more custom metrics using mostly the GitHub API. And this is something that we encourage teams to do. And we often connect teams to each other to collaborate across groups. And likewise, your Ospo can help make those connections across teams. Creating Ospo policies and procedures is a balancing act. On the one hand, you need some controls in place to make sure that you protect your company and avoid lawsuits. But you also need to make it easy enough that you encourage employees to contribute new features, bug fixes, and patches back upstream into the projects. And rather than being the office of no, your Ospo can be a resource for your employees to get help and guidance for their open source efforts. It can help to think about your policies and procedures from the standpoint of risk versus reward. And again, it really is a balancing act. There are some places where you need to have strict policies, but other areas are better served by having guidelines and best practices that help people do the right things without too many restrictions. For example, license compliance is something that requires strict policies and procedures that make sure everyone is following those policies. Because complying with open source licenses is not optional, it is a requirement. And not complying opens you up to lawsuits and can damage your organization's brand. So this is a big risk, but using open source has plenty of rewards. So then on the other side, allowing employees to contribute to open source projects is a lot less risky and also has again, significant rewards. So guidelines and best practices are probably more appropriate. And I'll talk more about all of this on the next few slides. Most of us regularly incorporate open source software within our products and services. And this is probably the area where your Ospo needs to have the strictest controls in place. The use of open source components allows us to better innovate, we can accelerate software development efforts so that we can better meet the needs of our customers. And while this is really beneficial, responsible use of open source requires diligence and accountability to ensure a successful navigation of this complex open source world of usage and license obligations. Your open source policies can help ensure that product service and other teams meet your quality and security standards by requiring identification of the exact source for all of the software you ship. And it's critical that you have strict policies and procedures that allow you to identify the exact source code for all of the open source project you ship. The source code prominence is necessary to make sure that you're adhering to the licenses for everything, as well as subsequently being able to track and remediate open source security vulnerabilities in those shipped products. And this helps avoid lawsuits and damage to your brand that can result when you aren't complying with open source licenses. Having good tooling can help make it easier for your employees to comply with your policies. And this is an area where your OSPO can collaborate with other teams and be seen as a strategic partner in this process. Spend time working closely with other teams to figure out what part of your compliance processes are causing the most pain or causing additional work for other people. And then put automated tooling in place to make it easier for these other teams. There are loads of compliance tools available and using them to resolve pain points on other teams will help people see you as a strategic partner who listens to people's concerns and works to help make things easier for everybody. Now in contrast, contributing to open source projects is one area where you don't need to be as strict. If you make it easy for your employees to contribute, your employees are more likely to reduce technical debt by contributing patches, bug fixes, new features, back into those upstream projects where they belong. If you have too many controls and strict processes, you're probably making a lot harder for your teams to do their work. And you should think about whether your guidelines or processes help people engage in open source projects in ways that work well for your organization. While you do need to provide guidance for things like licensing, avoiding accidental disclosure of confidential information and maybe internal review processes, this can be done in a more educational way. Now my caution about guidelines and processes is that they can be written in ways that discourage contributions, especially when they heavily use really scary legal jargon with an emphasis on how you're gonna punish people when they do something wrong. And instead, you're better off writing the guidelines in ways that help engineers understand what you need them to do and why and language that they can easily understand. Now VMware, we have a really robust set of open source guidelines and a very lightweight approval process for contributing to open source projects. So before an employee contributes to a new open source project, we run those through a really quick approval process to make sure that the project is indeed an actual open source project with an appropriate license attached to it. And then the OSPO handles any legal paperwork that might be involved, like signing contributor license agreements if they have them. And this frequently takes maybe a day to complete. This isn't hard. And it allows people to get started quickly. And then once someone has that approval to contribute to a project, they can continue to make as many contributions they'd like without any additional approvals. Now, here in the middle, creating new open source projects requires a bit of nuance and collaboration with your teams who want to create them. The amount of process required for this falls somewhere between the strict requirements for compliance and an educational guidelines approach to contributing to existing projects. And this is an area where your OSPO can provide guidance and help other teams think through the decision to create a new open source project. Because you want to make sure that you're open sourcing a project for the right reasons. A desire to collaborate with other people and innovate on your project. That's a good reason to open source it. If a project needs to integrate with a whole bunch of other technologies, open sourcing it can make it easier for people to help you integrate it with technologies that you might be less familiar with or don't have access to. And sometimes a team will want to open source a project because it has no users, nobody wants it, it's old, it's crusty, and they just don't wanna do anything with it anymore. Don't do that. So dumping your project into the open source community when it's old and crusty and nobody wants it is just gonna make your company look bad. Nobody wants that. I also occasionally see teams who want to open source something to get some press attention or for marketing purposes, which is also not a good reason to create a brand new open source project. The team open sourcing a new project should be prepared to maintain that project over the long term. Just like they would for something released under a proprietary license. And this effort just is not worth it if all you're trying to achieve is some short term marketing win. Maintaining an open source project will take time and resources. So teams need to plan for that. And if they aren't willing to make that long term commitment, it might not be a good candidate for an open source project. Let's talk a little bit about how collaboration works within open source projects and how your Ospo can help your organization make sense of this complex interactions that you see between individuals, companies and communities within every open source project. While there are some exceptions, contributions to most open source projects are centered around the individual. Contributions come from individuals rather than companies. When someone submits a pull request to fix a bug, add a feature, or update some documentation in an open source project, the change comes from that individual. Commits usually include a name and an email address. But in lots of cases, unless the person uses their corporate email address, you can't even tell where they work or really who they are. At VMware, we do ask people to use their VMware email address when contributing to open source projects as part of our Ospo best practices documentation. But to make all of this even more complicated for companies, in most open source projects, the leadership positions stay with the individual when that person changes jobs. So this means that an employee will take their leadership position in an open source project right with them to their next job. And it's important for people, especially your leadership, to know how this works, to avoid disappointment later. And your Ospo can help with this communication and help with setting expectations across your organization. In most projects, there really aren't direct ways for companies to participate or contribute other than dedicating time from individual employees who contribute on behalf of that company, which is pretty common. At VMware, we have people working full-time on projects like Spring, RabbitMQ, Kubernetes, and a bunch of other things. And in addition to devoting time from your employees to the project, companies are also in a position to help open source projects by providing additional resources. Open source projects need funding or in-kind sponsorships for loads of things like infrastructure, legal fees, and they also appreciate sponsorships for events and other activities. Your Ospo should work closely with other teams within your company to help them understand the resources that open source projects need and make sure that your teams understand how to work with an open source project in ways that reflect positively on your company. Open source communities include a wide range of individuals who are working together within open source projects. So this includes developers, release teams, translation, marketing, community managers, writers, users, other people who contribute to the project. And many of these people contribute as part of their day job on behalf of their employer and others contribute in their free time and they're both important. And all of these people are working together as one community to accomplish a common goal to deliver on an open source project. So it's important to remember that the community or project needs have to come first. If your company has something specific that you want to contribute to an open source project, that is only going to work if it's also something that the project and the community actually wants. Individuals and companies cannot force a project to take a contribution that goes against the direction of the project or isn't in the best needs or interests of the community. It's better to find ways for your needs to align with the needs of the project. And this is another opportunity for your OSPO to partner with the other groups within your organization to make sure that they understand this dynamic and by working to make sure that they're supporting the needs of the community when making contributions. Part of the role of the OSPO can be to help everyone navigate balancing this triad through education and best practices. The various groups within your organization really do need to understand that they can't just push features into open source projects unless it's something that benefits the community and the project as a whole. And when companies try to do this, it puts the individual contributors into a no-win situation. In this no-win situation, which impacts employee satisfaction and retention, the employee can't meet the needs of the community without jeopardizing their employment and you don't want to put individuals in this situation. And by making sure that your managers and leaders understand this dynamic, you can make sure that your individual contributors are doing work that meets your organization's objectives while also being good corporate citizens within the community. Now, let's talk in more detail about being a good corporate citizen to avoid some common but embarrassing mistakes. Your OSPO should be thinking about ways to help the rest of your organization do the right thing when participating in open source by providing guidelines, how-to documents, best practices, training, mentoring, and loads more. You should encourage people to spend whatever time it takes to fully understand the contribution guidelines, the code of conduct, and other expectations for collaboration within the project. The expectations for contributors are different for each project. So people shouldn't assume that they know how to contribute even if they have experience with other open source contributions. I also recommend that people take some time to lurk in the community like this little kitty lurking in the grass to understand how people participate. I've seen too many overeager new community members jump into the community with both feet. They make mistakes by violating community norms, talking about things that aren't relevant, and just generally kind of making a mess of things. Now, everybody makes mistakes at some point, but a lot of them can be avoided just by taking the time to learn about the community rather than barging in and trying to be an active participant on day one. Encourage people to sit back while they learn from other community members. By taking this time to observe and lurk for a bit, your employees can learn about how people behave and get a feel for how people typically respond. And this is a good opportunity for your Ospo to mentor people or help them find mentors in other teams to help navigate how to participate in a new community. It's also good to start with something small as a first contribution. I have seen way too many companies spend a ton of time working on some huge new feature internally, and then they dump them into the community as one massive contribution that no one was expecting, and frankly probably didn't want. And in most cases, this is just a huge waste of time for everybody involved, since that contribution is unlikely to be aligned with the project goals or the expectations for contributions. So you're better off encouraging people to start with some small things like bug fixes to learn about the contribution process. So every contribution is likely to receive feedback. Sometimes this feedback will be kind, other times not so much. It's important for people to remember that every interaction within an open source community, positive or negative, can impact the reputation of that individual and your organization. And again, this is where your Ospo can help by offering mentoring around how to respond to difficult open source feedback. It's better in the long run for the person to wait to respond until they can cool off a bit. Because even when the feedback is harsh, there will be things required to rework that contribution to make it acceptable. So it helps to stay focused on what changes need to be made. And in some cases, this might require hard discussions with people about the contribution, but it can help to focus on the problem and deliver the responses with a bit of kindness while avoiding any attacks on other people. It can also help to have someone else read your response before it's posted publicly to catch any issues of tone that might make the response sound more harsh than you think it does. And this is a difficult line to walk sometimes, right? But staying professional and being kind to other people when responding to difficult feedback can make a big difference in the personal reputation of your employees and the reputation of your organization within these open source communities. And in many cases, especially when someone's new to a community, they really should expect to iterate on that feedback. So after changes are submitted to accommodate that first wave of feedback, there's likely to be more feedback on the new changes. So just consider it an iterative process. This also means that people should plan for the time it takes to get multiple waves of feedback. Submitting something at the last minute before a release window closes and expecting it to be included is just going to be frustrating for everybody involved. So allow plenty of time for multiple feedback and resubmit processes. You'll want to make sure that your contributors spend time discussing proposed changes in the community before they start making them. By talking about contributions very early in the process, they can get feedback on ways to architect those changes so they'll be consistent with the expectations of the project. It's also an opportunity to learn about anyone else who might be doing something similar to hopefully avoid conflicting changes that might not work together when they're merged into the project. And these discussions also avoid surprising people, especially for new features or other really big changes. Your employees should also understand that it can help to break big changes into several smaller, easier to digest contributions. It's a lot easier for maintainers to provide feedback on smaller contributions and it gives people more time to make corrections if something they did wasn't quite right. It's also important for everyone to keep in mind that you have absolutely no control over any of the other participants in the project. Now this is different from working within a company where if you have a non-responsive employee, you can escalate things through management and managers do things to get people to respond. In open source projects, that's not how this works. You don't have a strict chain of command or other ways to exert control over the people you collaborate with. Instead, your contributors should strive to be kind and easy to work with since you will need to find other ways to influence people to respond to your pull requests or your patches. And by offering best practices and mentoring, your OSPO can help your organization understand how to work within these communities. A lot of the work that we do in open source projects is based on the relationships we have with other people. So I mentioned before that I did PhD research a couple of years ago and as part of that research, I interviewed a bunch of kernel developers and in all of the interviews, they talked about the importance of their relationships with other people. Almost all of them talked about how existing relationships made it easier to collaborate with others. All of the people I interviewed mentioned in-person collaboration at conferences and other meetings as something that was important. So we're happy to have the in-person conferences back. People talked about how it was just sometimes easier to work through really big, difficult kind of hairy issues together in-person at conferences. And it's easier to communicate with someone online if you've met them before and maybe shared a meal or a drink or just had a really nice conversation with them at the event. Knowing the human being on the other side of the keyboard can make a much bigger difference than people might realize. So if your employees are working on open source projects then you should see if there are any conferences where large numbers of other community members attend. By having some of your key employees attend those conferences, they can build deeper lasting relationships with other people that will benefit your company and your other employees. And your OSPO can help facilitate this, at least maybe for some of the key open source conferences where you might have contributors from multiple groups involved in related projects. At VMware, our open source program office sponsors and coordinates our participation at a few key open source conferences like these open source summits, for example. But we rely on our various business units to sponsor the events that are key to their business or their product strategies. Now I have spent a lot of time, maybe an embarrassing amount of time at open source conferences over the years, but I have deep and lasting connections with people that I've met at those events. And now when I need to do something new or have a question, I usually know someone who can point me in the right direction. And I often make introductions to other employees, to people outside of the company who can help us learn something new or maybe solve some tricky issue that we need some help with. Upstreaming your patches helps you become a good corporate citizen. It also has quite a few internal benefits for your company. When you maintain patches internally, every time the open source project releases fixes or other updates, you need to go through the work of reapplying your patches and possibly even rewriting some of those patches if they touched bits of code that were changed in the update. And the side effect of this sometimes difficult process is that people tend to put off applying updates, which can be a huge problem if the updates contain security fixes, which they probably do. And while it takes more time upfront, you're better off encouraging your employees to take the time to submit these patches into the open source project where they can be properly maintained as part of the project and where other people can benefit from them. And the easier your OSPO can make it for your employees to contribute these changes back into open source projects, the better off you'll be. And in general, upstream patches kind of consider the right thing to do in open source projects, which again helps maintain your company's status as a good corporate citizen. Understanding maintenance expectations is also a big part of being a good corporate citizen. Putting large chunks of code into an open source project, disappearing and expecting someone else to maintain it, reflects very poorly on your organization. If you fix a small bug or make some minor changes, you're not going to be expected to maintain those changes since someone else is probably responsible for that thing that you fixed or tweaked. Where you really need to think about this is when you're making large contributions. I can see the sign that said minutes, but your hand was over the minutes. Thanks. Where you really need to think about when you're making large contributions, like a new feature or a new driver. You need to make sure that your employees are planning to maintain the code over the long term before you contribute it into an open source project. And this is something your OSPO can help people understand via best practices or mentoring. Before I wrap this up, I wanted to leave you with a few resources you might find useful. Again, these slides are already on schedule, so you have those links. The to-do group, of course, has loads of guides with great info about all aspects of creating and managing open source program offices and open source projects. The CNCF contributor strategy, technical advisory group, has templates and guidance about contributor experience, sustainability, governance, and openness to help people develop strategies for maintaining healthy open source projects. The open source way guidebook also has loads of details about building and maintaining open source projects. And these are all great starting places for understanding how your OSPO can help your open source contributors. The work that we all do within open source communities is in the public, and it's highly visible. Other contributors and the press will talk about your behavior and your participation, which can reflect positively or negatively on your organization's brand. And your OSPO can provide resources to help your employees contribute. And while by being a good corporate citizen with an open source projects, you can help make sure that your participation has a positive impact on your organization's brand. With that, thank you for coming to my talk and we can open it up for questions. In your comments, you may have said not to like release all of those, which I think I have seen in terms of all, but like... Oh, thank you. So in a previous life, I worked at a very large company where we had old proprietary software that I don't know how many people cared about it, but we were trying to determine whether or not to release this open source, not because I wanted anyone to maintain it, but for disclosure. So what are your thoughts on that? Yeah, that's a good question. So generally, what I don't recommend is releasing something into the open source if it doesn't have any users and no one cares about it. So assuming that that software had users or people cared about it. We did at one point, but people were complaining that the file formats that were used were not documented and things like, but by releasing the tooling, we would have documented it like because it would have been in the code. That was kind of the thought then. We ended up not open sourcing at that company, but... Yeah, I think it kind of depends. And I think the key to doing something like that is setting expectations, right? So if you are releasing something, just provide some transparency into actually what it is and some of the file formats and things like that, but you're not planning on updating it or releasing security fixes. I think as long as you set those expectations and maybe put it in an archival mode so that people don't think that you're going to continue to update it and maintain it. Right, okay. And my real question is that I'm now at a startup where open source is key to everything we do. We're actually a silicon vendor that's trying to do everything from end to end in the open. And I sold the company very early in my role that we need an OSPO. And I don't know where to get started by building that into the DNA of the company. And were some of the links that you just had, would those kind of walk us through that process? Some of those will help. In particular, the to-do group guides will help with that. I also, did you listen to the keynote, Christine's keynote earlier today? Could you talk about F5's journey into open source? So that's... Well, I heard that. That was more of like a trans-mort formative type of story. And I'm more interested in like, we are starting from the ground up with this. And so what are their best practices in terms of pick this thing to focus on now versus pick this thing later and things like that? Yeah, and what makes this difficult is it depends a lot on your company and how you're using open source. But a lot of the open source program offices kind of start around compliance. Okay. And because that's probably, that's the area that's likely to cause you the most trouble if you don't get ahead of it. So what you don't want to get into a situation is lawsuits that are gonna bankrupt your startup. So compliance is probably a pretty good, pretty good place to start. And then from there, you can start expanding out on it and start looking at how you handle contributions to things, how you handle the process of open sourcing new projects. All right. Thank you very much. Yeah. Other questions? So you said upstream everything. Are there any examples where you don't want to upstream? Yeah, sure. So if you've had to make a change to an open source project that you've had to do in some, how do I say this? For something that's like confidential to your company, then you don't want to upstream that, obviously. So what you wanna do with that is you're gonna have to just continue to maintain it. Hopefully you don't have to do that. But I would say the only real reason to not upstream something is if it's, if it's something that you are going to patent or if it's something that's confidential to your organization. Those are the only things that I would tend to not upstream. And realistically, nobody else is gonna care about the stuff that's proprietary for your company anyways. Other questions? So the question was, is there anything unique to an ISPO, which I'm going to assume is an Innersource Program Office as opposed to an Open Source Program Office. Full transparency, I have never worked in Innersource Program Offices or on Innersource efforts. So I assume there are probably some nuanced differences. Innersource Commons is probably a good place to learn about those. Yeah, I wish I had an answer to your question, but I just don't know that much about Innersource. I suspect there are some differences that are kind of nuanced. Okay, no problem. Yeah. Just the second one I had was, is there anything else you can include within the repos other than the read me and contributing file that would help them from an OSPO perspective? Why comes to contributions in general or onboarding? Yeah, I mean there, so contributing guide is a good place to start, code of conduct, that's kind of a default. And there are loads of things you can include in your repo that will help people contribute. So some of the things that we recommend for CNCF projects is to have things like value statements, scope statements so that people coming in new to your project understand what types of things are in scope for this and what types of things are out of scope. So they don't waste time trying to contribute something that's just out of scope for the project. Architectural information is always good because that helps people kind of see the big picture. And then if your project is complex in some way or you're really trying to encourage new contributors then having some specific documentation that's separate for new contributors like new contributor onboarding documentation that can really help. And then just in general having good technical documentation about your project. So just having good docs in general can really help with contributions. And in particular, your read me or your contributing guide should really have a lot of details about how to build it, how to get started, how to make your development environment because I see a lot of projects that it's just like hey submit a pull request and then I look at it and I'm like wow this thing is super complicated and there are no instructions for how to build it or how to test it or how to run it. So really think, and this is hard for those of us that have been in open source projects for a long time, especially the same project, to step back and like if I was brand new to this project what would I need to know to build my development environment and contribute to it? And sometimes it can help having new people look at it and tell you what that is. But yeah, so those are kind of things I would focus on. Oh, tell me to stop. Oh, okay, okay. Matthew. Sometimes the best path forward is to fork, oh, don't shout now, that's wonderful. So you've talked about starting a new project and you've talked about contributing to existing projects. Sometimes the best path forward is to fork an existing project and be very public. This is a fork and it's an intentional fork and here's why it's a good idea. Is that somewhere that you think OSPO has a role or do you think that should be down to the individual department that's going to be making a contribution? I would definitely say that the OSPO has a role there, mainly in having that discussion with the team that's trying to do that to make sure that that really is the best decision because sometimes people will fork a project because it's the easy way out. They might have other options that they haven't really thought about. There might be other solutions that they can use and I think that the OSPO can help them navigate those discussions because forking a project and taking it in a different direction is a lot of work and I think a lot of teams underestimate the amount of work that that's going to happen. And realistically, generally the only forks that have been successful over time have been the ones where the community forked with it. So you think like MySQL to MariaDB, open office to LibreOffice. It's a lot harder to fork a project and make it successful when you don't have any of the original developers, which is generally what happens when companies try to fork it. So just think hard about that decision and the OSPO can help navigate that. Okay, I'm out of time. Thank you everybody for coming. Thank you.