HomeDockerMaintainers Spotlight: How Kent C. Dodds pays it forward through open source

Maintainers Spotlight: How Kent C. Dodds pays it forward through open source

We hear about open source initiatives every day, but we rarely hear from the people who maintain them. Maintaining an open source project is a full-time, often thankless, job. The Maintainers Spotlight blog series is an opportunity to highlight the essential position maintainers play in shifting initiatives and communities forward. In true open source fashion, we’re hoping that sharing these experiences and learnings will help out current and aspiring open source project maintainers.

Kent Dodds presentingFirst in this series is Kent C. Dodds, whose M-O is to improve the world with quality software, appreciating how open source has aided his growth as a developer and enables him to extend his efforts to anyone around the world. From managing personal workload to thoughts on community accountability, read on to learn from his experiences as a maintainer.

Tell us about your favorite open source project and what problems did it aim to solve?

I have… (too?) many. You can find them on my GitHub profile. All of my stuff is JavaScript. I have over 100 modules revealed to npm. I also have a lot of open source initiatives that are materials for teaching JavaScript, testing, and React, which people really respect.

Of all of my initiatives, Testing Library is probably the most impactful. I created the core (DOM), React, and Cypress modules. There are various other implementations of Testing Library for other frameworks and platforms that are maintained by other incredible people. Most of them are based on the core library which I wrote, and all of them are based on the philosophy I champion, which is: “The more your checks resemble the way your software is used, the more confidence they can give you.”

The dispute that Testing Library solves is it allows web UI developers to write checks that give confidence that the software works as it is supposed to. It does this by encouraging fine testing practices by widening the pit of success via a simple API. I have written about this at length on my blog and given several talks about this as well.

Where did the name (and brand) for your package approach from?

It’s a fine story! Originally, I created React Testing Library (DOM Testing Library was later extracted) and I planned on calling it “RTA” quick for “React Testing Assistant.” I thought it was a pretty fine name and tweeted that I was excited to announce it. Ryan Florence sarcastically responded “react-testing-library” and I thought it was just too fine to pass up. Maybe it’s my dry humor side.

The brand was chosen at random. I had recently initiated assigning emojis to my open source initiatives, so I looked through my emoji picker at animals I could use for my mascot and ended up selecting the Goat. A lot of people think I was saying React Testing Library is the GOAT (Greatest Of All Time), but that was purely coincidental (or maybe it was FATE!).

What made you want to become a project maintainer?

I delightin the fact that when I write code, I can run it as many times as I want and I don’t have to write it again to get the same value I got the first time. With open source, I can pass that value on to anyone in the world which magnifies my efforts and hopefully makes the world a better place. That’s why I participate in open source in general. Maintaining a project can feel thankless sometimes, but my experience has been stuffed with thanks from others and personal satisfaction for myself. Open source has had a massively positive impact on my life.

What’s 1 thing your current self would inform your past self when you were starting out?

Hey Kent, so 1 night you’re going to be working on api-check and you’ll be in really deep with it. Your wife will ask you when you’ll be done and you’ll inform her “soon.” When that happens, just stop right there instead of staying up until 2:00 AM and keeping her up waiting for you. You’ll thank me later. And then determine out better boundaries for your open source work.

One of my biggest regrets was not learning fine boundaries between my life and open source earlier.

How‌ do ‌you‌ ‌handle‌ your ‌workload and avoid burnout?‌

Now I have a personal policy that I only work on stuff that I need done (for work) or want done (for fun). If it’s something that other people need or want, I expect (and enable) them to do it themselves. This has the effect of ensuring that the only things that enter the project are things people really need and care about, encourages new contributors, and saves me masses of time.

I don’t mind ignoring people’s issues and PRs for a while. I hold in perspective that I don’t owe them anything and resist the urge to assume other people’s problems onto myself. I’ve not always been this way, but in the last few years as an open sourcerer, I’ve been able to maintain a pretty wholesome relationship to my open source work.

