Command Line Heroes - Ready to Commit: Contributing to Open Source

Episode Date: October 9, 2018

Looking to get into open source but not sure where to start? Are you a contributor trying to understand why only some pull requests get accepted? Or are you a maintainer who’s feeling overwhelmed? This episode looks at what it means to commit to an open source project. We follow our heroes as they progress through the roles of open source contributors: from finding projects and contributing to them, to building and maintaining thriving communities. Shannon Crabill shares how she got her start in open source at Hacktoberfest 2017, and Corinne Warnshuis describes how important it is to include people from all backgrounds to create good software. There are many ways to contribute to open source. Let’s walk through this together. For more about the characters, history, and stories of this episode, visit redhat.com/commandlineheroes. While there, check out how you can contribute to hero-engine and Command Line Heroes: The Game — all levels welcome.

When I started out doing software development, I was mostly just making little projects that amused me, little apps, little command line tools and stuff like that. I just really didn't know that it was so easy to contribute and that you don't need to have solved P equals MP. Your input can still be valuable. Local communities made me confident enough to contribute. When I was a total newbie to programming, I teamed up with my friend Dan to make my very first open source pull request, which would also make it my contributing to open source, about how amazing it was, but also how completely terrifying. I was very aware not all communities are kind and not all maintainers are nice. The project itself was a pretty good one for a first timer. We were just adding a JavaScript library, something to let people get a digital walkthrough of the website. Just a nice, well-scoped project, self-contained. And, bonus, if the thing didn't work, I was almost positive it wouldn't burn down the whole site.

And yet, I was crazy nervous about this pull request. Dan and I read the docs for the library, plugged away at our code. And I still remember when we were finally done, we just looked at each other like, that's it? We made our PR, it was reviewed, got merged. And I guess I was surprised by how, I don't know, mechanical it all was. It wasn't some big mystery or magical thing that only they could do. I realized I really could contribute too. And that's a bit of knowledge we're passing on in this episode. Making a contribution to open source isn't magic.

Doesn't have to be terrifying. We're going to walk through this together. It was just such a groundbreaking realization about like, oh, this is actually totally open. Like I can just do this. In that opener, you heard from command line heroes, just like you, who pushed through that same terror to join the ranks of open source. They were Nolan Lawson, Lindsay Tulloch, and Kaniku Muraka, all heroes. You're listening to Command Line Heroes, an original podcast from Red Hat. I'm your host, Saran Yitbarek. This is a story about two command line heroes just trying to make something better in the big open source world. One of them's a contributor.

The other's a maintainer. Neither of them are real people. Instead, these two fictional characters represent all the contributors and all the maintainers that shared their stories with us. Hopefully, you'll see some of yourself in their journey too. First, meet our friend, the contributor. She's a bit of a newbie, just like we all were once upon a time. She's not sure about what the basic workflow is, but she sees a need, and she thinks she could add a feature that would help. Our imaginary contributor is keen to make that fix, but how?

You're always growing new skills and you don't have to have taken apart a computer as a child to know how to code as an adult. That's Corinne Warnseis, the executive director of an awesome organization called Girl Develop It. It's designed to help women who maybe don't feel super comfortable asking questions or might not feel entirely welcome at meetups. Girl Development realized that making contributions isn't the same for everybody. Culture matters. And part of our job as a community is to build a little empathy and healthy diversity into the process. So there are many kind of barriers to entry as we see them, but we like to call them no good reasons. So there are kind of three no good reasons

that keep women specifically out of technology. And they are stereotypes, the accessibility, and the environment. And it's worth remembering here, promoting diversity doesn't just make good ethical sense, it makes good business sense too. Technology as an industry has probably the greatest potential to make the most change in the world today. And so you really want to have people from all backgrounds, from all perspectives, contributing to the tools and services and things that are going to shape the world. And so I think it's really important that people from all backgrounds are creating software and contributing to open source projects.

The fact is, we didn't all start with the same advantages or experiences. And the next great coder might not look like a Silicon Valley cliche. In-person instruction has been historically incredibly expensive and inaccessible for people. But again, I think, you know, from 2014 to today, that has improved. I think groups other than Girl Development, like Outreachy, like Code Newbie,

are doing that by providing kind of a safety net or a space to ask questions and get more comfortable. And so having kind of a safe, welcoming testing ground for some of those ideas and some of those questions is a good place to start. Speaking of newbies, back to that contributor we were tracking. When you're not from a mainstream background, that first commit can carry a lot of weight. It can feel like you have to prove yourself. So, once we get those barriers to entry low enough, what do we actually need to think about as we prepare to contribute?

It's cool to get excited about certain projects, but what is the use case that you're trying to solve? Vincent Batts works at Red Hat, mostly on container architecture, and he encourages new contributors to try and be intentional about the work. Find that niche where you and the project make sense together. I think a project to contribute

