Don't Be A Hero: Sustainable Open Source

Slide 1

Slide 1 text

Don’t Be A Hero Sustainable Open Source Development

Slide 2

Slide 2 text

Lillie Chilen li-lee shi-leen • Hi, my name is Lillie Chilen • My last name is not phonetic, so here’s a pronunciation guide

Slide 3

Slide 3 text

@lilliealbert • You can ﬁnd me on the internet as lilliealbert

Slide 4

Slide 4 text

• I’m a software engineer at Omada Health, where we help people avoid chronic disease by supporting behavior change. • I’m super grateful to Omada for covering my ﬂight and my hotel and giving me time oﬀ to come to Atlanta to talk to y’all about open source!

Slide 5

Slide 5 text

RailsBridge • When I’m not thinking about Omada, I’m usually think about RailsBridge. • RailsBridge puts on free weekend workshops to help make the Ruby community more diverse. • We maintain open source technical curricula and an open source event management app we call Bridge Troll. • I’m currently the chair of the board. • when I’m not thinking about Omada or RailsBridge,

Slide 6

Slide 6 text

• I’m thinking about Double Union a feminist hacker/makerspace in San Francisco where I’m CTO • I maintain our membership application and management app.

Slide 7

Slide 7 text

bit.ly/unhero • You’ll be able to ﬁnd links to things I mention in the slides, which I’ll be posting at bit.ly/hero

Slide 8

Slide 8 text

What is a hero? Hero Recovery Contributor Tips • What am I going to talk about? Three big things • What is an open source hero? • Pros and cons to being a hero • Things to do to stop being a hero • Tips for people to help open source in a sustainable way

Slide 9

Slide 9 text

What is a hero? • I think of heroes in the Ruby community are a lot like …

Slide 10

Slide 10 text

• … super heroes • Some of them have special abilities that they use to make our lives better

Slide 11

Slide 11 text

• Contributing this consistently has got to be some kind of super power. • But a lot of heroes are just …

Slide 12

Slide 12 text

• regular people who started helping out, ﬁgured out how to get things done, and who we've come to depend on over time.

Slide 13

Slide 13 text

• We tend to think of heroes as people who are highly visible members of the community. • Sometimes we put them on pedestals.

Slide 14

Slide 14 text

• But there are so many more heroes who we don’t see, who are members of the crowd, who maintain the gems that we depend on, and who make working on a Rails app so great.

Slide 15

Slide 15 text

confession time! • So, I confess that I’m a bit of a hero • I am the solo maintainer of Double Union’s open source membership app • I also do a lot of heroic things for RailsBridge

Slide 16

Slide 16 text

The Upsides • And it can be pretty great! • Having heroes in our community is fantastic for the stuﬀ they make. • And being a hero has some personal upsides, too

Slide 17

Slide 17 text

• If something is broken on the Double Union app, or a new feature is needed

Slide 18

Slide 18 text

• I get to save the day • And that leaves me feeling all warm and fuzzy inside • It can also be really nice to …

Slide 19

Slide 19 text

• … ﬂy solo • I already know where everything is in the app, so I can get things done fast • I get to make all the large and small decisions for my projects • I don’t have to worry about other people breaking the build or introducing bugs. (I just have to ﬁx the bugs your past self created) • And if you make enough contributions, or get involved with the right project, some people do gain

Slide 20

Slide 20 text

• … some recognition for your eﬀorts • Who doesn’t want to be be Ruby-famous?

Slide 21

Slide 21 text

Okay, sold. Woo heroes! • So, talk done! • Let’s all be open source heroes!

Slide 22

Slide 22 text

NOPE. Unfortunately not.

Slide 23

Slide 23 text

Downsides • The #1 reason that having heroes is bad for the community, despite all the amazing work they do, is that each hero is …

Slide 24

Slide 24 text

