Maintaining your joy in open source

May is Maintainer Month, and this year's theme is the joys of open source maintenance. Being a maintainer is hard work, but there’s also joy in the experience, which is sometimes easy to lose sight of. Creating things, putting them out into the world, and seeing other people use and contribute back to them is exhilarating, especially when you’re first starting out. So how do you hold on to the joy over the course of months or years? 

We talked with three open source developers about how they maintain their passion and reignite the spark when needed.

Meet the panelists

Kent C. Dodds is a full-time educator at EpicWeb.dev, striving to make the world a better place through open source and teaching people to make quality software. Among other things, he is the creator of Testing Library.

Cassidy Williams is a Chicago-based developer and CTO of Contenda. She pursues her passion for open source and helping people be as awesome as they can be by sharing her knowledge through talks, her blog (which is open source!), and email newsletter. She also created the open source word game Jumblie and is a GitHub Star.

Aaron Francis is a software developer, content creator, and co-founder of Try Hard Studios. He’s also an active contributor to the Laravel, Vue.js, and Tailwind ecosystems. He created the serverless Laravel deployment tool Sidecar and Airdrop, which aims to speed up deployment by skipping asset compilation whenever possible.

Klint: How did it feel when you first got into open source? What were those early days like?

Kent: My first pull request was a typo fix in a comment in the Java framework Play. From there I started working on a few different things, but Genie—a library for keyboard controls for web applications—was the first thing I started getting a lot of attention for. I also took over angular-formly, which was pretty big. What I really came to appreciate pretty quickly is that open source is a lot more about people than it is about code. You spend so much time working with humans when you're doing open source. 

Cassidy: I started out with typo fixes too! I was really excited when I first realized that open source meant I could fix typos and bugs, or even work on features. It was empowering and made me feel like I was part of the process of making the things I used, even if it was small.

Aaron: Yeah, I felt more like I was part of a community, rather than just consuming open source. Those early days were super duper exciting. I'd watched a lot of people I admired do open source and thought there was some sort of cabal or secret or rite of passage. Then I realized I could just do it, I could release something or submit a pull request. I didn't need permission or initiation. It was a lot of fun. I learned that people were having similar problems to the ones I was having. I saw that my solutions to those problems were helping people that felt great.

Klint: What still sparks joy for you working on OSS? 

Cassidy: The most minor things make me so happy with open source. Typos are still my favorite thing to fix because it's such a simple thing you can do to make a project just a little bit better for everyone. You can fix a little copy, help with some translation. I play the game Go online and I've made some contributions to the open source website UI. For example, if someone deletes their account on the website, it used to result in a super long entry in the database. It would cause UI problems with the text overflowing in different places. I fixed that, and it made the experience better. These seemingly small actions can have a big impact. I do like jumping in on heavier lifts, but it's really rewarding to make those quick changes.

Aaron: For me, it's continuing to scratch my own itch and solve my own problems. That's a pretty important and often overlooked aspect of open source. It’s tempting to become "captured" by the consumers of your library or package or whatever you've open sourced and committed to making things you won't use and don't even have an opinion on. There's a certain sense of duty that's required to be a maintainer, but if you maintain software you don't use or care about, you lose the fire.

There's a certain sense of duty that's required to be a maintainer, but if you maintain software you don't use or care about, you lose the fire.

Kent: Exactly. That's how I avoid burnout. I work on the things I need for my own use cases or that I like to work on, not because of pressure from other people. That’s led me to delegate things to other people. I'm open about not having enough bandwidth to take something on and let someone else step up. It also helps me give the same grace to other maintainers. If I find a bug or want a feature, I'll let the maintainer know, but if they don't fix it, I understand it's because they have different problems and priorities and I need to find a work around or fix it myself. My motivation for my pull requests are pretty practical now because I have a family I want to spend time with.

Klint: What can organizations and companies do to better support maintainers?

Cassidy: All companies should have some sort of fund to help finance the open source projects they rely on. There are so many people maintaining things that are core to software around the world, and they're hardly getting paid anything for it because we take it for granted that these libraries exist and will continue existing. We're starting to see more companies establish funds, including startups that build it into their budget from the beginning.