to usually comes out of kind of a reciprocal relationship. It satisfied a need for you, and along the way you found a way to satisfy a need for it, and it becomes a relationship, even if it is a community of people. For example, I ended up standing up a Slackware Linux box out of a recommendation by a friend. It was suitable enough for me to do what I was trying to do that I ended up helping them get it packaged for the mainstream Slackware Linux community and ended up becoming a maintainer and contributor on that project. Not because I sought out to be a contributor to that Slackware Linux community, but it most well suited the other project,

the use case that I was actually trying to solve. And I think that happens a lot for a lot of folks. They seek to write a database because of their tailored use case and they find that it works well in Golang and they wrote such a high-performance database that they were able to contribute back fixes or improvements to Golang that helped their database run faster. So you can find your little niche and let a certain amount of organic growth take place.

But the key point is, start somewhere. You don't have to wait for a degree or for absolute confidence. If you need direct experience writing code or writing docs or even being a system administrator for a back-end database web server, most of these communities are volunteer-based. And so you go out to some project like Debian, Fedora, or whatever, and those communities have docs pages that are set up. Those have to run on a web server somewhere. And somebody, even a community member that's not being paid to check if the web server's down or something went wrong, is gaining experience. Vincent stresses that point about the egalitarian nature of open source. Wherever you're coming from, you really can start contributing if you want to.

You can make a name for yourself if that's what you want to do. Once it's merged, then your name is like attached to something. You're publicly representable that you have made, you know, an improvement somewhere. Um, which is, which is incredibly meaningful. I've worked with folks that were like television repairmen and teachers, not in a technical day-to-day job that were very well represented. You know, like they contributed a lot in the community, but, and then on the flip side of that, I've worked with developers that sometimes had had 30 years of development experience,

but they had never publicly contributed code like that. How's our contributor doing, by the way? Well, she found her niche. She conquered her fears. And she's finally made her first pull request. Now she can sit back and be terrified while she waits for the maintainer to respond. Contributing that upstream is kind of like going on stage for the talent show for the first time. You get nervous and you go out there and your palms get sweaty and you do a thing.

And then it's like an achievement. You are profoundly changed. You never will be the same. Profoundly changed? Maybe. There are, in fact, four possible responses from a maintainer. Silence. That's a fun one. Or possibly outright rejection.

Or outright acceptance. Or the squishy middle ground, a request for change. Couple days after her PR, our imaginary contributor finally gets a ping back from the maintainer. And lo and behold, it's a request for change. Being new, she takes that as a miniature disaster. She doesn't know yet how a request for change is really an accomplishment. She even gets a flash of anger at the clipped tone the maintainer is using. Sort of sounds like he doesn't have time for her. There's a wall up, and that new contributor's got no idea what's happening on the other side.

Meet a maintainer. The project he's maintaining isn't his full-time job. It's a weekend project, and he stays up till the wee hours, lots of nights, prioritizing issues and reminding folks to update docs when they make pull requests, and you get the idea. He's got a full plate. Sometimes, he even experiences a little maintenance burnout. A real-life maintainer, Nolan Lawson, wrote a pretty amazing post that got a lot of traction recently about burnout.

I think part of that blog post was kind of a cry for help, honestly. It was me kind of expressing that I had stumbled into this open source thing. It was really fun at first, and now it wasn't so fun, and I wasn't sure what I should do to kind of recover. Nolan's got a day job. But, like most maintainers, he was putting in tons of after-hours work on his open-source project. Because the guy honestly cares. And ironically, part of his pain was coming from the fact that he knows the contributors honestly care too. What really burned me out more than anything was actually just the flood of well-meaning folks. And like, you want to help them. You really,

really do. All they're doing is asking a question. All they're doing is they've actually, you know, found a legitimate bug in your project that's blocking them, you know, or all they're doing is they, you know, they actually like bothered to download the code and figure out how it builds and to contribute a bug fix. And they just want you to review their code that they've contributed, right? Maintainers like Nolan are constantly reviewing a library of PRs, figuring out how commits will play into things. They're pushing contributors to do the best work possible, to conform to the house constraints, to contribute in ways that are most meaningful to the larger goals of the project. Here's my point. Chances are, those maintainers are not the jerks a new contributor might worry about. They're working their butts off, trying to get to everything.

And they even take the time, lots of maintainers do, to label some things as reserved for first-timers only, so newbies have a chance to take a swing. At the end of the day, though, the scope of all the PRs and commits gets overwhelming. So how do we make sure that doesn't happen? How do we create environments for maintainers that make sense? One solution is an open-source project with a strong community, like Fedora.

