 Well, thank you all for joining today. Thank you all for joining through the virtual summit and everyone through the streaming. So, my name is Daniel Isciardo, a bit about me to start with. By the way, we are in the talk defining the limits of risk, supply chain contract, Depends on Summit Europe 2022. It's a pleasure to be here with all of you. Just to say today, I am kind of testing an idea to get and gather feedback from all of you. For the record, I'm the CEO of Vitergia. We are a startup based in Spain. Well, the headquarters are in Spain, but we are remotely based all over the world. We do software development analytics. We help with your OSPO or Inner Source Brown Office is a strategy as well. We do software development analytics, Viterria Analytics. It's based on chaos project. We'll discuss about this later. Part of the governing board of chaos that stands for Community Health Analytics for open source software and MVP at the Inner Source Commons Foundation. So, you can find some more info about me there or if you have any question afterwards or so. You are more than welcome to drop me an email. So, well, first of all, big disclaimer. I'm not an expert in the field of supply chain, but I'm kind of entering now. I wanted to discuss with all of you some topics that I'm interested in. So, the first thing I did was let's go and define what risk is. Basically, there are two main concepts here that were quite of interest for me. First one is basically you need to do certain activity and then things that humans value. So, those two things are of certain interest. Basically, because if there is no value for certain definition of value, you don't care. And that's all right. This case, risk, we are defining risk in different ways. Maybe it's IT risk, maybe it's business. Maybe it's human resources. So, there are many ways of looking at the problem, let's say. Okay, so let's have a look at these parallel wide square or rectangle. Now, let's assume that this is all the source code you have in your company. And it happens that part of that source code is basically developing house. Okay, there is certain percentage. I'm basically making up of the percentages here or the areas. Depending on the company might be definitely different. Part of it probably it's something that you are outsourcing. So, there are third-party providers that may use open source, may not use open source. But they provide something, maybe they are not providing even the source code, may are providing binaries, depending on the industry and so on. But you have some percentage that is outsourced. There is part of that that is directly coming from open source software with companies, perhaps as B30 or others, that are providing commercial support. Right, and basically it's kind of a similar service or so, but they are providing that. And then there are some others, open source software that you are adopting directly bringing from the outside, inside. You go through certain risk analysis. And then it's done. You have a new product, a new beautiful product within the walls of your organization. So, let me simplify the whole corporate ecosystem into this. If we think about the providers, so basically those that are providing the services, we may have the big sun, the corporation in between and then there are satellites. Those are the providers. You may have key providers. You may have smaller providers. So, all the previous way of developing software, proprietary or not, just sharing with you the binaries, et cetera. So, this is like this ecosystem of providers, right? I'm definitely assuming here that we all want to have a healthy providers ecosystem. So, let me have this as well for today. So, why do we want to have a healthy providers ecosystem? Well, basically because we all want to grow together. You are outsourcing part of the discussion or your IT because that's interesting for you for different reasons. And the thing is that you want to grow with them. You want them perhaps to be, to grow a fantastic data scientists team with people there that are part of your company as well. Maybe you want them to be your own, you want to be the only company that they are providing to, let's say in the country or in the region. So then, basically you get an agreement with those people in somehow. But the better they are, the healthier they are, the better for you and for your company. You grow together, right? And then if we think about the different ways that we are measuring risk or how we take care of risk here for the in-house, the outsource, the open source commercial support or the open source software that you are simply taking through certain analysis, the question here that I wonder was, well, how can I take care of all of this risk? And then, well, if we think about in-house, maybe this might be the easier in somehow because you do certain code quality checks, you do certain security scanners. Basically, you go through certain internal process, whatever it is, okay? You have your teams, you have your people and then you have the source code available somewhere. So if there is a problem, you have someone you can call at the after all. If you go for outsource, probably on top of what I mentioned before, then we start about discussing about MBAs. You need to discuss about the financial status of that provider. You know, if there is certain risk that that provider may go bankrupt, maybe. So there are other analysis that you are doing around. Of course, depending on the industry, maybe the source code is not provided. For instance, in the automotive industry, things are really closed. So they are provided only binaries. They are serving documents. The process they follow, but you cannot see anything. So there is definitely a lack of transparency, really big. But the idea is, well, you have some tools to prove that there is certain risk under control. If we go for open source commercial support, then we think about compliance. We may think about that you start checking the code, code wilderness abilities, all the things that we've been discussing along the day of the day. And then open source with no support, then it's kind of a subset of the previous thing. So you check the code, you do certain compliance, because maybe you're integrating the code somewhere in your code base, perhaps it's closer to the in-house development. But then I'm missing some things here in the conversation. So first, we want to grow a really healthy provider's ecosystem, that's one thing. So then we do a lot of risk analysis, risk assessment for them, well, together with them. But then for those projects that we are adopting, coming directly from the open source perspective, can I check the financial stability of an open source project or open source community? Probably that's something different, it's something really hard to deal with, right? Maybe we cannot even do that. So what is their history? Can I talk to San Juan there? Can I say hello? I say, hey, we are interested in the project or so. So who are they? Even maybe we don't have that clue of who they are, right? So the thing is that there are some missing points and perhaps it would be good if we can go to those communities and say hello and try to understand how they are, right? Try to go beyond the usual analysis that we do when adopting those software. So coming back to this schema, basically today's presentation is about focusing there, right on the left. So open source software that we are adopting internally but with no support initially or perhaps there is commercial support but we are not interested in contracting that. So we just take the software. So the question for all of you is basically, what do you do with the open source code that you use but there is no, it's not under any commercial relationship or perhaps there is no company behind all of this. And we all do that. Basically there is a library, there is da, da, da. So there is a process, basically, I don't know, maybe the architects goes and decide, well, this software is interesting for us. So we create a product. We do, of course, all of the needed checks for code vulnerabilities, any risk analysis that we mentioned before. We do maybe, of course, open source software compliance, many things. And then suddenly, we have all of this as part of our official take internally. That's good. So the process is more or less like this from left to right. We have the open source world and now we want to have that software within the walls of organization, right? So we want to create a product of that source code. So maybe you are adopting certain amount of code. Maybe you're adopting a huge amount of code that depends on you. And the thing is that suddenly you have this beautiful pieces of software that you have a package that everyone can use within the organization, of course, and they are great, they are excellent, they are lovely, everyone loves them, but then suddenly we have some threats, right? We have some problems. So what do we do now? They are not that lovely nowadays, so that's a problem. Okay, how did we reach this problem right now? So maybe luck for sale or one of those problems that we faced some months ago is a good example, right? So suddenly, you realize that there is a problem there. So welcome to the supply chain con. Basically, this is part of the conversation that I wanted to bring to here. So this is, let's say, more or less the motivation. So my point here is that you are dealing with this open source as a risk while my point is have you considered to work with these open source communities as providers? And it's basically, you know, turning around the discourse is if you have a certain interest or a piece of code that's really interesting for you, it's a strategic for your company, instead of going perhaps to another community or maybe the community doesn't even exist or maybe there are any other reasons. So what if we go to the community? What if we sit down with the community? Because think that typically the way we proceed with communities is that, well, with open source project that perhaps there are certain vulnerabilities is that, well, I don't like this. This is definitely risky. I try to look for other options, right? So then in the call for papers, and this is why I have here, they mentioned these three concepts, kind of in built threads, source code level problems, dependency threads. But I think in these kind of conversations, we should have this in mind, basically countering community threats. My point here today is basically that instead of trying to go for another option or trying to deal with that internally in a downstream version of the software, what if we go to the communities and help them to grow? In the same way that we are growing with our providers, third-party providers, giving like an excellent service, what if we have something similar with the open source community with that source code? We want that source code to be part of the tool chain. So I don't know if this makes sense to you, the countering community threats, but I think it should be part of the conversation as well. How can we define community threats? Well, in the previous talk, there was some discussion about chaos as well. And well, maybe we can define things as, well, the software is poorly maintained, maybe there is a lack of effort over time. I don't know if, for instance, from your perspective, it's more risky to have only one company driving the development software of that project or maybe having several of them, same with individuals. Maybe there is like certain, the vast factor and some others variables that we can discuss about. So I think it's, what is more risky for you? And that definition of risk is something that probably we need to build all together. Maybe a lack of engagement by certain people, maybe the time to close things, the time to answer if you have a question, the time to merge certain stuff, or maybe if this is a lively community or this is not a lively community. These are some thoughts that we can discuss about what does it mean, this concept of community threats? Can we measure that in somehow? Can we measure that in an automated way? Well, you all said some in the previous talk as well about, well, I'm checking the number of people that are contributing there, or maybe the people that left, or maybe the areas of the code that are not maintained, or maybe some other things. But the thing is that we all can measure this. So question again is now bringing to the definition of provider these open source projects. How can I have healthier providers? And basically, and even more, if I can be aware that something wrong is happening, because perhaps one of the things is I want to grow, okay, I buy the idea, I want to grow my providers to have this healthy ecosystem, including those open source projects. But how can I be aware that this is happening, that they are perhaps getting worse, or maybe that they are having like really good, healthy, let's say ecosystem and so on. So there are, you mentioned before, I think the BRICT was one of the companies that is analyzing project health as part of the dependencies and so on, might be one of the examples of someone doing this. The first thing that probably think about this is about money. Well, can I put some money on the community so they can move forward? Maybe they can hire people or not? Maybe they can do things? I would say perhaps money is not the right solution. Companies, indeed, at the very beginning, or when they start in the open source discussion, they go for foundations and say, well, I want to understand a bit more about open source, what do I do? And then they basically bring money to the foundation. But remember, we are discussing about different things. We are discussing about open source projects and not open source foundation. So then maybe we need to start a bit smaller, perhaps, instead of going to the foundation, which is like the big umbrella, the big tent, what if we go to the projects directly, right? Well, basically this is open source. The idea is you as a provider be as transparent as possible, I'm sorry, you as a company, you should be probably as transparent as possible with open source providers as you are with your proprietary providers. Third-party providers are others that are part of your ecosystem. Like, okay, I'm using you, I'm using the source code, what do you need? So can we have a proper discussion with these open source projects? Can we contact them? Can we sit down with them? And can we say, hey, we are using you? We see that you are facing certain troubles in these areas. This is risky for us, for a certain definition of risk. What do we do now? Maybe you can bring resources, people, maybe you can bring maybe money, maybe did money, maybe marketing, maybe you help them to move forward the roadmap. Because the thing here is that if you are using certain piece of software and you are not part of the roadmap, all the others will decide for you. So then that's another definition of risk, right? Specifically in the case of open source. Now being part of the community, defining those likely communities, I would say is definitely something that large corporations at least should be doing. So the previous speaker, reference chaos of course, stands for community health analytics for open source software at chaos.community. You can go there. There are some discussions specifically happening in the field of risk. There is a working group, a risk working group specifically. So you can go there. There are some tools to automate all of this or to have at least insights of what community health is for some of them. One of them is GreenModelApp. Basically what it does is about gathering information from different data sources. Then you have a database with all of the metrics around community, activity, performance, that matter to you. Then with all of this basically what we are building in part of the community and one of the original developers. So you can go and start gathering and aggregating the data which is meaningful for you in different ways. Then at the very end you have some dashboards or reports if you're interested in. And well perhaps the key point here if compared to others is that this is open source tools to analyze open source projects. It works for internal development as well just in case but for the topic of today it's about having an open source option to analyze open source things. Let's say open source projects, open source communities, open source processes. And that's definitely important for the, in the place we are in the Linux Foundation open source summit Europe. Well the terms of the processor or the architecture is you create the ideas that you forget about any kind of data mining problem that you may face. You have everything in one place. And then after this there is like an enrichment process creation process and so on where you have all of the entry indexes and then this is more let's say closer to business whatever it is, you know, risk or maybe community health or maybe for community managers or open source foundations. So just forget about all the technical problems about gathering, incremental support, historical data, GDPR and then focus on the business on the data that you need to gather to make the decisions in the right way. Really simplifying everything and let me check the time. Okay, I'm really quick. The idea is we have a software bill of materials that by the way there are some for SPDX you have some sections where it's not mandatory but would be useful if you add basically your data repository or your data organization because if that's the case then specifically using certain tools you can automate the process and then suddenly you have like a table with a list of metrics that matter to you for a certain definition of risk. So basically you can automate the process and you can have these community threats metrics if we define them in that way. That's one tool and then you have community metrics. Business risk in the chaos community we are working on these definitions. There are some of them but if and I assume that you have other point of view or comments please come to the community show your thoughts and we keep growing. So there are some definitions of what this means. For instance in the risk working group we've been working on well maybe the metric of average issue resolution time or the vast factor by the way if some of the main developers core developers leave the project for any reason so is the project sustainable over time? So that's a definition there are others as for instance the elephant factor which is similar in these cases about companies or basically if there is only one company leading the development process what happens if that company disappears? Is the project dead? Is the project sustainable? Is other companies around that can take that lead? So that's part of the discussion to have internally in your OSPOP or wherever you are making these decisions. The age of the issues, the volume of them, basically how many of them are around, lines of code, you know how this is aligned and there are many others so we can discuss for instance about territoriality. So territoriality might be a metric that measure the percentage of files that are modified just by one developer. So if we have a really highly territorial developers is that a risky factor that we may have? Probably yes, it's about adding more metrics here. So if you have thoughts, can please come to the community so we can have these discussions and we keep growing together. Just as a call to action or so, well I would say my, the general feeling when you go to all of these supply chain analysis providers or so is, well we can, we help you to decide what's the best piece of software for you. But my point is, well treat your, work with your open source projects as another provider. So if you, in the same way that you are working with other providers they are important for you, they are important for your ecosystem. So work with them, sit down with them in the same table and then instead of running away try to build something together. So let's change a bit the focus on how to deal with open source projects. And this is it. So I would like to know from you, from your comments, I've been quite fast. Sorry, I just had like two coffees. But anyway, any comments, questions? Does it make sense to you? There are some people noting. Have you ever considered to deal with your, risky open source projects perhaps as a provider? Does it make sense perhaps? Any experience in that way? It's the same thing you do with it. Yeah, exactly. So what do you do if there is an internal development in struggling? Oh, for the people in the streaming. So basically the answer is, it's about understanding where the problem is and helping them to move forward. Yep, that makes total sense basically. More experiences, no more comments, questions, I know. Yeah, that's a very question. Well, it's basically a synchronous communication. So you will send probably an email or try to go through their communication channels. So there is certain research about entering into the project. By the way, the question for the people in the streaming is about how difficult it is to get in contact with the developers or with the open source project. So ideally, with all of the open source projects, they have like a website that you can enter, you can access and then they will define or detail the different communication channels, the license, the mission, the vision, where you can find the source code, et cetera. Is this difficult? Well, it will depend on the community. Ideally, you can go to the email, to the mailing list or to the channel they are using for communication and try and say hello. Hi, I'm having these problems. I'm facing this situation in my company. I would like to help here. How can I help? We have maybe a team of interested in moving forward with the project, helping there. It's about having a conversation. Behind all of these projects, there are people. So there are people with interest. It's about having a conversation, I would say. Or comments? Questions now? Okay, so we can close for today, I guess. Thank you for your time. Okay.