Every day, I take at least five to 15 minutes for open source. To me, it’s more like meditation than work. While some might use their spare time to take a nap or catch up on social media, I use those moments to work on maintaining projects. I made commits on my wedding day and on the days both of my children were born, and I was still fully present for all three of those events. My commits were simply part of my daily routine.

I understand the privilege of this position. I grew up in a family where I didn’t have to worry too much about money. My ethnicity and gender have never caused me problems. I don’t have a degree, but that’s never had a negative impact on my career. My path has been one of both privilege and hard work. So it’s important to me to support and empower other developers in the community. I want them to know that choosing the maintainer path might have been easier for me than it is for them — not because I had extra skills or talent, but because of my environment.

I recognize and cherish the ownership and responsibility I carry within the open source community, where a little negativity or positivity can go a long way.

Small actions lead to big improvements

Back in 2007, I helped build a start-up called MixMatchMusic in a garage with some friends. It was a collaborative community for musicians to remix ‘stems’ (a guitar riff, piano loop, etc.). We paid royalties to match the percentage of an artist’s contribution to each song, and evolved to include a platform for musicians to make their own apps.

Before I knew it, I was maintaining a bunch of projects. It would typically start when I was waiting for a new release from a project I depended on, or trying to fix a bug or merge a pull request. Eventually, the existing maintainer would get too busy and hand me the keys to the package. I would carry it forward from there.

In 2014, one of the then-maintainers of jQuery reached out and asked me to attend a meeting of TC39, the committee that specifies JavaScript. I figured, why not? I was immediately able to offer feedback that changed the specification in a way that I think a lot of people would agree was for the better. And that was such a gratifying feeling: I made an improvement on something that a lot of people would benefit from for decades. It’s a lot of pressure, but it also means that even if I only have five minutes to give in a day, it can make a difference to thousands of developers, teams, and companies. That’s the network effect of open source.

Relatively early on, I was also maintaining a package called es5-shim (which was why I was invited to attend TC39), which retrofits ECMAScript 5 to be supported by JavaScript engines on all browsers. I still work on es5-shim, along with over 200 other packages. I’d say at least half of those were inherited, and the rest are smaller ones I created myself. I have some very small, incidentally-used packages, and others that the entire developer ecosystem depends on like nvm, qs, enzyme, etc.

A little documentation is a powerful thing

The most challenging moment I’ve had in the open source community was with TC39. One of the proposals I submitted was globalThis, which defines a standard global property for JavaScript and makes it possible to write JavaScript code that works in all host environments. We needed a name that reflected the fact that it was everywhere, but there weren’t a lot of inspiring options.

I landed on “globalThis” for a variety of reasons and ran with it, but I didn’t consider the impact of such a seemingly simple decision. A small part of the community did not agree with the name I chose. They thought there were better alternatives, and that “globalThis” was confusing because it related to the concept of this, an already confusing aspect for many users of the language. A couple of people with strong Twitter followings tweeted about it, which invited a sort of mob mentality. Given that there were a lot of largely immovable reasons why the name was the way it was, changing course wasn’t an option. Because this name was for the entire JavaScript language, not just a personal package, I couldn’t ignore it. It belonged (and still belongs) to everyone. I needed to find a constructive way to reverse the tide.

So I sat down with Yulia, a TC39 chair and Mozilla engineer, to write a document that explained our decision. We listed all the constraints we were working with, and which names met or missed those constraints. Once everyone could see the reasoning and context behind the name, things rapidly quieted down.

Looking back, I think the community’s passion was well-placed. Their actions could have been more supportive, or they could have collaborated with me directly, or less publicly. But I learned that the more I can focus on documentation — and underscore the reasons behind my decisions — the better things will be overall. I now make an effort to convey understanding from the beginning instead of making assumptions.

Approaching code with kindness

My advice for new maintainers is to document everything. You don’t necessarily have to comment your code, but document thoughtfully. Automate everything you can, and clearly set your expectations for responsiveness. Define the types of features you’ll both accept and decline in advance. And be courteous with everyone you interact with; that includes being responsive. Try not to be short or snarky. It’s really easy to do that by accident, especially on days where the rest of your life is less easy.

The people within the open source community that I look up to are the ones who are always well-spoken, kind, and measured in their responses. As a human, nobody’s immune to getting a little upset. And somehow these maintainers have figured out how to be consistently decent with everyone. That’s how I want to approach each commit, and each comment.

I want to look back at my life at any point and feel generally positive about what I’ve done: what I’ve built, who I’ve interacted with, how I left them feeling. The technical problems are easy; it’s the people who are challenging. How do you communicate with everyone? How do you share your priorities and goals? How do you effectively convey pain points? I want to find ways to limit the negativity and maximize the positivity.

It’s my hope that this shift empowers others who don’t have the same privilege as I did to feel supported and keep working for what they want. I know it’s not easy. But it’s always worth it.