The Fedora project leader, Matthew Miller, explains what attracts maintainers and contributors to the project. A lot of Fedora is not development. It's all the things that go around development. And that's actually true with IT in general, CS in general, and open-source maybe doesn't have enough of it. That's sort of the support roles around open source. But what does that support actually look like?

One of the paid roles we have, for example, is the Fedora program manager who helps keep the schedule on track and bugs people about making sure the paperwork is done. And so having somebody paid to do it actually helps keep the bureaucracy down because they can put the time in to make it a human thing rather than something that is just a bunch of paper shuffling. So I think having corporate involvement like that gives stability to some of the roles that you can't guarantee with volunteers. It sort of reminds me of those workspaces freelancers use.

There's a shared reception area, shared Wi-Fi, and shared coffee. The manager's handling it, and you're free to do your own thing. Matthew told us about another Fedora fix. They save you from feeling like everything will collapse if you take a break from your project. One of the things we've looked at is making natural endings to leadership roles where you say you sign up for something. It's not necessarily a lifetime commitment. You can re-sign up. You're not kicked out after a year. But if after six months you want to move on, you can gracefully go on without feeling like you're letting people down.

So we've tried to work on making sure people have a clear exit. Matthew figures that finding ways to support that open source community without being heavy handed is the key. It's almost like a family rather than something like a workplace or something like that. It's meaningful to contribute to because you're working on this not just for yourself or not just for some paycheck or an end product, but because the people you're working on it with are your friends, and it's something that you're working on together to make something that's bigger than this individual effort. Whether it's thanks to Fedora or something else, a world where open source contributions are sustainable? Now that's a world worth fighting for.

Meanwhile, back at her desk, that new contributor we were following just finished the changes the maintainer asked for. She doesn't realize it yet, but she is about to have her first pull request accepted. It's easy to lose sight of those early steps when we talk about long-term issues like burnout. But every day, there are new contributors all over the world joining the party. And that's really why we need to build a sustainable, humane place where all this open-source magic can happen.

So, in the end, our contributor and our maintainer work together to nudge things forward. But there's one last piece of the story. Remember that all that back-and-forthing depends on development platforms like GitHub and GitLab, places where we can all come together. I wanted to dive deep into how those communities make our work possible. I got chatting with Shannon Crable about it. Shannon's an email developer by day, but by night, she's learning front-end development. She's also someone who knows firsthand about the value of community. Last year, she participated in a month-long celebration of open source called Hacktoberfest,

an initiative to get more people to contribute to open source. At the time, Shannon was very much an open source newbie. Thinking back to that point in October, it was, I feel like I wasn't finding much to work on. And there's probably other beginners or maybe even more beginners that were also not finding things to work on. So maybe if I put something out there that's relatively easy, they'll have some place to sort of try and learn and kind of, you know, get used to Git and GitHub. I think the hardest part is just like getting used to like the motions of just how it works and practicing and, you know, how do I push a repo? How do I share a project? How do I do pull requests and that sort of thing? And I got people to contribute, which was, you know, surprising, but also like really awesome. Was that scary at all? Because I feel like, you know, if you're new, you're putting yourself out

there just by even having the repo period and then now you have people actually contributing and you have to talk to them and you know like review their code and have opinions like that that sounds like that could be a little intimidating yeah it was i think the initial reaction for like oh my god this is so cool like, holy crap, what have I gotten myself into is I realized that I had, I think I had merged my own code into my own codes. I, you know, merged my own pull requests and pushed to the site and everything that, but I had not done anyone else's. I think I had not done, I guess I hadn't done a pull request, like merging it before then. So I had to figure that out. Merge conflicts in general or something that I still struggle with a little bit. But yeah, it was like, is kind of a whirlwind of feelings. Like this is cool. I don't know how to go about this. Everyone was really friendly and I just tried to stay very friendly and honest, even if it was just like, Hey, I'm overwhelmed and you know, I'm not, I see everyone's pull requests. I won't get to them tonight, but I'll get to them tomorrow. That seemed, people seem to respond well to that.

Yeah. Yeah. So one thing that I've always wondered when you are maintaining a project, especially as a newer developer is, does it mean that you have to be the smartest person on the repo? You know, because you're essentially grading, right? Like you're, you're judging, you're reviewing other people's code. Have you had a situation where you didn't know as much as the person making a pull request? And how did you deal with that? Oh, that's a really good one. I could see thinking that, oh, I need to be the smartest, best developer ever would maybe be a hindrance. Like, I think I was lucky that I didn't think that when I went into this, I was able to go into it kind of like, let's just go for it, see what

