Don't Be A Hero: Sustainable Open Source

Burnout Prevention

Lillie Chilen

2 talks

Don't Be A Hero: Sustainable Open Source

by Lillie Chilen

In the RailsConf 2015 talk titled "Don't Be A Hero: Sustainable Open Source," Lillie Chilen discusses the challenges faced by maintainers of open-source projects and advocates for a more collaborative approach to address these issues.

Key points covered in the talk include:

- Concept of Heroes in Open Source: Chilen likens maintainers who take on excessive responsibilities to superheroes. While they make significant contributions, their elevated roles can lead to burnout and isolation due to the overwhelming pressures associated with being a sole contributor.

- Challenges of Heroism: Being a hero leads to single points of failure within projects, resulting in existential concerns for maintainers. Chilen shares her experiences with burnout and how the role of a single maintainer can lead to project stagnation or abandonment when the maintainer is unavailable.

- Resource Constraints: One significant barrier for maintainers is the lack of financial support for their work, forcing many to sacrifice personal time. Chilen highlights the organization Ruby Together as an example of a group trying to provide funding for Ruby open-source projects.

- Areas for Contribution: Chilen encourages community members to assist in areas outside of coding, emphasizing documentation, project management, and recruiting collaborators. Proper documentation can empower others to contribute, mitigating the need for individual heroism.

- Project Management: Effective project management tools and practices are essential. Maintaining clear communication and timely responses to pull requests can significantly improve contributor engagement, fostering a collaborative environment.

- Recruitment of Contributors: Engaging with users to recruit co-maintainers and contributors can distribute responsibilities and help projects grow sustainably.

- Mindful Contributions: Chilen stresses the importance of maintaining enthusiasm in contributions and discourages the notion that open-source involvement should only be a stepping stone for employment.

- Building Resilient Projects: The talk concludes with a call to acknowledge the need for shared responsibilities among contributors to prevent burnout and ensure long-term sustainability of open-source projects.

00:00:03.430 Hello everyone, welcome to RailsConf.

00:00:08.670 Let's get started on time.

00:00:11.629 My name is Lillie Chilen. My last name is a bit tricky, so here’s a phonetic guide for you: Lillie Chilen. You can find me online as Lillie Albert on various platforms. I am a software engineer at Omada Health, where we focus on helping people avoid chronic diseases through behavior change. I am grateful to Omada for covering my flight and hotel and for giving me the time to come to Atlanta to discuss open source.

00:00:31.320 When I'm not involved with projects at Omada, I usually think about RailsBridge. RailsBridge is an organization that offers free weekend workshops aimed at making the Ruby community more diverse. We maintain a set of open-source curricula and an event management application known as Bridge Troll. I am currently the chair of the board.

00:00:51.140 Aside from Omada and RailsBridge, I also spend time thinking about Double Union, which is a feminist hacker makerspace in San Francisco where I serve as the CTO. I handle our membership application and management app. At some point today, I'll provide a link to these slides, although it's not available right now.

00:01:13.930 Today, we're going to discuss three main topics: what constitutes a hero in open source, how to recover from the mantle of heroism, and tips for becoming an effective contributor.

00:01:39.570 In my view, heroes in the Ruby community can be likened to superheroes. They possess remarkable abilities, contributing consistently to benefit our lives. But often, heroes are just regular people who start helping out, figuring out how to get things done, and eventually become essential figures in our community. When we think of a Ruby hero, we might picture someone on a pedestal — a visibly prominent community member. However, many heroes work quietly behind the scenes, maintaining gems that significantly enhance the Rails app experience.

00:02:04.210 I confess that I’m a bit of a hero myself. I am the sole maintainer of Double Union's open-source membership app and undertake numerous heroic tasks for RailsBridge. While this can feel gratifying at times, it creates challenges. On one hand, it's wonderful to have heroes who do incredible work and make developing Ruby and Rails apps enjoyable. On the other hand, being a hero comes with some unpleasant aspects.

00:02:50.630 For instance, when something is broken in the Double Union app, or when a new feature is needed, I am able to swoop in and fix it because I understand the context completely. This gives me a warm, fuzzy feeling. Being a solo contributor allows for rapid progress since I know where everything is in the app, enabling me to make both major and minor decisions without needing to consult others. However, this also means I’m solely responsible for introducing bugs, which inevitably happens.

