 Hi everyone, welcome. Thanks for having me and thanks for joining. This is my first open source summit in Japan, my home country, so I'm super excited. Today I will talk about strategic alignment of open source contributions with corporate product strategies. So let me share the agenda. Firstly, I will quickly walk through why a company contribute to open source and what kind of benefit the company can get from it. Then moving on to why we need to align our contributions with the corporate product strategies, how we work on the same project, collaborating with multiple teams within the same organization. Then I will identify the company's strategic projects, which open source projects are important for the company and can be considered as a strategic force. After that, I will talk about company open source reputation and project viability, how we build our open source reputation with the ecosystem, and how we assess our key project health and its viability. Finally, I will wrap up with a summary of key points and the actual steps to achieve the alignment along with the final thoughts. So let me talk about myself, my journey to come here, and my involvement in open source. I'm a senior program manager at VMware in the Osbo open source community strategy team. I lead strategic alignment between our contributions and our business strategies working with our product and engineering teams across the organization. I was born and grew up in Japan and studied engineering at university. After this, I joined the global technology company as a Windows software developer for four years, spending much time in Tokyo and Seattle. Then I had an opportunity to lead the UK team for 3G form protocol stack integration. At that time, I met my English husband and moved to the UK where I led Linux and Android based tablet development as a software development manager. This was my first contact with open source, working on Linux, BSP, SDK, JDK, and entire Android platform. After the company closure and the year out to look after my son, I decided to change my career from telecoms to cloud technology as everything was moving to cloud. Then I had an opportunity to lead a large scale company acquisition program at Cisco. This was a great move as it provided me an experience of cloud technology and working across many business functions. Moving up to date, I've led several digital transformation programs and have been at VMI for just over two years. So today, nearly all enterprises use open source with more and more using it strategically. It's a kind of unique tool to engage with developers, users, and customers. And it plays a critical role for the customers who are seeking flexibility. Not only the solution flexibility, but also the commercial flexibility as it doesn't require formal agreement that would be needed for appropriately software. So why should a company contribute to open source? What are the benefits for them? It's well known that the open source provides us with faster time to market and increased developer productivity by reducing technical debts. We can get more robust and generalized solutions that are tried and verified outside of the company. And this enables us to focus on the investment of our uniquely innovative software. It can create feedback loops benefiting from outside perspectives. We can work in the company, our community, benefiting from a combined workforce, making best use of our time and resources. Another benefit for the company to contribute to open source is to be able to influence the project direction. For example, they can influence what features should be implemented next. We need to bear in mind that these benefit come with the cost. We don't want to just use it. We want to contribute back to the project. So that the project we depend on in order to ensure a healthy foundation of our business. The ecosystem is bigger than us. We don't want to go alone. Together, we can create a great system. You will end up working with a collection of other companies, individuals, your competitors or together so that we can leverage that the balanced power behind the community. By participating in the project community, you have access to the feature roadmap, details of outstanding bugs, potential license change, security issues that may affect the business. We need to know that all this information because open source is part of our products. There are many other benefits to contribute to open source. It's a win-win solution for both communities and companies for their long-term success. So why do we align a contribution and our business strategies? At VMware, open source is built into most of our products and solutions and people continuously upstream their code. Some projects are massively popular and quite often they're used in multiple products across the same organization. We have many people who are also working in open source project communities and occasionally they observe multiple people from the same company, trying to promote different solutions without coordinating internally. Here, broader improvement should occur in a coordinated and thoughtful manner. When we were working on the key projects that our business relies on, it is important to make sure that our contributions are consistent and aligned with our business strategies. Inconsistency can cause confusion and delay. Having a united front in the communities will help us to drive more efficient and effective contributions by working towards the same business goals. Our investment in open source serves our business and open source is built on relationships that take a long time to build. So we need to set the expectations for our commitment over that time. So now let's talk about how we align. How can we collaborate on these projects across a big organization? VMware has tens of thousands of employees working in a different time zones across many countries, like all the other global enterprises. And all of the solutions and products that we bring to market contains open source. In order to drive our consistent behavior as one company towards the communities, firstly, we need to understand which open source project does our company contribute to, who is already working on them on which products. What are the strategies, why and how we use that project, and what is the dependency on these projects? We don't find answers to these questions for all of our open source revocals, as there are too many of them. So we will try to select the most critical open source projects for our business to focus on. We can call them as strategic projects. So which open source projects can be considered as a strategic for the company? If your company is like most others, there will be many open source projects built into your product, but not all of them are critical. There are three key criteria that we use to identify our most strategic projects. Number one, the key components that are used in our flagship products, which open source components are critical for your product portfolio. Number two, the projects and technologies that are likely to be important for our customers in the next few years. You will need to keep an eye on what projects are going to be important in future. And number three, they are active with significant contributions by your employees with regular commits and releases. With these criteria, we have now chosen a handful of our most strategic projects. The slides shown only a part of them. The next step is to identify people who are already working on these projects within your organization. Reach out to them to better understand the company's work and community roles to work together. Then document all of this information into a single table that all employees can easily access. Some are like your company with Pitch. For consistency, it's best to centralize this activity in a company. We have done this in our open source program office because most projects are likely to touch several business units and all different product teams. This single table provides a holistic view of the company's key open source projects, allowing people to learn, discuss, strategies, and ask questions all based on the same information in one place. Typically, a company has many internal conference pages created by many different teams across many different business units. And their format is not always the same and some of them are complex multi-layered structures. Even by using the search engine, it can be almost impossible to find the information you want. The biggest challenge with this type of information is to make sure the content remain up to date. As a Osmo program manager, responsible for curating this information, I regularly work with the teams who lead these strategic projects to review the contents and make updates. We also keep an eye on our product roadmap so that we can add new projects when they start to become more business critical. This also gives us an opportunity to rethink about product strategies around open source. Discoverability is also key. There's no point to keep this information without it being found and used by people. In VMware, we encourage people to review this table before they actually submit the stream contributions. And this process is also captured in our tools and our open source guidelines. So this is the actual example of the strategic project alignment table. The table was created in the Osmo's Wiki page and each business unit has a link to this table from the conference pages, from their conference pages. The main contents are project name and overview, key products that use project and product strategies around project, why they decided to use this project and what's their short and long term goals. Leading be a point of contact so that people who want to contribute to this project, they know who to contact within a organization. Leadership positions that our employees hold, this is important because you will be able to know the size of the influence that company, your company can make into the community. And the remarks for new contributors, anyone who wants to contribute to this project, this is a new starters guide. And project dependency and many more other information in the table. So now we've now identified our key projects, recorded and published the information together into a single table in an accessible location. But what are the benefits of doing this? Why we do this? It enables us to find our open source project that are the most important for the business along with our open source strategies defined by each business unit. For example, our executive senior leadership who don't have much time to research the information from scratch, they can quickly understand our open source project landscape from here. And it helps us to connect with the right people and the resources. We can find the right communication tools, emails, suck channels and get started page in the most efficient way. It also provides us our consistent behavior to prevent conflicting approaches by discussing with the people who are already involved in the project. So with this single strategic project table centrally stored, we can drive internal alignment to improve our community engagement, which is critical for our business. There's also a benefit to the company open source reputation. It is important that our community contributions reflect positively on that company. How do we build trust in the community? As said earlier, open source investment serves our business and open source is built on relationships that take a long time to build. Also, when the open source is an important part of our products, we want to gain a deep understanding and have a greater inference on its design. We know that the best way is to participate within the project by earning the leadership positions within the community. And the greater way to do that is to gain credibility through the valued contributions. Here's another example. Here's another example of the importance of internal coordination. My colleague is a Kubernetes maintainer and he faced the situation where the tech giant vendor was talking about open sourcing, one of their components. Then it was revealed that this component was already open sourced by a second team from the same vendor. Due to a lack of internal alignment, both teams had spoken to the community independently. This led to confusion and frustration, both in the community and across the internal teams. So with the clear internal alignment, we can avoid a scenario like this and avoid reputational damage to the company. So now we've identified our business critical open source projects, people and the resources, and we have encouraged employees to collaborate using centralized information before they actually engage with the communities. But how can we guarantee that open source in a product will continue to be available for us in the same way as today, aligned with our portfolio? If these projects are no longer maintained or if we don't understand the entire project, we will be unable to support our customers. As open source projects are maintained by the communities and because we are part of the ecosystem, we need to continuously assess their long-term viability to ensure they will continue to be available and successful for business and for the ecosystem. In order to mitigate the risk, we should regularly assess project viability and the engagement level within the project. We need to ensure the project continues to be successful, not just for our company and our customers, but for the entire ecosystem as a whole. So we know that the good open source projects understand their target audiences that they want to work with. They openly share their plans and resources, demonstrate healthy governance and community, to attract people to achieve their goals together. On that basis, we have identified four key areas with respective criteria. Project maturity, project planning, transparency, activity status and documentation adequacy. Does your project share a clear roadmap and a plan? Does it provide an adequate documentation set to enable you to develop and build on the project? Project governance impartiality. Is the governance spread across a variety of organizations to represent the ecosystem needs? Has the project defined clear roles and decision-making process? Project community, openness, adopters. Does the project have an open communication channel and hold regular meetings? Is the project adopted by many organizations in the ecosystem? Organization's engagement level. Does your team engage enough to understand the entire project? Does your organization hold any leadership positions in order to be able to influence the project direction? By breaking down each of these areas, we have identified a set of color-coded assessment criteria to be able to indicate the project assessment status. So let's recap and summarize. How can we get started? There are four simple steps to follow. Step number one, identify the company's most strategic project that we largely rely on to build our product and solutions. Establish your central place to store project information and maintain it. Step number two, get connected with people who are already working on the project to share the project information and its strategies across the organization and learn each other activities. Step number three, encourage our consistent contributions behavior aligned with our business goals. And finally, step number four, regularly assess its viability and the relevance of our engagement level within the project communities. And this is the Japanese translation. So my final thoughts. Taking a strategic approach towards open source contributions will secure our future business. We align our open source product strategies with corporate strategies. Adopting this approach will streamline our investments and grow our future business opportunities. Through effective open source collaboration, we can align our corporate strategies and community goals, along with ensuring our business continue to be viable and sustainable. By working together and innovating within open source communities, you can help the success of the project, not just for your business, but for the entire software ecosystem. Well, thank you. And that's all from me. And now I'd like to invite your questions. I'd like to also hear that what your Ospoor organizations do to contribute open source strategically. Any questions, please, in either English or Japanese, please. Thank you very much for your presentation. And do you have any difficulty when you establish your internal communication with different, from different members? OK, so this presentation is basically to try to coordinate internally across the years, different years, you know. So when I had, so firstly, I have created the table which is sort of a focal point to everyone to look at that project. And then as everyone is looking at the same information and so firstly, it can break the, it will help to, for people to have a first thought towards the project. Now the next step is that people who are working in the project from the different teams, different business unit, there are some projects which are like that, not all of them, but some of them. And yeah, this is actually, this table creation is started from that issue because people just do what they want to do and they're not aligned. So what I do is to regularly meeting with them, the teams who are contributing to that project. We also have the contribution, upstream contribution tool which captures all the contributors towards that project. So I will actually be able to see who I actually contribute into. So in other words, I know it, then I will work with the team and then try to invite all these teams regularly and get together and talk about what we actually do. There are many teams, but there are one or two teams who are actually leading that project of development and some are sort of not leading. I will be able to know that because they will also tell the which type of community roles they're taking, like steering committees or maintainers or TLC in the communities. So I will invite those people and also invite the less experienced teams together so that they will be able to talk together. So yes, the answer is yes, I had a problem before, but after creating this table and after coordinating the regular meetup, it's much less. Thank you very much. Thank you. So my question is, well, to put it into context, my experience is that various product teams will use open source projects to include in their products based on their specific needs or specific developer preferences. That also creates a push to be contributing to different projects that might have an overlap in scope. Do you have any processes to align that the same team use or different teams uses the same preferred software set that you can spend your contribution resources sort of towards the same project rather than spend it three or four or five different ways? Everybody has an in a source in parallel with this. So yes, we try to capture and cover and also our team of technical teams who are actually contributors and the maintenance of each communities and then they are actually involved and deeply involved in discussions to try to resolve these technical conflictions. And then your question, do we have any kind of tones or... Preferred supplier lists kind of, but for open source components. If I take an example from my own companies that we probably have upwards of 15 different databases, open source databases that could be deployed Cassandra or whatever. And that this leads us to contributing to perhaps five or six different open source database projects, which is sub optimal. Preferably we should be contributing to one, perhaps two and spending developer time there instead of sort of spreading ourselves too thin. So do you have such a preferred supplier list or is that not a problem for you that you're seeing? There's some of the other members in Oxford but at this moment because I am a strategy community, community strategy member and then trying to sort of align. So maybe in a one step deeper level, there will be some activities that my technical center members are tackling. But for myself, I don't have that experience. Thank you. Thank you. Thank you very much. And my question is, does your company has a global ospocheme or isolated ospocheme or ended? If you have a global ospocheme, how do you collaborate in the global ospocheme? Yeah, and we have many offices across the world and then our ospocheme consists of US and UK, Bulgaria and other countries as well. And so the answer is yes, we have a global ospocheme but not every single countries. And then for example, we don't have an ospo member in Japan but I'm based in UK. Yeah, yeah, yeah. So yes, I have questions from, because our Japanese office are mainly facing to the customer support, customer solution support. And then I heard a couple of times the questions from them. So I'm trying to sort of create the bridge between the Japanese team and the ospocheme because they have some questions but they're usually related to the licensed compliance side. So I will connect those teams to the compliance team. We have, our ospocheme consists of community strategy team that is me and also the compliance team and also technical team, technical center. And then I'm trying to sort of align and connect people across the organization, across the multiple countries to the right people. So we are the focal point of the open source. So when they have any questions, they reach out to me, sorry, to our ospocheme and also our ospocheme has a Slack jam on open source. It says open source. So if anyone has any open source related question, they just send a message to the Slack then we are always watching that message. So we're trying to connect and answer to the question, connect to, sometimes we have a very complicated legal questions then I will try to connect those people to the legal team directly. So that's what we do. Thank you very much. Yeah, thank you so much for your presentation. You introduced four steps to focus on the project and I think the first step is identify the important project. I think for example, this is a big project like a Linux foundation project. This is very easy to evaluate. But some project is, for example, early stage, initial stage project is very difficult because it is not stable but sometimes very important. There is some criteria or some thinking for such type of small project. You have some criteria or some evaluation point for small project. Yeah, so this table, this, okay, so this strategic project table, we just selected, not hundreds, less than 50, just let's say 20 or 30 project which are really important for our project and then they're usually a new, not new, these new projects. They're matured enough. They usually belong to some foundation, like CMCF or some big foundation and they have a good base lines. So we also have BMI originated project and then my counterpart, my colleague, is also looking after them. So she is focusing on to grow from the scratch. The new BMI project which is able to be good enough to contribute to some neutral foundation eventually. Some of them we don't want to contribute to all of the projects to the foundation. It's because it's not worth it. It depends on the company strategy but we have some open source, original open source project. We want to open source and then she will be, she's now looking after them to be good enough to be some kind of normal generic open source. So my side is more focusing on the third party project which is not our own project which is donated to the foundation already or started by the other third party companies. So to answer, trying to answer to your question, we don't have such a immature, small project. It's not covered in this activity. Thank you so much. But we have our, sorry, but we have our organization, our team, is trying to grow those, look after those projects as well. Thank you for your presentation. Actually, it's so interesting. We will run about your, I'd like to know you evaluate the such open source and the project to start the open source contribution as a company. But if you can talk, I'd like to know if the open source project is going to close or do you have any metrics or something for evaluate to closing the open source project? Some setting, yeah, yeah, yeah. So we have, as I said, my colleague is looking after VM-originated projects and it's our project, some are not open, some are, no, no, they're all open source, but some are donated to the neutral foundation, some are just owned by our company. And there are quite a few projects which are not worth keep going. The start was we thought, right, okay, we open this open source and let's make it and donate to neutral foundation. But their direction changes all the time and the strategy changes all the time. So we have an activity program going how to sunset those projects and then we have a clear assessment criteria, checklist saying, is it worth to carry on these projects or not? And then we have a regular assessment. When we know, okay, so this is not worth carrying on, it's a waste of resources and time, then we will close it down. But the thing is open source is open source. We don't know who is actually using them. So the process is very complicated, but we won't be, you know, we are trying to not disappoint those people who are actually using those projects, but we do have a process to sunset. I see, thank you. Do you have any questions? So thank you very much for having me and I will be here today and tomorrow. So if you have any questions, please come and talk to me. Thank you very much for having me and thank you for your time. Thank you.