happens. Yeah, you don't need to be like, you know, senior developer, 20 years experience, you think you just need to have an idea and just know how to use the software and just be willing to learn if you don't know. There were definitely one or two pull requests that added some really cool features to my project that to be honest, if it broke, I don't really know how to fix it. I can look at the code and be like, yeah, it's broken. But to be able to build that from scratch, I wouldn't know how.

But I think that's the cool thing about it. If it was just me contributing, I might have done some neat stuff, but not as cool as what other people are bringing their experiences to the table with today. Yeah. So as a maintainer, what are some lessons that you learned along the way to make the project more accessible, more friendly, easier to contribute to? Sure. The one thing that I think was really helpful, and I wish I had done this like initially, is to set up templates wherever

possible and like documentation documentation documentation um I definitely added a lot to my readme file as I went and I think like I mean just having a readme file to start is a really big right um just even links to like hey check out our you know guidelines for contributing check out our um I think I made a pull request template. I made issue templates, you know, click here to see current issues just so people aren't like submitting the same things multiple times. So making it as easy as possible or as user-friendly as possible, I think is a big step you can do as a maintainer. Absolutely. And readme is, you know, I feel like I see them all the time. I hear about how important they are. But I feel like it's also,

there's so much you can do in a readme, right? At the end of the day, it's kind of a blank document that tells people to read it. What do you do in that document? How do you structure it to make it really connect with people who are looking to contribute? So I think in my readme, I had a lot of GIFs in there. Nice. But yeah, I had GIFs. I think it had links. What I was starting to hear was that Shannon had quickly learned how important the relationships are. She knew straight away that the work was going to shine if people were

invested and even having a good time. Great. And there's people doing great things with open source projects, but I also think it can be like fun and just like a fun product to say like, hey, I made these cool bats that randomly generate on this page, you know, every time you click. And I also love that there's so many different types of things that people can do. So if you're really into, you know, the artistic cool stuff, you can do the bat generation feature. But if you kind of want to clean up, you can do that too. You know, if you're like, I'm going to stick to the documentation, I'm going to spend my time to make this room, this place a little bit cleaner for all my other contributors, then there's the option to do that too. Yeah. I tried to keep it, I tried to make it clear that, you know, whatever you want to contribute is fine with me. Like if you catch a spelling error and you want to fix that, great. If you notice a link is broken and you want to fix that, great. If you just want to

help comment this code so it's easier to read and understand, that'd be really helpful. And I think it's also just really awesome that you had such a positive experience with the community because I've heard lots of stories where that really wasn't the case, you know, and people weren't very nice online and weren't very welcoming and kind, especially to newbies who, you know, we tend to ask maybe some more simpler questions than are expected. What do you think helped make your community a nicer place compared to what some other communities are like? Just the fact that it was a very casual thing. Like if you want to contribute, you can. Cool. If you don't, that's also cool. I definitely had the thought

that open source was like kind of this big, scary thing. You know, you need to have all this experience and all these complicated languages are back in and front in and everything in between to be able to contribute to. Yeah, absolutely. So how has doing Hacktoberfest and how has that changed your idea of open source now? It's definitely changed it for the better. Like I said, I had a great experience and I hope everyone that was involved with my project in somewhere or another had a good experience too. It's definitely given me the sort of the push to want to try things like that more often, even if they don't go anywhere. It seems more attainable now.

Music to my ears. Here's something. Thousands of people from hundreds of companies and some from from no company at all, contribute to the Linux kernel. That means Linux, which basically runs the internet, is maintained by a whole army of everyday heroes. If you're feeling eager to make your first contribution to open source, maybe you want to learn more about the Fedora community. We've got a ton of materials waiting to help you out. Check out redhat.com slash command line heroes for more. Quick reminder, this season we're building our very own open source command line heroes game.

And you are invited to contribute in whatever way makes sense for you. Get the deets on how to be part of it. We would love for you to build this game with us over at redhat.com slash command line heroes. Next episode, we're all about the ruthless Darwinian process of errors and the beauty of failure in open source development, how it haunts us, guides us, and makes us better. Command Line Heroes is an original podcast from Red Hat. Listen for free on Apple Podcasts, Google Podcasts, or wherever you do your thing.

I'm Saran Yitbarek. Until next time, keep on coding. Hi, I'm Jeff Ligon. I'm the Director of Engineering for Edge and Automotive at Red Hat. The number one hesitation that I think folks have about Edge is that they assume they're not ready for it. They think that it'll mean starting over from scratch, or that every time their business needs to change, there'll be re-engineering solutions and re-evaluating vendors. And look, Edge is complex, and it does mean a different approach, particularly for devices at the far edge. But with Red Hat, it doesn't mean starting over with new platforms. We've taken the same enterprise solutions that simplify and accelerate work across the hybrid cloud and optimize them for use at the edge.

So you can manage your edge environments just like you do the others. Come find out how at redhat.com slash edge.