 So welcome everybody. It's early, I suppose, in the conference. What are we? We're a day tree, I suppose, but really, the kick-off start today. So I hope you're all having a great time. You're enjoying Vancouver. Vancouver is definitely one of my favourite places around. It's just the views, I think, and the way we're looking over the the Convention Centre is fantastic, I think. So today I want to talk about, you know, climbing that mountain from valley of force becoming a contributor, you're making that first contribution, and then getting up to the Zenit of Maintainership. I suppose, when I started out in open source, I heard a lot of phrases, and we'd go through some of them as we go along, but one of them would be, you know, chop wood, carry water, you know, look at the good first issues queue, you know, make yourself known in the community, you know, just get involved. But these are all great phrases when you know what they are, or you've been part of open source communities before. But if you're new to a community, they might make as much sense to you. And being able to understand these things are very important because we need to be, I suppose, more inclusive for folks, so they have a better understanding so we can grow our communities. So maybe rather than thinking of phrases like that, we should think of things like, where can I get started? Where is this first issue queue? Can you help me get introduced to people in the community? Maybe I'm kind of shy, and I'm not really the use of going up or talking to people or putting things out on Slack or whatever. And how do I find out how I climb that ladder into my next role? So if I make my first contribution, how do I build on that? And then eventually, is it achievable for me to get maintainer? So I'm going to talk through some of this today from my experiences, and mostly around the Helm community, which in the last few years, I've built up my contributions and gone towards the maintainer and onto the TOC. So who am I? So my name is Martin Hickey, and I work over at IBM. I'm a maintainer, as I said, in Helm, and I'm also on the TOC committee of the techno oversight committee of the Helm community. I've also made contributions to Kubernetes, open telemetry and other communities. And really, open source is a huge part of my life. And it's something I've really, really got a kick out of doing it for the last number of years, even more so than anything I've done previously in different jobs. So this is just a kind of overview of what we're going to cover today. So let's get started. So hands up here, who's a tea person? We've got hands. Sorry. Hands up for coffee folks. Okay, so, you know, I don't want to get into the whole debate of coffee, tea, snobbery here, like, but let's be fair about it. There's a wide variety of tea out there than just coffee. Okay? And as different variations, and if you're a tea person, well, you know what I'm talking about. But on a serious note, I think one of the first things when you get involved in open sources, like your tea, picking the right one for you is really, really important. And why do I say that? Because I think when things start getting difficult in community, and things will always get challenging as you go along, when you pick a community that you're really into, or technology you're really into, you have a better chance of staying with it during the difficult times. Now I've put in last tricks here because sometimes that's out of our hands. Sometimes our manager or company says to us, right, we want you to go over to that project and work in that project. And that can work out sometimes. But if the option is there, think about it. Now, this doesn't mean that it has to be your partner for life. You can always change. And an example of this is a person I was mentoring a number of years ago, because they were using tecton, and they want to get involved in open source, they said, right, I want to go into tecton. So first of all, they came to me asking me about helm because helm was my area. But one of the first things I pushed back to them and said, before I give you the details how to get involved in helm, I want you to write down your five top projects in order of preference. And when they came back about a week later, they probably thought I was mad because it was the first minter session and I was already pushing them away to come back. But when they came back, would you believe helm was number five and tecton was number one? So over the next year, they got involved in tecton, they started making some contributions. Well, what I noticed after a couple of months was they didn't start going to the next level of doing reviews of PRs, triaging issues. I didn't see it building. So after about a year, I said to the person, I said, no, what's wrong? And I forced them a bit reluctant and then they came back and said, I don't know how to say this, but I don't enjoy working in tecton. And this is not because it's tecton, it's just themselves. It wasn't what they felt they wanted to do. So I said, that's okay. Take a step back for a few weeks and think again what you'd like to work on. So then they came back and they said, you know what? I like serverless. I want to try Knative. So they got into the Knative community. And I'd say within six months or a little bit more, they suddenly were a committer. The next thing within about nine months, I'd say they were a maintainer on the project. They just blossomed and they've grown from there. They're on the TOC committee and that person has really, really found their feet. So choice is very important. So here's the one that, you know, a lot of hands up here who don't, who doesn't like writing documentation. Yeah. And I'm glad many police end up there because I know he definitely doesn't like writing documentation. He always gets someone else. You know what? I was in both camps, but I'm a strong believer in documentation as we go along. And you know, for people maybe that haven't worked in open source communities or use open source communities, you'd be surprised the quality of documentation in open source communities, not all of them, but when good quality docs are there, they suppress any product documentation. And you're probably asking why? Because the reason is they have to cover the full life cycle of the project. They have to show how people to get. First of all, use the project, but then also to become contributor and move up along. So if when you come into open source project, that documentation isn't there, you know, go and help to make it better. But why do I say read the docs? Because when you have a community that has put good documentation in place, it should cover everything. And this is from using the product, setting up your development environment, contributing how to make your way up the ladder from basically contributor up to maintainer. It should all be in there. But also by using the documentation, it gives you a great starting point to understand how the project works. And also, it's a great place to find bugs, which I'll talk about in a while. Because if you're using the documentation, you cannot do what you want you to do, then you know that you can already start pushing PRs and help make new contributions in communities. So it's a nice way of getting you started in a nice, easy fashion. Also, it'll tell you about how the meetings and where the slack channels, et cetera, are that you can start getting you involved. The next thing I'd suggest is, you know, and this might sound obvious, you know, go and use the project or the tool that you're going to be working on. And do everything from the basis of the documentation forward. So whether you have to, you know, set up your developing environment where you have to build and test. And it really gives you a nice way to understand the project and ramp you up in a kind of silent fashion. So if you don't want to get out there straight away, it's a nice way to where you can play around with things, see how things are going. And as I mentioned earlier, if you find any issues with the process or with the documentation, you can start pushing changes already and raising issues. And already you're starting to build yourself up and get yourself known. But it's a nice way of getting your confidence up, you know, when you're starting out. So become invisible. This is always a hard one I deal with because, you know, people always say to me, you know, you're very outgoing, you're very, you're very friendly. You know, I have to work on that as well. And one of the things I found the hardest is when I first went out to open sourcing, it was an open stack was someone said to me, okay, go out into what was IRC at the time. If you don't know what IRC is, it was the precursor to Slack today is a communication channel. And, you know, so I went in my first day and I said, hi, I'm Martin. I'm going to work on here on this and I'm really looking for it. I mean, like it was tumbleweed, not in comeback. All right. So I said, okay, I wasn't unperturbed. I said, I give it a week. So a week later, I went out and did the same thing. Nobody came back again. And what was worse was, there was people definitely that channel that knew me and they didn't even respond to me. You know what I mean? So I was thinking of getting some in my family on IRC to respond at least. All right. But I'm joking about this, but this is what happened. And I went, flip and hell, this is going to be hard going, you know. And it is tough when you're trying to start out. And the idea of being common visible isn't that you have to be up there and, you know, doing crazy presentation or a keynote speaker or doing so many amazing stuff that folks do in the communities. But it is a case of getting to know people. And, you know, no matter what technologies we bring in in this world, it's people that make these technologies. You know, and meeting folks, you know, that you might have seen for the last year or even longer, you know, I'm looking at someone nitrogen down there. You know, I had, you know, I'd missed him at Kilbran. It was great to see him like and some of the folks that I haven't seen for a while as well. Like, you know, this is what it's about. It's getting to know people so that when you're working on a topic, and there's a misunderstanding maybe over a digital communication, you know, you might meet in the hallway here at the conference and say, right, look, this is what I'm trying to do one day. I go, oh, yes, that's what you're trying to do. I thought you're trying to do this. No, no, nine times entertaining. It's a misunderstanding. And you can work together to get it there. So that's where the visibility is important. And so many things that I mentioned earlier about is, you know, finding those little PRs at the start, you know, I know people say go to the good force issue, but hands up, who's ever gone to a project, good force issues and actually found something that wasn't stale or already done. You were saying you did, Nigel? What community? Okay. There'll always be one that'll ruin your pitch, you know. Okay. Thanks, Nigel. But more often than not, and this is not going to do with the maintainers in the project or project itself. It's just good force issues are hard to keep good force issues going. And what I'm kind of looking at here is how'd you get around that? And as I said, which a documentation, that's the first place to go. And it's funny in the Helm project when we released Helm 3, which was a big change from Helm 2. We changed the underlying infrastructure. There was no longer a service inside the cluster and all that. So it was a big change. Yes, the API kind of stayed the same, but there were certain changes. You didn't have to initialization anymore. We put it all out there. We have the documentations up there. We talked to Kucan San Diego saying, right, I went docs, docs, read the docs. For the next year and a half, people kept asking questions, how do I need to serve us again? And you know what? It's not about putting the URL out there saying, look, here it is. It's about talking to the person and saying, okay, yeah, we don't have to do that anymore. Here's a link to the documentation. But it's just a good way of getting in there. Also as well, and I found this hard as well, is coming on to the meetings because, you know, people come on to the meetings and everyone looks so assured and so confident and they're talking about how the project is going and you're this noob that joins, you know? But it's nice sometimes to come on to it, maybe turn off your camera and just listen in the background. And after a while, you know, what happens is one day you'll have something you want to put forward. The Slack channels as well is very good way because for two reasons. Number one, you learn a lot like the meetings, what's going on. And then over time, you might see someone that has a problem that you saw and you can help them with. And that ability to help somebody is just brilliant in life. It makes you feel good about yourself, but also it brills up your confidence. And all of a sudden, slowly but surely, you're getting there without having to go out and say, hi, I'm such and such. Everyone say hello to me and then everyone says nothing. Okay. So it's a nice way of getting going bit by bit. And you're building up this rapport as well as you're going along and people are finding out who you are. And normally they know you just by your GitHub handled or your Slack handles or whatever. But over time then, when you get it, if you can get a chance to come to some of the conferences, then you can get to get to know people in person and talk to them by their name. Okay. So before we move on to the next part, this first part I was looking at is when you're making those first contributions and trying to get involved. And the key parts that to take out of that is picking your project is so important. Don't ditch the docs. Nice alliteration on the D's there. I'm happy with that one. You know, try things out and slowly but surely you'll start making yourself visible. And I don't like the word visible, but I'll use it here because I can't think of any other better word, you know, because it's not about being visible in life, but it's get knowing because it's like everything in life is when you build rapport with people, then it's a better chance of you being able to push in your PRs and make changes, etc. So now we're going to look at going from making those early initial contributions to become what I call, you know, a committer or a serial contributor. And this is what we look at next and it's building that respect as you go along. Has anyone ever heard the phrase don't be a drive by contributor? Okay. So I'm trying to get rid of those phrases again and really all it means is contribute regularly. Okay. And like you can see here the folks on the roof here, you know, they're all working together to build, to put the roof on this house. And that's the same in the community. No one person can do it. And if log4j had taught us anything, you know, you cannot let it on one person to do everything because they just can't. It's just a part of life. And if we've learned anything as well from COVID over the last few years is, you know, we're not solitary people, we need to talk to people, we need to, you know, we need to communicate with people, we need people to help us out in life. Okay. So getting involved and pushing PRs. And like, you know, if you start off forced and you don't, you don't have the confidence or whatever, as I said earlier, look at the PRs that come in, you're learning so much from that. That's the start. Maybe I did it at the start in a lot of projects I joined in, especially in OpenSec where I literally just look at the PRs, he'll eventually I confidence to make a comment. And don't worry, you know, everyone gets a comment wrong. Maintainers get things wrong from time to time. We put a comment in and some guy, what do you mean? This is what I mean. And then you go, okay, sorry. You know, I miss interpreted. It's the same that if every community should have respect for you, that even if you put in a comment, and maybe, you know, it wasn't exactly the right thing to say, people give you constructive feedback. Okay. Nobody should show that you will give out to you because you got something wrong. Everybody gets something wrong. Nobody knows everything. Okay. Michelangelo always said, I am still learning. We are all learning in life. And that's the nice thing about it. So if you want to build up your trust in the community and get known where you're moving towards the next phases, which is towards maintainer, here is where you build it up by working on things and being there regularly and making the contributions. Also to the triage of issues is really important. And maintainers really like people who do these things like triage of issues because we as maintainers do not always get to it. But somebody who's willing to come in, even if you don't know what the issue is, but you're willing to take the issue and try and reproduce it. That's the fourth step because that's what we do. We have to take you to and foresee, can I force you to reproduce this? And if you go and do that and at least put a comment in go, sorry, I tried that, but it didn't work. Or I was able to do this in such and such a fashion. That's fantastic and give the feedback. Now, if you can reproduce it, reach back to person, don't go, oh, I don't think that's an issue. You go, well, I tried it this way and it doesn't work. Can you give me more feedback to troubleshoot this? And this is usually the stage where you go, you always assume, I always assume people know more karate than I do. And when someone comes in with an issue, you have to take them in good faith because they believe that's an issue and it's something that's affecting them. So the first thing is take the person seriously and do due diligence. And if you can reproduce it, reach back and whatever. And you'll often have that back and forth with the OP person who raises it. But that's a nice way as well if you want to get involved is that you can try that and you're working it because we as maintainers will see that. We'll see such and such in that handle. They're great. They always come in and try things out. They always see if it's an issue or not. And then sometimes then if you have the confidence in you might say, do you know what, I'll push the PR for this because I think I can fix this. So yeah, that's the process and getting involved with that builds you up bit by bit. And suddenly this is where you'll see because remember here, contributions aren't just pushing code, their documentation, the triage in bugs, their reviews on PRs. These are the fundamentals that keep the community going. Features and everything else are lovely. Okay, but really it's the core part of it. You know that when you have a stable project, you know it's keeping that project stable is important. Don't be that person. Okay, so like life, be authentic, be sincere and be kind. And the last one kindness and compassion are the most important things in life. Okay. And if you know stuff has ever come to your door where you have somebody who hasn't been well or maybe it's coming to the end of life, kindness and compassion is the greatest thing you'll ever show anyone. Okay. And it's the same open communities. Okay, it's not about being right. It isn't about being shielded from the big bang. You don't always have to be right. You know, we can leave it go. Okay. And unfortunately, there's always someone who is just that person who decides not to be nice. And just if you feel you're going to, you know, for anyone that's older that thinks, you know, you can behave in a certain way in open source communities, this is the beauty of open sources. The ability here to basically say, right, we're all one people. We're all trying to work together. This is what we expect the behavior of people that if you behave in a certain way, you will be called out by the court of conduct. If you keep doing that, you will be blocked temporarily. And then if you repeat again, you will be removed from the community and I've seen it happen. So be nice to people. Don't be calling someone, you know, such and such because you taught to put in something that was silly or not right. Be nice and help folks. And we see that as well from a maintainer perspective as well is we often get comments that you know, are a little bit over the top. I remember someone, someone, they had something in, you know, I put a comment back saying, well, this is the way whatever they misinterpreted and came back in a bigger and then you just stand back and say, okay, this is what I meant this way meant. And in fairness to person on, okay, then, you know, and when you hear, okay, then that's kind of an apology without the apology, would you know, they're back in down and stuff. And it's not about me being right or wrong. It's, you know, we're trying to work together. So the famous chop wood and carry water. Have we all heard of this phrase? Okay. The way I look at this always is, has anyone ever had to clean the drains in their house? Okay. I was shown my son lately about cleaning the drain. Honest God, I've never seen anyone go so gray so quickly in my life. He was appalled. And that's just the drain in the shower. If I take him outside to the main drains, he wouldn't really like it. Okay. If no one likes doing the job, but it's one of the most important jobs anywhere. Okay. And it's the same in communities. There's lots of jobs I talked about like triage and PRs, you know, sorry, triage and issues, you know, reviewing PRs, not everybody wants to do that. They always want to do the shiny ball feature that's going in the big thing that's going to be massive and it's going to change the world. It's the other stuff that changed the world. It's the simple things we do the same as in our houses or apartments or wherever we live. You know, it's taken out the bins, it's cleaning in the floor. The little things keep the harmony and peace in the house, the same in the community. Okay. Look at it that way. And hands up here, anyone here who volunteers for stuff? Okay. Does someone want to be, say, all right, hands up anyone that wants to tell me why did you volunteer many on a serious note? And isn't it amazing when you volunteer, even if you're having a bad time, what you get back from it? It's just like, I teach a group of young boys soccer. And I remember their start of the season, their last year, the season that's coming to the end. I remember going, I had a session, I didn't want to go on the first session of the season. Things were just too much going on. But after the end of the session, I was in great form because they just came back with the energy and enthusiasm and the whole lot and it's lovely. And that's the same in the community. Volunteer, volunteer, volunteer, go out there and help because afterwards, if you're boss or anyone's asking how you're getting on that community, when you're volunteering, you're driving forward. You're doing the stuff, you're willing to put your hand up and say, oh, I'll host the next weekly meeting. All right. Or you become the bulk triager for the week. There's nobody that wants to be the bulk triager for a week. Definitely, especially in the middle of the summer, when everyone's on holidays, because you're going to get trashed. But it's the important part in the community and it's what drives communities forward. One other thing I'd say around that is doing stuff that you might want to do. So when I started a number of years ago on OpenStack, it was in the Neutron Project, which was the networking project. Now, I wasn't a network engineer, but so I was going in there cold, more as a developer than even assistance person. And I'd worked on this particular issue, a bog, and I was just getting going. And someone just mentioned, the maintainer mentioned, all right, well, you're in that area, we actually have this piece of work we need to do. And it was a mandatory piece of work for every project in the community. And it was that instead of having static config files, they generate the configuration through annotations in the code. Now, the minute he, the person mentioned on IRC, I went, oh, no, no. Like I've been around the wild programming. I knew what was involved. It was trawling through thousands, thousands of lines of code and files, finding the places doing the insertions. And I went, oh, no. So I went straight away and I was like, of course I'll do it. But little did I know, and I was only starting out on my journey, that the impact that it had was way beyond, you know, what I thought. I did it because I needed to do something. And I knew that I needed to be helpful. And I wanted to be helpful. But what it meant was, every maintainer in the project had input on that. It was a piece of work that was mandatory. That was sitting there. No one wanted to do it. Because they were too busy with other stuff, number one and number two, I'd say no one wanted to do it because it was so manual. But afterwards, we used to have these meetups in between the conferences called midterms or midcycles, I think they were called. And I went to a one in Rochester, Minnesota. And I didn't know I needed folks, you know, and I kind of just went, but folks came up to me, are you such and such with that handle? I said, yeah, thank you so much for working on that. And he went to even outside the project into across the whole community, because he got involved and how the builds of the projects and stuff like that would be. And it helped me so much. And he brought me that kudos. And I respect that people said, you are winning to go out and do stuff. And they said, they really liked the fact that no matter what comments came in to me, I didn't take them personally. I just said, okay, I'll fix that. You know, because 99% of the time they were right, you know, and yeah, maybe I prefer to do it some other way, but it doesn't matter. It was about getting the thing done. So, yeah, it helps that way. And the last thing I'd say, I suppose is, you know, mindfulness is a big thing that we talk over the last number of years. But to me, mindfulness is being there in the moment. Okay. Whatever that moment is, and I'm beginning to slow myself down that when I meet a friend for coffee, I'm talking to that friend. I'm not thinking about, hell, I have to drive here, or I have to go to that thing next, or I have to debug that piece of code, or I have to do whatever I have to do with my life. I'm with that person at that time. And it's the same in the hallway tracks. If you meet someone, be with the person, you know what I mean? Talk to the person, you know, get involved. And it's the same in the community. You know, we won't always be able to work 100% of the time in community work. We do get paid by a company, and we have to work on company stuff as well. But when you have that 20% or that 50% or 60% of the time you're in the community, work on that stuff while you're there and be there. Because that's how you're driving the project forward. And that's how you're driving your respect as well. Okay. So we've just talked through, you know, that middle phase where you're building yourself up, where you're earning your respect. And a lot of this really is about helping and volunteering and being there. You know, earning your strikes, making yourself be known. Because when you come to this stage of then that you, this was your goal or your zen itigoto, you know, you're pretty much already there. And I suppose it's akin to, or similar to getting a promotion at work. And I've heard it said before, and I never understood it, you know, initially was, you know, sure, you're already doing that job. No, obviously, that's an Irish way of saying it. No one says, sure, you're already doing that job. But you know what I'm saying, that you always had a phrase, you're already doing the job. And I think it's the same by the time you come to a maintainer, you look to become a maintainer, you're already doing a lot of that already. Yeah, maybe you don't have the access rights and eventually you get the keys to the kingdom. Do you know those lovely, when the email comes in, GitHub has now given you access rights and repo such and such, you know, click on the URL. Yeah, that's always beautiful. Or, you know, people often post out when they become a Kubernetes member or a Kubernetes sync member or whatever, if you're in different communities, it's nice when that comes along. But just know that the work you've done in your volunteering, you know, your chop mode, carrying water, you know, whatever else that you've already made yourself there. So the next phase then is probably the nomination process. And that's going to differ from community to community or project to project. So in some communities, it's in the mail to the maintainer list to say, I'd like to move towards a maintainer. In other communities is the maintainers themselves would raise a nomination and say, we want to do a vote on this for this person. And then they'll reach out to person and say, would you like to be a maintainer? Well, you think, you know, you have all the right attributes. You've shown time over time, you know, what it is to be a community member and so forth. Or in other projects and time gone by, maybe it was the project technical lead would, that person would raise a promotion. So it depends on what it is. But, you know, that's where the documentation is coming in again. Is the ladder, is it documented about the ladder and how you go towards that? And you can ask about that. Also, some communities as well, I know, in open telemetry, to even become a member of the community, you have to show X amount of contributions and so forth. And the same as well, when you went into Kubernetes SIG and Kubernetes. Wait, I like spider-man. So I just put that in as well. So I see today that NGDS, Rob, my phrase like with great power comes great responsibility. Now, unfortunately, he didn't know, seemed to know where he came from, which I'll have to say, I'll have to call him up on that. But on a serious note, like Peter Parker's uncle, it is important when you get to a maintainer, that, I suppose, first of all, you realize of why you're there. It's not for you to have this badge and go around, I'm a maintainer. Look at me. It's about, you know, we're kind of slightly switching roles where you're now going to become what I say is more a facilitator than to be driving loads of functionality into the project. So where now you're looking at, helping other people get stuff in, you know, helping with those reviews, those triages, etc. Really doing the core parts of the project, like, you know, maybe the security work that has to be done. So I suppose in the science community, we've been pushing the fuzzing from the community in the last number of years on our projects. So working on that. And I did some work on that in last year for the help project. And, you know, it's, you know, let's challenge it and stuff, but it's stuff that the project needs. But I always think the key part is helping people and facilitate them to drive forward in the community. So, you know, the shoes on the other foot now, you're no longer, you know, making your first contributions or committer, you're no helping those folks come up along. And that's what it's all about is it's lifting the rest of the folks back up like you were lifted up or helped when you were on your journey. Right. So I've done this talk at Open UK, and it was an interesting part at Open UK was around sustainability was a topic that the community asked you to bring in your talk. Now I was a bit confused because sustainability has so many different connotations in my head between, you know what I mean, energy and how we do things, you know, with a compost and everything else up to, I wasn't sure about the community and I don't know if I got it right or wrong, but I'm going to go with what I put up. So, you know, so you've probably all seen this picture on the internet and, you know, it's been brought up for a load of different connotations. Okay. But for me, I suppose it's twofold when we talk about sustainability. On one hand, it's what does open source give us? And on the other hand, what do we need to give to open source? So if I start with the first one, well, open source brings us. And this is something way back when I first went to an open source conference, which I think was in Atlanta, open second land in 2014, I'd say, was the collaboration. All these people who's going to rooms collaborating to get it from different projects, you know, from all over the world, different types of people, you know, arguing and discussing, you know, we're trying to go towards one goal. Yes, you're trying to do things for your company, which are also trying to drive the community forward as well, and finding that balance, you know. And because of that collaboration, you know, back when I started, I suppose in software, you really don't everything yourself. Yes, you might get to our party libraries and build on that. But generally, most companies build products and even companies build similar products. So there was a lot of hell of duplication going on. Yes, they were saying, oh, my one's different to your one and so forth. But the nob of it was the same, you know. And the great thing about open source we've seen over the years is now we're working to be more sustainable, to be more less duplication and more collaboration where we can now build stuff in the community and our products can build up on top of it. So we're not creating the stack and duplicating the stack, we're using the one stack and putting our value on top. And this brings around increased productivity, but also brings over knowledge sharing. Because from what I have seen and what I've experienced is I have learned more in open source communities than I've given back, I'd say, you know, I'm always learning from someone, you know, and I think we're all the same. And we bring that back into our companies or wherever else, because we learn when we're out in the communities. The lovely, the next lovely part of it is that if you've, if you're, if you've a device and you've access to probably GitHub and you've get, you can work in any open source community. It doesn't matter who you are, what village you grew up in, what area you grew up in, it doesn't matter if somebody, you know, called your names when you were grown up or whatever else, you can go out there and do stuff, you know, without being judged. And you're only judged by your GitHub handle or whatever else. No, I don't mean you have to have the lovely panel with greens all over the place to say, geez, I've made three and a half thousand contributions last year. That means you need to get away from the computer and get a life because you're, you're doing way too much then. But on a serious note is you can be anybody. And that's the beautiful natural, sort of organic inclusivity and diversity of open source communities. But, you know, that's built on as well by the great people that work in, in the groups to keep that inclusivity and diversity as well. So it's not just on its own, I'd like to say. And the last one then is our own shared environments and stuff that we can build it. And in fairness companies have been good providing systems and servers like that. The foundations have been very good that we've grown on where we have free CICD and stuff like that. And we can, you know, when we put a project out there with GitHub actions or whatever we use, CircuitCI, you know, it's given for free and we can build our projects on it. Flipping on our own, what do we need to do? Now, this is a phrase that was coined by a former colleague of mine, Chris Ferris, around the free puppy that open source is not a free puppy. So when you get, you know, if you get a free puppy, it's not just for Christmas walks. Just in January, when you're tired of the puppy, you can't put it in the side of the road and leave it there. The puppy needs work or any other pet you may have, you know, you need to feedback into that community. You can't expect, you know, to build your product on a series of open source communities and give out then when you find a bug inside the community, oh, look, there's a bug in there or you need to go and fix it. There's no ye. You know, if you're looking at GitHub, you obviously have access to GitHub. You've got it, you know, you're using it, go and make the fix or do the contribution. If you don't know how to do it, ask how you do it. So this is about giving back into it. And it's becoming a big thing now, I suppose, with all the security issues and for us as maintainers as well, like, you know, all of a sudden, you know, you're working away an open source community. The next thing you have to become a security major, a PhD in security and understand S bombs and other kind of bombs and everything else, do you know what I mean? You know, we're most of us are just hardly Joe soaps. Everyone of us is just hardly Joe soaps. So we don't know to do everything. And we can't be expected to know to do everything. I know I saw that when we were working on the fuzzing and someone reached out as well from a security tag in, in the CNCF about she asked me, like, you know, what, you know, what's your feedback when you worked on the fuzzing? And I said, there's a lot of knowledge you have to pick up around, you know, CBEs, how do you do the advisories and GitHub? You know, how do you do the fixes? How do you do the release? And it's sort of, there's knowledge and we're lucky we had knowledge of that in the project and we could share it. But nobody can be expected to do all that. So if you want to build your product to make money off it, give back, okay, get involved, put folks out there, you know, help it. The other one around stack and license and I suppose this one is around where, you know, sometimes companies decide they want to open source their stack. And I'm not going to name names, but, you know, a stack goes out there, they have it out there a number of years and in order people come along and I suppose steal their pie. They take the stack, they build on top and they're making loads of money off it and they go, hang on here a second, we didn't expect someone to take our stack. So, you know, and sometimes then they try to withdraw it and then it gets forked and all hell breaks loose. That's not always the company's fault because sometimes when they're putting out there, maybe they didn't realize what they were, what they were putting out there. So I suppose if you're going to put something out there into community, I suppose know what you're putting out there, your stack, know that once it goes out there, it's, you know, free for anybody to build on it and, and, you know, maybe they will find a nice product off it. Maybe that's just, that's just the part of life. Also around the licenses, well, put a nice permissive license out there, you know, like your Apache 2, your MIT, your BSTs, you know, stay away from the, the, the got you licenses if you're doing that. So I suppose all around there, you know, when you use stuff, give back in a nice way as well. Right, you conclude, if you start out as a nice person, you go out there with good intentions and you're willing to help out and do the stuff that maybe not everyone wants to do, well, you're going to make your journey through it. Yes, they'll be ups and downs. Yes, it's not all roses. Sometimes it's difficult, you're sitting at home or you're sitting in your office or whatever, right, the keeper going, how the hell am I going to do this? How am I going to get involved? Everyone goes through that. You know, everyone has some sort of imposter syndrome. Nobody is that confident. I don't care who you are. You know, you're the biggest business person with all the money in the world. They have to have self-doubt as well. But it's working with the community, making those communications, building yourself up. And then naturally, that'll bring you towards the maintainer if you want to get to maintainer. And after that, when you get there, giving back and helping the other people that come forward on it. And I think, I think, yeah, that's, that's it for me. So do I have time for questions or are we over time? Does anyone have the time? Oh, it doesn't. Okay. Before I go forward, actually, now they're reminded. There's a follow on talk here from Dawn, just here at the front. And she, she's actually going to go forward with the right, a really nice talk. She, the correct pronoun. Yeah. Yeah. Day, sorry. And day is going to go forward with a really good follow on talk where, you know, walk around the maintainer and how to be maintainer and, and also how to, you know, you know, keep maintaining the projects and keep projects going. So that's going to be a very good talk going forward. So hopefully you'll wait on for Dawn. All right. So anyone with any questions? Yeah. Do we have just one second? We might need to get a microphone made. So just one second. Samuel is just getting it back. Hey, here we go. Very nice talk. Thank you for that. So my question is, how do you identify such community where you will be just as welcome in a sense that let's say I am new to this, I'm undecided. I have a number of projects I am passionate about and I would like to contribute. I don't know anybody on these communities. For example, you're like ground zero. What science should I be looking for to know, oh, this community seems like a better fit for me than this one besides just reading and issues and people being, okay, the language they use is a bit kinder. So maybe this is better. What should be the science I should be looking for? I suppose first thing is what are you interested in, you know? Is it that if you're going to be doing a part time, is it a particular project that's part of your product you're working on? You know, because then it gives you a better opportunity if you're working with your manager or whatever else to say that maybe, can I use percentage of my day or week on this project because we use this and we depend on it. That'd be the first thing. But really it's what you're interested in. Second thing is I suppose is to look out in the project and probably something I didn't cover is an inclusive community. So is it owned by a foundation or is it owned by one company or one what we call benevolent dictator that may turn not so benevolent? You know, how many contributors are in the community? Is it a diverse group of people from different companies, etc? Things like that I think is what you're looking for. And our reviews taken seriously are PRs reviewed in a nice, you know, within an ice timeframe or they just spread out. Things like that I think is probably a good first step for you. And then, you know, a lot of stuff is online. So if you check online, there's probably comments somewhere, someone saying something about the community, you know, if you're here and kind of, I suppose like TripAdvisor, maybe, you know, if you're here in comments that aren't so nice of our community, maybe that's a right flag for you as well. Also on the license and is the last thing, is it a nice permissive open license where, you know, any contributions you do or if your company's building on top of, you know, will they have to give over the farm if, you know, they're requested to. So I think things like that start to note and what field do you get from it as well when you reach out? Anyone else? So we'll finish it up. So thanks very much for coming folks and I'll see you in the next video.