What are the biggest obstacles you’ve had to overcome with your initiatives?

Inertia is really hard to beat. Enzyme was really the only game in town for testing React for several years. Other frameworks have identical de-facto testing solutions. Even though everybody who tries Testing Library agrees that it helps them ship with more confidence than using the older libraries, it’s really hard to change the defaults that people have created for themselves after so lengthy. We’re nonetheless working on this. I’m looking forward to the day when enzyme downloads start going down each month rather than up because it means that people are finally starting to realize that they need to move their checks if they want to ship with confidence.

I realize that it seems like I’m really competitive and I just want people using my library, but I want to make it clear that’s not it. I’m interested in people making the world a better place and I just know that they can do that more effectively with what I have to offer than what they’re currently using. The biggest obstacle has been reaching people and convincing them of that. 

What events typically force action on your part as a maintainer?

For all initiatives I’m actively maintaining, I typically should approve every PR before it can be merged. So, PRs force my action quite often. If there were ever a Code of Conduct violation then I would take action there as well. Outside of that, not much.

How do you say no to a PR?

Like this:

Hi <insert name>,

Thanks so much for bringing this up. After our discussion about this I don’t think we’re going to do this <for well-thought-out causes x, y, and z which we’ve already mentioned>. <Re-iterate the workaround if there is 1 or the counseled alternative approach>. Good luck, and thanks again.

<Close issue>

How do you handle when you don’t have time anymore to support your open source project?

First, I automate as much as I can to reduce the amount of time desired. I’ve been pretty successful at doing this (my Managing Open Source Projects talk goes into this a bit). Then, I decrease my relevance by encouraging other people to help maintain the project. Then, I take time off. I basically took all of December and most of January off from OSS and the project chugged alongside just fine. It just takes preparation for your eventual fade into irrelevance or disinterest.

I had 1 project a while ago where I didn’t prepare for this very well and I didn’t have anyone who was really dedicated to the project as a maintainer. Honestly it may have been that it was a library written in AngularJS and most people were shifting on to Angular 2 or React like me, so that might have had something to do with it, but either way I just had to deprecate the project and archive the repo because nobody stepped up to maintain it. That was unfortunate, but truthfully that’s the best thing to do in that situation. If somebody really needs it, they can fallback on what they would have done if it hadn’t existed in the first place (write the code themselves), which is fine. In fact, they can just fork it so they’re better off anyway.

What are the standards to define a successor and how do you measure quality and success for a maintainer?

I’ve transferred possession of quite a few initiatives. Many of them nonetheless live on today with solid maintainers (a worthy example of this is allcontributors.org).

I used to pretty much say once somebody cared more about a project than I did, I would hand the project over to him or her. But ever since the event-stream incident, I’ve tried to be more careful about that and until I’ve developed a lot of belief with somebody, I won’t hand over the publishing rights and would rather deprecate and archive the project and encourage them to fork and publish under a different name if they want to proceed maintaining it.

In summary, my standards for a successor is they should:

  • Use the project actively
  • Care as much, or more, about the project than I do
  • Have a identical vision and philosophy for the project (though if I’m shifting on and not planning on using the project anymore, this matters less to me)
  • Have my belief (which is hard to gauge and construct, but when you know you know)

What do you think about accountability in the open source community? Who is doing it best?

I feel like once you install an open source project you are responsible for that code. If you have problems with it, they are just as much your problems as anyone else’s (more-so, in fact). For the initiatives that I depend on, I feel like I’m accountable for any issues I approach up against and anything the maintainers do to fix those is a gift they’re giving to me.

As a maintainer, I feel like it’s necessary to communicate intent with users of the project and it would be unwise and irresponsible to encourage people to use your project, investing in learning what you’ve constructed and construct up that belief, just to throw it away by doing something silly, like this.

Who’s doing it best? I don’t know. Fortunately, I think a lot of initiatives do a fine job of this.


Most Popular