 My name is Matashita and I'm the star programmer of Oversource Community Strategy of Osvaldo, a vehicle. So the background of this talk is this. A few months ago, the business needs told us that in addition to our current Oversource process and engineering guidance, they'd like to have a consultation from our business leaders themselves. For example, what they need to pay attention and how they can go in the process so that they'll be able to make more commercially competitive and more productive products. So in this talk, I will share some of the Oversource business assignment and the guidance that Oversource provided, which I hope will find useful for your organization. Let me take you through the agenda. Firstly, I will talk about why and what is the impact to the business with other strategies. Then I will talk about the typical Oversource business models and commercialization parts, addressing the differences between the priorities of the company and the product. Next, I will share an example of Oversource development approach, what we need to consider to minimize the risks in each case and about competitive technology. Finally, we will have a time for you. So I'm Japanese. I was born and grew up in Japan. I started my career as a Windows software developer at a global tech company in Japan. I worked in the U.S. and U.K., where I led mobile phone and tablet product development as a software engineer and dev manager. During this time, I worked on Linux, PSP, SDK, HDK, and entire Android platform. Then I changed my career from telecoms to cloud, leading multiple programs including financial security, risk control, large-scale business and IT transformations. Moving up to date at VMI in the last three years, I led the strategic alignment between the community contributions and the company's business strategies. So why are we allowing Oversource on a business strategy? Many companies that use open source understand its business value, speed, efficiency, flexibility, and many other advantages. But it is also important to remember that the full potential of open source is best realized when technology is paired with successful community engagement along with an effective business strategy. So as a first step, it is critical for enterprise leaders to build a strong strategy for their products with open source, identifying what and where they want to invest to lead the revenue growth. And in order to take advantage of these benefits, it's critical for the organization to make a strong consistent commitment to community participation in addition to the technology and the business goals. So in general, when we develop a new product or start a new project to secure buying within the organization, we will need a business case including return on investment plan. This also applies for open source. Sufficient research and understanding of the risks is critical. So we need to remember that open source itself is not a strategy. Open source has a very different philosophy and process to create software. The strategy is made up from why, what, and how we open source that will create vision, how to realize our business goals. So what will happen if we don't have a strategy? We may create products that may not produce or lose revenue, or we may degrade the value of our proprietary software and surprise the customer community by incorrect approach or license changes and there's a risk to damage to our business and company reputation. Open source can have a significant impact on our business both positively and negatively. Therefore, we need to build a clear strategy. In the organization, there are many people who want to use open source, but not everyone is familiar with how to choose the right project or how to use open source in a way that fits for their business purposes. As the center of gravity of an organization's open source operations, OSPO can provide a comprehensive guideline to help business units to avoid to build an effective strategy to maximize their opportunity while minimizing the risks to the business. For this purpose, OSPO provides a best practice guide, questionnaire, and host consultations to ensure our open source development strategies are aligned with our corporate business goals. And this will also help to bring consistency how we approach open source to the ecosystem, open source business model. So these are the most common open source business models. We use them as starting point, then customized to suit. So we will now look at each model in turn, the services and support model where we pay for professional support. This is the most traditional model and a good example would be Red Hat Enterprise Linux. It offers tested software for free and charges for professional technical support services such as bug fix, regular releases, new features, and optimization. It might be suitable for enterprise customers that look for one stop service with timely support. New feature development may be prioritized based on customer's demand. Although this is a popular model with startups and more established companies, very few companies have successfully adopted. As it's hard to scale and can be expensive with the additional cost of staff and total cost can exceed service revenue. The next one is the open core where we pay proprietary and or enhanced functionality. This is perhaps one of the most widely adopted models. Examples are MongoDB, Elastic, and GitLab, and other more. In this model, users can access core versions of technology as open source and the more featured and supported version as a proprietary. Typically, this model provides a community of premium version and sells an enterprise or premium version. In this model, it's important to curate the differences between open source and the proprietary part to avoid impact to the project. If the open source project is weak, the enterprise proprietary offering will likely suffer. As a primary contributor, sponsoring company can have direct control and influence the project roadmap and licensing model. But sometimes an active community will create open source alternatives to the proprietary features. The hosting SaaS model where we pay for tooling and operations. This is the most recent model which followed the rise of cloud computing. Examples are Azure Databricks, WordPress, and many other. It offers bounding of open source service and products as a managed cloud service. Large public cloud providers offer this model and customers use the cloud provider service. For this reason, sometimes open source companies change their product licensing to prohibit selling their software as a service without paying royalties to protect their commercial interest. The cloud providers can offer fully integrated services by guiding users towards their commercial offerings. If there's a lack of community consensus, it may lose the trust of the community. The marketplace as a partnership. Google Android generates revenue by performing the Google Play Store, Google Maps, and directing mobile web traffic through search engines. Mozilla Firefox earns its revenue from partnerships with companies as built-in search options in the browser. There are some other models, however, perhaps these four are the most common. To conclude, the best business model depends on the type of product, solution, market, and company strategy. The key is to customize and adopt a model that suits for you best. That satisfies both market and your business, thus ensuring ROI. It requires a lot of thought around how to balance the commercial and open offerings. If the open offering goes too far, there's no natural extension to the commercial offering, and if the open offering is not sufficient, the community won't be interested. When done well, products create unique value benefitting from the opportunity to monetize whilst being welcome and accepted by the entire ecosystem. The next one is open-source commercialization. Go to the market strategy. So the commercialization journey of product with open-source is very different to those based on proprietary software. Users who are the potential future customers want to make their own selections and avoid long procurement cycles. We take a developer community-driven approach to educate how the project works rather than marketing the product. Product-led growth is growth strategy where the product drives user acquisition and engagement. In the context of open-source, it allows users to try before they buy and engage as a potential future customers who like the product and stay loyal. They form a developer community that can also act as a support and sales team to disseminate your product. So this diagram referred from community to commercialization by Peter Levin shows an example of open-source commercialization paths. Here I use a value ladder as opposed to a sales funnel to a better reflect incremental value. This is broken down into four stages. The first one, stage one, awareness. Developer community engagement. In this stage, the focus is to generate awareness of the open-source project product in the developer's community in order to grow the user base. Promote the technical value by driving engagement and grow interest with forums or blogs. The next stage is consideration, product strategy refinement. In this stage, we start to analyze usage patterns and use feedback. Explore what and how it naturally extends to drive revenue. Further, define product strategy to mature project users into product consumers. Stage three, evaluation, sales development. Start out by marketing with specific segments who find value in the project. Learn more about users at a large enterprise or just healthy users. Understand further commercial use case. Focus on the needs of users and what they want to do with the project and product. Final stage four, purchase. Sales expansion and further adoption. Sales promotions to enterprise, both bottom-up user adoption to expand usage and top-down sales to land use. The go-to-market journey also depends on product, solution, market, and company. To conclude, we grow together with the community. By letting developers who are the primary decision makers for commercial open-source today try how our technology works in their own environment. We can build and grow a community which values and grows their wider interests. We must also work all aligned across the business functions from developers to product managers, marketing sales to leadership teams and all must stay focused on our potential customers' needs. This is why we build a solid product strategy and share within the organization and continue reviewing it so that they share a same framing in their mind. Also, it's important to continually finding the productization approach to mature open-source project users into product consumers. We must always focus on their needs, values, and capabilities where our potential customers will be happy to pay for. So far, we've looked at the business models and go-to-market strategy. Now, we will look at the strategic development approach. The purpose of developing open-source tends to fall into one of three patterns. To realize our unique technology, new features, or create a new platform, to utilize existing features and enhance them, or sometimes we just want to use it to get the job done without development. So there are two types of projects that organizations tend to welcome, either company-originated cell phone projects or third-party projects that belong to other companies or neutral foundations. When we create a company-originated project and build a community around, we can benefit from the power of many skilled people, diverse viewpoints that increase the resilience within the business. As a good open-source student, we need to make the communities a better place instead of duplicating efforts. Therefore, before starting a new project, we must ensure that our project is unique and different, differentiate from the existing ones so that the project will likely to be successful and benefit both our business and the entire ecosystem. If you create a company-originated project, the organization will become a maintainer and you'd like to build and maintain healthy open communities. Make sure your organization is willing to make a long-term commitment to maintain the project. If they can't, the organization should not create a new project. If the goal is to collaborate within a team, inter-source will be a better option. Transparency is also very important to build a successful project community. Share the project roadmap and feature plan so that people can check if it is aligned with their business goals. If the community loses interest or misunderstand the project, that project may fail. We must make an intentional choice which source code to open rather than sharing all by default. We need to establish a clear business plan behind it with the vision of which issues we'd like to solve for FOOM and what type of community ecosystem we'd like to build around and how we can take advantage of it to generate revenue from the product. The timing of when to open is also important. If we open a code too early, a project can have too little to appeal to the community and if we open too late, the community may feel there is less opportunity to contribute. The best timing will depend on our goals and type of community we are looking to build. The project license can indicate the intention to users. For example, using a CLA for vendor-driven product creates the impression that you are leaving the door open to your licensing or changing the license. Whereas using a DCL often feels more open and lower value to entry for the contributors than a CLA. You will need to engage with your legal team and make a business decision about what type of license is the best for you. Then consider how your licensing will impact your efforts to build a community around your project. Third-party open source project. By using third-party open source project and adapt it into the solution, we can access immediately available technologies or benefit from established community power. If a project plays a key part in your product, then you are likely to modify and upstream the code for the better productivity. There are many projects available and important to choose the right one. If we don't choose the right one, it may cost more and waste our effort. To minimize the risk, we need to consider a few points. Make sure the project meets the functional requirements first and check that it's compatible with your environment such as operating system, hardware architecture and programming languages. Understand the project license compliance. CPL and derived licenses will mostly enforce you to contribute customization to the original project before you can monetize while other licenses are more flexible. Project health is very important for business viability. Projects with significant adoption tend to be more successful and safe. Explore and research trends, focus, dependent project and which other companies are using them. Make sure the project is active and mature. Ensure it has a good set of documentation and shares roadmap and a feature plan. Evaluate the community health. The project with good culture and open communication will be more sustainable. Project governance and leadership is equally important. Look for neutral governance where decisions are made openly by people from different organizations. Watch out if the project is owned or controlled by your competitors. Make sure the security policy is documented with a solid process allowing anyone to report quickly. Our customers rely on us to ship products that are secure and disaprise to all the components within this project. Company engagement. If the project is used in a core part of our solutions or in our flagship products, we must ensure our business units are ready to commit sufficient budget and resources to contribute to the project. To avoid an expected surprise that could impact our customers, we must engage with the project community so that we have a good visibility and influence on the future direction. In addition, our contributions towards the project need to be consistent and aligned within the organization in order to avoid community frustration and protect our company reputation. Now I'm talking about competitive technology. So being aware of potentially competitive projects is critical at both the start and during the lifetime of our products. When we start the new product development, we should research existing open source projects that may directly compete. If any are found, both the technical quality and the community's potential should be reviewed. We need to review competitive open source projects on a regular basis. If any competitive project is gaining momentum in usage, contribution, or vendor adoption, a product's position is at risk in the market. In this situation, you will need to re-review the strategy of your product and project. So open source can become a powerful tool but also introduce risks if we don't pay attention to the basics. And there is no magic wand that guarantees revenue increase from open source. But we can guide the teams on what to consider to create a strong strategy that leads to business success. And an OSPO can help you to do this as a focal point of open source in an organization. We must remember that engaging with the community is critical to make open source successful, not just for your business but also to grow the entire ecosystem. Thank you and now is the time for questions. Thank you. Questions? No questions. Thank you for your presentation. When reviewing open source software for a party product to use within your own product, it's no longer a case of just looking at our product. It's usually looking at all the dependencies as well, often hundreds of dependencies or thousands. So what advice do you have for answering all those many questions you have about a product that is looking at many, many different dependent projects? Sorry, so maybe I can... If you take an example, rather than just looking at a third party project and discovering whether it's got a good license or whether it's secure or whether it's maintained, it may not be just that project but its dependencies and its dependencies and its dependencies and so on. React will give you 600 components, say. So how do you look at all of them and get a better picture? So in your OSPO, I believe that there are many other teams working on the dependencies as well in your engineering team and then we get to work together. I'm working in a community strategy side so I'm not the best person to answer to your question perhaps but is there anyone who can answer to the question better than me? Just have to follow. You have to follow all the stuff, all the chain so make sure everything is covered because it could impact you later on so it depends on how much exposure you're willing to accept. Thank you, thank you for having me. Hi, thank you for your presentation. You now see there's also a lot of discussions about open AI and open data. In your perspective, what's the role OSPO should play in those discussions or what can OSPO contribute in those discussions for the company? Yeah, that's a good question. I was thinking about it and then this is the one of the reasons I joined this conference. I think I will be able to have a better understanding. So I'll be very honest, I just started this and I just built up all the basics and I was thinking about open source or dramatically different having AI and all these new technologies so I have to put my thought. I need to do more research and I'm sorry I can't answer to that but yeah, that is a very good point and I was trying to learn it so that I can enhance my guidance within the organization. I have a question. For the open source project which we company owned put it in GitHub as an open source project I'm thinking how we hatch it from the small project how we kind of make people know about this project so this is like how to make this project bigger and bigger. To external. Yeah, that's a good question and we have in VMware we have loads of VMware originated project and then that is used for external. Some of them are very popular and used widely but some of them are not very famous and then nearly most of the maintenance are a company inside. So I think it's important to have for example the community manager of that project so that you can talk about. Go to the conference like this or via blog or any sort of opportunities you can sort of promote how good this open source and what you can do. So this is one of the key point of this slide of my talk today that you need to make sure you need to be very clear about what you can actually do and what type of problem I can solve for you make it very very clear communicating up so that people will find it interesting. You know you have to have a healthy and welcoming community as well but before that you got to be clear what actually what problem you can solve by your project. I think that is a key point to talk to external. Yes, I think that is a good channel like to join more publicly like conference etc. Which type of this conference kind of because your open source project can be focused on operation system or platform or application or user space different levels but it seems like I don't know how many channels like this topic different companies share with their own open source project which type of the conference. Yeah, I think there are many people who can answer better than me but actually there are many many you know Linux foundation provide many many good conference like this and also there are more smaller conferences focusing on the technology area and if you search on you know if you want to you'd like to find you're asking how to find these conferences or I asking which conference which focus on this topic like demo your own open source project not to the OSS submit like this. You thinking of specific project your just generally my advice would be the focus on the market and technology area sector and then you research you know I'm not as expert of finding the best conference for that. So just wondering since this is open source submit I mean many company have their own open source project just want to know how to from the smaller to evolve bigger and bigger this is a general question I think maybe somewhere. Yeah you can answer pretty better because you're smiling at me. So when you're asking what conferences or places you should be promoting your project in my opinion humbly you want to be looking at the type of project it is and like what the actual user base will be is it cloud base is it observability is it what is the specific technology and go to that group of people and speak to them directly in the sense of the conferences that they are intending so we're at an open source conference right now this is going to be like a generalist kind of area but you want to be going specifically to the technology that you're creating and to the users that will hopefully be adopting that work I think the idea of oh we have an open source project so we just promote it to open source people is very broad and that's good for some things but you really need to get very specific into the problem that you're solving and go to those conferences about that technology with those users and speak to them directly that would be my my own personal. I think after yeah in the coffee time and networking with other people you'll find a better answer as well thank you for helping hello so you said watch out if the third party you want to contribute to is owned by competitors can you please elaborate on this because it kind of sounds like someone is doing open source wrong then no yeah I don't know how much so yeah there are some certain projects I'm not sure how much I can talk about it but if you yeah so you know you know some of the similar very similar and then they're doing very similar thing but and then you know so and then also the competitors your competitors you have competitors at a company and then you just keep an eye and watch out what they are doing and you know see as well so that you can have a better approach towards it and so your question is how what to yeah so can you why should we watch out by third party owned by competitors I mean if it's a technology if you work on a lot of things as a company you don't just have one technology that you are really good at why couldn't you contribute to third party owned by for example in our case Bosch let's say are they why is it dangerous and if it is you can get problems with it aren't there some strategies how you can get in agreements and I don't know maybe donate a part to foundation or maybe license it differently or I don't know so are there any strategies or why do you think it's a bad idea to work together on open source when it belongs to competitor yeah so you're talking about if it's owned by competitor why you hesitate or is that sorry maybe I'm the only one who don't understand so I think in my understanding there are many many open source projects available and some of them look good even owned by or controlled by your competitors so you have to just pay attention how the governance is run and also communities run and so that you be able to if there is a risk you can avoid the risk in advance and whether you have opportunity to work with them collaboratively so that everyone is win-win you know we all win yeah maybe let me up to that I'm not properly governed so technically steering company might be in place but it's not a diverse group of people so it might be owned by your direct competitor and having your your employees the people from your company contribute to that just because they think it's a cool piece of technology that might end up in a tricky situation because they contribute basically to someone else's project that doesn't help your company yeah I can also add about this the open source project which is owned by your competitors is not always bad thing because then you have a vision of what they are also doing and the contributions that are also doing there certain danger might be exposed when the licensing changes and this is where you need to ask yourself a question who is the copyright owner of this and whether that can be your license because if you put this at the core of your development and then the license changes you cannot use it any more than basically your product suffers that would be the only thing that would be looking at well one of the first actually not the only one but one of the first thank you so on the assumption that part of getting that sustained commitment from the company to start a open source project is being able to show that it is successful what approach do you use to define success metrics beyond the sort of vanity things like github stars which really aren't very useful yeah so yeah similar question at the first talk today so there are many many matrix available from chaos project has lots of good thing and then you also probably have a data analyst in your team and analyze the data but I think the point is that what so your business unit has got some business goals and how you know how your business leaders what they want to see and what you want to achieve there must be a specific goals and you look at them and then you will find the right metrics and then trying to find a measure the success and also ROI is you know there are many external resources available to measure the ROI there are many ways and so one of the them that fits for your purpose pick up and then try to analyze it I think that is the good start. Any more questions? Okay thank you very much for your joining and thank you for answering the difficult questions.