 Welcome to RailsConf. Let's just, like, start on time, I guess. That'll be exciting. My name is Lily Shaline. My last name is in no way phonetic, so here's a little guide for you. Lily Shaline. Very strange. You can find me on the internet as Lily Albert in all the places. I'm a software engineer at OMADA Health, where we help people avoid chronic disease by supporting behavior change. And I'm really grateful to OMADA for covering my flight and my hotel and giving me time off to come to Atlanta and talk to y'all about open source. When I am not thinking about things at OMADA, I'm usually thinking about RailsBridge. RailsBridge is an organization that puts on free weekend workshops to help make the Ruby community more diverse. We maintain a set of open source curriculums and an event management app that we call BridgeTroll. I'm currently the chair of the board. And when I'm not thinking about OMADA or RailsBridge, I'm usually thinking about Double Union, which is a feminist hacker-maker space in San Francisco, where I'm the CTO. And I maintain our membership application and management app. So at some point today these slides will be at this bit.ly, but they're not there now. Right now it's just linking to, I don't know what it's linking to. So check that out later. So what are we going to talk about? Three big things. What is a hero in open source? How to recover from being a hero in open source? And tips for being a contributor. So what is a hero? I tend to think of heroes in the Ruby community as being a lot like superheroes. Some of them have, like, special abilities that they use to make our lives better, like contributing so much, so consistently, has got to be some kind of superpower. Right? But a lot of heroes are just regular people who started helping out, figured out how to get things done, and who we've come to depend on over time. When you first think of, like, a Ruby hero, you think of someone who's up on a pedestal, someone who's a highly visible member of the community. But a lot of our heroes are actually members of the crowd. They're people who maintain gems, who make working on a Rails app so great, and you don't necessarily see them a lot. So quick confession. I am a little bit of a hero. I am the sole maintainer of Double Union's open source membership app, and I do rather a lot of different heroic things for Rails Bridge. So this is kind of great sometimes for me. It's pretty great for the community. Like, we have these heroes that do so much stuff and make writing Ruby and Rails apps so wonderful. And there are some upsides for the heroes as well. So when something's busted for the Double Union app or we need a new feature or something, I can swoop in and I have all of the context in the world and I can help out. And that leaves me feeling all warm and fuzzy and it's great. It can also be really nice to work by yourself because you kind of fly solo. You already know where everything is in the app so you can get things done quickly. I get to make large and small decisions for my projects without necessarily getting other people's input. And I don't have to worry about other people breaking the build or introducing bugs. I pretty much just have to worry about myself introducing bugs, which I do. And if you make enough contributions or get involved with the right project, sometimes people do gain some notoriety in the community. Like, who doesn't want to be Ruby famous? So, we're all going to be heroes. Let's do it right now. No, sorry. It's not that easy. There are some real downsides to being a hero. And I think the number one reason that having heroes is bad for our community is that despite all of the amazing work they do and how much gets produced, every single hero we have is a single point of failure. Silo's are really bad and we know that, but they're impossible to avoid if you're the only person working on your project. And if nobody else has commit access, your users might be kind of screwed if you disappear or get eaten by a dinosaur. So, that alone, I think is a good enough reason to stop being a hero. But heroism can also really suck for the maintainer. I've definitely felt trapped by my responsibilities, especially on projects where I'm sort of the only person pushing things forward. If I leave, I worry that the project might fall apart. And then I worry that if I leave and the project falls apart and nobody cares, then what was the point in the first place? And then it's just existential dread and everyone's sad. So, how do I get here? I personally am a responsibility sponge. Like, when I join a community, I work on fixing whatever problems I see and then I end up becoming responsible for the pieces that I fixed. And if you repeat this enough time on any project, it's burnout town. So, it just doesn't work to do too much by yourself. I've actually quit Railsbridge twice in the last four years from being overwhelmed and not seeing how I could make it fit in my life. And when we use gems, sometimes the maintainer just kind of slows down their contributions, pull requests and issues pile up. And sometimes the maintainer will ask for help and nobody ever comes. And so they sort of keep half maintaining the project. And sometimes they just silently disappear and the users have to fend for themselves and you see an issue that's like, hey, this seems abandoned. Do we still, what do we do about that? So, that's quietly is a way that people burn out. But we also have visible members of the community who just rage quit. They just write a blog post about how Ruby totally sucks and they're over it and that's really no good either. One distinction, though, that I'd like to make is that not all prolific contributors are heroes, right? Writing a lot of code doesn't make someone a hero. It's awesome that people get things done. When I think about heroes, there are people who hold projects up by themselves. There are people who are silos, who are necessary for the project's existence. And sometimes it happens because the maintainer doesn't want other people's help or doesn't trust other people to actually give contributions. And that's terrible. But I think a more common reason that people become heroes is that they just kind of fall into it by accident. You're bitten by a radioactive spider and now you have 50 stars on GitHub and a bunch of users to talk to. So what can we do to help? What are some strategies for recovery? First off, I think it'd be really great if we paid people to do open source development. I think part of why people are heroes is for a lack of resources. And we would have more resources if people could actually pay their rent with open source work. If people didn't have to spend their evenings and weekends supporting open source, which then supports lots and lots of businesses making lots and lots of money. One organization I'm super excited about is new and it's called Ruby Together. It's a new non-profit trade organization, a 501C6 apparently. And they are supporting the Ruby tools and infrastructure with money donated by individuals and businesses. So you should totally check them out and get your companies to sponsor because they're pretty rad. So for you though, if getting paid to do open source isn't an option for you, what else can you do? So three big things that I would encourage you to think about are documentation, project management, and recruiting collaborators. Sadly, none of these things is right awesome code, but you should totally do that anyway, because that's why we're here. A big part of what makes a hero is that they're the only one with the tools to solve the problem. If everybody in Gotham had a Kevlar suit and a Batmobile, they wouldn't need Batman, but things would probably be a lot worse. So documentation though is one of the ways that you can give people the tools that they need to help. And the first place to start I think is kind of obvious, you read me. So you shouldn't just include how to use your library or your application, but also how to contribute. How to get the app running and the test passing, where you track your features and bugs, how you'd like to communicate if you use IRC or Slack or you have a mailing list or a Google group, giving people the basics to actually start contributing. And you probably already have some of the stuff in your read me. And it can be hard to see what's missing because you already know your project like the back of your hand. So what you do next is you find someone who doesn't know your project. I went through this with double union but not with a hippo and it was incredibly useful to get some fresh eyes on my read me and see what I was missing. Ben Balter of GitHub has a great post about open source collaboration that I'll link to in the notes for this. But one thing that stuck out from that to me was this idea of minimizing friction for contributors. So everything that we're doing here is trying to minimize friction so that people can get involved and you can not be as much of a silo. So your documentation can help with that a lot. You want to communicate your preferences like if you like squashed commits or specific formats for documentation, letting people know up front so that you're not just nitpicking their pull requests and you can focus on actually doing code review and pull requests can be really helpful because you don't want to disenfranchise people who are excited about your project. The next thing that you need to do is write down everything you do as a maintainer. There are probably a lot of things that you do that nobody knows about and nobody can help you do the things that they don't know you do. I actually recently went through this exercise with Railsbridge and I found this long list of random tasks that I'd sort of accrued over the years and a lot of them would be great responsibilities for a new contributor but I've just been hogging them because it was way easier. So once you have this list you can share it with people and ask for help with some of these things. So you can be less of a silo and other people can get a better understanding and more invested in your project. I admit I have not actually done this with my Railsbridge jobs. This stuff is hard but I'm publicly saying I'm going to do it on the flight back to San Francisco. So hold me to that. Next up, project management is hard and that's why people have jobs doing it but unfortunately we still have to do it. The workflow you use for your project matters. When you start off by yourself you can kind of keep a list of future changes in your head. This unfortunately is very hard for other people to access so you start writing things down but the tooling for this is not great. Most of the project management apps kind of assume that people will be consistent and open source projects often have completely inconsistent sets of contributors and so I do not have a silver bullet for that but you do need to find a balance between sort of your personal preference and then what is accessible to other people. On Bridgetroll we use Pivotal Tracker to keep track of our upcoming features and we inherited it from the people who started the app and it works pretty well because the people who do most of the contributing like tracker and use it and I have suspicions that it's not helping people get involved because they do have to kind of ask permission to be part of the team so we can hit the start button and then maybe that's that hurdle is too great but so far nothing else that seemed significantly better and inertia wins so on double union we use github for everything which means we can't prioritize anything but we can get creative with tags and it's great because it's super easy to find but not everybody is looking at github issues proactively so what I found helps is just emailing out the mailing list and saying like hey these are five issues that it would be great to get some help with and so far it's worked like people have picked up issues and then I know people that I should sort of like try to convince to do more things another piece of project management that is critical is the timing that you have when you reply to people's pull requests Mozilla did a study of contributor engagement and they found that if somebody receives a code review within 48 hours they were exceptionally likely to come back and make more contributions but if someone had to wait longer than seven days there was almost no chance that they were going to come back and give another contribution so this is obviously challenging if you're a solo maintainer because maybe you want to go camping for three days or four days and now the PR is sitting there but you should totally go camping you should not like bring your laptop with you and your Wi-Fi hotspot so you can respond to pull requests you really instead want to find other people who can help review those pull requests so that you're not the only person doing that which brings us to recruitment how can we actually find like these fabled contributors and co-maintenors to share our responsibilities with people we trust and no will help our project grow and succeed when you're making big feature decisions or just any feature decisions like who do you talk to hopefully you do get some input from your users talking to people is generally a good idea when you're making changes in the app but it has this wonderful side effect of letting you helping you find the people who are passionate about your project or maybe just slightly interested and whose opinions you find valuable and then you can try to recruit some of those people to help you when I'm talking to people who use the double union app there sometimes rails developers but mostly not so I have to do a little bit more targeted outreach to potential contributors which is pretty different if your project is a library if you maintain a library your users are obviously developers and they're probably Ruby developers which is awesome because it means all of your users are potential contributors but most people do work on apps in their day to day lives at work and library development can is pretty different from application development Sarah may actually gave a talk at nickel city Ruby that I'll link to in the notes called multitudes where she uses our spec as an example of how different the internals of a library are from its API and so there's a steeper learning curve for application developers when they're working with a library for the first time so keep in mind that even people who are have been professional rails devs for a while might might need a little bit more support as they get started helping with your library and that's okay so all of this can sound pretty painful instead of writing code I'm asking you to do all of this other stuff this documentation and like maybe emailing people but I actually really don't want you to do this by yourself I want you to not just become the PM of your project but find someone else to share all of these terrible responsibilities with right you want other people to help you with coding and documenting and communicating so that you're not a silo for any part of the application and when you are recruiting people it can be scary if you're working on an app that you're really invested in you don't know if someone's going to turn out to be evil right like they could be actually evil and try to ruin your app but it's much more likely I found that people will just not do anything at all they'll like show up and talk to you and then disappear so in open source I've generally just learned to manage my expectations of everyone which means it has the plus side I get really excited when anyone does anything so the bar is kind of low when you've done recruitment and you found other people and you have contributors what can you do to sort of help them grow in your project I first started at double union as the membership coordinator which meant that I had like all these spreadsheets and I had to write emails to people and I had to do all these things that were very obviously good for computers to do and luckily I'm a Rails developer and we had a Rails app so I was like oh I will just add features to make my job easier and it was awesome to the point that I was like hey what if I never email anyone and I can just focus on writing code and building tools and so I became I just worked on that somebody else got to be the membership coordinator it was great the board of double union noticed that I was like working really hard on the app and they actually gave me the role of CTO and I was like whoa that's awesome they gave me a title and a gift certificate for a massage and I was like that's awesome but unfortunately it did somewhat reinforce my heroic tendencies because I'm like I'm the boss of the code this is awesome I'll do everything but after you know a year or so of doing that I've now shifted and I'm trying to find someone to be a co-maintenor and I'm trying to build out a team instead of doing everything myself so you want to help people move from using your application or your library to maybe like helping fix bugs to maybe adding a feature and then a small small minority of them maybe could become co-maintenors there is a funnel right and how can you help people move through this funnel Mozilla in that same study found that showing someone the next bug that they could work on would dramatically improve the odds of them contributing again so just giving people a little bit of direction and encouragement can go a long way but having other people adding code and reviewing code and maybe things are getting onto master without you seeing them does require you to let go you might be like me you might really love being in control of things I really I know I can get things done quickly but that just reinforces the silo that I've built for myself so I try to remind myself that I have to let other people help even if it's lower and even if sometimes things fall on the ground even if some things don't go well I would suggest maybe non-critical bugs or features that are not super super high priority that are simpler can be reserved for new folks and marked as bite-sized in your backlog because getting people used to your workflow with smaller things means they'll be more comfortable making larger contributions in the future one of the things I learned from some folks at double union with this amazing phrase don't lick the cookies I don't know if you've heard of it before and it's the idea that like when you're working on a project with someone if you say you're going to do a thing and then you don't do it you have just licked the cookie and then just put it back on the table and that's like really gross so try to not lick the cookies as a maintainer it's especially easy because people hear you say like oh I have an opinion about this thing and even if you didn't say I am doing this definitely they might think oh well lilies got that she obviously cares she'll take care of it and so it's imperative that I if I notice that I have looked at cookie to let everybody know like hey I am not going to do that thing like I'm definitely not please take care of it I can give you context if you need it but please take it and run one thing Railsbridge is really good about doing is retros retrospectives are kind of regular meetings to look at your process and figure out sort of what's working and what's not and we do this at the end of most workshops and we get really great feedback from volunteers and participants and we grow a lot just knowing how the workshop went for people one thing that we're really bad about is ever doing them in any other context like I was volunteering with railsbridge for like two and a half years before we did any retros whatsoever and like any project whether it's like your job or a volunteer gig there's going to be challenges and they're going to be inefficiencies and without a regular mechanism for surface surfacing those problems will fester and things that you could have dealt with really effectively early on will become much bigger deals if you don't find out about them early and so you're going to lose time and people and energy to problems if you don't surface them so happy to report now we're doing more retros so far mostly as the board but I have ambitions for many more retros in the future and I think you should probably go schedule a retro with your team like now ish right after this maybe and if you don't have a team if you're working on a project by yourself you can have your own retro you can sit down and think about yours or what's going well for this project what do I want to change and maybe you could share the results of that publicly maybe it could help people know that that you do need more help but we don't just want to reflect on what's busted we also want to be celebrating people's contributions I love this so saying thank you like regularly and letting people know how you value them on your project can go a long way so even if it's just someone opening an issue to let me know that there's a typo or a dead link in a railsbridge curriculum I thank them either way like I am so grateful that people are helping improve this stuff and especially as the maintainer of a project or a leader in a project people are actually looking to you to determine how they should behave and so you can like lead people to be more awesome if you're awesome yourself and just a quick kind of housekeeping thing just don't hoard the passwords just like really if you have an app that you deploy get a shared email address get a password manager have somebody else who can publish your gem right because it's like you're not going to be around forever so sorry it's more positive things you're a new contributor you should totally do it and also there's a talk this afternoon all about this this afternoon Courtney Irvin is giving a talk in the beginner track and you should totally check it out but here's some suggestions anyway the docs might suck the docs will probably suck the maintainer of the project might not have been to this talk maybe but the good news is that you are uniquely qualified to help improve those docs because you do have these fresh eyes so please help make them better even though it might seem trivial like to make a text change and open up a pull request that's like all I did was change the text and the read me to make more sense that is incredibly useful and you are providing a gift for all future people who are using that library another thing about solo projects in particular is that they can be a little weird one person code can just like not always like it gets quirky right like if you don't have other people sort of contributing and sort of evening out things then the style can be weird so that's okay totally surmountable challenge one thing I wish that people thinking about contributing to open source new was that you totally don't need permission to open a pull request if there's an open issue and you want to tackle it just go for it you don't have to comment you can comment on the issue and say like I'm going to work on this but if you're me you're just not going to believe them because no one ever does that but you can open maybe a provisional pull request you can be like hey this is what I was thinking this is the direction I'm going in because it's a lot easier to talk about written code than discuss sort of like a potential implementation of an idea and if you do open a pull request on a project the worst thing that could happen is that like it isn't accepted because somebody else fixed it or the solution wasn't quite what the maintainer was looking for and hopefully they're going to give you some feedback or like the worst worst thing that could happen if the would be the maintainer would be a total tool and like say something really rude and like close your pull request but the silver lining there is that you know never to use that library again because you don't need to work with jerks because you're awesome another idea for contributors is to bring your own mentor to the project show a co-worker or someone at your local Ruby meetup the code that you're working on and get their feedback before submitting the PR so you're going to be helpful to get a little feedback first because the maintainer might not have time to be your mentor and if you can kind of save them the first couple cycles of feedback that's also a huge gift so here are some general guidelines for life or maybe open source happiness one thing that I would like all of us to do is take a look at ourselves and ask why we want to do this if you're currently maintaining a project are you still getting something out of your work are you still enjoying maintaining your library and if you're a prospective contributor why do you want to work on open source if it's out of like this vague feeling of obligation let me just tell you just you don't have to do it like you are not obligated to work on open source not everybody has the bandwidth and I think that guilt is a pretty terrible motivator but some great motivators are like you use a project and it has a bug and you can fix it or you got something out of your project and you really want to give back so if that's the case please please contribute to open source side note github resumes are bullshit right this idea that people have to contribute to open source in order to get jobs at places just completely it's really irritating not everybody has time to do this and this kind of practice totally favors people who have like a bunch of free time on the evenings and weekends to make contributions to open source and it also has this annoying side effect of people showing up being like I want to work on open source but they don't really want to work on open source they like want to get a job and they think that this is one of the prerequisites so if employers could just stop doing that that would be really great thank you because this is all optional you don't have to maintain a project forever you don't have to contribute to a project forever you don't have to do open source but you totally should because it's totally awesome if you want to the flip side of how optional it is is that we need accountability if we're going to make projects sustainable we need to know what happens when someone doesn't do the things they said they would and this is inevitable we need a shared vocabulary around accountability so that people know how to talk about it when they slip up and they totally fail to do something but you don't want them to feel like they're a failure as a person just because they failed to complete a task I think this is one of the things that can be most hard about working on teams because as a leader in the Railsbridge community I know that everyone's a volunteer and so I feel pretty guilty when somebody misses a deadline and I'm like hey that thing you're not getting paid to work on do you think you could finish it and so it's very important to sort of be upfront and I think retro's can totally come in handy when you have a space that everyone's just expected to be honest because part of not being a hero is like not fixing things every time they go wrong it's having a team that can handle failures and sort of keep going so to recap silos are bad we don't want people to be single points of failure they can't stick on projects forever it's not really it's not silos aren't good for the community or the users or the maintainers because we need succession planning we should all assume that we're going to stop working on a project at some point because we have no idea when we might become indisposed in the short or long term teams are awesome they can help take the burden off of you to do all the things so you can focus on what you're most excited about which can then take your project to like way more exciting places with less burnout and more unicorns thank you