In March 2018, I made the easiest hard choice: I left my job at Adobe to be a full-time open source maintainer. The decision was a long time coming and I recognize it takes a certain privilege and freedom to take such a leap. There are positives and negatives, and the ups and downs are inevitable, especially now, in the midst of a pandemic. But I’m still happy with my decision, and grateful for the opportunity to give back to others and meet people—and their problems—where they are.

Connecting with people and addressing the human side of open source has become a big part of my motivation. This comes from two places: my faith and my desire to make room in my life for human connection. Doing open source, in part, feels like a way that I express my faith. There’s a Bible verse from Corinthians I keep coming back to: “Though I am free from all, I have made myself a servant to all.” No one is forcing us to do anything in our lives and yet, here we are. We can choose to serve others, and that’s how I want to approach open source. There is an element of luck, and also privilege, where you can assess your options and, instead of getting stuck in your comfort zone, you can choose to take a risk. And if that’s true, I can choose to do something bigger than myself with open source: something that helps other people.

Recognizing the people behind the projects

I discovered open source when I lived in Atlanta, my home town. I was working for a local company, where my coworker, Jonathan Neal, contributed to a few projects, like normalize.css on GitHub. My use of open source was a classic case: I used it in my work all the time, I took it for granted, and one day something clicked. I wondered: Who’s behind that project? And even later, who’s funding this? Even though it may be obvious someone has to work on it, I started to understand that maintainers are real people with lives, jobs, and families, and are sacrificing a lot to give back to a larger community. I was inspired.

I started by making code style changes to Angular.js before moving onto the code linter itself, JSCS, which is how I met Joel Kemp. He was a JSCS maintainer, and one of the first to make a noticeably nice comment on one of my pull requests. After about a year working together, Joel invited me to interview for the Behance team at Adobe. The interview felt natural and the timing was just right. Before I knew it, I moved to New York unsure how much I’d like it, for a new job.

Working open source into work

By the time I left Atlanta, I’d been contributing to open source, mostly JSCS, for about a year. After joining Adobe, I was invited to join the JSCS core team, which is when I learned compilers weren’t that different from linters, and I started contributing to Babel. At the time, I was maintaining the project alongside Daniel Tschinder, Logan Smyth, and Brian Ng. Babel’s founder, Sebastian McKenzie, always had a clear vision of what Babel could become. As a project, the atmosphere encourages developers to really think about how to define JavaScript as a language, which always kept me engaged.

I was happy at Adobe, but something was missing. I thought I’d be working on open source, but, as you might expect at any big company, I got caught up meeting deadlines and open source became a side project once again.

Eventually, I gathered enough courage to talk to my manager and ask for what I really wanted: to work on open source projects. I approached the conversation thoughtfully, explaining how we already used Babel at work, and that there had been feature requests in the queue that would be tremendously valuable to the team. I floated the idea that I could dedicate my time to both proactively solving those requests and maintaining Babel, instead of waiting for them to be addressed in someone else’s free time. I carefully outlined that this shift would help the company and the community. To my surprise, they said, “Sure, let’s give it a shot. How about half time?”

The experience boosted my confidence. In retrospect, it was a rare opportunity and testament to my manager, Sean Dunn, and coworkers who understood the value of open source. At first I was excited to be able to dedicate my mental energy to something I loved, and avoid juggling jobs with the burnout that maintainers so frequently experience.

I helped develop and release preset-env, which was a big step forward in the evolution of Babel. But all the while, I was thinking more deeply about what would make me happy, and in the end, part time wasn’t enough. A company’s interest might not always align with the needs of an individual project, and it can be tough to holistically consider what might benefit the open source community at large. I wanted the freedom to think bigger about Babel and open source, so in 2017, I started exploring ways to be a maintainer full time.

I talked to others, like Evan You, and researched open source companies, but didn’t really consider doing it on my own. I don’t think we trust ourselves enough or give ourselves the freedom, credit, or mental space to consider dropping what’s typically considered stable and doing it alone.

Everyone at Adobe was supportive, but ultimately, the structure at work felt a bit isolating. That, combined with the split time and lack of community led me to quit my job on a Friday morning in March. Immediately after quitting, I shared the news with my community in a tweet and I was off to a church retreat for the weekend. I was shocked to return and find over $3,000 in my Patreon account. Funding was—and still currently is—a problem, but it was just the boost I needed at the time.

The (financial) terms of doing it alone

