 My name is Kate Stewart. I'm working at the Linux Foundation and I'm trying to focus on what do we need to do to make sure that embedded open source is dependable. And one of the key features of open source in general and systems is Linux kernel. And Daniel German, professor at UVic and down you want us to introduce yourself across the street from Seattle and Canada, British Columbia. And so I've been doing research for open source for a little bit more than 20 years. So one of my main goals in research is to understand how open source is developed. And then trying to identify interesting aspects of the development, interesting practices that then can be documented and promoted. For example, one of the, my team was one of the first to identify that code reviews don't, don't in the way that you are a very effective way of the code reviews. And so we were the first to have a paper related to that. And now they are common and used everywhere. And so that's a little bit about who I am. I do a little bit of open source here and there. I maintain my own projects. And I also contribute most of the time tried by contributions to open source and as much as possible I try to use open source in my own, in my own life. So big proponent and a big user of open source also. Thank you. Yeah, back to you. So, one of the tools we've been using is a project called Craig it. And this is looking at the gate commit history in the Linux kernel over the years. Craig it.linux-source.org anyone can go to and explore who's made which contributions what's going on there and so forth. But Daniel's been able to summarize the information behind and we've been sort of exploring this data set as a way of understanding what's happening from a trend perspective. There are over 21,000 unique contributors we've identified and there's 33,000 emails associated with those 21,000 contributors. So it's a rather large data set. We've also done a little bit of work using the gender computer to try to map people's names to their gender. So we can start to look at some of the trends from a diversity perspective. We have been since 2018 we've been doing manual verification as we knew people joined the community. And some of the people some of the names are very hard to classify. If you guys have questions, since we're a small group, I'd like to make this as interactive as possible. But you got questions. You know, feel free to just sort of raise your hands. But that's what we've what the background is behind the numbers you'll be seeing and the data. So one of the key things is the tokens and the evidence in the criminal process, every release is built on the prior releases. One way or the other. And actually we can actually still find tokens in the source code repository from that very first release last back in 1991. Currently, if you look at the whole size of the tokens for the kernel, there's 119 million tokens that make up the kernel today as a 514. And, you know, the portions obviously, these are done by year rather than by release. We've got everything sort of segmented by year base, and we get commits by year. But, you know, the bulk of the new work is, you know, last few years have shown that. So when you start looking, you know, there's a lot of contributions in the last couple of years and this year isn't over yet so it'll probably be more by the time it ends. But as you can sort of see, all of these together make up what we're using today as a kernel. And so that's what we're using as a basis for the analysis. Now, the tokens do get replaced over time. When we first did some of this analysis last year, there was the night there was, you know, 2964 tokens. They were from those first that first commits back in 1991. It's gone down a bit. Some of the things are like, you know, people clean up section, people refactor code, things like that, and that sort of adjusts and changes things. Oops, that was interesting. But as you can see, it doesn't really register on the percentage, but it's still there. There's still traces of it and it could be, you know, semicolons, brackets, variable names, a couple of things like that. Some of the work that's going on in real time is actually touching some of this older code. Some of the things like that and then other parts where people are cleaning up the print structures and things like that. That's all very much of the impacts that we're seeing. But when you start looking, you know, last year when we measure 2020, it was done again about the same time. And then we added by the end of the year, there was over 12,000, sorry, 12 million more tokens added into that 514 kernel. And so we're at about the same point again here. So these percentages are the ones you saw on that prior depth chart. But, you know, we can trace back exactly where these pieces are. For people's quick show, do you know guys on the way when I say token? Raise your hands or do you want me to explain that? Okay, I got, thank you for the feedback. So if you have a line of code and you parse it into, you know, the compiler takes it, translates your code into machine language. The process of transforming from a line of C source file into machine language, it looks at every little element, syntactic element, be it a variable, be it punctuation, like brackets, commas, things like that. Each of those things is considered to be a token. And that is probably the lowest common denominator. So what this analysis has done with Kregat is basically look at working the analysis at the lowest syntactic element. You're doing get blame on the token level effectively. Because lines change, whitespace changes, things like that, the tokens are actually a more immutable concept for getting more precision on the analysis. So if you look at this by release, what's been happening in the last year is, and you look at back, you know, all the way back, in this last release, we actually did see a record number of contributors on one of the releases. And there were so various articles in other UN and other places about some of the analysis that was done. And, you know, Linus has basically commented. So we sort of got curious about, okay, well, what's been happening across the space? And the part that I'm also interested in is what's been happening to women across this space? What's been happening to the diversity? Because you can sort of see here, this line at the bottom is the women. And this is sort of, as you can see, it's been very slowly growing. And we were starting to see a bit of acceleration towards the end of 2019. But it was sort of looking like, hmm, you know, I don't know if we could, I don't know if we're statistically significant or not, but nonetheless, it was sort of like, you know, is it keeping up or not? So this was the question we started exploring with the data to try to understand really what's going on. Overall, though, you can see that last year was, you know, by year, it was, you know, probably the highest number of contributors that participated in the kernel. And in terms of the commits, got the highest number of commits when you start looking at it by year. So this data, it's indicating that the kernel is doing quite well. And given the fact that most of the community is virtual, and everyone's sort of working, can we work remotely? I think that's been a large part of the success of, you know, the kernel's been community to grow. However, there are some interesting factors there. So Daniel, you want to take it over from here and just tell me when to switch the slides. So one of the things that fascinates me about the kernel is just the number of the sheer size of the project, the age of the project, and how it just keeps growing over time. And so as a system, it's a very complex, very interesting. And so as a researcher, I'm very curious about how it keeps working. And so as we were discussing before, so there's a very interesting trend in terms of the growth of number of contributors. Now, what's interesting here is that this is just the number of people. This doesn't take into consideration how much each one of them contributes. It just basically means that as time passes by, then the kernel keeps bringing more and more and more people and who contribute. And in here, by contribution, we mean they are either the author or the committer of a commit. And we know that the kernel is a complex system, so it's not only the people who write the code, but the focus that we have at this point is of the people who are responsible for whatever is in their source code repository. We also know, so we have done a little bit work before, that the kernel is not only this source code that exists in Linux Torval's repository. There are many other repositories that exist around the world and that might never synchronize fully with the rest of the repositories. So think for example of Android, so the people at Google probably have a repository of Android that is heavily based on the original one of the Linux kernel, but it lives on its own and it has its own entity and it probably never fully synchronized again back. So this is the view that we have is a relatively restricted one in that sense. But this is the core of the development team and without these people, we would not have a kernel. Everybody's necessary, but these are fundamental for the success of the project. The number of contributors also correlates with the increase on the commits per year. So we can see that the two plots are relatively the same and so as time passes by, the number of commits also keeps growing. So the kernels grow in terms of the number of files, the number of lines of code, the number of contributors, the number of commits that get into it. And so from the outside, you could assert that the kernel looks like a healthy environment. Now, one of the things we wanted to talk about was the impact of time and especially because we have been in very interesting times for the last year and a half. So we wanted to see whether there was anything that looked significantly different from the way the development was. Personally, my hypothesis was that COVID would have relatively little impact on the development of the kernel. Why? Because fundamentally the kernel is a distributed software development project. People rarely meet face-to-face. Most of the communication is done online. Yes, there are events that bring people together, but in general the kernel is being developed by people in their own computers. So whether they did it in an office or they did it at home will probably have relatively little impact. The other thing that I have observed is that there's a lot of development that is sponsored by an employer. So if the employer said you have to keep developing from home or from the office, then it probably makes a little difference. There's probably an impact in terms of those that they are volunteers, the ones that give their time on their free evolution to the kernel. And there might be a little bit of a difference in terms of newcomers to the kernel. We might see a little bit of that later. But overall, as you can see here, the number of contributors varies a lot from month to month. Well, not a lot. And we're talking about maybe a difference of 100 developers from one month to the next. Each one of these points in this plot is a month. So as you can see here, we have around 1,000 people, 1,500 people, 1,600 people contributors in a given month. And here I thought that the number of them who we have identified as women, there's also a little bit of viability, but because there are fewer people, the peaks of the valleys are smaller. But it's also interesting to see that this is essentially a growing trend and it will take a long, long time before it becomes 50% at this rate, but it's a healthy increase over time. And so we're seeing around 7%, 8% of contributors who are women participating in the development of the kernel. One of the things that Daniel pointed out that I found fascinating, and it's obvious when you think about it is, August and December, there's pretty much always a drop in the contributors. Yeah, so I wanted to zoom in into the plot that I showed before. And so here is just the last three years, actually. So this line here is generally this line here is generally this line here is generally. And, and there, there's some ability that basically you will expect. And there is always a deep around December. So December people, sorry, in December people do a little bit less. And, sorry, let me rephrase that. Some people do not contribute in December. And they, and then some more people come back in January, September, October, September, October, November, and we see a little bit of an update. And we also see a little bit of a dip in terms of the summer. So the summer months, some people actually leave, but in the big scope of things, the curve remains relatively straight. So those, those variations are small and which I guess that if a lot of people are being employed, then they will work most of the year and then only take few weeks of vacation most of the time. So that's what we probably have this stability around 1100 people. Women kind of have so few of them to really see any kind of seasonal variation. There is still a little bit of a dip around December, but not that much. And there's nothing really to make a strong conclusion with respect to this. So these numbers are both contributors. So these are a number of people who at any given month, they have contributed to the current. And that this is commits and commits are a little bit of a tricky measure because I know that commits are created equal. We might have a huge commit that has a lot of work that took a lot of time to be developed. Or we might have just a small change to which was just change a comment because the comment had incorrect grammar. We see both cases of commits and so each one of them individually is different. What is interesting is the overall trend more than the specific peaks and valleys. And as you can see here again, so there's a healthy growth in terms of that. And then there's sonality, but it's kind of harder to see because the variance is so big between one month of the other. And we can see also here with women, there's a lot of variability. And that's going to be from one month to the next. And I guess, if I'm a developer and I'm tasked to do a job. This month might require one commit the next month in my report three and and the one commit might actually require more hours than three commits so it's always a tricky metric to to use. And this is again, zooming in just to actually see what is what is going on. And as I said before, just a lot of variability so not very useful to try to make a strong assertion of what's going on. And this are the COVID bonds as you can see here in terms of commits is relatively flat. And from 2018 19 and then in 2020 we have way more ups and downs. So there is a peak going up right at the beginning of the pandemic keeps going on and then it starts to actually vary a lot from one month to the other. So, again, so very hard to make any strong assertion about what is going on. One of the hypotheses that we have and and it's high points because we have not tested is that perhaps the moment that COVID hit, we had more people who failed that they had free time to be able to contribute to the current. And we'll come back to that in other slides. And so that might explain why suddenly a job in terms of the number of commits and contributors during those months. Just tell me next Daniel. No, go ahead Kate. Okay, so I'll continue. So the other thing that we have been very curious about is this notion of sustainability. At the lives plumber session last week, it's obvious that the age of the typical Linux scale developer keeps increasing. And there are people like me that their middle age or even older, who have been contributed to the kernel for a long time. Those are the people who have the reins of the project. There's a lot of young people too. But from an outsider point of view, it's clear that the other people are the ones who are in charge of the project. We can see that in the age of Linus Torvales, Greg, and many of the of the main maintainers. And so this actually plots the median months of experience. So let me try to explain this a little bit. So at any given month. So let's say January of 2010. This basically says that 50% of the developers have contributed less than 16 months and 50% of the developers have contributed for more than 16 months. So the median essentially divides a population into two chunks, the ones who are above and the ones who are below. At this point, for example, here, this will be March of 2015. And this will mean that 50% of the developers have 16 months of experience and 50% of them will have less than that. So as you can see here, the months of experience keeps increasing. Now, this is not bad. And because you expect that in any company, you will expect that you want to keep experience within team. You don't want to have a lot of people leaving and joining your team. And so in general, do you want this to have an up trajectory? The challenge becomes when you have much more experienced people than new people coming into the team. And at which point this starts to become an issue. It might be interesting, for example, to start to think in terms of in how many years do general developers expect to retire. And so then a lot of these heavy months of, sorry, many of these people with lots of months of experience will suddenly cease to be part of the kernel. And then this curve will start to go down. So this curve goes up because people keep contributing for a long time and it goes down because we have new contributors. This is a more fine grained view of that data. And this requires a little bit of an explanation. So for every month, we divide the developers into three sets. So let me see if I can do that. So we have three sets. We have the ones who are, let me actually start with the ones that are one month old. So this is this line here. The one that is a thin line. So the one month contributors are the people who only contribute for one month and never come back. Those are the people who are maybe for the glory. They are here because they expect to get some brownie points, be able to maybe put in the resume, maybe because they want to test the waters. And to try to see whether they can contribute to the kernel. This is an interesting set for the following reasons. One of them is that these people have already committed to learn enough of the development process to contribute. They learn how to use the tools. They are willing to go through the stress of submitting patches to the kernel or have survived the review process. So these people have a level of skill that is sufficient to be able to start contributing. Yet they don't stay. And I find this to be an interesting set because we need to understand better what the motivations are. They don't stay because that was their intention from the beginning where they drive by contributors who expected just to do one contribution and never come back again. Perhaps that's actually the case. So in many cases, that's what they wanted to do only one. In other cases, they might have come do the work and say, you know what, this is not for me. I don't like the environment is too stressful, or it's not inclusive enough, or it's too much work and I don't have the time to do this. And so that subset is also interesting from the point of view of there's something that perhaps could have been done to keep these people around. That's the one pack. So these are the people who just come for one month and never come back again. So let me actually now go into the green people. So the green people are the ones, sorry, the ones who contribute for the first time. For example, if a person is in January of 2010, and this is part of this 40 people. That meant that that person contributing to 2010 and contributed at least one month later. So it contributed maybe one more month, maybe two months, maybe a hundred more months. So these are the people who contributed for the first time at that point and keep contributing at least once more in the future. So they could become part of the team somehow. This plot doesn't have, doesn't demonstrate how much they contribute. They just says they actually became part of the contributors. And then the corresponding opposite to that is the red line, which essentially means that these people contributed for the last time in that month. So if a person is part of this, let's say 26 people, the red one, it means that in January 2010 was the last time that they contributed. So they're essentially the green people who stopped contributing. And we haven't seen signs of them since then. So as you can see, sorry, say it again. Yeah, and we haven't seen signs of them since then, basically, though they sort of dropped off and not reappeared. They're counted in, yeah, they're not. They'd be counted differently. I'm not understanding what you're saying. Oops, sorry. Keep going. I'll keep quiet. Yeah, they'll do it. It's horrible in the presentation for this. But anyway, so the interest is so, so let's now look at the trends because it doesn't really matter what the numbers are. I think that what matters is what the curse tells us a whole. From this period, so for example, from 2010 to 2015, we see a little bit of an increase. There's a lot of viability, but you can see that this curve is growing. But this period here, it starts to be flat and then it starts to go slightly. It's almost like we have, let me draw here and slide. Sorry. I don't think you're going to draw again. So they can't see you drawing Daniel. It's something like this. And in that curve. And well, the red one, which is the people who leave, it's going up. So more people are leaving than people are reviewing this. Is this problematic? We don't know. All we see is just the data. So the data is saying that there's certain trends that are of concern. And you need to perhaps investigate them further and try to understand better what they mean. I think that there's a very interesting research question in terms of what is the best way to evaluate the sustainability and survival of an open source project. And we don't have precise answers for that. We just chime in here that we stopped the data a year ago effectively because that was our threshold. So that's why you're not seeing into 2021. However, March of 2020 is when you're seeing some of the key changes kicking in there. You know, we have a lot more new people there. We don't want to use data after that because the closer we get to the present, the more that this information will be biased. Because a person might still contribute, might have like a gap of three months and might not be contributing, but they're planning to return. And so we didn't really want to include information for the last year. So we just clip it right on August of last year. We'll probably, like I say, the trends may, some of these people may show up again later and so forth. So revisiting this sort of yearly basis will probably tell us whether or not this is significant in some ways. Yeah, and that also becomes an interesting question. So is there a significant proportion of developers who come back after one year of inactivity? So what is the likelihood that a person lives and they will come back? So at which point we basically consider that person to be lost or at which point that person can be recoverable within the system. I think that there are a lot of interesting questions regarding the people who come and they leave. And I think that we have, as a community, as a research community and as open source projects, I don't think that we pay a lot of attention to these people that only do changes once to try to see whether there's something could be done to keep them around. And make them become long term contributors. Because ultimately, the survival of open source projects depends on having software developers, software developers contributing to the project. You could have all the evangelists that you could have the people doing the documentation, etc. But if you don't have the software developers that your project will suffer. So let me switch over right now and touch on diversity a little bit. Obviously, there's many, many dimensions of diversity. There's geographic. Yeah, I'll leave it to you. I'll leave it to you now. There's geographic, gender, age. We can touch on all of them. But the ones that's easiest for us to do analysis and we've been sort of trending with is looking at the gender one right now here. And the women. So these plots are from Daniel and we're looking at the proportion of women per each release. And that's been plotted that way. At the starting point, obviously it's a lot of variables because very few numbers. And then as we've been going along, you know, we're getting over between 7.5 to 10% each release. Okay. Relative though, so there's the absolute proportion in blue. And then there's the actual relative number. But you actually have the scale of the numbers taking in. Oops. And this is a much more sensitive tension pad. So, you know, we're seeing about 150 women contributing each release, which for most projects is actually kind of a good number. But the challenge is, of course, in relative scale to the overall. We are sort of, you know, there's so many more men, obviously that we're at about, you know, almost 10%, but there's still more space to go. And one of the things that Daniel's been, you know, focusing on a bit is, you know, how many of the commits have been authored by women. And these are the ones that women only showed. And again, we serve can touch up towards about 10% of a release. And in the recent years, it's sort of, like I say, in the last year and so forth and 2020 from March onwards, you know, the question is, is it was going on quite a nice little trajectory upward, but we have a little bit of a blip. So I was, I was sort of hypothesizing that there was an impact and things happening with COVID were happening more that way. So that's where we, that's where we start all these discussions off to try to understand is there anything there or not that significant and only time will tell probably at this point. Why are you making more comments about that, Daniel? I'm not understanding what you're saying. Oh dear. The audio through the conference system is not very good. So I don't quite understand what you're saying. Okay. Okay. I'm just a second. Let me see. Let me just try something here. Computer and improve that. Let's see if this will help. Does that make it better? Or no. Yeah. It sounds a little bit better. Okay. It was on the other side. That's why. So I was just basically commenting. We can't really tell after March 2020 whether that drip is significant or it will be continuing on the upper trends eventually. Data's too young. At this point. Okay. Sorry to interrupt you. There's a latency of around 10 seconds between the Zoom session and when I hear on the other side. Lovely. So I cannot actually talk to you. So what I hear here in Zoom is very different than when I hear there. So if I respond to the questions there, it will take around 10 seconds before you hear me. Okay. Okay. So I'll just keep it here. So because otherwise. Okay. The other fact that I hear you now better. Yeah. Yeah. The other factor that Daniel followed on is. You know, what focusing on women who commit others code, I mean, sort of an indicator of seniority in the kernel. They provide, you know, commits, they provide guidance and so forth. And the interesting challenge is we only have 17 women who've ever done it out of the 701 contributors, but 2.5%. So while overall, in terms of developers, we're servicing 75 to 10%. The maintainer type of or those who are basically in the pipeline for commit and so forth is only about 2.5. So the challenge is going to be, how do we start bringing that pipeline on board? And some of it's going to be a function of, you know, time and what motivates people to sort of start to step up to do more of these type of maintainer roles. So essentially, the maintainer shortage is well known problem. And there is a reasonable pool of women here potentially that might be, if we can figure out the right motivations help help this problem along. And then there's the commits by the non author emerges and then again women only are being shown. And there we've, you know, we've got that 2.5. So the sort of commits and so forth for release is this was a big spike that happened back there. But for the most part it tracks proportionately to the actual absolute numbers that are happening in each release. So there certainly is indicators though. Again, what was sort of happening in February of 2020 to today it's sort of like it looks like there's something going on here. So I still don't know, but it was interesting. Any comments you want to say about these things before I go on. Yeah, so I think that some of one of the, the simple explanations for this is that women are younger in the system so therefore don't have the level of responsibility that comes with superiority. I explain actually why they are significantly fewer changes and significantly fewer women part of it. I think that it would be more interesting to do all of this analysis by generations so the people who start contributing in 2010. Where do they end? What portion of them become long term long term contributors of those become long term contributors, which ones take a role of committing code for somebody else. And how does it break by gender. So the raw numbers don't look very, very useful but I think that to make a, another quick conclusion. It would be necessary to really take into consideration, not to compare against the entire population, but compared against the population of people who started at the same time as them. Effectively a cohort. Yes. Okay. So, as you can see, we can't really drawing real strong conclusions yet from the data we're seeing. But one of the things last week we had Linux plumbers. We ran a survey as part of the plumbers event to hold that audience. What do they think is significant. It was an anonymous survey. And we just wanted to see what they were thinking about what's happening in the future and what the trends lines are. There's about 1000 attendees. And we had about 203 responses to a very short, simple survey. And so one of the first questions is, you know, do you think Linux will be as popular 10 years from now as it is today? And the answer is pretty overwhelmingly yes. 96%. Now that's kind of interesting in the sense that I interpret that personally as trust in the seniority, the senior people in the project. And they feel like it's on a good trend line and I don't think I was too worried about that. However, when you start looking, it's 20 years from now. Well, between 10 and 20 years is when we'll probably see a bunch of people retire. So that could be a part of it. Most people think it's on a solid, but about a third. You know, don't feel confident 20 years from now. Now this is, you know, Colonel, you know, this is the plumber's community. It's certainly not representative industry at all. But it was an interesting insight and, you know, get back to sustainability question. What's going to make things sustainable? What's going to make things, you know, how do we, how do we, how do we see the problem? And, you know, how can we put steps into address? And then we added a few other questions that I thought were kind of interesting. You know, do you think the git will be still used to collect and manage patches 20 years from now? Well, I think that's a vote of confidence in the git system. That, you know, 20 years from now, everyone still thinks they'll be using git or 77% too. And, you know, a bunch of others are, you know, not sure. But I don't definitely know. So I think git for developers is working out fairly well as a way for distributed sharing and collaboration on code is kind of how I take and interpret those numbers. The next question we had is, you know, do you think that contributions will continue to come in value mailing lists in 20 years from now? This has been a source of tension in LKML. The rate of it is such that you basically need a bot to manage it for yourself and to focus on the things you want to keep track of. And that workflow is pretty much baked into the whole kernel repositories. And there's been tensions for new developers coming in to actually master that email workflow and frustrations have been heard in various surveys along the way. And so I think that's starting to show up in here. That, you know, some people are, you know, 25% are saying yes, it will be. Others are saying no. Others aren't sure. So the email workflow, there's something possibly that, you know, it's being under discussion at the Chrome community multiple times and probably will continue to be under discussion as, you know, people age. And as a generation's age, you know, the senior developers who are very efficient with it, the new ones have probably less so. So trying to figure out, you know, is this an area that we should be focusing on with the, you know, from the development workflow perspectives. I think it's things that get talked about at the maintainer summit. We probably continue to get talked about the maintainer summit for the next 10 years until we figure out something that makes people effective and happy. You know, if you're contributing to other open source projects, and they're on their GitHub or GitLab, the interfaces are a lot easier for a new developer to come by, put a contribution in and to, you know, participate. So that's an interest, that was sort of an interesting trend. And then the other question, because of last week, all the Rust talks that were then, and the security aspects and the safety aspects is, you know, do you think that the links will remain fully, you know, primarily implemented in C? And 43%, 44% said yes. But we had about a third saying no. And, you know, there's a lot of actually really good discussions going on in the Rust with Rust and, you know, how can we make the security of the kernel safer. So, I guess to wrap it up, conclusions we've got so far is, you know, pretty much the kernel is vibrant, active, and it, you know, remain fairly resilient with the challenges implemented by COVID-19. You know, there's no really statistically significant slowdown that we can, you know, trust at this point, and there's possibly even an increase from the numbers you were seeing at the start. The trend lines are up, there's more commits, there's more contributors. And, you know, we're hitting these new milestones all the time. But some groups are being impacted, but we can't be authoritative. Potentially, you know, like I say, the women may or may not have, quite frankly, been impacted. There's fewer women that came in. That line was flatter over the year. But, you know, ask me in two years' time, I'm probably able to be a bit more authoritative. However, the sustainability focus is important. You know, as we transition the current leadership, as people age and retire, and get tired of working on the kernel, making sure we have a diverse pool of new contributors, and to keep things vibrant going forward. And part of doing that is to really understand the motivations for the new contributors. And, you know, why is it going to motivate them to stay, contribute, and be effective in the community since we all had to depend on it? And that is pretty much what I had for you guys today, and what Daniel has been sharing with some of the things that we sort of talked about through the course of the year and discussions on these topics. But does anyone have any questions? I'm looking around the room, Daniel. No one's raising a hand or opening their mouths. However, we did get enough people to serve eyes following, and I don't see anyone snoring, so I guess that's a good sign. Go for it. Not that we've been able to tell from the numbers yet. Like I say, we were seeing a lot more, but it's hard for us. Like, most of the corporates went remote, so there's no real data to let us see that. What was the question, please? Do we have any, sorry, my apologies, Daniel. Do we have any data showing the, you know, distribution between the corporate contributions when COVID started and the community? Paraphrase that correctly. Okay, good. And we really didn't do any analysis there. I was going to mention that that's something that we want to look at, and there's a little bit of threat to validity because sometimes people use a public email address. We see a lot of contributions from Gmail, but it's obvious that there is influence by the organizations. And in fact, my personal opinion, and this is more hypothesis, is that the through survival of the kernel doesn't depend on volunteers who joined the kernel, but it depends on organizations who joined the kernel and put developers to work on the features that the companies are required. So the true agents that control the future of the kernel are not volunteers, but are companies who have vested interest on the survival of the kernel. Thank you for the question though. If there's no more questions then, I will say thank you and appreciate your patience with us as we managed to figure out how to get this to work. Thanks.