 Hello. Thank you for joining my session. Today, I'd like to share some experience and insight that we gained while trying to establish a distributed OSPO. From the perspective of why, there is a shortage of OSPO personnel. Hello. Thank you for joining my session. Today, I'd like to share some experience and insight that we gained while trying to establish a distributed OSPO. From the perspective of why, there is a shortage of OSPO personnel. It will be about 30 minutes session, but I hope you enjoy this session. Thank you. Okay. I'd like to introduce myself briefly first. I am Norio Kobota from Sony Group Corporation. I am now a chair of internal OSS committee and represent Sony as a board member of Open Chain Project, Linux Foundation, and I also participate in SPDX working group and contributed to the SPDX light specification and so on. My background is as a software engineer in networking and security already a few years ago. Now, let's start with the presentation. Thank you for joining. See you about 30 minutes later. This is the background on this session. As you may know, we Sony conducts many different businesses, but of course, you know well, OSS is increasingly used in most fields. As you will see on the following slides, the OSS support scheme we have built was mainly intended for embedded and consumer products, and it worked well so far. But recently, as you know, OSS is expanding into various fields, so we feel the need to work more and more closer to business and technology. Therefore, we are now trying to establish a distributed OSPO for each business unit. This is the OSS support structure to date. In 2019 and 2021, we introduced about our OSS related organizations. Although there are some differences between regions and business entities, we have supported our engineers through OSPO, with several dedicated members, and through virtual organizations with people who are familiar with OSS in each business unit. Members with expertise in legal and intellectual property also join the virtual organization. We have established a system to promptly and appropriately receive inquiries regarding OSS. The system differs depending on the business unit, but basically, as shown in the figure, we take a step-by-step approach to escalate inquiries, as shown in the last flow diagram here. A particularly good feature of this system is members of the OSS committee in each division voluntarily work to resolve issues. However, because it is voluntary support, there is, of course, no guarantee. And when the person is busy, it may take longer time to resolve. On the other hand, when engineers contact OSPO directly, it still takes time for OSPO members to understand their technology and their business. This is a challenge that we are doing now. As shown in this figure, we try to establish a new OSS committee in an organization that has only a volunteer community in the past. As a member of the OSPO, I have been involved in the establishment of the new OSS committee. And I helped divisional leaders to become OSPO members. And this OSS committee consists of approximately 20 members, including legal and IP department members. And this business unit has about thousands of engineers. Now, one year has passed since the establishment of this committee, so I introduce the activity data and analysis results in the following slides. Firstly, the number of inquiries to the newly established committee through the year. The number of inquiries is gradually and steadily increasing and continuing. This result shows that this committee is gaining trust. And I feel this is a good trend. This is compared to the number of inquiries to the head office OSPO. In FY21, the number of inquiries to the head office decreased at the end of the fiscal year came. So I understand that the number of inquiries is steadily distributed. The new committee's inquiry system flow is shown in this figure. The new committee doesn't escalate inquiries. The new OSS committee has established a system. In which members discuss and respond to all inquiries, rather than having each member solve the problem individually. OSPO will also participate in the discussion and support as needed. Most of the committee members are engineers and have some OSS knowledge. And all department members participate in this committee. So I think any OSS inquiries about any technology field should be resolved by someone in this committee. So it seems to work very well for me. But in fact, even after a few months is the number of people who are leading the discussion didn't increase much. In the committee of about 20 people, only a few people participate in the discussion. And now we can see that the people who are you are always the same person from this chat. And the new OSS committee tend to rely on the specific person. But I feel this can't be helped because the committee has to be responsible for every inquiry. So everyone thinks that it's safest to have someone who knows OSS well solve this issue. But wait, they should have some OSS knowledge. Why can't they join the discussion? So I asked to a few people. Their answers were roughly two kinds. Firstly, they have no confidence to discuss. And secondly, they said, I don't know what to do. It's a problem. So I checked and classified the inquiries. The result is that 65% were inquiries about using OSS. And 14% were inquiries about contribution. Hi all. Do you know what is the OSS related to inquiry? Which accounts for 20%? Just like this. I will read this email. Hello OSS team. We are using Unity for our new software. And we are adding some modules that are available for free or for free from the Unity asset store. And the next sentence is very important. We know these are not OSS questions. But we don't know where to contact and what to resolve. The OSS team is often consulted like this question. And as you know, in general, the solution is to check the license and consult to the legal department. However, many, many engineers have never read the license. And after purchase, they break the shrink wrap without checking anything. Close the notice window and press the click button. And worse, we can develop software without paying attention to such things. Of course, a few years ago, I was a similar engineer. For this reason, I believe that each company carefully establishes internal rules and processes. In fact, not many engineers know where to ask these questions or where in the company the rules are. This is the type of inquiries that categorized OSS related issues. Most of the issues required consultation with other departments. Since these are issues about software, there are many inquiries that need to be consulted, especially in legal, intellectual property and audit department. In other words, people who solve OSS issues, like us, especially engineers. In addition to knowledge of software and OSS, you should be familiar with company rules and processes. And of course, it's very important to interact with the people in those departments and build co-operative relationships with each other. Next is the technical side, a little bit. When we are consulted about OSS, we need to know the OSS name, version, and what kind of product or services it will be used for. However, in most cases, such information is missing when the inquiry is first received. The newly established committee received only 18% of all consultations. This is a bit of exaggeration, but here is the example. This example shows that the OSS name and what the license is, but it doesn't explain what product or service it is used for or how OSS is used. Actually, OSPO has an inquiry template, but this committee didn't use it. Of course, it would be good if there is a template that enriches the items required for the questions. However, it is often faster to communicate with them than to have them filled in such details. I think it is important that the person who is consulted for OSS always confirm what information and communicate well with the inquirer, and this is also my personal opinion. But when you work as a member of OSPO, the most important thing to consider is to create an atmosphere where anyone can feel free to consult. I feel that a lot of people in the open source software world are very tolerant and honest. Internal engineers sometimes look at the open source world through the people who work at OSPO like a window. For this reason, I believe that a reliable and friendly OSPO is one of the factors for building a good internal OSS community. Okay, we are nearing the end of the session. It will be knowledge for those who have background in legal and intellectual property. Of course, OSS consultation requires not only OSS license knowledge, but also software technology knowledge. About 20% of the inquiries during the year require software knowledge, and sometimes there are questions that require you to know how to use CICD systems for a structure like GitHub and various OSS tools. Of course, I think the more knowledgeable you are about software technology, the more useful you will be in solving OSS issues. However, even software engineers cannot learn the details of all the software technologies that are spreading widely. The results of this survey also indicate that many different software technology questions are being asked, but if you don't understand the implementation in detail, only 9% of the consultations cannot be resolved. On the other hand, and if you are not good at software, you should have an overview of what that OSS is, and a general understanding of other OSS dependencies such as combining in build time and loading into runtime and so on. And it's more important to have the method to investigate it. If someone can do that, I think anyone can solve more than 70% of OSS inquiries themselves. Finally, my opinion, when we tried to establish a distributed OSPO, a shortage of OSPO talent became apparent. The following findings were obtained as measures to compensate for the shortage of OSPO talent. Firstly, it is important to provide OSPO members with not only OSS-related experience and education, but also training to run internal rules and processes. And secondly, it is also an important part of education, to promote communication between departments that don't normally interact much, such as legal and engineering departments. Thank you very much. That's all for my session. Thank you again for joining. If you have any questions, please comment in the chat box and so on. Bye-bye.