• … a single point of failure • Silos are bad but impossible to avoid if you’re the only person working on a project. • And if no one else has commit access, your users might be kinda screwed if you disappear. • That alone is a good enough reason to stop being a hero. But heroism can really suck for the maintainer, too. • I have deﬁnitely felt …

Slide 25

Slide 25 text

• … trapped by my responsibilities on my projects where I’m the only person pushing things forward • If I leave, I worry the project might fall apart. • But if I leave and no one notices, oh no, no one cared. • And I’m left wondering what was the point of working on it in the ﬁrst place • Existential Dread for everyone!!

Slide 26

Slide 26 text

responsibility sponge • I am a responsibility sponge. • When I join a community, I work on ﬁxing whatever problems I see, • and then become responsible for whatever part I ﬁxed • Repeat this enough times on any project • And it’s …

Slide 27

Slide 27 text

• … Burnout town. It just does not work to do too much by yourself • I’ve quit RailsBridge twice in the last four years from being overwhelmed and not seeing how I could make it ﬁt in my life • With abandoned gems, often the maintainer just slows down their contributions, pull requests and issues pile up. • The maintainer asks for help but no one ever comes, so they keep half- maintaining the project, And sometimes they just silently disappear, and the users have to fend for themselves. • And that one way people burn out. But we’ve also seen visible members of the community …

Slide 28

Slide 28 text

• Just rage quit • They writes a blog post about how ruby totally sucks and they’re over it • And that’s no good, either • One distinction I should make now, though, is that

Slide 29

Slide 29 text

Not All Proliﬁc Contributors Are Heroes • Writing a lot of code for a project does not alone make someone a hero. It’s awesome to get all of things done • A hero is someone who holds up a project by themselves, who is a silo, who is necessary for the project’s existence • And this can happen because the maintainer doesn’t want other people’s help or don’t trust people to help, which is bad. • But a more common reason people become heroes is that they fall into it…

Slide 30

Slide 30 text

• by accident. • They got bitten by radioactive spider, and now they have 50 stars on GitHub and a bunch of users to talk to.

Slide 31

Slide 31 text

So You’re a Hero strategies for recovery

Slide 32

Slide 32 text

$$$ • One way to have fewer heroes in open source is to make it more people’s jobs. • Part of why people are heroes is for a lack of resources, and we’d have more people able to contribute if they could help pay their rent with open source work

Slide 33

Slide 33 text

• I’m really excited about Ruby Together, a new non-proﬁt organization supporting tools and infrastructure with cash money donated by individuals and businesses. • But if getting paid for your open source work is not an option for you right now, what else can you do?

Slide 34

Slide 34 text

Documentation Project Management Recruiting Collaborators • These are three big things you can do to make your project more sustainable • Sadly none of them is write good code, but you should do that anyway • A big part of what makes a hero is that they are the only one with the tools to solve the problem.

Slide 35

Slide 35 text

• If everyone in Gotham had a kevlar suit and a bat mobile, they wouldn’t need batman. • Documentation is one of the ﬁrst ways that you can give people the tools they need to help. • And the ﬁrst place to start is …

Slide 36

Slide 36 text

… your README, obviously • Not just how to use your library or application, but how to contribute • How to get the app running / tests passing, where you track features and bugs • And how you like to communicate (IRC, mailing list, Slack) • You probably already have some of this stuﬀ in your readme, and it can be hard to see what’s missing because you already know everything about your project

Slide 37

Slide 37 text

• So find someone who doesn’t! • At Double Union, I went through the README in detail with someone else. Useful! • Ben Balter of GitHub has a great blog post about OS collaboration, where he talks about minimizing friction for contributors. • Your documentation should greatly reduce the difficulty of contributing • Communicate your preferences (like squashed commits or specific formats for documentation) upfront • Not in one-off comments on pull requests • The next thing you need to do is

Slide 38

Slide 38 text

