 Hello everyone. How are you? I am here to answer questions. I can answer questions on lots of different things, so feel free to ask away. There are a few topics that I'm particularly passionate about and happy to answer questions about. So things like the Chaos Project and Open Source Project Health Metrics. I'm happy to talk about governance, leadership, careers in open source. So it looks like my first question is about my work on the Chaos Project and how we use Open Source Project Health Metrics at VMware. So this is something that I am particularly interested in and quite passionate about, frankly, it's something that I enjoy doing. So my work on the Chaos Project, I'm a governing board member and maintainer for the project. So I help lead one of the working groups and I'm involved in a couple of the other working groups as well. So it's a great project. It's full of friendly people. So if you like data and metrics, it's kind of a cool place to get involved. It's also one of those projects that you don't necessarily have to contribute code to participate to. So it's one of those projects that we're always looking for people to help us define metrics. So how do you use them? What questions are you trying to ask? What should a metric look like? And then we also then implemented in software. So we have Grimoire Lab and Augur, which are two of the software tools along with Cragut that are part of the Chaos Project. So we have lots of tools that can help people measure their project health. So in the past, I've used Grimoire Lab a lot. I decided at VMware to give Augur a try. So that's the one that I've been using most recently. What I liked about Augur is that it allows me to do a lot of customization on the metrics. So it basically provides me with a back end. So it stores all of the data in a database and I can query it and do whatever graphs I want to do around it. Some of the things that are important to us at VMware, I look at for our projects. I look at things like contributor risk. Are there enough people contributing to the project that if one of them won the lottery and went away tomorrow, would it still be viable and we still be able to maintain it? I also look at responsiveness. So one of the guidelines that we give people for time to response for pull requests is two business days. So we look at that. I look at whether they're closing about as many pull requests as they get. And I also look at release cadence to see if we're releasing fixes, which to me indicates that we're also fixing security issues and other things like that. So there's another question about girls in STEM and chaos. So I mean, I do think that it's a particularly interesting project to contribute to for all kinds of different people. So I certainly think that women who are involved in STEM, so science, technology, engineering and math are particularly, I think would be good for the chaos project. So I do think it's something that people can get involved in. We also do a number of like Google Summer of Code and things like that. So if there are some people that want to get paid to do this, we can look at that the next time Google Summer of Code comes around. So I do think it's a really accessible project for people from various underrepresented backgrounds. So my presentation, this is the other question. My presentation scheduled for later this week is about collaborative leadership and governance. Why is this important for open source projects? There are a lot of things that we maybe don't spend as much time thinking about as we should for open source projects. So collaborative leadership and governance is something that I certainly think a lot of us don't spend enough time thinking about. So you can look at, I like to frame things in terms of risk. That's how I frame my metrics. Things are higher risk, lower risk, but it's also how I look at a lot of open source projects. So I tend to look at things like, is it under a company? Is the project owned by a company or is it owned by a foundation? If it's owned by, you know, a nice neutral foundation like CNCF, the Linux Foundation, Apache Software Foundation. Those are great places to host projects and it's probably slightly lower risk than it would be if it's controlled by a company. For example, when you are basically at the wins of the company. And with it being under neutral foundations, you can, you can get lots of people involved. You have, you know, contributors can move in from all kinds of different companies and you get this really sort of diverse group of people. And I think you can innovate better on projects that way. I think that's, I think that's the reason Kubernetes has been so successful was because it was donated to CNCF where we could all contribute to it in a way that I think helped it get a lot of traction within the ecosystem. Let's see what makes a company a good open source citizen and open source projects. This is something we also spent a lot of time thinking about in VMware and we've actually, our engineering team along with collaboration from the rest of the open source program office has put together a really nice list of internal guidelines for how to be, how to participate well in open source projects and how to be a good corporate citizen. I think there are a few key elements in being a good corporate citizen in open source projects. One of them is that you, you really do have to put the community first. So you've got this open source projects have this weird triad so they've got individuals who are participating. A lot of those individuals are employed by companies, but they're participating in this community. So you've got this individual community company triad. And it's important for you to think about the company first or the sorry, not the company don't think about the company first think about the community first. So what is it that the community needs. And if what you're trying to push through because it's what your company needs isn't what the community needs you're just not going to win that battle. You're going to be frustrated and it's going to be unpleasant and and you lose employees that way, to be honest. So I think that really is kind of the key to being a good corporate citizen in open source is in what you know everything that you do really thinking about what the what the community needs. What do you love about working in open source. So I love this question, because it's, you know, it's sort of funny like I grew up in a farm in Ohio, and everybody I knew worked in factories and on farms. That was that was my whole worldview, to be honest growing up. And I sort of ended up looking into being able to go to university and get a computer science degree. And, you know, my first job out of out of college was as a sad man for Unix at the time it was the 1990s. And, and this sort of launched this whole career for me. And because I was a sad man I used a lot of open source projects. And then when I went to Intel a few years later, they got me involved in a whole bunch of open source work. And what I found fascinating was that, you know, these, these communities work really well there's all this kind of there's all the structure behind it that maybe you've not not noticed if you're not involved in the community. But by being involved in these communities, I have met people all over the world. I, you know, if you had told 15 year old Don Foster that I was going to get to travel the world and go to lots of conferences and all kinds of really exciting places and give presentations about technology to other people. I would have been like, you're crazy. That is not a job. People don't pay people to do stuff like that. That's, you know, that's, that's fun. That's not really not really something you get paid for. But the people I've met are super interesting. And I can realistically I can go a lot of places around the world. And, and I know people from these open source projects that I've worked in and I can get together with them for for coffee or for a drink or lunch or something. And it's it's really, really kind of cool because these are interesting people to talk to their, you know, they're fun to be around. And so it's just this, the people that I've met has just been been fantastic and that fantastic and that really, really is what makes the, what makes the community. Can you talk about the balancing the needs of the individual, the company and the community within open source projects. I kind of talked a little bit about that because that is that is sort of the the triad that I was talking about earlier. But you know, as an individual, your, your company has things that you want them to do. The community has things that make sense for them. And you as an individual have to end up balancing these two things. So how do I get things done that are things that, you know, the company is going to pay me to continue to do this really awesome open source job. But how do I do those in a way that it's something that the community actually needs and wants and it's going to be is going to be interesting and so being able to balance that is is is hard, but it's one of the things that will make you successful as an employee in open source. So Christian Patterson asks what role the foundation or project charter and fostering community or making a breaking community. So I do think that the project documentation, the what I will broadly call governance. So things like project charter decision making documentation, things like that. I do think that that can make or break the community. So if I look at a governance, a governance doc or a foundation that maybe isn't, it isn't very neutral. It's completely controlled by a company, or almost entirely controlled by a company. And it's not clear how I as an employee of some other company, or as an individual who's not employed by a company, how can I participate and be effective. And if I like it, how do I move into a leadership position. And if that's not clear, I think a lot of people just don't tend to participate in those those types of projects. Because if, you know, if it's something that you really love to do and you start to get engaged and it's just not clear that it becomes clear that you will never really get to do any real work in that project because you don't work for the right company. I think is very disheartening to a lot of people. And I do think that that can definitely kind of make or break the community. The other things that I think are important, things like, you know, code of conduct, good contribution docs, so that people know how to contribute. Yeah, and like, you know, contributorship, there's so much that you can do that I, you know, broadly kind of falls under governance that really can help make the community great. Denise, hello, Denise. So Denise asks, you went back to school recently, how has that new degree enhanced your boss journey. Yeah, so I spent 20 years in tech, I from my midlife crisis decided that I was going to quit my job, move to London and get a PhD, and I was going to study collaboration within the Linux kernel as my, as my project for my PhD, which was which was loads of fun that got me back involved in things that were more technical again. So this is one of those things you move up within a company you start managing more people and then you're managing more people. And then you sort of work yourself out of getting to do anything technical again. So what this gave me an opportunity to do was play around with the grammar labs tools, huge data sets, I wrote piles and piles of Python code. I wrote piles and piles of R, which was really kind of terrible and horrible. But, but it was, you know, honestly, it was, it was a lot of fun because I got to play with data, I get to learn interesting things. And, and I really did. I really didn't enjoy that. You know, and then going back, getting you know, going back into the tech industry, which was always my plan from the very beginning. You know, I've been able to do a little bit more of the metrics and been able to kind of work it into my jobs since then, which has been, which has been pretty cool. Christian asks, what kind of metrics do you like to look at when evaluating community contribution? Yeah, so when I look at the VMware open source projects, there are there are really four things that I look at. So I look at a look at contributor risk. There are enough people contributing that if one of them left that we'd be able to sustain the community. In the project, I look at whether we're merging PRs in a timely fashion or bizarre responding to PRs in a timely fashion. I'll look at whether we're closing about as many PRs as we open so not not necessarily merging them but closing them so even the ones that we aren't going to merge get closed in a timely fashion. So I look at those releases, which I use as an indicator that we're we're fixing bugs, we're applying security patches and then we're, you know, pushing our release so that people can then easily easily get those. So those are some of the things that that I look at. And then we also look at things like, you know, spotting up code of conduct or the good contribution docs there's there's loads of stuff that I look at when evaluating community contribution. Dirk, look, this is a loaded question from the boss. How have open source communities changed in the last two decades that you've been involved. So I have indeed been involved in open source for a very long time. I think a lot has changed in open source communities over those those two decades. So, you know, originally most of the communities looked like the Linux kernel was a mailing list you set patch diffs. And most of the interaction happened there. I think the tools have evolved significantly. So I think with the introduction of GitHub, and it becoming so incredibly prolific within the industry. That's that's really changed the entire model for how we, how we engage with people and how we collaborate on on projects. And so I think that the tools have changed significantly. I also think that there is a concerted effort to make these communities much less, let's just say to make them much more accessible to people and a fun place to participate. So, you know, 20 years ago a lot of the open source communities were super toxic, especially to new contributors. And there, you know, there wasn't always, you know, much of a push to get a lot of people involved. And, and when you did try to get involved you, you know, people didn't treat you very well if you were if you were new and you made a little mistake or you didn't know what you were doing. And so that I think I think it was really hard to get engaged in open source projects contrast that with Kubernetes, which has a really clear contributor ladder so this is what you do to get engaged in the project and move up within it. Here are the mentorship programs that we offer you. Here's the new contributor workshop that you can go to to learn how to be a new contributor. Here are the piles and piles of amazing contribution docs that you can read if you have questions about, you know, any part of the the contribution process. And here's the contributor experience SIG where you can go and you can ask questions and you can learn more and you can you can really get involved. So I really do think that that's been the other like that just the kind of culture of these projects and being more welcoming and I still think we have a long way to go when it comes to diversity and inclusion and open source projects. But I do, you know, I am optimistic about the progress that we've made so far so I do think we're, you know, moving in the right direction and just take some time. So Cassandra asks what are some successes that you can share some lessons learned that can be applied to someone's someone's own project. Wow, I don't know where to start with this one one of the things one of the things that I would say is that every open source project is different. So that's actually one of the things that makes this an amazing job that I could do for 20 plus years is that every community that I work in is a little bit different. But what that means is that I do think you need to be careful not to compare your project with other projects that are very different from yours because it's easy to get discouraged you know my my project is not this this other project has this. So you know I'd be careful about comparing the projects too much. But one of the things I would encourage you to do is learn from other projects and see how you can apply some of the changes are some of the things that another project is doing back into your project. So now I mentioned the Kubernetes community before it's always the example that I give people when they're looking to grow community. And because it really they really have loads of documentation and mentorship programs and shadow programs we can shadow somebody for for a role and then maybe eventually take over that role. So they have all kinds of good things outside learn learn as much as you can from from other other projects. Rob asks did you ever encounter a community that drastically changed an atmosphere and culture. That's a good question. I would say that none of the projects that I've been directly involved with have maybe drastically changed in culture during the times that I was involved with them. I would say that I do think that the Linux kernel has changed quite a lot when it comes to when it comes to culture from you know looking at it 20 years ago to looking at it now. You know I certainly think there's you know still progress to be made but you know they have they have a code of conduct. They're involved in the outreach you program where they get you know lots of really great interns who do cool work from underrepresented backgrounds. So I do think that you know the Linux kernel is is certainly is certainly getting there. I think the biggest one of the biggest challenges that they have is is kind of the tools that they use so it's not particularly accessible to people who aren't intimately familiar with how how mailing list should work for open source projects which makes it a little bit a little bit harder I think for for new people to to engage in in those projects. Yeah, I think that's probably probably the example that I would that I would use. And I think where are we out of time. I think this session ends at 25 past, which is which is right now. So I guess I guess the session is over. So thank you all so much for coming come to my talk tomorrow I'm going to talk about a lot of the stuff that I talked about here it's kind of focused on leadership and governance but I will touch on some of the other things. So it should be fun. So joining thanks.