 I live in upstate New York about two hours north of the city in a city that was the first capital of New York until Sam Fippin and the British burned it down, like twice. You can find me anywhere online at the handle Eileen codes. That means Twitter, Instagram, e-mail, GitHub, anywhere that I actually want you to find me. I'm a senior systems engineer on GitHub's platform systems team. Platform systems is the team that's responsible for Rails and Ruby and other libraries and how those interact with the GitHub application. I'm also the newest member of the Rails core team, which means that I'm allowed to tweet from the Rails Twitter account, which is the only important part of being a Rails core team member. But for those of you who don't know, we're also responsible for defining the future of Rails, releasing versions, and fixing the bugs for all of you sometimes. Today we're going to talk about the unbearable vulnerability of contributing to open source. Before we deep dive into that, I want to give you a bit of background on my involvement in open source and what I mean by vulnerability. When I talk about vulnerability and open source, I'm specifically referring to contributing to open source and how that exposes our insecurities and makes us feel like we're not good enough to contribute. The vulnerability that we feel when contributing can inspire us to change the software we use and the communities we belong to, or it can be so unbearable that it's paralyzing because our vulnerability makes us afraid of contributing. I've been contributing to open source for a long time, and I still feel vulnerable, especially when I contribute to a new project or build a major feature. Vulnerability is an inherent part of contributing to open source, and I don't think that's something that I'm ever going to go get over. I opened my very first pull request on GitHub in 2012. It was a pull request to fix a typo in a read me of a project that I had been using. The PR was never merged because the project had been abandoned for a few years. Almost a full year later, I opened my second pull request. Many profiler is a database and request profiler for Rails applications. I noticed while using many profiler that there was this little extra space at the bottom of the page that was super annoying, and I thought, oh, this is a CSS bug. So easy to fix. I quickly found out it was not CSS, and it took me two days to find the invisible UTF-16 character that was hiding in, like, it was a JavaScript file or a CSS file or something. It was so bizarre. And even though I had spent lots of time looking at that issue, and I was confident that I had fixed the bug, I was still worried that I was wrong or that my contribution wouldn't be welcome. I felt vulnerable because I didn't know what to expect. After giving a talk in 2014 at Mountain West Ruby, I learned that I had found a bug in ActiveRecord. Aaron Patterson, who most of you know is Rails and Ruby Core team member or just as Tenderlove, asked if I wanted to pair with him to implement a fix for the problem. Shortly after pairing on that fix, I opened my first pull request for the Ruby on Rails framework. Even though I had worked with Aaron and knew that I had the right fix, I was still really nervous about opening a PR against a repo where 2,000 people get notifications every time you open an issue or pull request. I felt vulnerable because I was a new contributor. What if somebody thought my fix was stupid? What if somebody thought I was stupid? These thoughts might seem irrational, but they are embedded in contributing to open source because we're dealing with people, not code. The other side of that fear, though, is the high you get when your pull request is merged. I continued to contribute to Rails regularly after that first pull request. Maybe it was because I had someone mentor me and help me understand the Rails internals. Maybe it was because I had such a good experience contributing that first time. One of the goals of this talk is to provide ways in which you can improve your community so more contributors experience that high instead of the unbearable vulnerability when contributing to your project. This past year I worked on a large feature for Rails called system tests. Previously, a lot of my work on Rails had been refactoring code, fixing bugs, or improving performance, you know, all that stuff that no one actually cares about. This was my first experience adding a major feature to Rails, and by major I mean it was literally the highlight of the Rails 5.1 release. Working on this project reminded me how hard contributing to open source can be. I had been contributing to Rails for over two years, but I was nervous opening this pull request. I have those familiar thoughts. What if everyone hates this feature? What if someone thinks my code is bad? Even though DHH, the creator of Rails, literally asked me to build this feature, I still had to deal with the reviews and the comments and defend my decisions that I made. When I opened the pull request, I had already put three months of work into it. The project was personal to me because I had spent nights and weekends working on it, and I became attached to the code. In the time the pull request was open, I received over 150 comments and 11 reviews. That's a lot of other opinions to deal with. I felt stressed and vulnerable just like I had when I opened my first pull request. Someone even tweeted about the PR, which only drew more attention to it. And don't get me wrong, attention is good, and reviews are good, but I was drained by the endless bike shedding and nitpicking of details. None of the reviewers met any harm. They were really excited about the feature. Still, a level of discomfort nod at me. I had been an average contributor of Rails for two years and released Rails 5, and I had commit rights. So why was opening this PR a nail-biting, stress-inducing event in my life? I figured I'd be over the unbearable vulnerability by now. While thinking about that, something hit me. I realized that even if we get used to working on open source, we can still experience vulnerability when we work on a new project or a large feature. The more time we spend on open source, especially free time, the more attached we become to the work that we're doing. And there's only one explanation for why this happens. Contributing to open source was only about writing code. It would be easy. What we all know contributing to open source isn't easy. We're not just dealing with code or ones and zeros. No one would be worried about opening a pull request if open source was about writing code. So if open source isn't about writing code, that means that open source is really about people. And it's the people who make us feel vulnerable. Contributing to open source is about our insecurities, our fear of being wrong, and our fear of showing our peers our work. Often just the thought of pushing code to a public repository can cause anxiety for me. Given that, while people are the source of our vulnerability, they are essential to the open source ecosystem. Let's take a minute to think about what open source would be like without people. Say you write a gem or a library and open sourced it. Sure, it's public for anyone to use, but if no one downloads it, is it really an open source project? Open source doesn't work without users. Otherwise, you're not really sharing your code with anyone. No users means no bug reports, which means your work doesn't improve. And if you stop improving it yourself, no one's going to notice because they don't use it. While your code might be public, it's just public code until someone uses it. Let's say you have tons of users but no contributors. Sure, you get to control the project and you never have to deal with other ideologies, but is that really open source? If you stop improving the project or move on to something else, the project won't really be useful anymore. Open source can't survive without contributors. Imagine a moment for a world where Matt's created Ruby but had no contributors. Would it be as robust as it is today? Definitely not. Would all the engineers who learned Ruby and got jobs not writing Java be as happy as they are today? I don't know. Maybe everyone would have adopted PHP instead, but the community and tools would be very different from where they are today if we had done that. I wouldn't be here today giving this talk if it wasn't for Ruby, Rails, and its success and all of those contributors contributing to that success. So I've convinced you that you need people as users and contributors to have a successful open source project. In that case, what are we going to do about the unbearable vulnerability? Vulnerability can be harnessed as a motivator for change or it can deter us from contributing. There are ways we can foster a welcoming community and attract more contributors rather than deter them. Before we explore ways in which we can make better open source communities, we're going to look at ways in which maintainers make vulnerability unbearable. Vulnerability can be a deterrent for many new and long-time contributors. Feelings of inadequacy can keep folks from contributing to your project, which means maintainers lose out on changes from other viewpoints that can make their project more robust and stable. We want to avoid creating an environment that fosters fear of contributing in favor of an environment that's welcoming and inclusive. We want to create environments and communities that cultivate creativity and inspire contributors. One of the ways maintainers deter contributors is closing pull requests without providing feedback. When maintainers do this, they don't leave room for contributors to improve in the future. Maintainers should always explain why a pull request wasn't accepted. Otherwise, contributors might take it personally. Contributors spend a lot of time and emotional energy on contributing and it can be demoralizing to not have your pull request accepted. Ask clarifying questions if you don't understand why a change was made or what their use case is. Being dismissive and not giving feedback will cause contributors to feel like their time isn't respected and they may not contribute to your project again. Another way in which maintainers can make contributors feel more vulnerable is through violent communication. An example of violent communication is saying, this code sucks or did you even try to fix the problem? This communication style passes the blame onto the contributor and shames them. This will lead to contributors feeling defensive and more vulnerable. It will deter them from contributing in the future because they don't feel respected. It's easy for context to get lost over in communication, so try to over communicate with nonviolent techniques to get your points across so you don't alienate contributors or future contributors. If you want to learn more about nonviolent communication, you should watch this talk by Nadia, who's sitting right there, called This Code Sucks, a story about nonviolent communication. Her talk explores what nonviolent communication means and the benefits for using it in your communications at work. Often I see bad behavior being tolerated by someone who's a high impact member of the team. They respond to lots of pull requests or they send lots of patches. Even if a contributor or maintainer may seem like an asset, if they're abusive towards new contributors, that will deter other contributors in the future from joining your community. It's important to protect your contributors from bad actors and to not tolerate behavior that's exclusive or offensive. A power dynamic exists between maintainers and contributors. It's important to recognize this because maintainers inherently have more power than contributors. This will always be true because maintainers decide what gets merged and who gets to contribute. Because of this power dynamic between contributors and maintainers, it's up to maintainers to set and reset the tone of the conversation. There are always going to be assholes who come into your project and demand free time from you. But most of the people contributing to your project mean well. It takes a lot of energy to be rude to people. Wouldn't maintaining be easier if we could learn to diffuse stressful situations instead of making them worse? As a maintainer myself, I have felt the pull to tell someone off. When that happens, I try to put myself in their shoes and take a walk before responding. They're probably frustrated. Maybe their boss is breathing down their neck to get this fixed. Maybe they dropped a production database. Often taking the time to tell the contributor that I know they're frustrated quickly turns the conversation from defensive to productive. This doesn't mean giving the contributor everything they want. It just means treating them the way that you want to be treated in a stressful situation. Vulnerability can be harness as a motivator as well. Being vulnerable isn't a bad thing we have all felt it before. Every single maintainer and contributor has at one time felt vulnerable and probably will feel vulnerable again. But when we feel safe being vulnerable, we're more creative, more inspired and more open. If we can change our open source communities to be more welcoming and supportive, they will be more sustainable and the vulnerability will be bearable. So why is it important that we create a welcoming and supportive open source community? Why does it really matter if contributors don't feel safe being vulnerable? Open source is a funnel. At the top you have your users. Some of those users become contributors and some of those contributors become maintainers. The more maintainers you have, the more sustainable open source can be because you have more backup. Making our open source communities more welcoming will attract more users to become contributors and more contributors to become maintainers. If we don't do this, we'll end up on an island alone maintaining projects by ourselves. This leads to less users because you can't sustain the project alone, less job offers because no one is using your project, and less friends because let's face it, you're spending all of your time working on open source instead of having a life. Imagine a world where instead of burning out on that island, the funnel didn't lose so many potential maintainers. I just realized like how much debt has been talked about at RubyConf and I just threw a skull up on there. It's the theme. But don't worry. You will all live. You will learn to live better. What would the ideal open source world look like? It might look like something like users and contributors and maintainers all moving equally among roles. In today's open source world, maintainers often stop being users of their own product. Some even stop contributing beyond approving and merging pull requests. It doesn't have to be like that. But I also think that this ideal world is very hard to achieve because of open source and the political structure of everything. So if this ideal world isn't really possible, what is possible? I'd like us to aim to get the funnel to be a little bit more like this. Users are still the majority of people who are involved in our, in your product, but users are more likely to become contributors and contributors more likely to become maintainers in the previous funnel. I'd also like there to be less friction to move from users to contributors to maintainers and back again. Open source needs contributors. Without them, open source will cease to exist and thrive. We need to make open source more sustainable so that people continue to contribute to open source. Open source software is the present and future of technology and without it innovation will stagnate. So how do we create a welcoming and supportive open source community so that new contributors join and open source communities thrive? There are a lot of ways in which we can make open source a better experience for everyone. Healthy communities benefit from the new platform. We need to make open source more sustainable so that people can become maintainers, contributors, and users. One way in which maintainers can attract and retain more contributors is through mentorship. Many of my first contributions to Rails were the result of pairing with Aaron Patterson. Mentorships don't need to be official and can happen organically. I met Aaron at a conference after my, and after my talk he told me I discovered a bug in Rails and offered to pair with me to fix it. Before I made my first contribution to Rails, it was a really complicated code base and it can be difficult to get used to working on. On top of that, the community is massive. Rails has over 2,000 contributors and at least 2,000 people get notifications when issues in PRs are opened. I didn't think that I had something more to offer than they did. Aaron and I started pairing regularly, which helped me learn faster and feel more comfortable contributing. It didn't erase all of my anxiety, but instead of feeling unbearable dread when contributing to Rails, I was excited. Aaron's guidance helped me navigate both the code base and the community making contributing to Rails less stressful. I knew he had my back and would help me defend decisions in PRs we made, mostly because those decisions were his crazy idea. Mentoring can happen in many forms from pairing to email to inviting contributors to a group chat with other maintainers. I've helped folks get their first contribution through Twitter DMs, pairing and email. Mentoring doesn't have to be official or time consuming. The point of mentorship is to act as a guide for your mentee and help them feel welcome in the community. Writing up clear guidelines for contributing can help make maintainers feel more welcome to your project. It's always easier to contribute to a repository that's explained what's expected rather than guessing. Each open-source project has their own rules for contributing. For example, the Rails project doesn't accept feature requests on the GitHub issues tracker. Other projects are fine with this type of issue, so clearly setting up the guidelines for contributing will allow contributors to focus on contributing rather than being worried about breaking unspoken rules. Be sure to add a contributing mark down file to your GitHub repository. Include any rules about contributing that are unique to your project like requiring all pull requests to be a single commit or not allowing cosmetic changes to the code. The Rails team provides bug report scripts that can be used to replicate bugs experienced in Rails applications. This means that users don't need to provide us what they're experiencing. If the bug can't be reproduced with one of our scripts, then we know it might be a gem or something that's about, something weird that's about their data specifically with their application. This helps us triage issues faster because we can see directly where the behavior is caused from instead of playing guessing games and figuring out a reproduction. This helps contributors by reducing the amount of work they need to do to give us a reproduction, so they spend less time stressing out and just give us what, and then it's easier for them to contribute after that. When possible, use bots or scripts to handle pull request triaging or to remove personal bias or ensure contributors don't feel ignored. On the Rails project, we use a bot to auto-assign a pull request to maintainers. Rails gets so many pull requests that it's hard to give everyone attention, but with the assignment bot, we can mostly do this. This helps new contributors know that someone is paying attention and will respond to them soon. We also use linters to tell contributors what needs to be fixed which reduces bike shedding and nitpicking about small details because nobody wants to argue with a bot. Everyone makes mistakes, so if you see a new contributor, fail to add CI skip for a documentation change or open a feature request on the issues in the future. Kindly tell them how to contribute better in the future. This will ensure that even if in that case their pull request isn't merged or you ask for changes, they don't feel like you are nitpicking on them and making them feel bad for making some tiny little mistake that doesn't really matter, so Travis runs one extra time big deal. I guess it's probably a bigger deal for Travis to help you. When you're a maintainer of a project, it's easy to think that you have to do everything yourself. I think it's important to know when and how to ask for help. You can use your read me to document areas where your project needs help. When I first started contributing a mini profiler, I knew exactly what Sam Safran wanted help with because he laid it all out in his projects read me. In fact, he still needs help. Contributors will feel more welcome to push changes to your project if they know the work they're doing is wanted. This reduces vulnerability and stress when opening that initial pull request. Asking for helping your documentation is a great way to get contributors you need and bring the contributions you need and bring contributors who are passionate and maintainers. Rails wouldn't be as successful as it is today if DHH didn't share the burden of making decisions, releasing new versions and sculpting the future of Rails with us. Rails currently has 12 members. That means all of us don't need to be available all the time for Rails to thrive. While smaller projects aren't likely to have a team as large as they are, trying to maintain a project by yourself is a fast track to burn out. We can create more sustainable communities if we're nice to and respect everyone. Maintainers set the tone of the conversation. Yes, assholes will always exist, but the majority of contributors come to your project with good intentions. One of the most important things to remember as a maintainer is to not review pull requests before you've had your morning coffee. I've personally jumped to snap conclusions when I review pull requests before having coffee. Often, it's more likely I'll be short with the user and dismiss the pull request without a proper review. Take the time to take care of yourself before reviewing pull requests. Contributors will feel more welcome and won't have to put up with your crabbyness. Being dismissive or rude because of the lack of communication is the best way to interact with contributors. You probably should employ nonviolent communication methods in all areas of your life, but right now we're just talking about open source. Using nonviolent communication will keep the conversation open. Remember that as a maintainer or contributor of a project, you set that tone of the conversation. Recently, we had a situation on the contributor getting defensive because we weren't listening to them. I took the time to respond to the contributor and let them know that I understood how they felt and I asked what solutions would work for them. This immediately changed the tone of the conversation. Instead of being annoyed, we were able to talk about solutions. This doesn't mean the contributor is going to get exactly what they want or that we're going to fix the issue, but they no longer feel comfortable. You can show respect. You can show that you respect your contributors and future contributors by adding a code of conduct to your project. This will attract new contributors because they know that you're serious about maintaining a professional and respectful community. While codes of conduct benefit everyone, people from underrepresented groups are more likely to feel comfortable and welcome contributing to your project if you implement a code of conduct and ensure with respect. Maintainers can use GitHub provided tools to signal that their community is healthy and welcoming. A great feature that GitHub added a few months ago is the first time contributors badge. This badge clearly indicates when contributors are new to your project. When you see this badge, give that contributor a little extra time and be a little extra helpful. When I see this badge, I like to take the time to congratulate the contributor on their first pull request. As a maintainer of Rails, I want contributors to have a good experience and letting them know that I appreciate the time they put into Rails, especially as first time contributors, they will be more likely to contribute again in the future. Another GitHub tool that was rolled out recently to everyone is the community profile. The community profile tool is a tool that shows GitHub's recommended standards for creating a welcoming and sustainable open source community. The community profile is located under the repository insights tab via a link called community. The community profile page will show you six items that make a healthy open source project, a description, a read me, code of conduct, contributing guidelines, a license and issue in PR templates. Each of these items will help make your project more approachable and sustainable. If your community profile is not complete, GitHub provides a wizard to help you add the missing items like a code of conduct or picking a license that works for you in your project. We've talked a lot about how maintainers can build better communities. All of this helps you to feel welcome and inspired. The goal is to make vulnerability bearable for our contributors. Now we're going to look at ways that contributors can find healthy open source communities where they know their contributions will be welcome. One of the easiest ways to find a project to contribute to is to look at the tools you use every day. If you build Rails apps, go look in your demo file for ideas of projects that might need your help. Go to the tools that you use because that's where you'll be most useful. In open source, users become contributors and contributors become maintainers. So with that logic, the easiest way to become a contributor or maintainer is to first be a user. A great way to find a community or project you want to be a part of is spend some time observing the behavior of the maintainer or other contributors. First, make sure the project is active. Active projects have recent commits. Look at the top bar and GitHub repository for the last commit was. Projects that are active will have pull requests merged or issues closed in the last few days to months. My first open source contribution was for a project that had been long abandoned and it didn't feel good to make a contribution that would never be accepted. There are few ways you can go about making changes to abandoned projects. You can offer to take over maintaining the project or open a PR with the expectation that it won't get merged. Don't open an issue that asks is this still maintained, especially when it's very obviously not maintained. Once you're sure the project is active and accepting new contributions, take a look at how maintainers respond to new issues or pull requests. Subscribe to a few of those pull requests on the project and see how maintainers treat contributors. Are they kind or dismissive? Do they do questions go unanswered or do they help them get the pull request merged? This will help you know what to expect when you open that first issue or pull request. Most maintainers so being unresponsive doesn't mean they're rude. They're just busy or burnt out. But knowing the communication style of maintainers up front can help you be more prepared when you open that first issue or PR. Just as most maintainers are volunteers and open source, you're a volunteer too. You don't have to work for free for assholes. If a maintainer or other contributors aren't respectful of you and your time, it's okay to say nope and go work on other open source applications that I wouldn't contribute to because I didn't think the maintainers treated people the way that I wanted to be treated. I didn't want to have to interact with them in order to get my bug fixed and then just feel like shit all the time because they were rude to me. There's no requirement that you voluntarily work on open source projects where maintainers or contributors are rude to you. A big part of contributing to open source is learning how to accept rejection. It's really demoralizing to not have a vision for their projects and that's a big reason why pull requests are accepted or rejected. I've had many pull requests rejected and I know that it's not fun. But don't take the rejection personally. It's all part of contributing to open source. Ask for advice on how to do better next time and apply that to your future work. Once you do find a community in projects that you want to contribute to, be as respectful as you want the maintainers to treat you. Hitting a bug but maintaining a project is hard too. Most maintainers are volunteers so while the majority of this talk was about how maintainers can do better contributors can do better too. Treat maintainers the way you want to be treated if you were a maintainer. There are a ton of resources to help contributors and maintainers have a better experience and build more sustainable open source communities. First timers only.com help new contributors find projects that need help and are actively seeking out new contributions. Open source.guide is written by my lovely colleagues at github and it's a resource for contributors and maintainers with ideas about building more welcoming communities, finding your first pull request and implementing open source Fridays at your job. Open source isn't about writing code. Open source is really about people, people, people, people and community. The thought of contributing to open source or interacting with toxic communities can be paralyzing but open source cannot survive without contributors. It's our responsibility to build welcoming communities so that open source is sustainable and inspirational instead of paralyzing and toxic. We can do this by mentoring asking for help when we need it and demanding up on ending up on that island, burning out from maintaining projects alone. We get to work with bright minds and share ideas in a healthy, sustainable community. The benefits are endless. Building a better community will attract more contributors. This makes open source communities more stable and sustainable. Maintainers and contributors are less likely to burn out because they're more likely to share the burden of contributing with less demand on their time . Let's build open source communities where less contributors experience dread when contributing because they're vulnerable and afraid and more contributors experience that high because they were inspired by their vulnerability to build something amazing for your project. We must all work together to create more sustainable open source communities. The future of open source depends on all of us. I hope the maintainers of open source communities I hope the folks in this room who have never contributed to open source are inspired to move past their vulnerability and contribute and I hope that everyone will respect each other and recognize the vulnerability everyone has to overcome to contribute to open source. The job of growing these communities doesn't lie solely on one maintainer, one contributor or one project shoulders. The responsibility is all of us. We can make sure open source thrives by building welcoming and sustainable communities. Together we can make the unbearable vulnerability of open source bearable. Thank you. Anyone has questions I think I have time. Wait, do I have time? I have time, okay. And afterwards I have stickers from GitHub. So if you haven't gotten enough stickers I have more. I have about the question is how much time do I spend reviewing and other things? I would say that since joining the Rails core team in February I spend less time writing software for Rails and more time triaging and pull request merging. I don't know exactly how many hours I spend because some weeks I don't work on it at all and some weeks I spend more time on it five I should spend more time on it is really what I'm getting at I don't feel like I'm spending enough time because we have issues trackers insane right now but that's why all of you need to become contributors of Rails you can join the core team we'll never have inbox zero it's fine but you can all help me triage issues I don't think that was a good answer to your question I'm sorry and how contributors move users move to contributors and then maintainers and what I also talked about how Rails has a lot of open issues and doesn't seem like maybe we're not moving that funnel around a lot and we how we can improve that funnel I think that Rails is a hard example for for that because it's such a complicated code base I think there are things that we could do better we could we could mark issues that are that are easy more often we don't really do a good job of that I think we could pair more with new contributors I think we could I think we could do a better job of explaining how we figured bugs out because I think there's a lot of people who think that we on the Rails core team are like magic unicorns who understand Rails internals but it still takes us hours to figure out problems sometimes too and if we talked more about I don't know if everybody even seemed like Richard Schneem when he does his blog post about I debugged a thing and they're really good we should do more of that too everyone who everyone who spends time investigating bugs in open source it would be great if we all and I say that as me too I should do this it would be great if we all wrote more about finding those problems and solving them because sometimes they're not sometimes they are really hard and sometimes they're just oh I knew that like this was in this gem and like this is how to make a script to test it and here's how to bisect and then that's how you that's most of the time how we figure it out yeah get bisect best tool ever does that answer your question okay I don't see any hands but I will be around come ask me questions I have stickers and thank you