Don't Be A Hero: Sustainable Open Source

We know that low bus numbers, silos, and grueling hours can make hiring a dev nigh impossible. So why are bad conditions accepted as facts of life for open source software maintainers? Let's stop.

This talk is about how maintainers can become leaders instead of heroes, techniques for building an awesome team for your project, and the ways that everyone else can jump in and support open source software in an effective and sustainable way.

Here are links to various things I mention in the talk:

* Ruby Together: https://rubytogether.org/
* Ben Balter on OS best practices: http://ben.balter.com/2015/03/17/open-source-best-practices-external-engagement/
* Mozilla contributor research deck: https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g4435d357b_20
* Sarah Mei talking at Nickel City Ruby about the differences between app and library development: http://confreaks.tv/videos/nickelcityruby2014-keynote-multitudes

And things I do:
* Omada Health: https://omadahealth.com/
* RailsBridge: http://railsbridge.org/
* Double Union http://www.doubleunion.org/

Additionally, in the Q&A for this talk, we discussed taking over an abandoned project. There's a great talk by Daniel Doubrovkine from GoGaRuCo2014, check it out:
https://www.youtube.com/watch?v=8ijzefV-B7U

Transcript

1. Don’t Be A Hero Sustainable Open Source Development
2. Lillie Chilen li-lee shi-leen • Hi, my name is Lillie Chilen • My last name is not phonetic, so here’s a pronunciation guide
3. @lilliealbert • You can find me on the internet as lilliealbert
4. • 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 flight and my hotel and giving me time off to come to Atlanta to talk to y’all about open source!
5. 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,
6. • 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.
7. bit.ly/unhero • You’ll be able to find links to things I mention in the slides, which I’ll be posting at bit.ly/hero
8. 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
9. What is a hero? • I think of heroes in the Ruby community are a lot like …
10. • … super heroes • Some of them have special abilities that they use to make our lives better
11. • Contributing this consistently has got to be some kind of super power. • But a lot of heroes are just …
12. • regular people who started helping out, figured out how to get things done, and who we've come to depend on over time.
13. • We tend to think of heroes as people who are highly visible members of the community. • Sometimes we put them on pedestals.
14. • 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.
15. 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
16. The Upsides • And it can be pretty great! • Having heroes in our community is fantastic for the stuff they make. • And being a hero has some personal upsides, too
17. • If something is broken on the Double Union app, or a new feature is needed
18. • I get to save the day • And that leaves me feeling all warm and fuzzy inside • It can also be really nice to …
19. • … fly 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 fix the bugs your past self created) • And if you make enough contributions, or get involved with the right project, some people do gain
20. • … some recognition for your efforts • Who doesn’t want to be be Ruby-famous?
21. Okay, sold. Woo heroes! • So, talk done! • Let’s all be open source heroes!
22. NOPE. Unfortunately not.
23. Downsides • The #1 reason that having heroes is bad for the community, despite all the amazing work they do, is that each hero is …
24. • … 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 definitely felt …
25. • … 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 first place • Existential Dread for everyone!!
26. responsibility sponge • I am a responsibility sponge. • When I join a community, I work on fixing whatever problems I see, • and then become responsible for whatever part I fixed • Repeat this enough times on any project • And it’s …
27. • … 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 fit 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 …
28. • 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
29. Not All Prolific 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…
30. • by accident. • They got bitten by radioactive spider, and now they have 50 stars on GitHub and a bunch of users to talk to.
31. So You’re a Hero strategies for recovery
32. $$$ • 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
33. • I’m really excited about Ruby Together, a new non-profit 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?
34. 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.
35. • If everyone in Gotham had a kevlar suit and a bat mobile, they wouldn’t need batman. • Documentation is one of the first ways that you can give people the tools they need to help. • And the first place to start is …
36. … 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 stuff in your readme, and it can be hard to see what’s missing because you already know everything about your project
37. • 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
38. • Write down all the stuff 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
39. • 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 stuff is hard. I public commit to doing this on the flight back to San Francisco. • Next up:
40. Project Management Is Hard, That’s Why People Have Jobs Doing It
41. 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
42. * 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 significantly better, and so inertia wins … for now.
43. • 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 find 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
44. 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
45. Recruitment • Recruiting people! • How can we actually find 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 …
46. • 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
47. 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 different from application development • Sarah Mei talk at Nickel City Ruby called Multitudes where she uses Rspec as an example of how different 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!
48. • This does hurt • Instead of writing code, I’m asking you to do all this other stuff, like working on documentation and sending emails. • But! Don’t do this alone
49. • 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 …
50. • 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
51. Then There Were Contributors
52. • And what do you do to help people once they’ve shown up? • My first 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 offered me the role of …
53. CTO • CTO. And I said yes! So they gave me the title & a gift certificate for a massage • This probably did reinforce some of my hero tendencies • At first I was like “I’m the code boss”, I’m going to do all the things! • but now I’m trying to …
54. • searching for a co-maintainer and trying to build out a team, instead of doing everything myself
55. • You want to help people move from user to bug-fixer, 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 …
56. 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 workflow with smaller things means they will be more comfortable making larger contributions in the future.
57. • “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 find you’ve licked a cookie, you should just let everyone know that you’re not actually working on that project, and offer to give them any context they’d need to get started on it themselves
58. 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 first 2.5 years that I was involved • Any project, whether it’s your job or a volunteer gig, is going to have challenges and inefficiencies. • 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.
59. 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…
60. • 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
61. 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)
62. 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
63. 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 qualified to improve them • Please make them better!!! • This will help EVERYONE • Another thing about solo projects in particular is that they …
64. …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
65. • 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 fixed it first, 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.
66. • 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.
67. Guidelines for Life or at least open source happiness One thing I’d like for all of us to do is …
68. • … 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 fix • please contribute to open source!!!!
69. (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 affect of people saying they want to help with your project and never doing it. • Employers, stop doing that.
70. 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 flip side is that
71. 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.
72. Recap
73. 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
74. We need succession planning • We should all assume that we’re going to stop working on a project some time,
75. • because you don’t know when you’re going to become indisposed in the short or long term
76. • 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 take your project to way more exciting places • With less burnout
77. • And more unicorns
78. Thanks
79. 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