• Write down all the stuﬀ you do as a maintainer, because people can’t help you do things that they don’t know you do • I recently went through this exercise for RailsBridge, and came up with a long list of random tasks that I’ve accrued over the years. • A lot of them would be great responsibilities for a new contributor, but I’d been hogging them because it was easy. • Once you have this list

Slide 39

Slide 39 text

• You have to tell people that you need help with some of those things, so you can be less of a silo, and other people can get a better understanding of your project. • I admit I have not yet done this with all my RailsBridge jobs. This stuﬀ is hard. I public commit to doing this on the ﬂight back to San Francisco. • Next up:

Slide 40

Slide 40 text

Project Management Is Hard, That’s Why People Have Jobs Doing It

Slide 41

Slide 41 text

workflows matter • Your workflow matters. • When you start off by yourself, you can keep a list of future changes in your head. This is difficult for other people to find. • Drop-in teams are hard to PM • Most tools assume that people will be consistent • Lots of people start stories and never finish them • You need to find a balance between your personal preferences and what is accessible to other people

Slide 42

Slide 42 text

* For example, Bridge Troll is the RailsBridge open source event management app * We inherited a Pivotal Tracker backlog that we use for features * I do suspect that it’s not helping new people contribute, since there’s more barriers to entry. * But that’s hard to prove, and nothing else seems signiﬁcantly better, and so inertia wins … for now.

Slide 43

Slide 43 text

• On the DU app, we just use GitHub issues for everything • You can’t prioritize, but you can get creative with tags. • Issues are SUPER easy to ﬁnd but not everyone looks at GitHub issues all the time • So I send out emails to the DU mailing list with the top 5 issues I’d love help with • 2-3 of those issues end up getting picked up by someone • Bonus: features happen!! • Another piece of project management that matters a lot is

Slide 44

Slide 44 text

timing also matters • How quickly someone replies to pull requests • Mozilla did a study of contributor engagement (slide deck): • If someone receives a code review within 48 hours? They are exceptionally likely to make more contributions. • If you wait longer than 7 days: virtually zero percent chance of coming back. • Obviously challenging if you want to go camping • But you should go camping!! The solution is not to bring a hotspot to the woods, is to have more people who can review PRs so they can happen quickly

Slide 45

Slide 45 text

Recruitment • Recruiting people! • How can we actually ﬁnd these contributors and co-maintainers to share our responsibilities with? • When you’re making big feature decisions, who do you talk to? • Hopefully you get some input from …

Slide 46

Slide 46 text

• Your users!! Talking to people about changes you’re planning is a great idea • It will make the project better, but it will also • help you find people who are passionate, or maybe just • and whose opinions you find valuable • … which will then help you recruit some of those people • When I’m talking to users of the DU app, they are sometimes Rails devs but mostly not, so I have to do a bit more targeted outreach to potential contributors. This is pretty different if your project is a library

Slide 47

Slide 47 text

apps v libraries • Whereas if you maintain a library, your users are developers. probably ruby developers! AWESOME. • But most people work on apps in their day to day lives • And library development is pretty diﬀerent from application development • Sarah Mei talk at Nickel City Ruby called Multitudes where she uses Rspec as an example of how diﬀerent the internals of library are from the API that you are used to interacting with • So even contributors who use your gem will have a steeper learning curve, and that’s okay!

Slide 48

Slide 48 text

• This does hurt • Instead of writing code, I’m asking you to do all this other stuﬀ, like working on documentation and sending emails. • But! Don’t do this alone

Slide 49

Slide 49 text

• You don’t just want to become the PM on your project • You’re looking for other people to help you with EVERYTHING • coding • documentation • communicating • So that you’re not a silo for any part of your project • And when you’re recruiting people, it can be kind of scary, especially when you’ve working on an app mostly by yourself, because you don’t know if they’re going to turn out to be …

Slide 50

Slide 50 text