00:03:15.330 Some contributors earn a certain level of notoriety in the community — who doesn’t want to be famous in the Ruby world? But becoming a hero is not easy. There are significant downsides to taking on that role. One major issue with having heroes is that every hero represents a single point of failure. Silos are detrimental, but being the solo maintainer of a project makes them unavoidable. If a project has only one person managing it and they disappear or become unavailable, users can be left in a difficult position.

00:04:46.790 Moreover, heroism can trap the maintainers in a cycle of overwhelming responsibilities. I have felt this way in my roles, especially when pushing projects forward all alone. If I leave, I fear the project will crumble, and if it does, I worry whether anyone cares. This spirals into existential dread and sadness for everyone involved.

00:05:39.970 Personally, I tend to be a responsibility sponge. When I join a community, I take on fixing problems I observe, eventually becoming accountable for those areas. If this continues over multiple projects, it can lead to burnout. In fact, I’ve quit RailsBridge twice in the last four years due to feeling overwhelmed and uncertain about how to balance my commitments.

00:06:17.740 With Ruby gems, sometimes maintainers start slowing down their contributions as they become overwhelmed. Pull requests and issues pile up, and sometimes they ask for help but receive no assistance, leading to half-hearted maintenance of the project. It can even result in maintainers silently disappearing, leaving users to fend for themselves. You may find issues labeled with confusion about whether a project has been abandoned.

00:06:59.050 Not every prolific contributor is considered a hero. Simply writing a lot of code doesn’t designate someone as a hero in my mind. Heroes are those who hold projects together independently, who become essential for the project's survival. Sometimes this arises from a distrust of others among maintainers, which is disheartening. More often, however, heroes inadvertently fall into this role by chance, akin to being bitten by a radioactive spider which results in gaining GitHub stars and an engaged user base.

00:08:35.549 So, how can we assist and what strategies are available for recovery? Firstly, it would be beneficial if we could compensate individuals for open-source development. A significant reason individuals become heroes is a lack of resources. If developers can make a living through open-source work, they wouldn't have to sacrifice their evenings and weekends, contributing to projects that ultimately support many businesses making substantial profits.

00:09:07.650 I am particularly excited about an organization called Ruby Together, which is a new nonprofit trade organization. They are committed to supporting Ruby tools and infrastructure through funding contributed by individuals and businesses. It would be great if everyone could check them out and encourage their companies to sponsor them.

00:09:47.430 If paying for open-source work isn’t an option for you, what else can you do? There are three major areas I encourage you to consider: documentation, project management, and recruiting collaborators. While none of these activities involve writing awesome code, they are essential and should still be prioritized.

00:10:12.290 Much of what elevates someone to the status of a hero is being the only person with the solutions to problems. If everyone in Gotham had access to a Kevlar suit and a Batmobile, Batman wouldn’t be needed, but chaos would ensue. However, documentation can be a powerful tool in providing others with the means to contribute. A great starting point is your README file. It should include not only how to use the application or library but also how to contribute, how to set up the application, and how to run tests.

00:10:46.000 You should outline where to track features and bugs and indicate preferred communication channels, be it IRC, Slack, a mailing list, or a Google Group. By giving potential contributors the basics on how to start contributing, you can break down barriers. Often, maintainers already overlook elements that newcomers might need to understand. Therefore, it can be incredibly valuable to find an outsider who does not know your project. Their fresh perspective can reveal gaps in your documentation.

00:11:27.000 I went through this process with Double Union. Ben Balter from GitHub has a fantastic post on open-source collaboration that highlights the importance of minimizing friction for contributors. Everything we do should aim at reducing friction, thus encouraging people to engage and reducing the likelihood of becoming isolated.

00:12:02.310 You should communicate your preferences up front. For instance, if you prefer squashed commits or have specific formats for documentation, let others know. This approach prevents you from nitpicking their pull requests, allowing you to focus on the actual review process and not discouraging potential contributors.

00:12:49.690 Next, make a list of everything you do as a maintainer. There are probably numerous tasks that you handle that others might not be aware of, and they can’t assist unless they know what you do. I went through this exercise with RailsBridge, compiling a lengthy list of responsibilities I had taken on over the years. A lot of those duties would suit new contributors perfectly, but I’d been keeping them to myself because it was easier.

