 So, I'm Yvonne. This is me in various places. So I'm a release engineer at Chef, and we are hiring, so I just have to put that pitch in there. For those of you who don't know, a release engineer is somebody who works mostly on internal tooling and packaging and publishing of packages out to the world. So that's kind of what we do. Tool Smith, there are other names for it. For the purposes of this talk, which is about getting started in open source, I'm currently a contributor or maintainer for a bunch of stuff in the Chef ecosystem, I'm a best bento, Artifactory Jenkins, stuff like that. I'm also a contributor and maintainer for a project called Git for Knitters, which is just this little side thing that started between me and Emma Jane Westby, who is writing a book on Git for Teams. When we had this long Twitter conversation about how Git is really a lot like knitting, and so it's like, this is great. We should put this someplace more permanent, so that's what that is. Contribute if you're a knitter and you use Git. So why this talk? So I was trying to write, when I was writing this talk, I was trying to think about what audience do I have in mind, and I'm thinking that it's like, so the audience in my head is people who are interested in contributing to open source, like they thought about it, they see a benefit to doing this at this point in their careers, but they don't necessarily know anybody who does it, or who can give them sort of direct guidance. So this is kind of what I'm going to talk about, because a lot of what I'm going to say is stuff that if you know somebody who does it, they'll probably tell you a lot of the same things. But so why? So people see the value in contributing to open source, I mean like you read something about it in the news, you hear about it at work, you hear about it in developer boot camps, all sorts of places, but you also hear all of these things about the open source community and what it's like. And that can make it hard to get started, especially for people who feel outside the perceived norm of open source culture. If I think about what an open source developer looks like, I don't necessarily think of someone who looks like me. And though I am an open source developer. And the other thing is that, well, open source culture is not especially organized. I mean, it's not a monolith, and so it's not transparent, and things are hard to be transparent when you're not organized. And when you're, so it's hard for people to explain the rules, or necessarily even to tell what the rules are. And there are rules, I mean, or conventions. So a couple of things. Before getting started in open source, things that I tend to suggest to people are, think about identity and channels, like how do you want people, what are the mechanisms you want people to use when interacting with you around open source? Another one, and I'll talk about this in more detail, is consider whether a personal project is going to serve your needs better than contributing to somebody else's project. And then there's sort of the myth of open source community. Sorry, I'm used to giving very interactive talks. So I tend to take, it's a little bit weird to be like, well, you're all staring at me. OK, so which is why I keep stopping and looking around, because that's sort of my any questions queue. But OK, so online identity and channels. So open source is kind of, so when you sign up to work on open source, you don't necessarily think of it, but you're actually signing yourself up for kind of being a very minor celebrity. And that they're going to be a lot of people in the community who know who you are, like not who you are, but like they're going to have opinions about your work that they're probably going to conflate with opinions about you. And they're going to want to tell you stuff. And you need to be able to manage your attention around this. So like I have co-workers who get email to email addresses that they check once every three months for open source work that they did five years ago for some other job. Like I have co-workers who get spammed on Twitter when people don't like something that they said on a pull request or who have an issue and they feel like they're not getting enough attention or whatever. And so it's really nice to be able to say, you know what, I'm really busy at work this week. I'm just not going to look at that email account. I'm not going to look at that Twitter account. I'm not going to do these things because I do not have the spoons to spend on that stuff right this minute. And I don't really, so I obsess a lot about online identity and things like context switching and context collapse. I'm not suggesting that you should, but I think it's totally worth reading Violet Blues, the Smart Girls Guide to Privacy, which was recommended to me by Jessica DeVita. And just spend five minutes thinking about how do you want to be around this? How do you want to manage your attention? How do you want to manage your inputs, all of that stuff like that? So personal projects. One of the things that people say to me about why they want to get involved in open source is that maybe they're changing careers or starting a career, and they want to build up a profile of code that they can show to people doing interviews or for networking purposes or future employers. Open source isn't necessarily the best venue for that unless you have a lot of code in a project. And the reason why is that it's a very collaborative process, and so it's hard to talk to any piece of code in there as being specifically yours unless it's a pretty big piece of code. So if your goal is I want something that I can talk to in interviews, like totally consider doing a small personal project and pushing the code up to GitHub and standing up aside on Heroku or whatever just to show it off. So it's a great way to showcase your own code skills, your own designs. Like as a person who interviews people, I like seeing stuff that people have done end to end for whatever that means. Like it might not be a website. But it's a thing that where you can talk to and you can talk about your design decisions and things that you wanted to do differently or that you would do differently now, whatever, knowing what you know now. Like a thing I want to mention because I am an ops engineer and I know a lot of ops engineers and they're people who don't necessarily get a chance to open source a lot of the code that they write or have a lot of time to open source, to write something specially. But you know what, even small projects will work for this. Like I have had perfectly good conversations with people about a particularly nice .bash profile, a way to organize their personal stuff. And it's a hugely useful thing that they can talk to, they feel good about it, they feel ready to show it off. And I can ask them questions. So that's kind of my advice. The myth of open source community. So tech culture is incredibly weird about mixing social and versus professional kinds of behaviors. Some of this I think is due to the geek social fallacies. If you haven't ever taken a look at them, I highly recommend this. But the thing that I just, so there are all sorts of weird things about if you work with somebody, you want them to be your friends. And if you, and so this extends to open source, where it's like, these people are my community, they're supposed to be my friends, they're supposed to support me in certain ways. Why is this happening? Is it something that I did? And what I would say to that is that collaboration's not the same thing as community. That, I mean, I think both are important, but I don't think you have to get both of them in exactly the same places. So I was talking to a friend of mine about this, and he, about community. And he made the point that, in his professional life, that he feels like he's found a lot of opportunities for collaboration, some friendships. But not so much community, because he thinks of community as consisting of reciprocal care. You all take care of each other. Shared memory that it's like, you can all say, oh, right. Yes, we talked about this before. And nobody has to feel bad about it. It's just a reminder. And sort of a lasting kind of social organization. I think a lot of people do go into open source, and they find these things, and they're like, these are my people. I was not one of those people. I don't think there's anything wrong with not being one of those people, and you shouldn't worry about it. I mean, if you want it, you want it, but don't necessarily expect to find it within the confines of open source. So the other thing that people like to ask me a lot is, so I want to do open source. How do I pick a project? Like, how do I know whether a project is worth contributing to? And it makes sense, because it's an investment in time. I mean, it's an investment in some part of your professional self. You want to know that the thing that you're doing is going to be rewarding. And my answer is, well, you do volunteer work, right? I mean, how did you choose that? How did you decide to work with homeless people, or transgender youth, or arts organizations, or environmental causes? And it's like, well, so some of this is, are you interested in it? And I'm going to talk a little bit about that. But also, is work available that you want to do, right? I mean, for a particular organization. How does their schedule and time commitments mesh with yours? Can you feel productive? This is a huge one for me, right? I mean, we've all had the experience of doing volunteer work where it's like, I hope that helped, but I don't really feel like I got anything out of it. And that's not fun. And what are the people like? And I will talk about all of these in more detail. All right, so this is, I love this slide, because I spent three years doing very badly in graduate school learning this. So I'm giving you this advice for free, so that you don't have to do that. So just because something is a really interesting topic does not mean that it's fun to work on, or that it's fun for you to work on. Like a lot of times, people will say to me, you know, I'm really interested in databases. And maybe Postgres is a good start for me. And it's like, well, maybe. I mean, Postgres is an awesome community that does a lot to help new contributors and all kinds of beginners. But just because you're interested in databases doesn't, you know, that might not translate to being interested in the internals of how a database is implemented. So, you know, like if you run into something like that, you know, if you're like, well, you know, like, I'm not saying don't do it. I'm saying if you do it and you find out that maybe not so much, because like the C++ thing is so not me, you know, don't feel bad about it, move on. Interesting topics. They often require specialized skills and knowledge, and this has a time cost. Again, I'm not saying that I think that ZooKeeper would be a terrible way to bootstrap yourself on distributed systems, but, you know, adjust your expectations accordingly. Know that you're going to have some amount of ramp up time. And I'd say it's really critical to look for projects that work where you can make progress. I think that's really important so that you get that little positive feedback loop going. And, you know, it's a thing that you wanna keep doing. It's a thing that you wanna keep making time for in your life. You know, I think that's really important. So, seeking interesting open source software work. A thing that people often do not think to do is to check out a particular project's issues or bug track for work that looks interesting. So a lot of projects now are trying to organize themselves so that they tag issues upfront as, you know, jump in or getting started or whatever. And these are intended to be for people who are new to a project and are thinking about contributing. So, you know, it's worth looking, it's worth, you know, it's a sign if a project has tags like this even and it's a good way to find out, like, is this a good place to get started for meeting it started. It's important to live for projects that can use your skills and knowledge. And I say this as an ops person who has a lot of experience in the Chef ecosystem. There are a lot of weird operating systems out there. Anything that is a non-linux can count as weird. Like if you have access to, you know, switch hardware, you work on a BSD, you work on these things like these are all really good venues for participation because, you know, people need to make their stuff work on that and they might not know how. So doing a port isn't the worst thing you can do. Look for work that isn't being done that you don't mind trying to do, right? I mean, like I know people who bootstrap themselves on open source by just going in and writing tests for projects that are like, yeah, you know, we're not where we should be with tests. You know, we don't know if we're going to have time, but you know, like if you're willing to invest some time learning their test framework, it's a good way to get started. And my thing is absolutely do not do work you don't want to do. Like I think there's a difference between, like you shouldn't do things that you don't think are fun. There's sort of a difference. You know, I will caveat that by saying that I think it's important to follow the development processes of the project, whatever they are. So, you know, do not be the jerk that refuses to write tests because you just don't want to do that. You know, if the project is like, no, we want tests. But you know, really, this is supposed to be optional, right? This is supposed to be work that you do on the site. And you know, don't do it if you don't want to do it. People are always saying things like, you know, you should totally get started by fixing the documentation or fixing typos. This turns out to be not as easy as you would think. Because for two reasons, one of them is that documentation that is in a pretty straightforward format, like markdown or text, that's probably pretty straightforward for you to fix if you see like something obviously wrong. Documentation that's generated out of a framework where there's a lot of templating, where there's a lot of abstraction, that's a lot harder to break into. And so it's kind of less rewarding as a contribution for some people. I mean, it might not be for you, but it is for some people and they just get discouraged. Typos are sort of controversial because some projects really care that you don't just come along and fix a typo. Like, you know, they want their typo fixed, they just want them fixed as part of something else. And you know, this is a thing where you can look at the history of contributions and see like, what have they accepted? What have they not accepted? So that's the thing. Some new code changes are really hard to get through as a new contributor. Like, I see this a lot with design features. Like, I will show some UI to a designer friend and they will look at me like, there's so many ways that this could be so much better. Like, this is just, no. And I'm like, oh God, I wish you could fix this, but it's so hard to fix it without having a history with that project. You know, because like people, design is a thing that people react to. And some projects would be like, yes, awesome, and other projects might be like, who are you and why are you talking to us again? So, you know, just know that this can be a thing. And the other thing is be very careful about taking on emotional work. There are every project, well, you know, there will be some fight that really boils down to personalities. And especially as a new contributor, you do not want to get involved in that. Like, do not do this, do not go there, do not pass code, do not, you know, just keep moving along because it's a knowing situation. I mean, kind of the open secret of open source, which everybody knows, but people don't tend to articulate, is it's about, it tends to be, the community is made up of people who want to write code. I mean, like, that's the core. And not in the sense of being important. It's core in the sense of, you know, these are the numbers, these are who started things. And the things that get done well in open source are the things that get done that people who write code like to do and want to do. Other stuff, it kind of falls off the end of the universe. This is not true of all open source projects. Like, there's some really notable exceptions like Seth Vargo, who is a former coworker, Fletcher Nickel, who's a coworker now, Jordan Sissle, who's just somebody whose projects I've used. Like, these are all people who really care deeply about making the entire experience of interacting with their project good, not just the parts that, you know, people use. There are lots of people like that, but, you know, there are a lot of projects that do not operate on those terms. And, you know, set your expectations. Scheduling and time commitments. Avoid over committing. It's really easy to over commit in open source. It totally is. Just, you know, avoid committing too much time to it. Just be careful. Follow project conventions for claiming work. These are a little bit weird and they're not always well explained, but, you know, people do different things to say, yes, I'm working on this. Nobody else needs to work on it or if they're working on it, talk to me. Whatever they are, follow them, find out what they are. If you're a person who cares deeply about synchronous events, like face-to-face things, like, is this a project where you can make any of those? Like, you know, can you make their video chats or their meetups or their hangouts or their in-person bug bashes? Because, you know, it's not fun to feel left out. And if you know going in that this is a no op for you, you know, that's the thing. You might want to make a different choice. So my sidebar here is how does anybody find the time? Which is a question that everybody who works in open source gets asked. And the answer is, for a lot of us, it's our day job. Right? I mean, we work for open source companies like Chef or Basha, Elastic Search, where, you know, it's a company that has a core product with a substantial open source component. We work for companies that are friendly to open source. Nordstrom is a great local example of a company that has, you know, they have a lot of things that are not open source, but, you know, they have a lot of things that are, and where they do, where they can, they try to contribute back. And there are also people who work for open source nonprofits, like the Linux Foundation, where they explicitly get paid to work on certain things. The reason why I wanted to bring this up is that it's really easy to say, oh my gosh, this other person is so productive, and what have I done, you know, in my two hours? And it's like, you know, it's worth keeping in mind that that other person may be somebody who has a lot of job support for their open source work. And that, you know, you should not feel bad. You should not compare, you know, their work to yours, you know, in a negative way. Because it's, because, you know, you don't know what the circumstances of their work are necessarily. So Willis Project make me feel productive. This is huge for me. So for me, like, how organized or predictable are they? I have seen a lot of people try to contribute to open source and they get all excited and they do their first PR. And then it sits for six months and then somebody is like, oh, well, you've fixed things like five things and rebased it against master and then we might accept it. Like, that's depressing. Right, I mean, it totally happens, but it's depressing. So, you know, people get upset about this and, you know, they're entirely justified. And this was not the first time that that project did that to someone and all of that is in the history. So, you know, if you know going in that this is a thing that you care about, then, you know, take a look at a project's history, you know, like read their issues and their code submissions and their PRs and their mailing list. And see, like, you know, do you think that this is the thing that you can work with? And, you know, can you work with how they work? There's this old Linux joke about bike sheds, about a group of people getting together to decide what color to pay to bike shed and the discussion goes on and on and on. There are a lot of them in open source, like coding style is a huge one, how you manage commits is another. If you know that these are things that bother you going in and you look at a project and you do things the other way, do not work for that project. Because there is no, there's no compromise available, right? Nobody ever says, well, you want to do four space indents and I want to do two space indents, so let's try three. Like, this is not a thing that happens, right? Like somebody, like, you're just going to have to suck it up and do it their way. And, you know, as the newcomer, at least for a while. And if that's going to bother you, don't do it. And what are the people like? Do you like how people treat each other? Are there people there who you see as being like you in whatever way you consider valuable? Because, you know, that matters. It's really isolate, you know, like, I've worked on plenty of open source projects where I am the only woman. And, you know, sometimes there's just a little bit of sticking feeling where it's like, okay, I'm going to have to explain again that, you know, I'm not going to take out the emotional garbage for them, or whatever it is. And, you know, like, like, do you want to be the person who breaks them in? And codes of conduct, community guidelines, you know, all of these are things that determine that, I mean, they're signals for how much is this a project that pays attention to its community? You know, like, do their values look like mine? That, you know, so look for things like that. So that all sounds like a lot of work. Like, I got to the slide and I was like, oh God, I've just made it sound so depressing. So I thought I'd close by reminding us all about the benefits of working on open source. So it's an awesome way to give back and help others. Like, I feel really good when I merge a PR and people are like, yes, thank you, you fixed this thing that's been bugging me for months. It's a really good opportunity for professional development and networking. So, you know, people get jobs through their open source work. People make contacts through their open source work. You know, these are all things that it's totally worth, totally worth your time. And it's a really awesome way to diversify the conversations you have with people around technology. You know, like, in work, we tend to get very focused on the day to day and on the, okay, what do we have to do to meet this next deadline? And this is a way to open the spread of that conversation a little bit. So that's it. Thank you for your time. If you have questions, you can catch me in person. I'll be around all day or hit me up on Twitter. Thank you so much.