• evil. • But it’s much more likely, that rather than do something terrible, they just won’t do anything at all • I’ve just learned to manage my expectations of people • Which means I get really excited when people do actually do things • Because the bar is pretty low • So you’ve done this recruitment, you’ve found other people, and you have contributors

Slide 51

Slide 51 text

Then There Were Contributors

Slide 52

Slide 52 text

• And what do you do to help people once they’ve shown up? • My ﬁrst role at Double Union was as the membership coordinator, which meant a lot of spreadsheets and emails. Luckily, I’m a Rails dev, so I automated a bunch of that. • We then found a new membership coordinator, so I could focus on building tools! • The Double Union board noticed I was working hard on the app and oﬀered me the role of …

Slide 53

Slide 53 text

CTO • CTO. And I said yes! So they gave me the title & a gift certiﬁcate for a massage • This probably did reinforce some of my hero tendencies • At ﬁrst I was like “I’m the code boss”, I’m going to do all the things! • but now I’m trying to …

Slide 54

Slide 54 text

• searching for a co-maintainer and trying to build out a team, instead of doing everything myself

Slide 55

Slide 55 text

• You want to help people move from user to bug-ﬁxer, and maybe to maintainer • This is a funnel!!! • How can you help people move through this funnel? • Mozilla found that showing someone the next bug they can work on dramatically improves the odds of contributing again. • But having other people adding code and reviewing code, and maybe features getting onto master without your input does require you to …

Slide 56

Slide 56 text

let go • Let go. You might like to be in control of things • I can get things done quickly, but that just reinforces the silo I’ve built for myself, so it’s imperative that I let other people help. • Even if it’s slower than just doing it myself and even if things sometimes fall on the ground. • Non-critical bugs and smaller features should be reserved for new folks and marked as “bite-sized” in the backlog. • Getting people used to your workﬂow with smaller things means they will be more comfortable making larger contributions in the future.

Slide 57

Slide 57 text

• “Don’t lick the cookies” • When you indicate that you’re gonna work on something, no one else will pick it up, because that cookie has been licked • As a maintainer, be aware of what cookies you have licked, even unintentionally just by having expressed an opinions about how something should be done • If you ﬁnd you’ve licked a cookie, you should just let everyone know that you’re not actually working on that project, and oﬀer to give them any context they’d need to get started on it themselves

Slide 58

Slide 58 text

Retros No • RailsBridge is really good about doing retros at the end of workshops • We get feedback and ideas from volunteers and participants • But one thing we were really bad at was doing retros as any other level. We didn't have a high-level retro for the ﬁrst 2.5 years that I was involved • Any project, whether it’s your job or a volunteer gig, is going to have challenges and ineﬃciencies. • Without a regular mechanism for surfacing those things, you’re going to have problems fester that could have been dealt with, and you’re going to lose people and time and energy to the problems.

Slide 59

Slide 59 text

Now, Retros! • I’m happy to report that we retro more often now, so far mostly as a board • but I have ambitions for many more retros in the future • I think you should schedule a retro with your team right now • And if you don’t have a team, you should still take some time to reflect on what about the project is going well and what you want to change, and consider sharing that publicly — maybe it could help you find more help :D • Remember, though, that we don’t want to just reflect on what’s busted. We also want to…

Slide 60

Slide 60 text

• Celebrate people’s contributions!!! • Say thank you, even if it’s just a typo • because as the maintainer of a project, people are looking to you to determine how they should behave

Slide 61

Slide 61 text

PS: Don’t hoard the passwords • And for god’s sake, don’t hoard the passwords • If you have an app that you deploy, get a shared email address and use a password manager. • Have someone else who can publish your gem to ruby gems • (Don’t be a silo)

Slide 62

Slide 62 text

New Contributor? • If you are a new dev and want to hone your skills with open source contributions, check out Courteney Ervin’s talk this afternoon in the beginner track. • Here are some suggestions for you

Slide 63

Slide 63 text