00:13:33.860 Once you compile this list, share it with others and solicit their help in managing those responsibilities. This move diminishes your silo status while allowing others to gain insight into and investment in your project. I acknowledge that I have not implemented this with my RailsBridge commitments yet. It's challenging, but I'm publicly committing to doing it during my flight back to San Francisco, so hold me accountable.

00:14:24.420 Project management is another challenging area. While people have designated jobs for managing projects, open source maintainers frequently still need to manage their projects effectively. When you start working solo, it’s manageable to track changes in your head. However, this isn't accessible to others who join later.

00:15:04.840 You will eventually need to write things down, but the project management tools available can be inadequate. They often assume consistency among contributors, which can be rare in open-source projects. While I don't have a silver bullet for addressing this inconsistency, it is important to balance your personal preferences with the accessibility for others.

00:15:56.020 We use Pivotal Tracker for tracking features in Bridge Troll, inherited from the app's creators. This tool works well for our frequent contributors, but I suspect it might hinder engagement among newcomers due to the need for permission to join. So far, nothing else we've tried has proved significantly better, so inertia wins.

00:16:57.330 On the other hand, Double Union operates completely on GitHub, making it easy to find tasks but difficult to prioritize them. I've found that sending emails to our mailing list helps. I can highlight specific issues that would benefit from additional input, and so far, this has yielded positive results.

00:17:54.560 Another vital aspect of project management involves timely responses to pull requests. Mozilla conducted a study on contributor engagement and discovered that contributors are far more likely to return if they receive a code review within 48 hours. However, if they wait longer than a week, their chances of returning drop significantly.

00:18:37.870 This can be challenging if you are a solo maintainer because you might want to take time off. It’s essential to find additional team members who can help review pull requests, preventing you from being the sole reviewer. This leads us to the question of recruitment: how do we find contributors and co-maintainers to share responsibilities with?

00:19:45.970 When making feature decisions, it’s useful to consult your users. Engaging them not only helps you shape your app but also identifies passionate individuals who might assist in your project’s development. When I engage with users of the Double Union app, I often find some are Rails developers. However, I predominantly reach out to non-developers and tech enthusiasts for targeted recruitment.

00:20:40.550 If your project is a library, your users will likely be developers — Ruby developers, to be specific. This scenario makes it easier to recruit contributors. Still, work on applications differs significantly from library development. Some developers may require additional support when shifting from application to library work.

00:21:39.830 Many may find the transition challenging, and this is perfectly okay. Additionally, it’s good to keep in mind that newcomers don’t necessarily need permission to contribute — if an open issue excites them, they should feel free to work on it.

00:22:25.760 I encourage everyone to provide feedback before submitting their PRs by utilizing mentors or co-workers. Saving maintainers from the initial steps of feedback can be a valuable contribution. Here are some general guidelines to foster happiness in both life and open source.

00:23:05.560 We should regularly introspect to understand our motivations for contributing or maintaining a project. If you currently maintain a library, ask yourself: are you still deriving joy from it? If you aim to contribute, ensure it's driven by enthusiasm or a desire to give back, rather than a vague sense of obligation.

00:23:50.700 The notion that one must be involved in open-source projects to secure employment is damaging. Not everyone possesses the luxury of time to contribute, and such pressures disproportionately affect those who can dedicate time only during evenings and weekends. Additionally, individuals sometimes arrive wanting to work on open source primarily for job prospects rather than a genuine interest.

00:24:41.780 If employers could stop imposing this expectation, it would be a tremendous help. Remember, involvement in open source is not a burden nor a lifelong commitment. It's perfectly acceptable to join for short periods or depending on interest.

00:25:16.540 However, accountability remains crucial for the sustainability of projects. We must discuss what happens when goals aren’t met without trivializing individual contributors' experiences.

00:25:59.350 This expectation is vital when working with volunteers, as I often encounter guilt when a deadline is missed. To mitigate this, creating retrospectives where honest, candid discussions about project issues can flourish will contribute to reducing heroism in favor of teamwork. Team collaboration allows for shared responsibility that can lead to resilient projects.

00:26:53.790 To summarize: silos are harmful. We should avoid creating single points of failure and develop succession strategies. Teams are indeed beneficial; they distribute responsibilities and allow maintainers to focus on what truly excites them. This promotes a healthier project environment, minimizing burnout.