 So, hello everyone, a very good afternoon. And hopefully you'll have had your share of caffeine, or tea, or whatever's your preference. But I'm Divya, and I work at SUSA. And... I'm Bill Mulligan, and I work at ISA Valent. And we're gonna be speaking about, you know, the 10 biggest mistakes you shouldn't make in open source. And that's partially inspired by what we've experienced, and what we have committed as, you know, probably mistakes in our open source journey. So, before we go ahead, we would like to introduce ourselves because not a lot of you all know us. So, as aforementioned, my name's Divya, and I work as a technical writer at SUSA. Also, been around in the ecosystem for around two, two and a half years right now, working on a bunch of open source cloud native stuff. But, yeah, most of my, you know, career prior to SUSA was in the proprietary side of things. And this journey has been really eventful, which is why, you know, Bill and I sort of thought of giving this presentation about how folks could actually avoid the mistakes that we made. What about you, Bill? Yeah, so I'm Bill Mulligan, and I work in the community around Cilium and EBPF on the open source side. Fun fact about me, I actually don't know how to code at all. My degrees are in biochemistry and social science. So, if you were inspired by the keynote this morning and want to get more involved in a project, but don't know how to code, don't worry, there's stuff for you in here, too. But before we go ahead, we just want like, you know, show fans as to who's actually contributing to open source or who's actually trying to get into contributing to open source, like, oh, that's a fair one. So, the very first thing that we'd like to sort of shed light on is, you know, basic etiquette, right? This is what every kindergarten or every basic preschooling activity teaches you to say or be pleases and thank yous. Unfortunately, when it comes to, you know, adult interactions, I think we kind of forget them. So, one of the very first mistakes that you could possibly make is to not actually be decently courteous to the fellow human beings that are across the world or, you know, across the computer. So, it's very easy to forget that, you know, that person who's sitting across the computer is not actually a person. So, you should definitely, definitely be courteous and show basic human decency. Yeah, this is just like kindergarten, say please and thank you to the maintainers, to contributors, to every single, everybody. Right, and then when we speak about, you know, the fact that, I mean, not just showing basic human decency, we also need to take into consideration that the human being at the other end is probably going through, you know, some personal struggles of his own or their own. And it's important that we take that into account, be considerate and be empathetic. Especially, I'd like to throw back to this incident during log4j wherein we had a huge outcry about the, you know, log4 shell issue and not a lot of companies after that even took up the actual mantle of having contributors, you know, our sponsoring contributors to that project. So as much as we love for, you know, open source to be more considerate and empathetic towards the contributors and towards, you know, the projects that we put out, we also want for the reverse to happen with us, right? We want for companies, we want for organizations to be empathetic when they're interacting with us too. But in the next slide, we realize that it's complicated because again, human interactions are complicated, humans are complicated. So when we talk about, you know, interacting with another human being maybe from a different part of the globe or maybe from a, you know, not a different ethnicity or maybe a different race, it's very, you know, easy to take for granted the fact that, you know, that person is, you know, not doing this as part of their day job and is there for you as a maintainer or as a contributor. So targeting that person via various avenues, whether it be via DMs or emails or LinkedIn messages or where have you, it's very easy to forget that that person probably might be too busy to reply or might have a life of their own. So we have to be considerate when messaging or, you know, putting our concerns across. And there have been several instances, not just within the Kubernetes community or within the Israel community or any of the cloud native projects that we work with but across larger, you know, the larger open source ecosystem where this has not been the case. Yeah, another fun fact is maintainers actually do go on vacation too. Sometimes. Yeah. And talking about being considerate and empathetic, how can we actually forget about, you know, folks coming in and asking maintainers or contribute, like, you know, people in the contributing side of things. So why a particular feature was not implemented? So, you know, it's very easy to actually say, hey, I actually want feature ABC to be implemented in this project. Why don't you go ahead and do it? But the thing is it is a lot of effort and open source projects are community driven. They are not, you know, motivated by a single person's or a single company's desire to move forward. And it's essential that we take into account what's best for the community as well. Like, yes, your feature is important and it's probably important to you as a person or you as a company or an organization. But you also have to put the interest of the larger community at heart while making suggestions and be nice and show basic human decency while requesting for features because it's not easy. A lot of us do this apart, I mean, as part of our day jobs and also outside of it. So if, you know, you're going to pester or you know, you're going to be rude to a maintainer or a contributor, maybe a side effect of it will probably be that, you know, it'll fall on deaf ears. This is a very great example of how contributors amongst the community in itself were not, you know, showing the basic human courtesy of actually, you know, allowing another contributor to step up because communities thrive when everybody thrives. Try everybody within the community thrives. So if you're not allowing for other contributors to step up or if you as a maintainer are not providing an avenue for other contributors to step up, it's clearly a miss and it's clearly a lack of empathy from your part that you are not ready to delegate or let other people step up and do the work. And it eventually will not board well for anyone because taking a lot, taking on a lot of the work, taking on a lot of the, you know, pains for a project will sort of lead you into burnout. So nobody wins if you are not actually helpful or, you know, allowing others to step up and take on roles within the community. Within the ecosystem, there is already a guideline, at least in the cloud-native ecosystem, we have a basic guideline in place in the form of code of conduct. And that really helps set the baseline for how community interaction should be. Although most of the times we do find that events and, you know, even just, you know, interactions within the community are adhering to these, there have been cases where this is not followed. And oftentimes it leads into unwanted scenarios where, you know, you have to take people aside and scold them like they're little children and that's not something anyone of us as adults cherish. So being considered an empathetic is absolutely important when you are getting into a community. Yeah, and please follow code of conduct. It's not just applying to hear at KubeCon but anytime you're contributing or interacting with any CNCF projects and open source in general. The next thing is what I was talking about, thinking that only code contributions matter. As I was saying, like, I don't know how to code at all but I still make a lot of contribute contributions to open source upstream. For example, what I'm doing here is I'm adding a blog post to the Sillium blog, you know, helping spread the word and the message and helping other people find what's going on in the Sillium community. Other examples that I've done in terms of contributing is creating templates, so sharing like the knowledge that I have or, you know, documenting different things. Divya's an actual technical writer. I just write a couple sentences so people can find things. Yeah, and for those who think, I mean, at least I've heard a lot of this recently that, you know, code can be self-documenting. Please do not fall prey to that fallacy. It's not the case. Code cannot be self-documenting for everyone. There are a lot of new contributors and only when, you know, you have good documentation can you drive adoption for your project or your product, you know, if you're talking from the propriety side of things. And beyond that, there's lots of different ways to contribute besides just code. A community grows through lots of different things. One example is bringing people all together at events like KubeCon or in more local, more regional events like the Kubernetes Community Day program, bringing adopters of cloud-native technologies together on the local level. You can become an organizer, a program committee member, someone who's just helping, like, spreading the message and tweeting about that. And that's all contributions that you can do that don't require you to know how to code. For instance, I gave a talk actually earlier today about the Kubernetes Community Day program. If you're interested in learning about that, I highly encourage you to check out the recording afterwards and if you have any questions, also feel free to reach out to me about getting involved in the KCD program. The next thing that you shouldn't do in open source is trying to start too big. You don't want to come in with a 16,000-line PR to a project. Maintainers aren't gonna be happy and it probably won't get accepted. Also, it's not a great place to start because you might not know everything about the project. And actually, it's a lot easier to smart with smaller contributions. These are actually my first two contributions to open source and actually Kubernetes too. If you can't quite see what it is, the one on the upper left is fixing a broken link and the second one is adding in a documentation entry in the Kubernetes glossary. So both very small changes, but helpful for people looking for information later. Yeah, and I think your first code contribution was similar. So I started out with contributions to docs. So basically, it was a small JavaScript date change. It was to add the dates to the JavaScript code that was there within the docs. But it was a relatively small change compared to the things that normally you would expect of a contributor to do. But we hate to say that please don't think of any contributions as big or small. And try as far as possible to reduce the manual overhead that a project is facing. Because those are important areas too. Given that a lot of people try to work on trivial edits or trivial parts to a project, but automating it will help like a lot of manual efforts for the manual efforts to be saved rather when the maintainers actually have to work on reviewing and everything else. So don't try to start too big. Even minute contributions help. And focus on trying to reduce the manual overhead overall rather than targeting small edits or small parts of the documentation. Because as you grow in the community impact matters a lot. The kind of work that you do matters a lot. And making trivial edits will take you so far. But you should also go beyond that and try to help the project in general with reducing the manual overhead that they have. Yeah, the next thing is as you're starting to contribute, there are a lot of resources in a lot of projects and you should do your research. I know a lot of maintainers get slightly annoyed by the questions that are asked repetitively over and over. If you saw the keynotes this morning, we have about 1,000 maintainers supporting 7 million people. Unfortunately, that doesn't scale out. This is why we try to document a lot of things and you should try to see what is out there kind of look around. The things that I would recommend doing if you're approaching a new project and trying to figure out how it works and how you can contribute to it. The first one is read the read me. It's called read me for a reason and it's a really good place to start. The second one is if you're in a project slacked, a lot of them have pinned items. Those are important things, usually ways to contribute, style guides, important resources, who you should contact. Look at the resources that people have pointed out for you to use. Attend a meeting. This is a great way to get that one-on-one connection. So if you think you want to move forward with something and you do want to get in contact with them, a lot of projects do have meetings and the last one is most projects and all the ones under the CNCF should have a contributing file. If you want to contribute, read that. It has the ways that you should do it, probably how to set up your environment if you're contributing code or how they want to style things if you're contributing documentation or other ways that you can contribute to the project too. And it's usually a great resource to start with. At one last item to whatever Bill has said, so plus one to whatever he said, but over and about that, if you find things missing in the contributing or in the readme files, that's a good first way to contribute to the project too. Go ahead, make that suggestion to the person who is probably leading the SAGOP, leading the areas of efforts for that particular project and talk to them about including that thing in their particular readme or in their contributing so that it becomes easier for the next generation of contributors to start contributing to that project. Yeah, for instance, so when I joined ISOvalent, I wanted to add some things to the website, but I realized how to contribute to the website wasn't documented anywhere in the contributing markdown. And so I added that section to the contributing doc so that other people when they want to contribute to the website in the future have the resources to be able to do that. Like I said, when you go about this journey, you are bound to require help, all of us do. It's not like a lonely journey where you have to go all alone and reach the top or whatever, because like I said, a community thrives when all the members thrive. So people are available to mentor. It's just about you seeking them out. One of the major, I think, mistakes that people assume when they are experienced is that, hey, I already have a job. I already know XYZ about some part of the tech industry. I don't need anybody coming in and telling me about other stuff. I can probably figure it out if I read the documentation alone. But that's a major flaw, because what tends to happen is the human interaction or the value that a human interaction can bring is grossly undernoticed by most of us. Primarily because in more academic or corporate setup, mentorship is not something that's actively encouraged. We don't have programs for that. So in open source, it's different. We have actual programs and we have informal ways of delivering mentorship to people who are in need. So CCART mentors, CCART people who you want to actually, who you think have a good grip of the ecosystem, ask them for help. Obviously ask them in a nice way, because they're humans too, but it's instrumental in getting your journey off the ground because what a human interaction can do to your career is something that no reading docs can. So that's one thing. And we have several internship programs. It's not just Google Summer of Code, Google season of docs. These are just four that we remembered, but there are several of them. And fun fact, I think a lot of them also accept experienced members within the industry. It's not just for college students. So take the opportunity of seeking out mentorship and actually taking help from somebody else in the ecosystem so that you can navigate it better. Yeah, and the cool thing about all the programs listed on this slide is they're actually all paid too. So you can get paid to learn and contribute to open source. For instance, right now in the Cilium project, we have a mentee working on improving the security of the release project for all of our projects, which is pretty cool. But beyond just like paid ones or those programs, there's other programs across the ecosystem too. Yes, so this is like the Kubernetes release shadow or shoutout that I have to give because this was one of the things that I was part of. And it's a fantastic program to get involved in for new contributors and experienced alike because you get to have a grip of the ecosystem. The Kubernetes project ecosystem, of course, not the entire CNCF one, but you understand the ecosystem better because there's someone to hand hold you and show you the ropes rather than you trying to, you know, climb it all alone. So this was one of the instrumental programs where I met a lot of friends and I made a lot of them there in the audience. So shout out to them and shout out to all of them who gave me a chance because I wouldn't be here if it was not for them. The next one is not attending meetups or events. When we were talking about, it's also important to meet people in person. These are a great way to do that. Create that one-on-one connection, find a mentor or someone who can help you out with the next project. Being here at KubeCon is one of those ways, but you don't have to travel halfway across the world to meet other people in the cloud native ecosystem. As I said before, there's probably a KCD in your area that you could attend or you could go to one of the CNCF meetups in your cities or a city close to you. For instance, I think this is a really great example. So he attended KCD Banglaroo and attended the Kubernetes contributor summit there. Well there, he got inspired to start contributing to the project and became a maintainer of one small part of the Kubernetes project. He was then able to give a lightning talk at KubeCon in Valencia in May. So you really see this from attending event all the way up to becoming a maintainer and giving a talk at KubeCon. It's really, this whole spectrum all kicked off by attending and being expired at the local level. So it's a great way to meet people and to start your journey. I actually also have a similar story. This picture is from me in Barcelona in 2019. What I didn't know, the person just to the left to me was gonna be my future boss. So I met Liz first on a bike ride when I attended KubeCon and when she tweeted, I'd actually already met her a couple of times on bike rides and it made it easier for me to find my job that I surveil it. Yeah, so we basically wanted to give a shout out to our own talking like this like inception at this point but one of the things that we wanted to give a shout out is the fact that we wouldn't have been here had it not been for others who shared their learnings with us and others who had not shared their mistakes with us and had held us and attended these and had we not attended all these events. So that is one aspect of it but also it provides a nice segue to the next one wherein they shared their learnings with us. They shared their mistakes with us whether it be via talk, whether it be via a blog post or whether it be via a video. All of them shared their learnings with us and we tried to pay it forward by doing the same thing. So I think Bill writes a newsletter every fortnightly basis and I try to write a newsletter every week, not successful in terms of the fact that I stick to the routine but I try. And that's my way of paying it back forward. I mean not paying it back forward that sounds wrong but paying it forward. So that's one thing that you always need to do when you're in an ecosystem because once you're at the states where you are able to, you know, you know something, you at least know how to contribute, it's your job to lift others up as well. And it's absolutely essential that you pass on the knowledge to another contributor maybe experienced, maybe new because everybody stands to learn something from another person. I learned a lot by working with Bill on this one. So it's all about sharing what you know and learning from others in this case. Yeah, and sharing your learning is another great way to do non-code contributions. So these are Divya's and I's GitHub repos and the different ways that we've shared our learning. So as she said, we each have newsletters. We've also given different talks like this one to share a learning with the community. We've written blog posts and spoken on different types of podcasts. Each one of these are great ways to help educate other people and get them involved in open source. One of the things that you, that I probably am guilty of earlier on in my career is to not experiment at all. Probably that's also because of the fact that I had a job and this is not distinct my previous employers, PSA. So I was also in a job where I wasn't really allowed to experiment is not the right word but I didn't have the time to experiment because I was doing my night of fire, going back home, doing the daily routine. But when it comes to open source, we have the option to choose our own adventure. I think Taylor was the one who actually said it in today's keynote that open source is all about choosing your own adventure. So that is one thing that's afforded to us as contributors within open source. You get to choose your own adventure. You get to choose where you go next. And if you don't take that opportunity, it's gonna be sad because every single interaction that you have, every single talk that you attend could be the next thing that you get interested in and tinker on. So my journey sort of looked like, first I was an electronics engineer. I was not even part of the IT industry. And then I jumped into IT and worked for like, I think about eight years as a systems administrator. The only reason I came into open source was because of Kubernetes and trying to explore the Kubernetes project. And from there onwards, it has been experimenting with one project after the other. And I'm not gonna say that I know a lot, but I know a little more than what I did when I started out. And that's a lot because I really think that it gives us so many opportunities to actually grow not only in our careers, but as people because in the previous, like I said in the previous slide, it's a learning journey and you get to learn not only from the technical side of things, but also from a holistic personal growth side of things as well. Yeah, and from my side, like I said, I had absolutely no idea what IT was. I sat down at my first day at my first job and they said, open the command line that I didn't know how to do it. Obviously I've come a little bit from there, but not very far, but kind of on my journey, how I got from each job to the next was actually following all the advice that we're doing. So when I was at my first job, I started attending local meetups and events that eventually landed me my second job. While I was there, I started to share what I'd learned through the open source ecosystem and had non-code contributions to the ecosystem. That helped lend me my job at CNCF where I made lots of friends, attended, cube counts all around the world, shared my learnings, and started doing my research. And it's ultimately how I ended up here at ISOvalent working in psyllium and EBPF communities. My whole journey has been an experiment in what I was interested in. And last but not the least, you know, like I said, we are, you know, still very much interacting with humans in open source. The bots haven't taken over yet. So, you know, why not make friends along the way? Why not, you know, join people along for the ride? Because otherwise it's just gonna be a long, long journey with nobody to accompany you. So I met a lot of, you know, my friends, current friends in the cloud native community. And it also definitely helps solve the problem of not having to, you know, not having adult friends when you're 30. So like I basically solved that problem as well. But having a community around you means you get to learn, you get to make friends, and you get to have a lot of fun at events like this. Yeah, and I think the best part about open source is once you leave a company, you still get to work with the same people. You don't have to leave your friends behind as you move from company to company. They keep going with you on your open source journey. So make sure you make friends along the way. I think there's like this code that commonly gets thrown around. It's a different company, same team. So I think that's the ethos of open source because a lot of, you know, the same folks run around in the same circles. And it's always a pleasure when one person succeeds because you get to share it as a community. But that being said, I think we are at the end of a presentation. And thank you so much for having the patience to sit through it, and we hope you enjoyed it. Yeah, thanks for coming. Oh, also if you have time for questions too, we're happy to answer any. Yeah? It's actually not a question, but maybe slide five. I think you could add, when there is a template for opening an issue or a PR, like, feel the template, just don't like forget to say half of whatever is required. Yeah, I think that goes along with doing your research. A lot of projects do have templates for issues in PRs. They're not just there by mistake. Yeah. Anything else? Yeah, we have a question back there. Two questions back there. Yeah. Hi. As someone who created an open source project and then sort of left because it was just too overwhelming, how would you recommend dealing with people who come with a great feature but accepting that feature just leads to more work for you in the future, because they leave and don't come back and maintain the feature? Yes, you're talking about like drive-by contributions where yes, you can accept something, but then it's up to you to maintain it. I would honestly just be clear with them upfront and be like, this is a great feature. Unfortunately, we don't have the support maintenance or we don't have the support required to keep maintaining this. We're happy if you have your own fork of this, where you do that, but unfortunately we can't maintain it upstream unless that person wants to maintain it. I think it's easier if you're just transparent from the beginning and maybe defining it in your roadmap what is and isn't part of the project. It's sometimes tough when people hear that their feature or what they really want isn't gonna be accepted, but I think it's probably better that than burning out the maintainers and it's easier to do that from the start of the process rather than trying to pull it out way later. Yeah, I kind of agree with that. Setting expectations right at the start with the help of a roadmap and with the help of proper scoping because that is sort of what helps set the expectations and set the baseline for how people can interact with us. But if there are situations where that arise and where such cases arise and people are coming and asking you for a feature or demanding rather, I don't think there is anything wrong with them asking for it, but you need to communicate to them and that's also a very good way for them to invite potential new contributions. So if they want to start maintaining an upstream fork of it or whatever, they are also welcome to do it or if they are okay with helping out with the maintaining or creation of the new feature or enhancement, they are welcome to do so, but they will have to expend the efforts that require any further work on it. They are welcome to build a community around it and that could possibly pave the way for newer contributors to chip in. So again, setting the expectations right and communicating it right at the start is important. So I completely agree. Great presentation overall, I love it. There are a lot of people that I imagine here that are trying to get into open source. So I love the tip about you don't have to be a developer or provide code contributions because I am not a developer. That being said, can you explain how you both are so awesome? I'm not, easy answer. I think the most important thing is it's a community and you create, build and maintain the community that you wanna be a part of. And so I think the key thing is if you want a great community, you have to be fun, you have to be helpful, you have to encourage other people to contribute and if you continue to do that, those are the people who will be attracted to you and if you instead create a bad environment, those are the people who will be attracted to you. So it's up to you what type of community you want to contribute to and you want to be a part of. Yes, so going against the laws of physics with just a bit like attracts like at this point. So you embody the values that you want to build in the community yourself and I think the rest follows. Like if you're transparent, if you're truthful, if you're honest about what you're doing, I think those are the kind of people that you attract and those are the kind, again, setting expectations right at the start, right? So, yeah. Okay. We're being axed, we're being thrown off the stage right now. Apparently we weren't that awesome. Thank you for coming. Thank you so much. We'll be here for questions if you want.