 Hi everyone, my name is Masashita. This is my first in-person open source conference talk, so I'm very, very excited. I joined VMA last July. Before that, I took many different roles, started as a software engineer, development manager, then delivery project and program manager. Worked in IT, semiconductor, telecom sectors at NEC Renaissance, Microsoft, Nokia Broadcom and Cisco, based in Japan, US and the UK. During this period, my experience of open source was not very long time, mainly building the solutions on Linux and Android platform. I led a program to consolidate corporate IPs and open source licenses. I implemented product security and compliance process as part of company acquisition program. Now at VMware, I'm a senior program manager in Ospo's open source community strategy team. I lead continuous improvement of upstream contributions. Today, I'm here to talk about strategic alignment of open source contributions with corporate product strategies, what it is, why and how we do it. So today's agenda is this. So what is the benefit for the company to contribute to open source projects? Why do we align our contributions with company's product strategies? How do we align and collaborate across organization? Which open source projects are strategic for the company? How we define and what we do with them? How do we build a positive reputation on the company? How do we ensure our business continues to be viable with these open source projects? And what is the steps to succeed? So before getting into the main topic, let me quickly go over why we contribute to open source from the company's benefit viewpoint. Our business recognizes that the open source product provides us with first time to market and increase developer productivity by reducing technical debt. More robust and generalized solutions that are verified outside the company. And this enables us to focus on the invest of our uniquely innovative software. We can influence and take leadership in the community by participating in the project. And we'll be able to know what's coming next and where the project is going next. It is important for us to contribute to and influence these open source projects to benefit the greater community. We must recognize that the benefit come with the cost. We don't just use but contribute back to the project. We depend on in order to ensure a healthy foundation for our business. Ecosystem is bigger than us. You don't want to go alone. Together we can create a greater system. We can leverage advanced power behind the community. By engaging with community, you will have access to the feature roadmap of the project, outstanding bugs, security issues and security issues and any license changes that may affect us. We need to know all this information as open source is part of our product. So there are many other benefits but open source contribution is a win-win solution for both companies and communities for a long time. So why do we align our contributions to corporate product strategies? Today, open source is built in all of our products and services and quite often we contribute to the same open source project across different products. In VMware, there are many people who are also working in open source communities. And time to time, they observe multiple people from the same company trying to promote different solutions without coordinating. Broader involvement should occur in a coordinated and thoughtful manner. For the key project that our business relies on, we want to make sure that our contributions are consistent and align with the company's business strategies. In consistency, it can cause confusion and slow down the work. Having a united front in the communities will help us to drive more efficient and effective contributions. So we understand why we need to align with an organization. Now let's talk about how we align. How do we collaborate on those projects across the organization? VMware is a global company. Over 34,000 employees are working across the countries in different time zones. All the solutions and products that VMware brings to the market contains open source. You cannot deliver modern software today without open source. To behave consistently as VMware towards the communities, we need to understand which open source project do we contribute to, who is working on, and in which product. What is the product strategies around the project? Why and how we use them? And what is the dependency on those projects? It is essential to share this information effectively within the organization. We don't want to do this for all of the projects as there are too many of them. However, we selected most important ones for business. These are our strategic projects. So which open source projects are considered strategic for the company? The criteria we set are their key components used in our flagship products, their active projects that regular commits and releases are made, and projects to which employees significantly contribute. With these criteria, we've chosen a handful of most strategic projects that are important for business. Put them in one table. This provides us a holistic view of our key project information, where we can share, discuss, strategy, ask and answer questions from contributors. This table resides in Ospo wiki page so that anyone across VMware can access, easily find and access. There are thousands of conference pages created by different product and the engineering teams. Usually they are different format and the many layers and not maintained. Even with the clever search engine, it's almost impossible to find what you want to find. So Ospo wiki page is the right place for this. We work together with teams who lead these projects in the company, regularly review the content and make updates. We also add a new project when it appears to be critical for our business. The target audience of this table is especially senior leadership, product management and engineering teams to understand which open source projects we have and what we do. This will help them to think about their product strategies and connect with people who are already working on the project in the company. And the link to this information is included in open source tools and product pages so that they can find them at an early stage of development. So what is the benefit of finding, defining a project as a strategy? It enables us to find our most important open source project for our business quickly along with our business unit open source strategies in one consolidated place. This helps us to connect with the right people and the resources for our key project. It drives our consistent behavior to prevent conflicting contributions and this improves our engagement and the influence within the communities which is very, very important for us. So how can we ensure that community contribution reflects positively on the company? How do we build a trust? When the open source is an important part of product we want to gain a deep understanding and have a greater influence on its design. We know that the only way to gain leadership is to earn the role within the community and the great way to do that is to gain credibility through valued contributions. Another example of the importance of internal coordination. One of my colleagues are Kubernetes maintainer and he faced a situation that one of the tech giant vendor was talking about open sourcing one of the components. They was revealed that the component was already open sourced by a second team from the same vendor. Due to a lack of internal alignment both teams has engaged with the community with which led the confusion and frustration. With the consistent approach we can avoid the scenario like this and the reputational damage on the company. So now we have gathered and shared the information for the business critical open source projects and engaged with the communities. But how do we know these projects continue to be reliable and sustainable? We want to make sure they continue to be viable. We want to avoid the case like one day they're not available for anymore. To mitigate risks and grow a business opportunity we will need to regularly assess their viability and engagement level in these projects. Leadership roles are ownership and engagement within the project. Which leadership roles we hold and how many? How many maintenance and contributors we have? Contribution. Update frequency. How often commits and releases are made? Numbers of other contributing companies. Who and how many contribute to that project? Governance. Neutrality. Are they owned by a single vendor or are they belong to a neutral foundation? Governance documentation and security policies. Are they in place? Community. Do they have outstanding issues? How do they meet? How often do they meet? Do they have code of conduct? And how do they look like? We regularly review these items with the teams who lead the project in the company to identify the issues and make recommendations to sustain a future business. Okay, so let's get started. Where do we start? Step one, find the company's most strategic projects, which project we largely rely on to build our products. Step two, get connected with people to share the project information across the organization to learn each other's activities on them. Step three, encourage a consistent contribution aligned with the business goals. Step four, regularly assess project viability and checkup our engagement level within community is relevant. So taking a strategic approach towards open-source contributions will secure our future business. Adopting this approach will streamline our investment and grow our future business opportunities. We can help our product strategies on open-source to align with our corporate strategies to ensure our business is viable, reliable, and sustainable. So that's all for me. Thank you very much for taking time to join. Thank you. Any questions, please? So we keep an eye, is there any new project coming up? And if it's strategic, then we regularly do that. But the table we put in the Oslo wiki, I'm trying to update the company I'm trying to update all the time the update is made but I will go through all the projects. You know, the project I just presented was just part of it but I will go all of them and then talk to the each team every three months. That's the, yeah. Is it prior? Yeah, so there are obviously, there are some, you know, big projects and inference massively like Kubernetes and other main open source but we don't actually prioritize them. I will just go over, some of them are originated by VMware because VMware is quite advanced in open-source in their software. So yeah, I don't prioritize it. I just go through and then I just keep, you know, keeping touch with all the team, point of contact people who are looking after and leading the project in the company. Then whenever it's updated, you know, people leaves and joins and now I just keep an eye on, you know, so that makes sure that anyone who goes to that table will not be lost and then just reach out, you know, be able to reach out to the right updated information. Thank you. Yes, please. Yeah, so we have the list of the project, strategic projects and then, you know, our OSPO leadership will keep an eye on always making sure that the list is always up to date and then sometimes this comes from the developer side. They say, hey, we think this open-source is really, really important and can be strategic. Can you review? And we get that information and we'll review and if it meets the criteria, then we will put in the list. Yeah, so open-source, it's a decision to make which open-source they develop and all these things are owned by the business unit side, not owned by us, OSPO. OSPO provide the best practice and facilitate to help their alignment but actual ownership is in the business unit side. So they will, you know, some of the business unit are very advanced and then their leadership is aware that developers should have a time to contribute because it's really difficult to allocate the time as a part of their work in time. Even they're part of the work, you know, work related open-source. It's really difficult to spend the time to contribute to because, you know, delivery managers often say, oh, don't worry about the contribution, just get delivery done. You know, that's their priorities. But, so we are trying to sort of inference and make their culture changed for the upstream first cultures. So half of them have say in a company, they're still quite not sure about the open-source contribution but some of them are quite advanced and then they allocate enough time for the engineers to make a contribution to the community. Yes, please. I'm sorry, I'm not sure. I take, yeah, can you? Yes. I think I understand what your question. So we have a list of strategic projects and then that's what Ospo is focusing on at this moment because we contribute many, many projects. But for those projects, we regularly assess and check that, you know, how the project is going, you know, is it taking a big part of our business and if we think that why we open source to this project to the community, are we making any benefit or are we making any profit or something? Then if we come to that stage, then we will discuss with the team and, you know, final decision will be made by the team who are using and if it's originated by VMI, then they're the main key player in the community. But I think we have to assess regularly and if there's absolutely no point to open source, if we think, then we probably may think about changing. But so far, I don't think it happens yet but it may happen in future. Thank you. Yes, please. Can you process how to... Take them out or...? Ah. Because I'm here only a year, so I'm not sure that happened. Okay. Yeah. Thank you. Thank you. Any other questions? Okay, thank you very much.