 Entitled from no open source experience to the core team in 15 minutes a day and mostly it's going to be about why you might want or not want to work on open source and then a specific plan of like things that you can do from any level of experience until you have more experience so that you can do something else until you have made it onto as much of the core team as you want to be of any open source project. So to start off with I'm Andre Arco I'm indirect on the internet things that is my picture on the internet things so maybe you recognize me from that. I work at Cloud City Development as mostly a Ruby and Rails consultant. We do architectural consulting and team training and pairing stuff. If that's something that your team could use maybe talk to me later. I co-authored a book that came out this year the Ruby Way third edition. The first edition of the Ruby Way back in probably 2003 is the book that I learned Ruby from and so getting to update the book for Ruby in the 2010s and beyond was pretty cool. The current edition covers Ruby 2.1 and 2.2 and I think it's cool and if you buy it you know now you can have something with my name on it to prop up your monitor when it's old. That's a great, I endorse this. I founded a nonprofit called Ruby Together that's also my t-shirt and what it does is it helps keep Ruby gems and the servers that all of us use for fun or for our jobs functioning as they need work done on them. One of the things that Ruby Together supports is work on Bundler. I'm the lead developer of Bundler and I have been for I guess about four years now and turns out working on open source is lots of work but it's also a great way to learn about the community, learn about Ruby. It's a great way to interact with the community and that's ultimately what led to this talk. So at conferences on the internet when I talk to people the most common question I get is not why is Bundler broken although that's a close second. The most common question I get is how can I start contributing to open source and I've spent years trying to answer that question well to be honest. It is a hard question without an easy answer and this talk is the list of suggestions that I have managed to put together that have still seemed good a day or a week later and so to start with let's talk about what contributing to open source actually means and the most common misconception about working on open source is that you need to have a lot of experience to do it. The next most common misconception is that you need to have any experience to do it. I totally understand where this idea comes from. Existing projects seem complicated and hard and there are a lot of things that you don't know about yet but you are experienced enough to do it. Working on an open source project is a super powerful way to learn more about the language, to learn more about the project, to learn more about the entire ecosystem of developers who help one another write code in public on the internet. It's really not said often enough but there are no real programmers. Everyone can tell a computer what to do. The most senior programmers still spend huge amounts of their time confused about why things are happening. There is no magic experience that makes you say ah I understand everything that is happening in my computer it is vast beyond your comprehension. I would argue that the core skill of programming and the one that you can be good at whether you have experience or not is investigating things that don't make sense until things make enough sense that the computer is doing what you want. Despite many companies I guess at this point claims GitHub is not a resume. Making free software does not prove that you are a good programmer and many of the best programmers that I have ever met, known, worked with, learned from making no open source whatsoever. So before, I know you're all here because you want to work on open source, but before you do that I would like to at least make sure that you know what you're getting into. So what are your goals? Why are you in this talk to learn how to contribute to open source? Do you want to improve your skills as a programmer? Do you want to gain fame and, well fortune is not really an option, but fame. Open source can be a good way to accomplish those goals, but it's not the only option that you have, right? You could write software just for yourself to hone your skills and not have to deal with the other side of working on projects with people and users who are cranky. You could volunteer to be a teacher or a mentor at RailsBridge or Code 2040 or a lot of other programs where teaching is a way to learn and understand things better. If all you're really looking for is shouldering a pile of crushing guilt, you could just get a lot of entitled relatives who want you to fix all their computers and that reproduces the dynamic of an open source project really well. You have a lot of options is what I'm trying to get across. So ultimately your time is your time and you don't owe it to anyone else and I hope that you'll keep that in mind as we talk about all the things that you could be doing. Think about your goals, choose to spend your time on things that accomplish your goals and if you want to just write software that solves a problem that you have, maybe do that. If you want to work on a project that you already used to make it better, you can totally do that. If you want to work on a project that is hugely popular and you're really stubborn, you can do that. But if you want to just work on your career by writing software at the company where you work, that is also a totally legitimate option that I endorse. So when I talk to people about what they think of as contributing to open source, they kind of always paint the same like vague no details picture of a genius programmer working late at night furiously typing, opening PRs, closing bugs, merging, opening PRs that contain code so good it doesn't even need code review before it's merged. This is basically the exact opposite of reality. Contributing to open source is actually more about understanding other people's problems and trying to help them with those problems than about writing code. Sometimes that understanding people's problems and fixing those problems does mean writing code, but sometimes that just means writing a paragraph that explains to them what they're confused about. Sometimes that means adding that paragraph to the documentation. Sometimes that means fixing an error message or working on a website or designing something better. You can contribute to open source without being ready to code. You can contribute to open source without even having coding as one of your core skills. Writing code is a tiny fraction of the work needed to solve people's problems at scale, which is theoretically what open source is about. So benefits, there are actually some benefits, which is cool. You can practice building projects yourself from scratch, which is maybe an opportunity that you don't get out of paid job. You can practice working with a team of developers, allocating tasks, estimating work, blowing through deadlines, disagreeing about how things should work. This is all very like modern software development process that maybe you don't get the chance to get experience with in your day job. I have worked both at jobs where I had no chance to work on small projects where I had control, and I have worked at jobs where I had no chance to work on projects where I had to actually collaborate with people. Open source contains the opportunity for you to do both of those things, and being good at both of those things is part of being good at writing software. Ultimately, working on open source provides a lot of benefits of an unpaid internship, but you don't have to get someone's permission to be an unpaid intern. If that sounds appealing to you, keep listening. So the upside to not needing someone's permission to not get paid is that you don't need someone's permission to not get paid, and you don't need anyone's approval to do whatever it is that you're interested in doing. And sometimes that is super valuable and super powerful. And open source, you can work on, you can work in your own time when you have time. You can work at your own pace. There's no one with a deadline who will follow up with you looking for those TPS reports. You can work on anything that seems interesting to you until it doesn't seem interesting to you anymore. With no obligation to work on any particular thing for a particular amount of time or to a particular deadline, you can actually just learn a lot of stuff. Turns out that's cool. So now that you know about those benefits, there's kind of the ultimate caveat that I'm aiming to get across is only work for free if you can and if you want to. And that is actually probably the most important point of this entire talk. So I'm just going to say it again, only work for free if you can and if you want to. So can you work for free? Let's look at that. Open source work is basically never paid. Open source developers do a lot of work that companies use to make money. Open source designers do a lot of work that companies use to make money. Those developers and designers in particular will probably never see any of that money in a cut or in a payment or in any way. Companies taking advantage of the work done by individual people to have bigger profit margins is a thing. I super strongly encourage you to read Ash Dryden's ethics of unpaid labor and the open source community for a detailed discussion of that particular problem. So I want to take this moment to call out that while creating open source tools and expanding your reputation is cool. Working on a side project that earns you money so you can pay bills and so you can buy food is also cool. Paying bills, buying food, these are important life goals. These are probably life goals you want to put above being an awesome open source person. Even really well known open source developers get caught up in demands from people because their users are people who have problems and forget to take care of themselves while they're trying to help other people with their problems. Every time you're tempted to work on open source, just be aware of the time and potentially money that you are sacrificing in exchange for the benefits that do actually exist. If you're still interested, I have one last warning, and then I'll actually tell you the plan. So we're almost there. So my last warning about open source is that choosing to release your open source means that you have voluntarily given up any control over what happens to it. In a very recent real life scenario, there someone who wrote many, many packages that were hosted on npm got really upset about a legal trademark decision that npm made. And he deleted every single one of his packages off of npm in protest slash rage. And his work out of those 50 packages, there just so happened to be one that basically every node application in the universe depended on. Amazingly, it was called left pad, and it let you add spaces to the left hand side of strings. Turns out enough tools depended on left pad and enough other tools depended on those tools and enough applications depended on those tools that when left pad disappeared, almost every single node application in the entire universe stopped working. CI stopped functioning, deploys stopped working. No one could like it just everything blew up. It was terrible. But left pad was open source. And someone took their own copy of left pad and put it back on npm under the same name. And because it was open source, that was explicitly permitted by the person who had rage deleted all of his code. So even though the author of the code explicitly wanted all of his code to be deleted from npm forever, he no longer had the legal right to make that decision. And now everyone still uses his code to this day because he actually gave them permission to do that. No matter how upset he is about it. So as you're thinking about that, keep in mind that putting code on GitHub does not mean that you are giving people permission to use it, although they probably will to be fair. Research is a great way to do that. You can choose a license, choose a license that you are comfortable with. GitHub created a website solely to help with this problem called choose a license.com. It has a pretty great summary of the high and low points of each open source license that is available. The Creative Commons project offers another option where you can use their pre-made mix and match licenses to reserve rights like commercial use or noncommercial use or whatever you want. You can allow it or disallow it explicitly. And once you've made your work open source, keep in mind that anyone can use it for anything that your license allows. So in the most dramatic and horrifying and yet real world scenario that I can think of, that means you can't stop someone from using your work to say build a system that uses robots to drop bombs on civilians and kill them. Be sure that you're okay with the idea of your unpaid work being used to do something that you would never ever do yourself before you open source it. So if you're still here, thank you. I appreciate that. And now that your expectations are appropriately lowered, let's talk about actually working on open source. So as I said in the title of this talk, plan to spend 15 minutes a day on this depending on your personality that may very quickly become an hour a day or two hours a day or sometimes for me it's more. There is no end date, right? When I said 15 minutes a day, I didn't say for a year. Popular open source projects surprisingly, not surprisingly, never run out of people who need help. So you can just do this until you decide that the trade off isn't worth it for you anymore and slowly disengage or burn out or step back for your sanity. Those are the three most popular exit plans for open source maintainers. The more projects you pick, the more time you'll need. Spend some time thinking about projects you use, projects you think are cool, projects you're interested in working on. Pick one, maybe two. I would definitely recommend you pick no more than three projects and then get ready to actually dig in. So step one, what is happening? Read the read me, read the manual, read every single page on the entire website for this thing, read the developer documentation, read the contributing guide, read the change log, are we warmed up? Okay, now the fun stuff. Open the GitHub project, open the issue tracker, read every single issue. Maybe not the closed issues, depends on how big the project is, but read all of them. Read every comment, read every problem, read every person who doesn't understand what is happening and is like, I don't know why I just saw this backtrace. Follow the repo so you get notified about every new issue and every new comment and read those two. To be clear, only do this for 15 minutes a day, right? There's no time pressure on this. You can take as long as you need to accomplish all of these things, but this is how you get oriented on a project and know what's going on. So for big projects like Rails, at 15 minutes a day, it might actually take you weeks to read every single issue, right? Last time I checked, there was about 2,000 open issues on the Rails repo. But that's okay. You're in this for the long haul. Someone I know, Steve Klamnick, did this with Rails. This was his plan explicitly. And it did take him weeks. But after he finished, he followed through on a few more steps of this plan and eventually wound up on the Rails Committer team. So this is totally a doable plan, trust me. So now that you've read all of the issues and all of the comments and all of the documentation, it won't actually take very long before you start to notice new issues that contain questions that you already know the answers to. You're like, oh, the documentation answers that question over here. Or, oh, I've seen other people answer this question in five tickets, so I'm sure that the answer to the sixth ticket is still the same. Answer the questions that you know how to answer, and now you're contributing to open source. Good job. Answering the questions is just the beginning. Once you can start answering questions, you can start helping with tickets more than just answering questions. A lot of tickets are repeats of old tickets that by now you've already read. Once you're familiar with the scenarios, you can not only answer those questions because they repeat. You can try to figure out where in the docks to answer that question so that the tickets stop repeating, which is cool. Work yourself out of work. Open source in a nutshell. Start improving the documentation based on all of the things that you just learned by reading every single issue. Add warnings for common problems. Improve things that are confusing or wrong. Start thinking about how to improve error messages. Turns out that is actually the highest leverage way to reduce ongoing maintenance and support work is just improving the error messages, not making the error messages go away. Keep reading new issues for your 15 minutes every day. And at this point you probably are getting a feeling for how the project works. You've seen pull requests probably happen and code review happen and changes get merged. And this is an ideal time to go back and reread all of the documentation and make it better. You are still new enough that you understand the problems that people who are new to the project will have, but you now have enough understanding and context to fix a lot of those problems. And that combination is very uncommon. As someone who has worked on Butler for years, I can no longer even reason about what things people don't know. And it's very hard to find people who still remember what it is like to not know things to help us with the documentation. This is also a super great point to start helping with issue reports. When someone reports a bug, when they can't provide steps to reproduce the bug or they're not really sure what the bug is, you can be the person who figures that out. You can find the reproduction steps. You can put those reproduction steps on the ticket. As a project maintainer, I will leave you a little party emoji for every time that you send me a reproduction case. And I will be completely serious about it because I'm very excited. I don't even know how to state the value and importance of people who are willing to investigate bugs and either reproduce them or tell the person I did the same things you said and I got this different result. That is what makes it possible to write a test. Having a test is what makes it possible to fix the problem. That is what I am aiming for. Oftentimes I do not have the capacity to do all of those things and so contributors doing some of those things is just amazing. The next level of helping after a reproduction case is not that surprisingly, now that you know exactly how to make it not work, figuring out how to make it work, if you have a test case honestly you could just write the test case and then open the PR and I would be super super excited. I can't like a PR with a failing test is like makes my day. It's like the best present, right? And you didn't actually have to understand anything about the contents of the code, right? All you had to do was figure out how to make the problem happen again automatically. Once you have figured out how to make the problem happen automatically though, it's not actually that big of a step to then be like if I change this does it go away? If I change this does it go away? I mean that is what I am going to do. All of us could try it, right? There is no pressure on this. There is no time frame where you should feel comfortable doing this but chances are high that as you continue to do this more and more over time you will reach the point where you are like oh that was clearly nil and we called a method on it anyway, maybe I could just like check to see if it's nil and not call that method. You can. It's cool. You can just open the code. It's open source. It's amazing. Writing code that fixes bugs and adds features does require understanding, right? And this is the hard part about contributing to open source. Understanding the code, understanding the users of the code, understanding the project and the goals of the project, those are actually the hard things about working on open source. And unfortunately it's hard even if you're the person who wrote the code to understand the code, right? Like I look at things that are broken in Bundler and I am like I wrote every line in this file four years ago and I do not remember any of them and I don't understand what the problem is so I guess I'm just going to treat this like code that someone else wrote. And once you're able to do that you can do anything, right? Start using it. Be like oh that's awkward. That's a confusing option. That informational message could be clearer. I just made it do a weird error. I should do something about that, right? Suddenly when you have enough experience with a particular project that you're like oh I can do things to this project, everything gets annoying. Why is this error message so bad? Why is that option confusing? This should obviously I think to myself work easily and clearly and it doesn't and that makes me very upset, right? As soon as you start feeling ownership you're like oh this is terrible and now you can make it better which is super cool. And once you can work on anything chances are good that you can start coordinating with the actual core team and be like hey you have probably figured out things that would make this better but you haven't had time to do them yet, right? And the answer will be yes yes we have a long list of things that we know will make it better that we don't have time to do that. You could be someone who has time to do that and that's pretty cool like talk to the people who already work on the project, like come to consensus about priorities and or just say well I'm willing to work on that so that is now the highest priority thing because I have time. Guess what? You're an open source contributor, I just snuck up on you and now that's you. Keep it up, keep doing this, spend a few weeks, months, probably months, probably not years. If you stick with it you're basically guaranteed to end up on any core team because you're actually making the project function. That's what core teams are, they're the people who are actually still there making the project work and there are basically no other qualifications. And if you keep this up for a few years someone will probably tell you that they quit and now you're in charge. Speaking from personal experience this is a very real thing. Congratulations also my condolences. So what did we learn? Open source can be rewarding, open source has a lot of benefits, open source can be worthwhile, it's not necessarily for everyone, consider what you're giving up, keep the trade-offs in mind and do the thing that has the trade-offs that you're happy with. It is possible to figure out what is happening and why it is happening and fix it. Because computers, unlike people, are ultimately understandable. And finally, understanding and helping the humans who are maybe not ultimately understandable is actually the core skill of open source work and maybe all software development but I'm not sure I want to defend that right now. So building tools that improve the lives of users can be just phenomenally immensely satisfying and that's what keeps me doing it. Thanks.