Everyone’s life circumstances are different, but for me, tying open source so inextricably to making money was based on the fear of getting by financially. And the more you think about money, well, the more you think about money. I was lucky in that I knew I could find another job if it didn’t work out. I had the choice to take this big, one-time risk or opt for another path. I also felt I might regret it if I waited, and figured it was better to make this kind of decision earlier in my career rather than later.

Because I grew up really into math and science, I had a hard time leaving quantitative success behind. There’s no shortage of ways we can try to measure it: We can count stars, downloads, contributors, or users. But each, on its own, isn’t a great indicator of success. What if users grow but maintainers don’t? That might be an indication that a project isn’t successful.

It was difficult to recognize that maybe qualitative success was better for me—and that my motivation was intrinsic, driven by my convictions and beliefs, rather than by chasing paper. In fact, all the research in the world might not be convincing enough. But when I removed the fear of supporting myself in New York, I was able to clarify my sense of purpose: I wanted to build something meaningful that helped people. After all, where would our society be if no one acted on their motivations and ambitions to do something different?

Maintaining humanity in a code-driven world

As engineers, we run up against a stereotype that we only think about the code. In a way, code is the easy part. The hardest problems in engineering are about people, and open source is no different. Despite our best attempts, there are no simple solutions or algorithms for how best to interact with each other. When we log onto our computers, we tend to automatically disengage and lose our humanity—even though that’s exactly what distinguishes us from machines.

The more an interface feels like a set of video boxes or a list of issues, the more you’re likely to focus on efficient communication and forget that real people are behind all that code. Users and passing contributors feel entitled to get something done, and they might not know you at all or think you’re some kind of celebrity. You would think as maintainers, we’d have the empathy to relate to other maintainers, users, and contributors, but we definitely still get frustrated. At the end of the day, we’re all just people trying to figure this out. More than project management skills or technical expertise, empathy is the most important skill in open source.

One of the reasons I quit my job was because I didn’t want to focus just on the code or the features. I wanted to do the people stuff. And the more I worked with open source, the more I recognized the value in people and relationships. When I think about my own purpose in the world, I think about connecting people, humanizing our online interactions, and bringing people together around common goals.

Open source intersects with so many related fields, and has encouraged a personal interest in exploring those intersections, from faith to urban planning to media studies to archivists. In her 2016 report, “Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure,” Nadia Eghbal compares cities and physical infrastructure with open source. Open source is a shared digital infrastructure that connects people all over the world. Strangers with different skill sets have to work together on the software we all have in common. And, of course, when we work better together, are civil to each other, and recognize our humanity, everyone has a better experience.

It should be said that it’s often assumed that it’s the maintainer’s responsibility to do everything: fix bugs, reach out to community members, create a vision, provide documentation, fundraise. But if we consider our code as infrastructure, then are those who volunteer the only owners? What is the role of users and companies in maintaining our digital infrastructure?

Making boundaries to make room for yourself

Nadia recently released a new book, Working in Public: The Making and Maintenance of Open Source Software, which takes an honest look at our open source communities and the individuals who become the center of our online social systems.

Normally, we think the problem with open source is that maintainers need help, so the obvious answer is to add more people. But more is not always better. Especially in the JavaScript community, we have a culture of being very nice and welcoming, which is good. But when you try to be too open, inclusive, and free, and you don’t impose rules or boundaries, it can quickly lead to burnout because anyone can get involved. And individual action only goes so far. We need systemic changes and platform help. Open source consumption is free, but the maintainer’s time is not, even if we’re not paid.

So we need more boundaries. Without them, many maintainers get to the point of wondering “why am I even doing this?” They feel bad for wanting to sleep or needing a break. They have thousands of GitHub issues they might never read. Especially now with the pandemic, anyone who can is working from home, and it seems there’s more time that we “should” be filling with work.

For me, there’s no boss or set schedule anymore, and this kind of freedom triggers bigger questions about what I’m doing and how it affects others. With all these horrible things happening in the world, it’s human nature to question if we should even be doing this. So I’m trying to make a point to define for myself how I want to show up as a maintainer, and how I can make connections and create experiences with people outside my areas of expertise.

It’s important for me to recognize that what I might really need—and what we all might benefit from—is rest and the humility to set our own boundaries. Now more than ever. What we’re doing is hard, it’s ever-evolving, and it’s emotionally and financially challenging. But it’s worth it.