 Thanks so much, Jen, if you can move forward to the next screen, because I want to put this survey we're talking about a report and at first before we do that I like to put it in a larger context. The title of this whole webinar today is actually amusingly provocative, because we can also ask the question why don't developers just always write proprietary software that secure. And it's clear from the endless vulnerability reports endless updates the proprietary developers haven't solved the problem of how to develop perfectly secure software either. That said, it's true that open source offer has some potential advantages in developing secure software. And particular open source offer can be peer reviewed by many mass peer review, and that gives it a potential advantage and there is other there is open source offer that's very secure but unfortunately this potential is not always realized and some has been saying for a very long time that while open source offer has potential security advantages that doesn't automatically make it more secure or perfectly secure, or anything like that. And in that context, back in 2014, the Hartley vulnerability and open SSL. I think suddenly raise this issue for a lot of other people that who finally started paying attention to wait a minute. We've been seeing this all over the place. Some of it's quite secure some it's not. What do we do about that. And this really brought attention need for increased security in open source software. At that time it led to the foundation of something called the core infrastructure initiative the CI whose task was to fund and improve critical elements of open source software, including open SSL established something called the CI best back best practices badging program, which we may talk about later to project censuses trying to figure out well what are the most important open source projects, and what we're going to be talking about today is the 2020 FOS contributor survey next. Thank you. More recently, this is also led to this issue has led to the foundation something called the open source security foundation the open SSF. This was formally established announced on August 3 that's quite recent. This is a consolidation of many different organizations, many different folks working together to improve the security of open source software. And so it brings in the core infrastructure initiative the open source security coalition, the joint open source initiative. A couple of the members are listed there this including GitHub and Google and IBM and Microsoft and red hat. In fact that's just a partial list. If you go to the open SSF website you'll see a much longer list. Lots of organizations are now involved. So, hopefully that kind of that gives you a little bit of context and now within that I'd like to introduce Frank, Frank Nagel, who will be talking about the results from the report that we're discussing today. Right. Great. Thanks so much David so thanks again thanks for providing some context here and as David mentioned this this sort of contributor survey that we ran over the summer of 2020 was aimed at better understanding the human side of open source and open source and open source security in particular. Jenny, you can go to the next slide. So, in particular, we wanted to understand a lot of things but one the main purpose was to better understand how why developers aren't writing secure open source software from the get go. And so we looked in particular at three areas. So, go ahead Jenny the first is motivations. The second is time allocation and the third is incentives and so we felt that these three together gave us a pretty good picture of what drives contributors to contribute to open source, but also why they didn't spend their time on some areas like new features or things like that, as opposed to other areas like secure, you know, securing vulnerabilities or even secure coding practices from the beginning. So when we conducted the survey will will highlight some of the results here today. So in particular focus on these three areas but if you look at the report itself you'll see in the appendix. We asked a lot of detailed questions that we couldn't highlight everything here today. So do take a look at the report and you'll see more in detail. Next slide. So in particular what we looked at to answer those questions was thinking about the demographics of the contributors themselves. Then also, you know their current activities in free and open source software and how what projects they work on what they do and things like that. So we better understand the role of employers and companies in the open source ecosystem and so we asked questions about their employers and their stances towards open source software. And then we asked specifically about motivations and why people get involved in open source and why they spend their time doing what they do. And then we asked about time allocation to better understand how people think about their, the way that they spend their time in open source. And so there's the highlights in the report but just to give everyone here, a couple of numbers. We sent this direct emails inviting people to fill out the survey to the contributors to the top 200 projects that we identified in our prior work that we released a report back in February. So that was kind of a targeted approach, but then we also had an open survey link that anyone could fill out any open source contributor. And we tried to publicize that as widely as possible through various Linux channels as weather, as well as other, you know, general tech media channels. And so that led us to end up with just under 1200 responses that where people filled out at least some of the demographic information and at least some of the other information we decided that since the survey was fairly comprehensive. We had to force everyone to answer every single question. And so about half of those 1200 people answered every single question. But the full 1200 led to usable insights and so you may see the number of respondents kind of change from question to question as we go through this. And that's the reason why. And what was also nice about the way the survey was structured was that we asked people about their specific involvement in specific projects so we asked people to identify the five projects open source projects that they most frequently contribute to in any way whether it be code commits or documentation or anything else. And so that led to us, you know, from these 1200 survey respondents, we had over 2200 individual projects identified by these respondents so obviously some were working on the same projects but more than 2200 projects are represented in the answers to the survey. Obviously, it's not, you know, a completely representative survey, but we do think we have some pretty wide coverage here which is which is good for their ability to and a generalized the results. Next slide. So, before we dive in, I just want to cover a few definitions because we'll use some of these as we kind of slice and dice the results of the report. Well, we asked people their level of involvement to in a given open source project, and we gave them essentially these four choices so I'll let you read that yourself, but the four choices were in order of kind of highest involvement to lowest involvement, maintainers, core participants, occasional participants, and then one time participants. So for each project that the respondents identified that they worked on, they were contributed to, we asked them to also identify which level of involvement they had for that project. And I will point out to that, most of the time we'll look at results at the person level so at the contributor level, and from there. Obviously, if somebody contributes to multiple projects, it could be a maintainer for one project and a one time participant for another project. If we're looking at people at kind of the person level will default to the highest level of involvement that they have on any project. So, so for example, if you know somebody's a maintainer on one project and one time participant in another for most of the results that you'll see, they'll show up as a maintainer. Next slide. And then the last few definitions that we wanted to highlight before we dive in are the difference between paid and unpaid contributor. So again, multiple people contribute to more than one project. And in many cases they're paid for their contributions to one project or maybe two projects, but they also work on other projects that they're not paid for. So if you're paid for any work on open source on any of the projects you work on, we consider you a paid contributor. And if you're paid for none of the projects that you work on, then we consider you an unpaid contributor. So with that, let's let's dive straight into the demographics right. And so again, I mentioned we had 1200 responses total. For the people that answered precisely what projects and what levels they were involved in was a bit less. And so for this, we've broken out the demographics based on the level of participation but also age and gender. So gender obviously is probably the first thing that pops off the page here 93% of these respondents were male. And it's a full sample that was about 91% that was male. So this subset is slightly higher. There's there's plenty of studies out there that have looked into gender involvement in open source. Certainly ours is consistent fairly consistent with other studies that they have shown. So obviously our results are heavily male skewed, but that is for better or worse is representative of open source contribute contributors and we've talked about actually some future research and future work, digging deeper into why that is and to better understanding how that can become more representative of all software developers in general. And so you can see here, again, maintainers are overweighted and that's partially because if you're a maintainer on any project you show up as a maintainer in this in this slide. And so obviously there's, you know, there are some younger folks, there may be folks contributing to open source under the age of 18 but for legal reasons for the survey we had to only allow people that were over the age of 18. We also have people on the high end, obviously fewer well into their 60s and 70s working on open source but again, you know, it's clear from from the results that the at least the core of the respondents to the survey were, were more between the ages of 20 and say 55. And so we do have a good distribution of folks that are maintainers but also people that are core occasional in one time developers as well. And, yeah, so that's that Jenny next slide great. So yeah so the other main demographic that we considered was of course location. You'll see that little over a quarter of the respondents are in the US. The next would be Germany with 12% France with 7% in the UK with 5% and then a very long tail of other countries as well. So, you know, clearly, this is a bit, you know, the results will be a bit more representative of the US and Western Europe. But we do have, you know, some good insights into folks as well from from other countries and other geographies which is helpful. Great. So the one thing you know I meant to kind of tease this a little bit already but we wanted to in particular think about the role of money in open source and how that relates to security and sustainability of open source in the long term. So what we found is that over half of participants, or as our half of respondents reported receiving payment for at least one project that they work on, either from directly from their employer, their direct employer was about 49% of respondents, or a third party which was about two to 3% of respondents said that they received payment from a third party for their involvement in open source and of course the other 49 ish percent did not receive any sort of compensation for a variety of reasons. So if you think about this, you know, payment over the countries. Go ahead to the next slide. We can see a little bit of a difference in kind of the breakdown of who's getting paid by country and so obviously, you know, towards the end here there's a smaller number of people and so it may not be completely representative. So for example, of the people that said they live in the US and reported whether or not they were paid for open source, about 64% of people said that they were paid for at least some of their work on open source. Germany pretty close to that France a little bit lower but again we're kind of getting lower in the number of responses here so less easy to kind of generalize from that. You know, generally here see somewhere between 40 to 70% of respondents from a given country, being reporting that they're being paid, although less so in India and China, but again those numbers start to get a bit smaller and harder to interpret. So the other thing that we asked about so this is this is the go ahead. This is the one slide that we looked at the project level so as I said, before we, we, you know, lump people we call people a maintainer if they're a maintainer on any project. But here we wanted to break down and think about per project, are you what is the level of your involvement and are you paid or not for that particular project. So clearly, you know when we look at this, there is, you know, this this kind of clear trends that the more involved you get in a given project, the more likely you are to be getting paid for your work on that project. Whereas if you're just a one time contributor down at the end. That's, it's kind of 5050. And so when we think about you know the people and the projects that they're working on. Obviously we have some of the higher level contributors in this survey, which I think gives us a lot more detailed information because one of the things that we're in particular kind of thinking about is how to get these folks that are the core maintainers of projects to really encourage all of their team to get more security conscious. So when we think about, you know, again thinking about kind of money and the way that it is involved in the whole system. We asked about people's employment status and as mentioned we ran this survey over the summer. So in the midst, but not the height of the COVID-19 pandemic, but the bulk of respondents said that they were employed full time. So overwhelming majority are employed full time. And then the second most high highest bar is the being self employed or a freelancer. And so again, you know, when we think about the people that are contributing to open source in the old days it was assumed it was kind of all, you know, college students or things like that. Now we're seeing this is much more heavily represented by people that have full time jobs. And in particular, you know, this is makes make some sense given the state of the world at the moment. The skills necessary to contribute to open source are actually super highly valued in the general job market. And so when we think about, you know, the support for open source people and we'll talk about this in a moment when we look at motivations. But most of them have a full time job that, you know, allows them to pay the rent and put food on the table. And so when we think about what incentives and how we can change behavior in open source is particular related to security. We'll come back to that that notion. So the next thing we asked about was how people's companies that given that so many people are full time employed, how do their employers IP policies relate to contributing to false on their own free time right so this isn't, you know, are you this is independent of are you paid or not. This is just does the company allow you to contribute contribute to open source in your free time. So we wanted to try and get a sense of trends over time. And so we did ask people. What is the case of your employer today, five years ago and 10 years ago, obviously, as you if you look at the legend there. You see that the number of respondents kind of dwindles over time, either because people didn't remember back 10 years ago, or they weren't involved. And so what's clear here is, you know, the highest bars there are moving in a positive direction right so more and more companies are allowing their employees to contribute to open source on their free time. But what's slightly concerning here the last two bars is that even though they're going in a generally positive direction. There's a still a large percentage of people who believe that their company either has a very unclear policy towards open source, or they don't actually know what the open source policy is of their company in the first place. And so we'll revisit that towards the end. So generally this is a, you know, a good trend that we're seeing overall, but those last two columns are a little bit concerning in terms of employee awareness and clarity of the company's policies. So then next I mentioned we asked about motivation. So what you'll see here is a list from of 10 motivations that are often considered the primary reasons that people contribute to open source. And so when we looked at and so to prevent, you know, from survey standpoint we showed these responses in a random order to people so that they weren't just inclined to rate the first one number one and etc etc. And so what we found was that the most frequently rated number one reason was I enjoy learning. And so when we think about why people, you know, contribute to open source, it's this I enjoy learning and then the other two top reasons for contributing, whether they use this piece of open source and need a specific feature, or it'll contributing allows them to scratch a creative it short they find it challenging or enjoyable. So these three highlighted in green, where the top three, most frequently in the top three of people's rankings. What's interesting is that none of these are on their face at least none of these are monetary right and so when we think about the motivations, and especially when we want to try and tweak people to spend more time on security. It turns out that at least in our respondents in this survey, monetary incentives may not be the way. Indeed, if we look at the bottom three motivations. So these are the three motivations that showed up most frequently at the bottom of people's list. The most frequent at the very bottom was I'm paid to develop open source. The next was that I think this will help my career, and then valuing the recognition of my peers. And actually when we when we looked at the subset of people that said they were paid to develop open source so you know this is this is all people the way that we have it here. But then when we looked at the subset of people that said that they are paid for at least some of their work on open source. Even those folks said that payment, I believe it was the eighth most least likely to show up so it wasn't quite at the bottom, but it was pretty darn close and so even for the folks that are paid to develop open source. That payment is not necessarily one of their primary motivators for their involvement in open source. I mentioned that we thought a lot about was time allocation and how do people spend their time on open source and so we asked people, you know you can read the report and see some numbers around how much how much time per week people spend on open source. The next highlight here today was how people would like to spend their time on open source versus how they actually do spend their time. And so you can see, you know that the dark blue line is is the ideal percentage of their time that they would like to spend so you know if you spend 10 hours on open source. Ideally, you on average people would like to spend around 34% of that time working on new code, but in reality, they actually spend less than 25% of their time on new code. And so we can see, you know where we end up getting people spending more time in reality than what they would have the ideal is kind of in the middle so maintaining projects and managing bug reports and administrative activities. So in the report we break this out by the maintainers and the core contributors so those high level contributors. And there, this is even more skewed for them that they're spending a lot more time than they would like on these kind of maintenance administrative tasks. And then the last thing I want to point out here this particular relevant to our discussion today is all the way at the end there. And so the security is is a very small percentage of people's time, both in reality and what how would they actually want to spend their time. And so this is, you know, particularly concerning when we think about as David mentioned at the beginning bugs like Heartbleed sorry had a brain for there so Heartbleed, you know, thinking about bugs like that. This is a little bit concerned because we would like to see more time spent on security and and perhaps even we'd like to see people have a higher level of interest in spending more time on security. But that's obviously not what we're seeing here, which is concerning and we'll talk about that as we think about next steps and moving forward in our suggestions. Great. And so when we were thinking about crafting this survey one of the particular things that we wanted to better understand was how do people that are working on, you know, open source projects, what types of help are they looking for. And so we asked them to say which of these eight or nine options are the things that would most benefit the project that you work on that needs the most assistance and overwhelmingly the highest here was bugs bug and security fixes. Obviously, you know, new features and financial help and some other things come along the line as well. But bug and security fixes were super high. So, so what this tells us combined with, you know, the prior results is that people know that bug and security fixes are very important and they need to be addressed, but they don't want to spend their own time working on that. And that's even, you know, when we consider that we asked about people's security training and their, you know, development training, 40% of people said that they had formal training and secure software developments at a different point in the survey. But even they, even they are still requesting this external help on bug and security fixes. And, you know, in the middle there you can also see security audits and obviously we kind of over weighted the help requested or we have more detailed when we were thinking about the security aspects because that's what we wanted in particular. And so, you know, the fact that these options were shown up here helps us kind of guide what we're thinking about in terms of next steps and how we can help we as the community of open source enthusiasts or open source users can help the contributors and maintainers of the projects that we use. So in aggregate in the survey in the report, you can see it in more more detail but we came up with four suggested actions around kind of our main high level findings. So the first was related to this employment, employed full time and also related to those incentives that I mentioned, or I'm sorry, the motivations that I mentioned. So, you know, 75% of respondents are employed full time, and most people, even the ones that that's that are paid for their work on open source, say that that that payment is not a primary motivator of why they're involved in open source. And so this is important when you know when we think about wanting to tweak behavior or nudge people towards in this case spending more time on on security. We have to recognize that that this is this is not that money may not solve the problem in this case right in some cases certainly there are some projects that are underfunded there are some contributors that would like to be paid for for their work. And that may be an option to lead them towards spending more time on security. But it turns out that actually the, you know that that may not be one of the primary ways to incentivize people to spend more time on secure security. And so what what needs to be done in that case is potentially give external support more directly for security so for example, when people request you know talked about financial support. They were interesting and have external people do security audit so that the contributors can keep doing what they do and working on the code and contributing new features and doing the maintenance. But actually, that's the, what they need to do, you know what they need for security purposes is external audits. And so the next thing that we looked at the next thing that we looked at was also that notion of people not wanting to spend not wanting to and not actually spending time on security right so 2.8% on average of their time was spent on security and you know from our perspective this needs to increase. And so in addition to funding those security audits for in particular the critical FOS projects, like those that we identified in our prior report, but and others that have done similar types of work, but also thinking about how do we address this from the ground up so obviously security audits and external, you know, security work helps address the bugs that have been intro already introduced to open source projects, but how do we actually prevent those from the future in the future. And so one of the ways is to really help prioritizing the secure software development and the secure software development lifecycle and the best practices associated with those. And so when we think about, you know, the role of companies and employers here, they have an opportunity to require their developers to actually take some training along those lines so as mentioned only 40% of respondents had any sort of secure software development lifecycle was slightly higher for the paid contributors, but still room for introducing more in terms of incentives for the paid people to actually take training classes related to secure software development. And then also, when thinking about the platforms that are hosting open source so GitHub, GitLab, etc, etc. There may be opportunity or there are opportunities to actually incorporate security tools and automated automatic testing directly into the development pipeline. And so that was one of the other recommendations that we had for again kind of when we think about open source we're trying to think about the entire ecosystem, what can any one project do themselves. So the next, when we're thinking about, you know, this this payment and the potential for, you know, using that as a lever to encourage people to spend more of their time on security. And when we think about, you know, the this this change over time because you know in the old days, very few people were paid for their involvement in open source and now it's much much higher. So these companies that are paying their developers have the opportunities to actually change the way that their developers are spending their time. One of the other pieces, you know that I think is important related to this employer, you know, involvement is that there might be fears that large companies in particular but even smaller companies are pushing open source in directions that are either, you know, not necessarily for the community or are overly good for the company itself. And so when we think about, you know, the company involvement that has been increasing over time. We argue that there should be ever more transparency related to this involvement, and also clear commitments because when we think about, you know, some companies that are super heavily involved in driving a particular project. Some of those companies who may end up using that project want to know that there's going to be continued commitments to it over the time over time. And so increased transparency and also clear commitments. We're not talking about code commitments here or code commits. We're talking about commitments to be involved and help support these projects in the future. And then lastly, we also think that there's opportunity here for mentoring. So when we think about, you know, the one time people or the, you know, occasional involvement less frequently or those people actually paid, but they could use mentoring and so this may be another way for companies that are involved in open source to contribute back to the community, not just through code, but also through mentoring new volunteer contributors who are not being paid for their involvement. And then lastly, also thinking about allowing a false projects to be transferred the ownership to foundations with neutral governance, so that you know the company no longer owns the project, even if they're supporting it quite heavily. So then lastly, our last high level takeaway was the finding that 17.5% of respondents reported that their employer had unclear open source policies. So I mentioned that before when we were talking about that. And so again, despite this increasing openness of companies toward employee involvement in open source. Many employees are confused about what their companies policies actually are. So we encourage companies to clarify their policies on how and when employees can contribute to open source, and also actually promote this contribution to open source, because some of our other research has shown that this can actually be quite beneficial for the companies and their community. And in particular, though, we would encourage them to encourage their employees to help focus on security issues, because these aren't the things that the free contributors want to focus on or the un, sorry, the unpaid contributors want to focus on. And so the companies have an opportunity here to encourage their employees to actually focus on security. So with that, I will go ahead and we'll open it up for question and answer. I'll introduce a few other folks that were in heavily involved in the report. So you already heard from David Wheeler who's the director of open source supply chain security at the Linux Foundation. And this is on the report where he left it's a soft, who's an associate professor of information operations and management science at New York University Stern School of Business, and she's also a faculty affiliate of the laboratory for innovation science at Harvard. Also involved in the report was Haley Ham, who's a data scientist at the laboratory for innovation science at Harvard, and Jenny Hoffman who's the assistant director of research management at the laboratory for innovation science at Harvard. And two additional folks with us from the Linux side who are integral to the effort. That's Mike Dolan who's the senior vice president general manager of projects at the Linux Foundation and Kate Stewart who's senior director of strategic programs at the Linux Foundation. So thanks everyone for for all your hard work on the report itself. I'm going to turn your cameras on and so everybody can see your faces and see the people behind this voluminous report. I know the team has been answering some questions, because as people rolled in, but I think we can kind of open up the q amp a. And so, let's see, Jenny or David who's been keeping an eye on the questions. Do we have any open questions that we haven't answered yet. We do we do. We actually there just as a kind of a housekeeping issue. Hugo asked if we can share the slides we're happy to do so. So, well, we'll happily do that. And then there was a question if there's any data of contribution of students like students doing intern like an internship or a part time job to improve skill contributions and so we, we did look at the cross section of people at different employment statuses so it's a little hard to parse out if someone has an internship while they're full time students so we gave people a select one out of employed full time employed part time full time students, temporary worker, we didn't specifically ask for the internship question, but that is is something that we could look into for our next iteration of that. And then there's two we do in the report we mentioned that those types, you know, students participating in Google summer of code or other projects like that are a great way to encourage people to get involved in open source from an early stage, but to make sure that security is being baked into kind of the way that those projects are being, you know, are being contributed to. I know you've been a little bit involved in some of those efforts did you want to add anything to that sort of stick you on the spot there. Multiple programs and that people are participating in between the outreach he wants as well as Google summer code and links foundation has the bridge mentorship programs and all of these do tend to be good channels for people to get engaged in open source and then start to continue to contribute. So getting them working and engaging and realizing it's not quite so scary is, you know, a really good way of pulling people in. Excellent. And David, I don't know if you wanted to also mention a little more about open SSF and the role that they're playing in kind of, you know, one of the things that we can quite highlight in the report here but a lot of the solutions to, you know, some of the problems that are identified require a multi organization level of involvement. And so I think that when we when we think about the open SSF was just launched this summer. I'm curious if you wanted to just comment a little bit more about the work that they're doing and how you know as he pointed out at the beginning there's a lot of companies that are involved in this, and it's an open group that others are welcome to get involved so David you want to just mention how people can get more involved in that if they'd like to. David you're on mute. Yes, the standard phrase for 2020 you're on mute. So, um, so if you're interested in open source software and security I would urge you to check out the open source security foundation the open SSF. So, you know that's at HTTPS colon slash slash open SSF dot org mean simple straight for you URLs you can get. And overall their tagline is collaborating to secure the open source ecosystem. The last number I saw they've got 35 organizations in fact I know they have more now they've just recently joined. I think that's that tagline by the way though is a good summary of what the open SSF is all about. Currently has six working groups, I'm going to read out just the names because I'm hoping that some people are listening this webinar watching it. I will say oh man I'm interested in that and so let me just read that out security best practices, identifying security threats to open source projects and that's particularly focusing on metrics. Securing critical projects, digital identity at a station vulnerability disclosures security tooling. And I, you know, and of course they may form new working groups as they choose to do so so if you're interested if you're interested in open source software and security that that the intersection, I would certainly urge anyone to, you know, check out the open SSF. And I'd like to go back to another question that was asked earlier on related to contributors receiving payment by contributor status per project. And so I'm going to go ahead and share a screen. This was submitted by and forgive me if either Jen or yawn, there's no pronunciation next to it so forgive us. But I'm going to go ahead and share a screen and then pass this over to Haley. Um, and let me go ahead and share that screen now and let me know if it's, if it's visible for everyone. Great. Thanks for this question. Oh, thank you Jenny. So yeah thanks for this question because it helped me realize that I had the wrong y axis there so each as total all bar should add to 100% now with this new y axis and so it's more looking at it as you know, 25 ish 20% of the projects are people who are maintainers and they were paid for that specific project is how you would read it but thanks for pointing it out because it was not the correct y axis. And we'll make sure that's correct in the reports. Yeah. So what is the what's the famous, you know, quote, it's with many eyes all bugs are shallow, all typos are shallow so thank you very much and and we really appreciate that that this is part of why we're we're presenting these things we want to make sure that we're, we're getting the right information out there. I have a question about depend about which automate security and vulnerability and so I know that in some of our questions we discussed different tools different different security tools that people use and depend about was something that came up very often, as in people's text responses. But I'm going to leave that to the other panelists if there's any other additional question or any additional insights that they had on that particular piece. Maybe the your cape maybe. Okay, yeah, I can jump in here a little bit. You know, I'm not. I've done a lot of studies of the years about tools and security tools and I'm not a believe that one tool is the one true answer, or even one kind of tool, different kinds of tools help for different purposes. The vast majority of software today is mostly reusing and combining other software. And so you need to make sure that those that other software you're depending on also knows your dependencies. In particular, if they have a known vulnerability, you need to rapidly become aware of that update so that you can keep your dependencies updated. And so depend about is just one of several approaches, you know, several kinds of tools, where it can tell you how to tell you, Hey, wait a minute, you've got a vulnerability quickly update on so you can get updated. Now that's not the only tool you need in the tool box kind of tool you need the toolbox. I mean, you need to not only be warned about vulnerable components but generally you're rewriting custom code, and any other tools to help you identify the vulnerabilities in your custom code because those kinds of tools can only tell you about publicly known vulnerabilities. You know, absolutely, we need to use tools that detect vulnerable known vulnerabilities and our dependencies. We need more than that though we need tools to help us detect vulnerabilities in the custom code. We also need to prepare for example to update make changes so for example, a dependency tool that tells you about a vulnerable component doesn't help. If your software if you haven't developed your software to make it easy to update so using package managers, having automated test suite so oh I need to update boom update tested ship. Okay, if you can't do that quickly. You've got problems. So, you know, certainly, we want people to use those kinds of tools, but securities much bigger than just using that kind of tool. And also I add in that it's also important that we have the software transparency, so that we actually can find that these dependencies and things like that are there for the tool so having improving the dependency of the software, and having that automated and having it so we can track this stuff in an automated fashion is going to improve the security of the ecosystem as well. There's a question about whether or not we ask contributors if they were involved in monitoring security attacks and or just responding to security incidents. So we did not ask directly about monitoring security attacks we generally when we were thinking about security was the vulnerabilities in the code as opposed to people using those vulnerabilities for attacks. But that could be something that we look into the next time we run the survey or our goal is to, you know, run the survey on a yearly basis and to tweak it as we go because this was the first time we ran it so that may be something worth looking into for the next time. And then there's another question about which companies are supporting development of specific open source projects, like did you want to weigh in on that. So we didn't get into it specifically we didn't ask participants into the survey what company do you work for what percentage of your the code base is being developed by your company relative to others. However, we do have other tools that are available to help understand that relative to certain projects. There are you know a number of tools out there that will potentially help you. We use a tool at LFX dot dev. So if you go to the LFX dot dev website. There's an insights tool and if you use the insights tool you can look at most of the Linux foundations hosted projects and take a look at who's contributing what percentage of the code base under whatever time frame you want to. So you can take a look there and improves through the Linux foundations projects. You know, other foundations may have similar types of tools I think open stack had one for example. And I'm forgetting, I think eclipse might be using deterges tool for being able to display some of those results so the answers are probably out there, it just a little bit harder to find, but we can find that mostly through contribution history and being able to identify who was contributing from which organization. Yeah, and I'll say I'll add on top of that. You know, as many companies have started to become much more transparent in their involvement in open source and, and some of the platforms are allowing that to even go further and so for example, I'm going to throw out an example if you go to github.com slash Microsoft, you can see all of the open source projects that Microsoft is involved in there, which employees are contributing to those projects, etc, etc, etc. And so, we, you know, at the end of the report we do call for more transparency of company involvement in open source, but some companies are already, you know, going down that path which is great. Frank also the financial, you know, intrinsic and extrinsic motivation, you know responses also lead us to understand for a lot of people they have jobs they're employed in, you know, they're maybe using open source as a way to get that job, or they're being paid because of their skills in a particular open source project, whatever the reason they are financially compensated in some way that leaves them comfortable to also contribute to other open source projects and do other things that they want to do, and that's what I thought was an interesting finding from the board. Let's see. Good. So just growing through down through the questions. Is there's a question is there any insight in how the contributors to open source approach security in their workflow, legal and licensing choice architecture language and pyro. So, so we had some questions. They're more focused in the appendix of the report the details. What tools people actually use for security so what tools or processes people use for security and so indeed that it digs into some of the legal and licensing choices, some compiler choices, some other best practices, even things like the Linux core infrastructure initiative badging program we asked about that. And so a lot of that's in the appendix. And so I encourage the anonymous attendee that asked that question to take a look at the appendix of the report in particular, because there's more detail on that. Okay. This is a perhaps a good a good final question but can each panel member take a stab at a short answer to the title question for this meeting. Why can't open source developers just write secure code. So, why don't we in to wrap things up why don't we go ahead and we can just go round Robin. I can take a first stab but but I may steal other people's answers but I do think that a lot of it has to do with that motivations time allocation and incentives that we talked about. And so, you know that they they want to contribute, they have a limited amount of time, and they'd rather spend that time on on things that they find interesting right and on average, you know, many of the developers just don't find security that interesting or, you know, kind of interesting, basically, and I will say we didn't put it in the slides but we did put a few quotes about exactly that type of question in the report itself from people's responses in the open ended portions of the survey. One of which comes to mind that somebody said that security is essentially a soul wrenching on, you know, necessity that they don't want to spend any time on. Another said that it's the domain of lawyers and accountants, not, you know, not software developers which I think you know that in itself is a little bit concerning that that's the attitude folks have because, you know, part of the development process is ensuring that the code that you write is secure, but obviously that's not necessarily the attitude that everyone takes. I'm not sure if others want to jump in on answering the title question as well. Can do a jump in here. I think also we need to be seeing more tooling showing up in the CI workflows such that developers are flagged right when they commit something. It's potentially going to hit boundaries or things like that such that it adds another layer of eyes effectively in the practices when someone may not be thinking of something right off the front that. Yeah, so if I can jump in, I think it's a, it's a, it's a valid question with a complicated answer. And of course, as I mentioned at the, at the opening, it's not like the proprietor folks are developing proprietary software have solved this problem. We were constantly updating software every month because of security vulnerabilities, and I constantly see vulnerability reports and proprietary software so I think there's it's complicated, you know, in some cases lack of incentives, but I think many folks many situations part of the problem is there's other challenges, lack of education, lack and difficulty in doing it. Education, we're already working on that. I mentioned the open SSF the open SSF just released a set of three courses, specifically on how to develop secure software. It's free. It's actually not specific to open source but it does include open source discussions because that's very important when developing software in the modern world. I think, I think as Kate mentioned just a moment ago a key part of this is going to be tools. I think it's fair to say that developers be it open source or proprietor are already feeling a little overwhelmed. They're already having to do a whole lot of things already. They don't want to add vast amounts of additional time to do things like security. So what does that mean. We're still going to need to have some education. Okay, that's because things like tooling can't solve everything, but with a little education and with different kinds of tools and brought to bear. I think we can make a difference things like, you know, getting into the CI pipeline tools to detect problems ahead of time tools to detect dependency issues, changing our tools so that that's much more difficult to have a vulnerability in the first place. It's been quite a lot of effort to make it so that primary languages and libraries by default will be, you know, if you just use it the obvious way it will be secure in all too many situations the obvious ways the insecure way. If you work really really really hard and never make a mistake you can make use it securely, and that's not really desirable for anyone. So, I think, I don't think there's a simple single answer which is why you need organizations like the open SSF and others to, you know, folks working on s bombs. Sorry, software build materials and so on, basically working together to to resolve this because it's not a look there's do this one thing, and it's all solved others. Oh, go ahead, go ahead. I was just going to say, I think you can say the same things about, you know, why we know that diet and exercise helps keep us healthy and and and happy. I don't know about you guys I'm still sitting on that couch and, you know, Benji Netflix so I think it is, you know, as we create more nudges like we do for for social other social behaviors. I think, and a lot of what we try to suggest are these nudges these behavioral nudges from employers from projects themselves from thought leaders in in open source. And that's what we're trying, you know, we're trying to do, but just as just as it's something that we've we've always struggled with every New Year's. I think it's, I think this is something that's going to be a sticky wicket for many years to come but it doesn't mean it's not worth still kind of chipping away at every, every chance we get. And as David pointed out, the nudge book it's it's definitely worth a read. I healer did you want to jump in. I wanted to say to them what David said on how the community thinks about security and the quote that you brought is really important the fact that someone does not think that security is part of what they need to do right. So from my studies of Wikipedia, which is different, but has some similarities, I think it is important to think of this report as kind of saying, look, this is something we need, we need to think differently about because so far it's not being taken care of. So one way is to make the tools much easier and Wikipedia they have invested a lot in making bought and things that will make it. Now it's unbelievable that how fast it is compared to how it was a few years ago to fix all kind of you know crazy stuff that used to happen in Wikipedia and now it's something that we can't really do. If you think about Wikipedia back in the day it wasn't reliable because of it so I don't think open source has that threat that Wikipedia had to deal with on the reliability but it is something important that we need to think of, and not to take it as external to the community and its ethos so I think it's something the community wants to think of this is important to us it is part of what we want to do and make better so what David is saying about the institution and how we should take part of it I think it's something that we need to think more. Also, how do we make security part of what makes open source great and not just like something external, more of a to learn from other communities that have done it. So I will defer my time because I think the panels covered pretty much all the all the thoughts I had for him. All right, David I think we'll give you the final word. There were one or two things you wanted to make sure we mentioned. You're still on mute. I'm trying to be generous generous to others and not interfere. So anyway, so I would of course encourage people to look at the report. I think we're going to tweak that y axis that we mentioned. But, you know, the reports raise news questions we're hoping to do another survey in next year so if you see that when you see the announcement if you're a contributor please participate. If you're interested in open source and security I would encourage you to get involved in the open SSF open SSF.org. I mentioned the CI best practices badge if you're contributing to a open source project. You know, by all means work on that. And I think the broader issue here is, you know the world depends on open source software. So, you know, if you're interested in collaborating with the open SSF or anyone else we would love to hear from you, and just find ways to contribute. So thank you very much. Great. Thanks everyone. Feel free to reach out if you have questions. Thank you for those that feel out the survey. Thank you. Yes, thank you. Thank you very much.