RX Patient Tools
Use these quick guides before reading the article, or return to them when you need help preparing questions for a doctor.
We hear about open source projects 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 role maintainers play in moving projects 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.
First 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 published to npm. I also have a lot of open source projects that are materials for teaching JavaScript, testing, and React, which people really appreciate.
Of all of my projects, 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 amazing 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 tests resemble the way your software is used, the more confidence they can give you.”
The problem that Testing Library solves is it allows web UI developers to write tests that give confidence that the software works as it is supposed to. It does this by encouraging good 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 logo) for your package come from?
It’s a good story! Originally, I created React Testing Library (DOM Testing Library was later extracted) and I planned on calling it “RTA” short for “React Testing Assistant.” I thought it was a pretty good name and tweeted that I was excited to announce it. Ryan Florence sarcastically responded “react-testing-library” and I thought it was just too good to pass up. Maybe it’s my dry humor side.
The logo was chosen at random. I had recently started assigning emojis to my open source projects, 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 enjoy 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 filled with thanks from others and personal satisfaction for myself. Open source has had a hugely positive impact on my life.
What’s one thing your current self would tell your past self when you were starting out?
Hey Kent, so one 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 tell 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 figure out better boundaries for your open source work.
One of my biggest regrets was not learning good boundaries between my life and open source earlier.
How do you manage 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 loads of time.
I don’t mind ignoring people’s issues and PRs for a while. I keep 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 healthy relationship to my open source work.
What are the biggest obstacles you’ve had to overcome with your projects?
Inertia is really hard to beat. Enzyme was really the only game in town for testing React for several years. Other frameworks have similar de-facto testing solutions. Even though everyone 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 long. We’re still 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 tests 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 projects I’m actively maintaining, I typically must 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 reasons x, y, and z which we’ve already discussed>. <Re-iterate the workaround if there is one or the recommended 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 needed. 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 along just fine. It just takes preparation for your eventual fade into irrelevance or disinterest.
I had one project a while ago where I didn’t prepare for this very well and I didn’t have anyone who was really committed to the project as a maintainer. Honestly it may have been that it was a library written in AngularJS and most people were moving 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 honestly that’s the best thing to do in that situation. If someone 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 criteria to define a successor and how do you measure quality and success for a maintainer?
I’ve transferred ownership of quite a few projects. Many of them still live on today with solid maintainers (a great example of this is allcontributors.org).
I used to pretty much say once someone 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 unless I’ve developed a lot of trust with someone, 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 continue maintaining it.
In summary, my criteria for a successor is they must:
- Use the project actively
- Care as much, or more, about the project than I do
- Have a similar vision and philosophy for the project (though if I’m moving on and not planning on using the project anymore, this matters less to me)
- Have my trust (which is hard to gauge and build, 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 projects that I depend on, I feel like I’m accountable for any issues I come 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 important 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 built and build up that trust, just to throw it away by doing something silly
