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 Im still happy with my decision, and grateful for the opportunity to give back to others and meet peopleand their problemswhere 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. Theres 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 thats 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 thats true, I can choose to do something bigger than myself with open source: something that helps other people.
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: Whos behind that project? And even later, whos 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 1 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 Id like it, for a new job.
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.
Working open source into work
By the time I left Atlanta, Id 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 werent 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. Babels 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 Id 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 elses free time. I carefully outlined that this shift would help the company and the community. To my surprise, they said, Sure, lets 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 wasnt enough. A companys 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 didnt really consider doing it on my own. I dont think we trust ourselves enough or give ourselves the freedom, credit, or mental space to consider dropping whats 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 wasand still currently isa problem, but it was just the boost I needed at the time.
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.
The (financial) terms of doing it alone
Everyones 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 didnt 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. Theres no shortage of ways we can try to measure it: We can count stars, downloads, contributors, or users. But each, on its own, isnt a great indicator of success. What if users grow but maintainers dont? That might be an indication that a project isnt successful.
It was difficult to recognize that maybe qualitative success was better for meand 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?
It was difficult to recognize that maybe qualitative success was better for meand that my motivation was intrinsic, driven by my convictions and beliefs, rather than by chasing paper.
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 humanityeven though thats exactly what distinguishes us from machines.
The more an interface feels like a set of video boxes or a list of issues, the more youre 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 youre some kind of celebrity. You would think as maintainers, wed have the empathy to relate to other maintainers, users, and contributors, but we definitely still get frustrated. At the end of the day, were 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 didnt 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 its often assumed that its the maintainers 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?
More than project management skills or technical expertise, empathy is the most important skill in open source.
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 dont 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 maintainers time is not, even if were 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 theres more time that we should be filling with work.
For me, theres no boss or set schedule anymore, and this kind of freedom triggers bigger questions about what Im doing and how it affects others. With all these horrible things happening in the world, its human nature to question if we should even be doing this. So Im 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.
Its important for me to recognize that what I might really needand what we all might benefit fromis rest and the humility to set our own boundaries. Now more than ever. What were doing is hard, its ever-evolving, and its emotionally and financially challenging. But its worth it.
More Stories
A teenager from Co Offaly has been “inundated” with orders for his handmade reindeer decorations after his mother put up a post in a popular Facebook group.
Run Windows apps such as Microsoft Office in Linux (Ubuntu) and GNOME as if they were a part of the native OS, including Nautilus integration. – Fmstrat/winapps
With Australia’s relationship with China at a very dangerous stage, the timing of what is expected to be a ‘more nuanced’ approach from a Biden administration could not be more welcome.