Also, organizations should encourage their employees who use and contribute to open source to triage issues. Label the ones that are good first issues so new people can start contributing. Close-out duplicate issues. This sort of support can be crucial.

Kent: Funding can come in many forms besides donations. If you rely on something and don't want the team behind it to get distracted by their day jobs, you can ensure longer-term success by hiring that team and making sure they can keep working on the project without being distracted by the need to work for someone else. Of course, even big companies can't do that for everything, but it's a huge help when you can. If you can't hire the team outright, make sure the engineers on your team are at least given permission and autonomy to contribute back to the projects they use. When I was at PayPal, I had a lot of autonomy. My attitude was that as long as I was pushing the company's mission forward, it didn't matter if my work was in a private repo or a public one. I think that's an attitude companies and managers can adopt.

Aaron: Besides funding, attention is really important—even if it's never going to pay the bills. Not a lot of open source authors get into it for the money, but it’s a viable way to market yourself as a developer. It gives us the rare opportunity to show the work we've done. Companies can support maintainers with newsletter mentions, retweets, or anything that elevates them and increases job opportunities. Maintainers really like to know how people are using their projects, so sharing that sort of information in a blog post is helpful. Even better, let them use your company logo in their readme file.

Klint: Have you ever had to step away from open source? If so, what brought you back?

Aaron: Yes. In my case it wasn't mental burnout; I was physically exhausted. We’d had our second set of twins, our third and fourth children. I also had rheumatoid arthritis. I wasn't sleeping. I just had to step away from the computer for a few months. 

Now that I feel rested again, I'm getting back to my open source projects. Laravel 11 just came out and I have a lot of packages I need to update. As for what brought me back, I do feel a sense of duty to get them up to date. There's also that marketing angle I mentioned. Plus, now that I'm not coding full time for work, open source keeps me in the game. I think what it takes to bring people back will depend on why they stepped away in the first place.

Kent: I used to spend a lot more time on open source. I'd often respond as soon as someone opened an issue and have a fix 5 minutes later. But I was spending so much time after hours that it began impacting my relationship with my family and my other work. I decided that if I'm not personally interested in doing something for the fun of it, and I'm not using it for work, I shouldn't work on it. 

I moved from Angular to React, so I wasn't using angular-formly at all anymore. Nobody else was able to take over the project, so that project pretty much died when I moved to React. It's still useful and popular, but nobody has maintained it over the years. I learned a lot from that experience. I realized I need to have a succession plan in place if I move on from a project. In a more recent project, a DOM testing library suite of tools, I did a lot better with onboarding contributors. If someone said "Hey I have this problem," and I knew it was pretty straightforward to deal with, I'd invite them to work on it. Eventually I did move on from that testing library. It's still actively maintained. It's a much more gratifying feeling, like I can move on from a project without feeling like I had to keep it going myself.

Cassidy: I haven't really stepped back from open source, but I've stepped back from projects, mostly my own, when the expectations become too much. For example, I made a task tracking app for my own use. I open sourced it and pretty soon other people were using it too. At one point it had so many issues I couldn't keep up anymore. There were some good ideas, but I don't have the time or energy to implement them, and they're not things I'll necessarily use. When I go back to something that I previously walked away from, it's usually just because I'm in the mood to code and I'll pick something up and start working on it again.

Klint: When was the last time being a maintainer brought a smile to your face? What was it?

Aaron: It always brings a smile to my face when someone says something nice about my work. Sometimes someone will randomly tweet that they use one of my libraries. It reminds me that there are people out there using things I built and might even have forgotten about.

Cassidy: It sounds so cheesy to say "every day," but it's true. I made a word game called Jumblie and people play it every day. Seeing people actually play something I built out in the open is just the best.  

Kent: I love merging pull requests from other people. It might not be something I even need, but it makes the project better. Seeing people come together and, without an extraordinary effort on any one person's part, lift heavy objects that we couldn't on our own is what makes me smile.

The ReadME Project is a GitHub platform dedicated to highlighting the best from the open source software community—the people and tech behind projects you use every day. Sign up for a monthly newsletter to receive new stories, best practices and opinions developed for The ReadME Project, as well as great listens and reads from around the community.