 Thanks, everyone, for coming, given the beautiful weather outside, and then it's Sunday, and the beautiful weather. Welcome to my presentation with the spicy name, all the things that didn't teach you at university. I hope you didn't come here expecting I'll teach you everything you didn't learn at university in 30 minutes. Otherwise, you're in for a letdown. So anyway, first the boring part, who am I? I'm Dan Cermak. I'm a software developer working at SUSE. I also work, do things in the Fedora community. And so for my interests, besides doing things on the computer, also working on development tools, I'm quite passionate about testing. And occasionally when I get to it, I write documentation and then break my home automation, because I like standing in the dark or implement funky stuff there. If you'd like to stalk me on social media, you can find a few links there. I might post some stuff there, for example, link to the slides, but there will be some later. So now that we are done with the boring part, I'd like to maybe share a bit of a history, because first I thought, yeah, well, so first the disclaimer, I didn't study computer science. So I studied physics. That means a lot of the stuff that I learned from my day job I had to teach myself. And I thought, well, I'd like to share a few things that I learned over the years. I mean, my Unix beard is not that long. So I most certainly don't know everything by far. But I learned a few things. I wanted to share them. And so I started to write my thoughts down. And what I learned over the years, and I realized this thing's going to start grow and grow and grow and grow. And it's not going to be a presentation. It's going to be like two lectures, maybe three, maybe a whole lecture series. So yeah, let's not do that. Because I'm going to tell you things like, yeah, you should test your stuff. You should have a proper staging setup. But no matter how good your staging setup is, you still occasionally will have to go into your production server and just comment out the faulty line and pray that you can get into your production server unless it's some kind of certified super secure hardware and you aren't allowed to touch it unless your manager is standing behind you and their manager and someone is signing that off with their blood. Also, ugly things like most real infrastructure is all together by duct tape, glue, hopes, and dreams, and a lot of magic. But also more positive things like if you want to do today something with computers and with code, you'll have to use version control and that means git. I mean, nothing else is really used in practice. If you want to do backend development, nowadays you're going to use Python, Node.js, Golang in the front end. It's still all JavaScript. WebAssembly is becoming a thing, but it's really not that you're in there and if you go into the enterprise world, it's going to be Kotlin, Java, Java, Java, more Java. If you're unlucky, it's also going to be XML and maybe a bit more Java. And you're going to touch SAP, whether you like it. But, well, some of this stuff will change. Some of this won't. So I would hope that the infrastructure stuff will change, but I'm afraid it won't because it's been like that for 30 years. But if you work in open source, one thing will really never, ever change, probably, and that's you have to work with people. And the interesting and challenging thing with open source and when it comes to people, so if you work in a company, you also have to work with people. But you have the same HR department. You're kind of there because you get paid to do your job. And if someone doesn't want to cooperate with you, you can escalate things. Or sometimes it helps, sometimes it doesn't. But there's structures for everything. But if you work in open source, you are there for your own motivation. And the other people, they have their very own motivations. And they can be completely different to yours. Maybe you do it for fun. They do it to put it on their resume. Maybe you're doing it because the software doesn't do a thing. And the other contributors do it for completely different reasons. Maybe they just like the community. Your employers are probably some completely different companies. Maybe a bunch of the contributors do it in a free time. And their HR department won't be bothered if you try to file a complaint because they do it in a free time. I don't care. Not our problem. Maybe they are on a different continent. And even if you do it in your day job, it doesn't concern them. People work from all over the world. And you have completely different cultures, which can be a great challenge when it comes to communication. And also, one thing that you really shouldn't underestimate is time zones. Most of us probably are sitting in Zoom, Teams, Jitsi, whatever calls all day. And you know the trouble of time zones. But this can be a huge problem for open source projects if you are suddenly all the contributors are sitting in North America, and you are in Europe or in Asia. And they decide stuff in a meeting. And for you, it's 3 AM, or it's 12. And you are at your job. And you just can't join a call for your free time project in the middle of your working day. And you have people in volunteering positions, maybe that get paid. Maybe you have outside contributors who get paid. You do this in your free time. And they tell you, hey, fix this bug for me. No, I'm not going to give you money. Sorry. Maybe you have students. And this all makes open source much more challenging than really close source development, where you just have corporate structures which may or may not provide you with some backing, maybe not. But so that's really the, I'd say, the most challenging part of open source. I mean, you can also just make your project open and not accept any contributions at all. Technically, that's most certainly open source to the letter. But in my opinion, it misses out the one big thing. And that's the community. So your open source project usually has some kind of community behind it. And for many projects, a community is really, it's just a bunch of people that work together on a common goal that they share. Usually, it's just keeping this project around. And for many open source projects, you just become part of it by showing up because there's no clear onboarding process. I know there's projects nowadays that have welcome channels and you can get, and they try to onboard you in very friendly ways, which is definitely a good thing. But I know the first open source projects that I joined, I just came there, started fixing bugs. And eventually, they told me far quicker than I was comfortable with, hey, yeah, why don't you get merge rights? You're sure about that. But yeah, so the point of the community is to have a common goal and really to empower others to work on this shared goal. And since we're dealing here with people, the big question is always, how do you communicate with people? So you've got your multiple options. You can have your asynchronous communication forms, where you have your mailing lists. We all love them, don't we? Forums, but then also more synchronous ones, like a simple chat, so maybe Slack, maybe Discord. Maybe you're still an IRC or a voice chat. But these really serve completely different purposes. So my recommendation is if you are building up your open source project, or you are participating in one, you should have one of each. Don't have five different places, because people will land in the wrong one. At least someone will. So really, just have one. Also, issue trackers, bug trackers, et cetera, PP. Nowadays, that's mostly GitHub. But there's also other things for that. Hopefully not JIRA. If it's JIRA for your open source project, I don't envy you, but you do you. And as I said, have really one place for everything. So have one chat. If you want to do voice chats and video chats, you can do that, but really take into account that people come from very different backgrounds. They come from very different time zones. If you want to do voice chats, you might run into people who are sitting in the rural area and the internet connection is really bad. And if they are going to join a video chat over Jitsi with 10 video streams, their internet connection is going to crash. So maybe don't do that for important decisions, especially synchronous communication always excludes people from the other side of the world. And that's still a big problem. So if you want to try to keep most of the discussion asynchronous so people can follow up when they want. And when it comes to communication, try to avoid ambiguities. So there's many people, unfortunately, including myself, who try to be funny. And if you say so, for those of you who are fortunate enough to enjoy an English education and maybe watch a few English shows, you'll know the phrase, yeah, right. If I pronounce it like that, it's an affirmation. If I say, yeah, right. I'm being sarcastic. If your English is maybe not so good because you didn't get the opportunity to learn it at school or because maybe you had to work instead of going to school, then I already lost you. If I try to put that in writing, well, all hope is lost. So don't do stuff like that. Try really to be as unambiguous as possible. It can be hard. And also, really, so try to keep your communication simple. And usually, what's always a good idea to just assume good intentions. Most people aren't actually bad. There's always, I mean, you get your rotten apple. But frequently, people don't have bad intentions. You can just, if you assume that maybe you misunderstood them, usually stuff gets resolved. So try to be kind to each other. That usually gets you very far. But how do you make really a community welcoming? And I'm going to suggest something that people might not like, but codes of conduct are actually not evil. It doesn't mean that you are going to enforce rules for everything and say, you have to communicate in exactly this form. And if you deviate, we're going to throw you out. A code of conduct really can mean be kind to each other, assume good intentions. But it also means if you decide on something like that, which you should, you have to enforce it. And you have to live by it. If you just slap a code of conduct in your repository and don't do a thing about it, it's not worth the, well, paper. But you get it. It's really not worth having it at all, because it's not going to do a thing. So if you want to put down some rules, how you want people to communicate in your community, how they should behave, or how you want them to behave, and live by that, and enforce them. And to have a nice community, you want to provide a place where they can meet, where they can talk. So that can be a chat room. You can also have video chats. But then again, time zones, unfortunately, make this complicated, and also what I would recommend for all things to document processes. Documentation is really king. Unfortunately, no one likes to write documentation, including myself. But sometimes I do, because documentation really helps. Especially when it comes to community processes, when it comes to code review processes. Because let's say you get a pull request for something and suddenly disagree. Especially bad if two maintainers suddenly disagree. Who gets to decide? If you have a rule written down, you can point to the rule. If it's just by some, well, usually we do it like that, people will start to argue. So if you can avoid somehow for people to argue over often very stupid things like code formatting, that's something that programmers often like to argue about. Just use a code formatter. It decides for you. If you can document rules, if you can enforce them preferably automatically, that's always a net win. But please don't try to solve social problems with technology. That doesn't work. Technology can help, but technology will not solve people problems. You have to solve people problems with people. As a maintainer, you should always, or as a community member, try to be present and try to be friendly to newcomers. If you tell a newcomer to RTFM, you're not going to see them again, unless they really, really, really, really want to use your project. But nowadays, there's so many projects, they're going to use something else. And help newcomers to do what they came to do. So as a maintainer, you might feel like someone comes in and they could solve a problem. Yeah, but I mean, I can do that in like a tenth of the time. Don't. If you'll help them, it will take you twice as long, but they might stick around. And in the long run, that will be a win. They might stick, they might not stick around, but you'll never know if you never try. So what I'd also like to cover is a little bit why do people actually contribute to open source. Because if you understand why people contribute specifically to your project, you can make them stick around longer. Or also, if you're self-looking for a contribution and maybe need some reason, you can find a few. So I mean, some people just contribute because they believe open source is the right thing and closed source is the highway. So let's take my way. Some do it just for altruism. People also just contribute for fun. That, I mean, yes, coding actually is fun if you don't spend all day in JIRA. Some just do it for kinship. So you like the community, and you want to contribute to the community and do it for them. Or just for your reputation, because I'm the one who solved all the nasty bugs. Reciprocity. So you feel the duty to just give back. Maybe you use this project for your day job all the time. So you feel like you should also give back to this project. It's also a great learning experience. So that's most certainly a good way. Or the good old scratch your own itch. So if you've found a cool project that doesn't do exactly the one thing you needed to do with open source most often, you can tweak it. You can use it as a career starter. I mean, I'm a software developer at SUSE, and I don't know exactly the reasons why I got hired, but I'm pretty certain open source contributions didn't hurt. And nowadays, many people, including myself, are fortunate enough to get paid for doing open source contributions. So that's also motivation. Now, please don't get scared. This terribly looking graph, which you can kind of see it. I stole that from a paper. That's also going to be linked in the presentation. So if you want to keep your community engaged, you have to know why they're contributing. And you also have to keep in mind that this can change over time. So this graph shows you on the initial motivation. So this has been a questionnaire for why people contribute to open source. And this is the initial state when people started contributing and how it evolved over time. So I think the questions were essentially, why did you start contributing and how is it now? And you can see a few things. So for instance, the scratch your own itch decreased by a lot. But many and also learning decreased a little bit. But people kind of stuck around for fun increased, reciprocity increased, alt-rhythm. And at least in my opinion, the takeaway from this is that many people stick around either because it's fun or because they like the community. So if you want people to stick around, make your project a fun place to be and a nice place to be. Keeping people around because they'll never be able to scratch their itch, I don't think that's going to work. But you can try. But I don't think that's a viable way. But again, every project is different. And finding out why people contribute well. You can try asking. Maybe they'll tell you. But I wish I had a magic recipe for that. But unfortunately, I don't. A nasty thing, unfortunately, is conflicts. So in your community, you will inadvertently have conflict unless you're only one person. But once you have more than one person, there's going to be a fight at some point. With fewer people, it might take longer. With more people, you will get them, unfortunately. And I would really suggest that you try to resolve conflicts given your rules that you've put down. Because otherwise, if you just let the conflicts kind of linger on and fizzle out, people will build up resentment and either they'll start to avoid them each other and you'll get silos in your community, which is always not fun. Because then they'll start doing their own things. And also, if you get conflicts more often with one person, then the famous phrase, one bad apple can spoil the barrel. Unfortunately, it's very frequently used nowadays to say, yeah, you shouldn't judge the whole thing by just one bad apple. But the one bad apple can really spoil everything. So if you have a bad actor in a community, you shouldn't be, you should eventually think about removing them, because they can poison the whole thing. So with that, I'd like to switch more into the path of a maintainer. So if you find yourself to become an open source maintainer, one of the most valuable skills is, I think, that you should learning to let go of things and to share responsibilities. If you can't do that, you're going to have a bad time. Because if you hoard all the issues for yourself, you can do that maybe for some time. But eventually, just a psychological burden of having all of this on your mind, and I have to take care of that, it's going to burn you out. So try to share your responsibilities, try to share your tasks, because actually what studies have found is that if you give people the rights to contribute to your project in a more meaningful way, like they are allowed to accept poor requests, they're allowed to merge them, their contribution quality will go up. So if you want to have a better project, share your responsibility with that. But unfortunately, as a maintainer, you also have to do the boring parts like take care of infrastructure, write documentation. You'll be doing that a lot. So documentation is unfortunately never enough. That's not an excuse to not do it. Because no documentation is even worse. Unfortunately, people will still not read documentation, but again, documentation is still king. So you'll also be covering the onboarding process and mentoring, issue triage, merge requests, maybe find cash, because infra doesn't pay for itself. If you have a forum, you maybe have to do more duration of the forum. You'll have to debug why your server suddenly stopped working, why your CI stopped working. And if you're very lucky, you also have to start looking into licensing, do all the fun managing stuff. But maybe more fun things like making your project more popular, because your open source project, unless you are the lucky person who found exactly the one thing that everyone needs, like I guess Docker or Curl or SQLite, which are literally everywhere and are something that people really need, getting this one lucky project, you will have to do very little marketing yourself. But if you're not that lucky person, you would have to do marketing. And as a computer scientist, maybe, or as a programmer, I think, talking in front of people. But otherwise, if no one knows about your project, no one's going to use it. So if you want to make your project popular, talk about it, write tutorials. And what also works, if you're trying to solve a certain problem, find projects in need and send patches, maybe they'll accept it. You might have to be persistent, but maybe they'll start using it. And over time, popularity will grow. And as I said, did I mention documentation? Write it. And making a project popular has also another advantage. So this is Mike McQuade's contributor funnel, slightly adapted of the sales funnel. But the idea is essentially, if you want to have more maintainers, the one most common path to becoming a maintainer, you start out as a user of some project, and eventually you get sucked into becoming a contributor, and then you get sucked further along the funnel and eventually maybe become a maintainer. But the ratio between maintainers and users can be, I don't have numbers, but I guess it's in a best case scenario, it's maybe going to be 1,000 to one, but I guess it's more like 10,000 to one or even worse. Really depends on the project. So if you want more maintainers and you have five users, you're not going to recruit more maintainers from that. So make your project more popular. How do you do that? So this is from a study from Mozilla that I think from 2007, so it's not super recent, but they reviewed how you get people on board of the project and what the influences of certain factors are. So essentially the x-axis shows you the impact of a certain property on onboarding and the y-axis, that's just certain factors. And what you can see is that what really has the biggest positive impact is the perceived future impact and the recent volunteering experience. So really if you want to get people on board, the vision matters. What actually doesn't matter is the past impact at all. So if you want to onboard people better, you have to give them a vision. And how much impact they had in the past isn't really that important. What matters to them is that they think they can impact it. I mean, if you just give them the impression that they have some impact and they won't, they'll eventually find out. But if your project has a vision and has a path to improve it, you will be able to get more people. So give them a vision. And also what this study found out, that if you have a great onboarding experience, it will motivate people to also onboard others. And another thing, if you want to keep contributors, especially for code contribution, quick responses are very, very important. So that's also from the same Mozilla study. They did a review of how long it takes someone to respond to a pull request. And they found out, OK. So if the maintain a response within 24 hours to a pull request, there's quite the likelihood that the contributor will stick around or that they will work further on this. If it takes you longer than a week, the chances are zero. But it doesn't necessarily mean that you take the time immediately to review the pull request. It can also just mean, hey, sorry, it's my weekend. I'll take care of it on Monday. Or I'm traveling. Sorry, my internet connection is super horrible next week. That's enough. But just answer them. And I know it sucks because it might have to check your work emails on the weekend, unfortunately. But really, if you want to keep especially newcomers around, you have to be quick about this. And a big thing for being a maintainer or also an open source contributor, really take care of yourself and don't burn yourself out over this. So stay true to your motivation and why you started contributing. And if it stops being fun, stop. I mean, even if you get paid for it and the project turns into a toxic dumpster fire, talk to your manager and tell them, this is horrible. Because you must stay your top priority as a maintainer, as a contributor. If it's just going to stress you out and the thought of opening your issue tracker gives you cold sweat, it's not going to work in the long run. You might be able to force yourself to do this for just a while, but it's not going to work in the long run. And another thing that I'd like to quickly cover is feedback. And as we all know, maybe feedback in open source can be challenging because people often come only when things don't work. But then again, all feedback is still a gift because you get feedback from people from vastly different backgrounds that might have read your documentation and misunderstood it because you thought you said A and they read B. So still take it, thank everyone for it, absorb it and reflect. And really in most cases, feedback is not an attack on you as a person. It's just something that people tell you there might be people who just aren't SDS holes and they like to tell you that you suck and your project sucks and more things that I don't want to have on the recording. But really don't defend yourself. Try to absorb it, adapt to it. And if it's appropriate, discuss it. But don't take it as a personal attack that you really have to defend yourselves from. But as I said, unfortunately, very, very frequently, but I think things are changing maybe a little bit. You mostly get negative feedback on none at all. So it's often very hard to get people to actually tell you what they want, what they are missing, or to test beta releases and similar things. People come to you when their stuff's broken, unfortunately. And that can be very frustrating, can be very crushing, because you don't see the 10,000 happy users. You see the 10 who are unhappy and come to you and dump in your issue tracker. But then again, you don't have to address everything that you receive, because there's also people, there's stuff that you can't react to. And really not getting bothered by this is something that you just have to train. So I once had the opportunity to talk to Daniel Stenberg, the curl maintainer, and asked him about this. How do you do this? And his answer was, unfortunately, a little bit, he just told me, yeah, well, I just don't get bothered by it. Which as someone who is not a great open source maintainer and struggles with things like that, I'm, OK, damn it. So but as many things in life, you can train them. And given that I only have two minutes left, I'm going to do my favorite thing. That's one, two, skip a few. Yeah, if you provide feedback, I think you never hurt anyone. So thanking someone when you write a bug report, it never hurts anyone. And people are far more happier. I hope this didn't discourage you. So if you didn't start your open source journey, you can start now, or please start now. But if you're building something, maybe wait until it's kind of ready. It doesn't have to be perfect, but marketing still tells you the first impression counts. So the first impression should be really good. And if you think this all sounds very, very terrible, it's actually not. It's still always a lot of fun. You can learn a lot, but only stay in project as long as it is fun. And yeah, well, I told you this. No, I didn't tell you everything that you didn't learn at university because we all still learn. But I hope I gave you a starting point, some food for thoughts. And if you need more, there's the great collection called Uncurled from Daniel Stanberg. This is the paper I mentioned for motivations for contributing. That's a link to the study from Mozilla and the open source contributor funnel by Mike McQuade. And there's my slides. If you want to find them, or you can just grab the QR code. If you have your phone at your hand, if you have any questions, I'd be more than happy to answer them. Yeah? So how did you start, like, what was your entry point? So I started, I'm not sure if I started first contributing to Fedora, or I started, so really code contributions, were to a C++ image parser, which had some where I just found out, okay, it got someone found out that if you run an ancient C++ code base and you use AFL to fuzz it to hell, you'll find about 100 bucks in an hour. And I started fixing them. And eventually did all the mistakes, like hoarding bugs and trying to fix every problem myself and eventually burned out. So that was a great example how to not do things, but that was my start. I was already, I mean, at that point, I thought I was fairly experienced, but it was, I already had my master's degree, so I think for like a month or so. But then again, I studied astrophysics, so I learned coding on the side to write simulations. Okay, then, thank you for your attention, and enjoy the nice weather outside. Thanks for having me. Thank you.