 Hello. Oh, there we go. Hey, everybody. My name is JJ Asgar. I'm a developer advocate for a small startup you may have never heard of called IBM. That was supposed to be a joke. Nothing? OK. Hey, there we go. I really do have the email address of awesome at ibm.com. So if you are ever looking for someone on the IBM side, seriously, email awesome at ibm.com. My job is to be helpful for you. So I'm here to talk about the lessons learned in cultivating open source communities and the experiences I've had. Now, a lot of these stories are from things that I've actually gone through. So these are my opinions, et cetera, et cetera. We're all trying to make the community better, so hopefully this will work. By the way, I'm a Texan, so I do say y'all. And I do occasionally curse, and I don't realize it, so I apologize ahead of time. So first of all first, this is not a tools talk. We know there's a ton of tools out there to make everyone's life easier, but this is actually the squishy stuff that we've got to talk about being part of the community. I might mention some here and there, but this is what you have to do as to make sure your communities are successful or are great, and the stuff that I've learned from it. The very first thing I learned about an open source project is how to scope it. Believe it or not, you'd be amazed on how many open source projects just don't have a reasonable scope. We all have been involved in the community for quite a while here that we might remember the thing called the Big Tent. Yeah, I have opinions. The irony of the first project I ever used was a small Linux distribution called crux. I was the frequently asked IRC help guy, and the irony of that project, even though it was an operating system, a Linux distribution, the actual scope was really well defined. There was a clear mission statement and how to be able to actually say, this is what we're exactly doing. There's no scope creep is the term. Believe it or not, to this day, I still have friends in that community, and this was back in 2003? Yeah, before I met my wife. That's crazy. So it's amazing how these things kind of work, but you need to absolutely scope your project. So there are two buckets that I like to call, first is a personally backed project. From what I learned, that's the majority of projects out there. It's that thing that you are working on because it scratches that itch, right? The largest, it's your baby. It's the one that you have put your lifeblood into. You have to be the leader and the project, and the project, it becomes part of you. Believe it or not, it's really hard for you to let those things go. There's a handful of people you haven't learned to trust to work with, but then it's just you. Personally backed projects are also... I worked at Chef Software for a while. There was some people there that took it really personally during that time between Chef, Puppet, and Ansible. You are the end-all be-all, and it can be very, very stressful. On the other side, there's corporate backed projects. We all know those projects out there that have a corporation behind it. It's open source, but the corporation actually deems everything, the mandate behind it. Hell, I think quite a few of them are in this room right now. The challenge, though, is when a corporation backs your project, they ultimately run your decisions. It's no longer a human or a group of humans doing it. It's now a corporation and possibly stakeholders and investors, so that actually causes problems on the downstream side, because if you need this feature involved, or this feature of that project, and it turns out some person four people away from you say no, you might never get that. So it's important to recognize these things. And I, you know, frankly speaking, I know it wasn't an open source project, but I still miss Google Reader, do you? Yes, I saw someone shake their head. Okay, the next thing is the empathy for your audience. Believe it or not, but as an open source maintainer or an open source leader, you're a performer and a seller. As much as you want to just be writing code, if you are a leader for an open source project, you are actually a sales guy, as much as you hate to say it. You have to be constantly recruiting an always-on brand for your project. This also doesn't happen overnight. This takes months or sometimes years of dead silence, and then all of a sudden, a bunch of people are interested in your project. The scary thing is, is all these volunteers that are there to help you can disappear in a moment. Sorry about my pump. Have you ever been, raise your hand if you've ever started a meetup before? Got one or two? Okay, cool. That first meetup you started, did you have a bunch of people show up all of a sudden and they were really interested? Yeah, more than yourself, right, exactly. Well, that second time you did that meetup, was that same amount of people there? No, no. And then that third time, the question is, if you're running a meetup by yourself and nobody shows, is it a meetup? I don't know. That's the joke, but it's also true, right? The same as with the open source project. When you start something, people show up, but then people trickle away. And you need to recognize that that happens with open source. And I don't have all my notes, this is unfortunate. Oops, okay. I'm not gonna read this, but this is important to recognize that I came up with a thought once, which was in Texas, right? We can't just put together a trash pickup. We have to get, if we have a park or something like that and you wanna go clean a bunch of trash with a bunch of people, turns out you need to get permits and you need to set up water stations and because Texas is hot, it's like 115 right now. That's insane. And you need to have logistics. You need to recognize those people that come along to your open source project are like the volunteers for that stuff. But you need to also recognize that they don't care about the logistics you have to deal with to keep your project going. They are there to help you clean up your trash, right? I mean, that's what your code project, honestly, if it's not Hello World, your code is probably trash. I'm kidding, no, I'm not. Anyway, but in all seriousness, you need to recognize that people don't care about logistics, they don't. So when you're spending all this time doing this work, they're gonna be helping you clean up trash. I actually have a really nice blog post about this and if you're interested about it, find me afterwards or email awesome.ibm.com and I can send it to you. Okay, so we've talked about some logistics, we've talked about this. Believe it or not, for you to have an open source project to be successful, you need to celebrate. Version one has been released. Huzzah, right? Like you need to actually celebrate these things. You need to yell it from the top of the mountains. You released a new version, not even one, 01, celebrate these things. You promoted a user of your space to a maintainer. You found out that you were not just using an open source project, it turns out your dependency just made a major release. Talk about these things, make people excited. Everything should be vocalized. Newsletters, anything like that. Again, all of a sudden you start recognizing there's a lot more here than just writing code. Nothing is too small to celebrate and take any wins you have. On the flip side, you gotta admit your defeats. With all celebrations, there are problems. And as long as you are transparent about the things that happened, you will be successful. Do not hide the things that you fucked up on, right? Like you had a problem with a dependency or some CVE has happened. Admit that, tell your community. Things break and go off the rails. Okay, I'm getting close to time, so let's talk about some successful traits. This feels obvious when you say it out loud, but it's true. You need to trust your users and your community. You have to default to trust in the open source way. Out of some of the companies I've worked with, believe it or not, they don't do this. They don't trust their user base, which is bonkers. I mean, it's open source. That's the reason why we're in this space. You'd be amazed on how many people just throw code out there and don't trust anyone to change it. Also, you'd be amazed on how many people just think they can throw code out onto GitHub and assume the nerds will come and just write their software for you, right? By releasing your code to the world, you trust it in many hands. What's that old adage, many hands make light work? Well, you've also got to recruit those hands to help you. Accessibility is another very important, successful trait. I'm not talking about accessing the project, but I'm talking about how to access the community and things around it. One of the largest problems I had with OpenStack Chef, which I was a PTL for for a while, was there was this nice little firewall in China that didn't allow communication other than IRC. I had a bunch of IBM developers there that couldn't actually work on our project and communicate with us because we were going through, I think, Google Meet at the time or something like that, so we actually moved to IRC so we could get more people involved. But it's important to recognize that you might be losing part of your community because you're not using accessible technologies. Nowadays, people have kind of defaulted to Slack, which I get, it's fine, whatever, but recognize those things. Also, having your meetings at the exact same time every single week is actually really, really valuable. It's back to that meetup joke earlier. If you show up every Tuesday at 3 p.m. central time, because I live in Texas, but you know that people can find you right then and there, you'll be amazed on eventually how many people show up. Back to the scoping of the project, you need a clear vision. Have a plan to move on because you will need it. You are not gonna be playing with this baby or this project for the rest of your life. You're going to hand it off to someone else or you're gonna mothball it or put it on the shelf or archive it, right? Eventually, you will get bored. So with a clear vision gives you a clear path to what you believe will be success. Being an engineer and a developer, you're a constant learner. Eventually, your project will not scratch that itch. So if it takes off, which I really hope it does, you will need to hand it off to someone else to be able to keep it going. Otherwise, you'll just get people angry. So hopefully, we've learned a handful of ideas of things I've learned from this. This talk is usually much longer, but that's fine. Oh, one final question, is it worth the hassle? With who I'm speaking to and who's actually here, probably. You probably had some level of debate in your head about this. And you know, day in and day out, it depends, right? Like every software engineer tells you, it depends. There's a loneliness aspect to being a leader. There's problems you don't actually recognize until you've gone through the motions. And it's important to see if you're willing to invest that time and effort. Being a leader in open source and the lessons learned that you've come from, or at least I've had from it, it's not just writing code. There's actually a lot of human squishy stuff involved. Thank you. And by the way, if you want to scan that QR code, I have a little survey that only goes to me just about my style and how I talk and whatever. It'd be lovely to get some feedback for people. And again, never hesitate, awesome, at ibm.com. Thank you again. Yeah, they really, oh, there we go. Any questions, thoughts? I'm a Pisces. I'll be your Plex friend if you want to know what that is. No, okay. I did have a lot of good dad jokes originally, but somebody didn't let me put them on. I'm blaming the tech people and I'm kidding, kidding. All right, well, thanks y'all.