00:00:06.000
Hello RailsConf! Welcome to my talk titled 'Why I'm Closing Your GitHub Issue.' Today, I'm going to talk about stress and open-source projects, focusing on what maintainers can do to avoid burnout and stay motivated.
00:00:20.699
A little about my background: my name is Henning, and I lead development at Makundra, a Ruby consultancy based in Germany. We build and host bespoke web applications and maintain very old versions of Ruby on Rails for our Rails RTS service. I spend most of my day training junior developers and maintaining our toolchain.
00:00:44.520
Like most development teams, we have a kit of Ruby gems and npm packages that we use in our daily work. Rails apps, in particular, use a lot of open-source components. For instance, I've pulled some numbers from a few applications that we built over the last few years. We use around 200 Ruby gems and around 900 npm packages for every single project we release.
00:01:18.240
And who built these packages? That is us, because when people talk about the open-source community, they usually mean everybody. There are several great reasons to start an open-source project. First, it's a fantastic way to learn about a domain or a programming language. You may also have a strong mission for a solution that you want to share.
00:01:35.940
Some people find joy in crafting software just the way they think is right without any customer requirements. Others contribute to open source to enhance their resume. While that's not a requirement for landing a job, it certainly helps to stand out. You may be craving recognition from your peers rather than your boss or customers. For some, there are overlaps between their open-source projects and their day jobs, allowing them to help their work teams.
00:02:07.139
However, one motivation that isn't great is the pursuit of money, which only works for a very select few individuals. Over the past ten years, I've invested a lot of time in open-source projects, launching around 25 projects. Not all of them are still active, but many remain important. This chart illustrates how I've felt about my open-source work over time.
00:02:48.540
The horizontal axis is time, while the vertical axis represents mood—the higher, the better. This neutral line indicates my feelings, and you can see my mood fluctuating. Initially, when I built my first library, it was a lot of fun. I enjoyed doing everything my way, and releasing something for the first time felt exhilarating.
00:03:09.240
You may even receive a few GitHub stars, which represent the smallest unit of recognition in our community. The highlight comes when people start using your project and the download numbers increase; it feels amazing the first time it happens. However, this experience often leads to your first GitHub issue.
00:03:45.500
When someone reports a problem with your library, you might think, 'Okay, I guess I'll fix it for them.' But then, you start receiving more and more issues, and eventually, you realize that you've got a second job on your hands—one alongside your regular job.
00:04:19.580
This shift can be overwhelming, and I refer to the low point in that experience as the 'dark zone.' It's a place people can slip into, but if you stay there too long, you risk burning out. Open-source maintainers often have a predisposition to burnout because their work connects to passion.
00:04:40.500
No one forces you to work on open source; you choose to do it out of intrinsic motivation. However, driven individuals don't always recognize when they're giving more than they have to give. I've learned that publishing an open-source project is just the beginning.
00:05:03.600
GitHub has this 'New Issue' button, which makes it easy for anyone to send emails directly to your inbox, resulting in an unending flood of issue notifications that can be draining. Not all issues are polite; you may encounter rude or entitled people. They're not the majority, but they can sap your energy significantly.
00:05:46.740
If you find yourself struggling, know that you are not alone. Here’s a tweet from Brian J. Brennan expressing his experience: he feels a mix of panic, guilt, and shame every time he sees an email from GitHub in his personal inbox. This feeling is common for developers who hesitate to post their work due to the fear of perpetual support responsibilities.
00:06:02.940
Here's another relevant tweet from Aaron Patterson—who many of you might know as the keynote speaker at this conference. Aaron stated that user entitlement is a significant source of burnout for him with open-source projects. He struggles with how to deal with this entitlement efficiently and ends up either needing to put in a lot of effort to say no or he reluctantly agrees.
00:06:36.960
Six years ago, I found myself in the same dark zone, feeling grumpy about GitHub issues at night and on weekends. When people asked me what was wrong, I often replied, 'Oh, nothing.' However, my demeanor reached a point where I had to change my approach or stop entirely. Before quitting, I decided to try once more—this time, on my own terms. To my surprise, this strategy worked.
00:07:40.740
What worked for me may also help some of you. I gave myself permission to be a bit self-serving and allowed myself to focus my open-source time on projects that genuinely motivated me—those that energized me. Earlier, we discussed various motivations for contributing to open source; not all of them apply to me.
00:09:27.540
For my current project, I have a strong vision that gives me direction. If that vision motivates me, I should invest more time into things that align with it. I tend to be a perfectionist and enjoy tackling challenging problems to produce precise solutions, so I should prioritize projects with elegant or intriguing implementations.
00:09:50.260
Also, there are overlaps between my open-source work and my job. I want my team to succeed with the tools I build at work, so I should put more effort into things that benefit both my work environment and my projects. Once you identify your priorities, you must stop taking on projects that don’t align with your goals.
00:10:36.500
Time is limited, and doing one thing means not doing another. While you may have a lot of time when you're young, family and work responsibilities increase as you age, making it essential to prioritize effectively. Choosing not to engage looks like closing GitHub issues without making changes—something I had to learn.
00:11:23.160
I have a list of issue types I would have dealt with in the past but now simply close. For example, if you propose a feature but are not willing to do the work, I will close the issue. If you discover an edge case that doesn't affect me or most of my users, I will also close it. Additionally, I will no longer write tests for your pull requests if they are missing; I do need tests to maintain the project.
00:12:18.000
If you haven't communicated with me and suddenly send a large pull request with a feature I don't need, I'll close it without merging it. Although closing issues may sound rude, I always strive to be polite and clear about my limitations.
00:12:30.800
It's not easy to close issues because it often requires saying no. Saying no is challenging compared to just agreeing, but we can learn from those who excel in this area. One such person is Sam Stevenson. He works at Basecamp, and those familiar with Ruby have likely benefited from his contributions.
00:13:01.180
Five years ago at RailsConf, Sam presented TurboLinks, which accelerates page loads in web applications and includes native app adapters. After the presentation, an audience member asked about Windows Phone support. Sam replied that he didn't have plans to support it, but if someone wanted to contribute, they could look at how the iOS and Android adapters were built.
00:13:36.480
His response demonstrates important principles: first, he set clear boundaries that he wouldn't do the work himself. Second, he offered actionable advice to help the audience member find a way to do it on their own. Lastly, he remained polite and encouraging, making him a great example of how to handle feature requests.
00:14:16.800
To practice a similar approach, I created an app called Superclock, a terminal clock with a retro aesthetic. If I receive an issue requesting a 12-hour format feature from a user named Fubar, my response would be to acknowledge that while I don’t need the feature myself, it could be beneficial, and I would invite Fubar to create a pull request.
00:15:10.200
If I ask Fubar to prepare a pull request, often, they will end up doing it. Surprisingly, even if they didn't initially offer, many people are willing to help when asked. However, in most cases, you might never hear from them again if they don't intend to contribute; in that situation, I would keep the issue open for a while before ultimately closing it if there’s no response.
00:15:53.160
Receiving an issue about Oracle Enterprise Time server unsupported from architect 64, I would decline to build an integration with Oracle products since I have no intention to use them or complicate my project. I would reply honestly that this isn't a priority for me and suggest the individual fork the repository and implement the changes themselves.
00:16:38.760
Dealing with a pull request that changes my entire repository often feels awkward, especially when the contributor has put in considerable time and effort. In such cases, I may want to thank the contributor for their work but must remember to maintain my project's integrity by rejecting the PR if I don't want to shift the technology stack.
00:17:29.080
Through these experiences, I've found that it’s acceptable to ask users to address their issues. You can close issues without requiring permission; you don’t have to wait until the user feels it's acceptable. Lastly, rejecting changes that you do not want is part of the responsibility—since you are the one who needs to maintain these projects.
00:18:31.080
You might wonder if I'm still utilizing GitHub issues. I don’t close everything; instead, I still see a purpose for them. I use them to discuss whether a feature fits the library and aid contributors in making the best pull requests possible. I’m here to help; however, part of growing is that you need to learn to drive your contributions.
00:19:10.480
Reflecting on my mood curve, it initially dipped into the dark zone, but once I aligned my work with my motivations, I started to see progress. Although I've nursed my feelings about open source, I'm now more energized by my projects than before.
00:19:56.480
If you’re feeling worn down by your open-source projects, I hope to provide some ideas for improvement. Everyone uses open source every day, and it can be frustrating when you've raised an issue only to see it ignored. I’ve experienced this frustration myself.
00:20:39.120
There are strange internet traditions where people poke fun at older GitHub issues that have remained unresolved. These comments reveal much more about the commenters rather than about the projects themselves. It's crucial to understand that an issue is simply a request for change and not a work order for the maintainer.
00:21:34.020
Open-source maintainers do not work for anyone. An issue isn’t a guarantee that a change will occur nor is it a deadline. If you want your requests met, be friendly and persuasive, offer help, or be prepared to do the work yourself.
00:22:06.480
When interacting with open-source communities, it is essential to understand that while they might not have issues, they may still be using and benefiting from your projects. Therefore, I encourage you to express gratitude to open-source maintainers.
00:22:59.960
Go through your gem file, select a gem you’ve successfully used, and open an issue thanking the maintainer for their work. You might be surprised by how much that simple acknowledgment will brighten their day, even if they close it with a smile afterward.
00:23:53.520
Thank you, RailsConf! It’s been wonderful to speak to you today. If you'd like to follow me, my handles on Twitter and GitHub are available. I want to take this opportunity to briefly pitch my open-source project called Anpoli. It's an unobtrusive JavaScript framework for server-side web applications.
00:24:54.540
Anpoli allows you to build fast, SPA-like frontends while retaining your rendering logic on the server. There's growing interest in techniques such as HTML over the wire, especially after Hotwire was released last Christmas. Anpoli also supports these methods, but we approach them differently than Turbo. If you’re interested, check it out at anpoli.com. Thank you for listening!