the docs might suck • the maintainer of the project you want to help might not have been to this talk! • The documentation might be terrible! • You are UNIQUELY qualiﬁed to improve them • Please make them better!!! • This will help EVERYONE • Another thing about solo projects in particular is that they …

Slide 64

Slide 64 text

…might be a little bit weird • One person projects tend to be a little quirky since you don’t have a diversity of opinions, but that’s a very surmountable challenge

Slide 65

Slide 65 text

• I wish for all of you to know that you don’t need permission to open a pull request. If there's an open issue that you want to tackle, go for it. • Maybe open a provisional PR because it’s way easier to discuss written code than it is to talk about a potential implementation of your idea • The worst that could happen is your PR isn't accepted because someone else ﬁxed it ﬁrst, or your solution didn't match what the maintainer was looking for, and that is okay. • Well, the maintainer could be a total jerk and close your PR, but the silver lining is that you now know never to work with that project. You don’t need to work with jerks, you’re awesome.

Slide 66

Slide 66 text

• If you can, try to bring your own mentor to the project. • Show a coworker or someone at your local ruby meetup the code you’re working on and get their feedback before submitting a PR • The maintainer may not have time to be your mentor, and that's okay.

Slide 67

Slide 67 text

Guidelines for Life or at least open source happiness One thing I’d like for all of us to do is …

Slide 68

Slide 68 text

• … take a look at ourselves, and ask why we want to do this? • Current maintainers: are you still getting something out of your work? • Prospective contributors: Why do you want to work on OS? • If it’s from a vague feeling of obligation, let me tell you: you don’t have to do it. Not everyone has the bandwidth. Guilt is a terrible motivator. • But if you’ve gotten a lot from a project and you’re excited about giving back or • because you use a project and it has a bug you can ﬁx • please contribute to open source!!!!

Slide 69

Slide 69 text

(GitHub resumes are bullshit) • I really hate that employers want to see code on GitHub before they’ll interview you for a job. • This favors people who have the bandwidth to do OS contributions on evening and weekends and has the kind of annoying side aﬀect of people saying they want to help with your project and never doing it. • Employers, stop doing that.

Slide 70

Slide 70 text

This is all optional • You don’t have to maintain a project forever. • You don’t have to contribute to a project forever. • You really don’t have to do open source. • You should only do it if you want to, it’s awesome • But the ﬂip side is that

Slide 71

Slide 71 text

but also: accountability • We do 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. • We need a shared vocabulary around accountability so that people can talk about their slips and failing to do things without feeling like they are failures as people. • As a leader in the RailsBridge community, I struggle with asking people to do the things they said they would do for free, and retros really help with having a space to talk honestly about our commitments.

Slide 72

Slide 72 text

Recap

Slide 73

Slide 73 text

Silos are bad • Don’t be a Single Point of Failure • People can't stick on something forever • It’s not good for the community, the users, or the maintainers

Slide 74

Slide 74 text

We need succession planning • We should all assume that we’re going to stop working on a project some time,

Slide 75

Slide 75 text

• because you don’t know when you’re going to become indisposed in the short or long term

Slide 76

Slide 76 text

• Teams are awesome. • They can help take the burden oﬀ of you to do all the things, so you can focus on what you’re most excited about, which can take your project to way more exciting places • With less burnout

Slide 77

Slide 77 text

• And more unicorns

Slide 78

Slide 78 text

Thanks

Slide 79

Slide 79 text

PHOTO CREDITS!!! I took all the photos except these four: Wonder Woman & Photographer: https://www.flickr.com/photos/julochka/15351397147 Wonder Woman in invisible jet: https://www.flickr.com/photos/sergiorojas/15918250720 Wonder Woman carrying bike: https://www.flickr.com/photos/laura-kali/15568467339 Spider-Man: https://www.flickr.com/photos/whatleydude/13950241545 @lilliealbert / lillie.chilen@gmail.com