Maintainer spotlight: Henry Zhu

We’re sharing interviews from several open source contributors about their projects, challenges, and what a GitHub sponsorship means to them. This week, read about Henry Zhu.

|
| 7 minutes

With the launch of GitHub Sponsors, open source maintainers and developers can apply to receive funding from the community that depends on their work. Through sponsorship, open source maintainers have the freedom, financial security, and autonomy to continue the work they’re passionate about to further build and strengthen the open source community.

Over the next few weeks, we’re sharing the stories of several open source contributors. Learn about their projects, challenges, and what sponsorship means to them.


Henry Zhu is a New York City-based maintainer of the community-funded compiler Babel. Previously at Adobe, he’s also a host of two podcasts that discuss the lives of maintainers, Hope in Source and Maintainers Anonymous.

Can you tell us a little about the project(s) you maintain?

Babel is a tool that developers use to make websites. It enables developers to use the latest (or future) version of JavaScript while allowing for backward-compatibility in older browsers. It accomplishes this by translating new syntax into older syntax, which is why the original name was 6to5. Over time it’s been used more frequently as a dependency in other tools, such as Next.js, Parcel, and create-react-app, and has become lower in the stack of a front-end developer. Becoming so common, while simultaneously not at the forefront, is how we know Babel is successful, but the lack of visibility can make it difficult to maintain or get help.

Why did you start or become involved in this project?

I didn’t start Babel myself, but thanks to community funding, I’m able to work on it full-time. The project was created by Sebastian McKenzie, and he explained that he started working on the project to better understand JavaScript. After using it for years, he became curious and started asking the fundamental questions of how programming languages were created.

After trying out Traceur, Sebastian decided to build his own compiler for fun. Could it output code similar to the kind he writes manually? He wanted to learn everything about JavaScript: programming language theory, compilers, all of it. Similarly to other maintainers, I also learned everything on the job after joining Babel.

Before I joined, my involvement with the project was a bit of an accident. I just showed up with a few others during a time when Sebastian was feeling burnout from the project. I stuck with it until I was able to quit my job.

What do you think is the biggest challenge that open source faces?

The more I’m involved and learn about open source the more complicated it feels. One of the challenges is being confident in what’s important at any given time. Do I prioritize stability or sustainability, security or convenience, code or people? We’ve gone through Heartbleed, left-pad, and so much more.

And yet open source is so varied. There are corporate and community projects, different licenses (GPL/MIT), foundations versus single maintainers, entirely volunteer or full-time staff, and other variations. There aren’t any formulas to solve here.

This makes me consider that the challenge isn’t that we don’t have the correct solutions or technologies, but maybe we aren’t asking the right questions and thinking holistically. It’s easy to get caught up in the technical issues that are people-focused. As technologists who have affected the world through code, we keep hoping to solve the challenges of open source by minimizing the problem as a lack of the right code, money, or technique.

Should open source operate similarly to startups or more like towns? Should we remember the values of free software or should we abandon, forget, or change them? Who is responsible—creators, maintainers, companies? Is it all of us or no one? There are so many questions and many yet to be asked. Meanwhile, as we put the focus on funding and sustainability, maybe we need to spend more time thinking about the aspects of the community such as leadership, governance, and dealing with burnout.

How has your involvement in this project helped you grow, personally or professionally?

My involvement in Babel has completely changed the trajectory of my life. It’s where I learned how to grow from being a contributor with little knowledge of compilers, to working on the most popular language in the world, to leaving my job to work on an open source project full time.

In the beginning, I just wanted to be involved to get my name on the list of committers. It took me several years to learn how to take on more ownership of a project that we all use and share. It’s challenged me in what I actually want to do with my career and overall life. It’s a privilege to be able to serve this community in a manner that speaks so deeply to the heart of what I’m passionate about, especially as it resonates to other parts of my life, such as my faith.

What is the greatest contribution need for your project now or in the future?

Like most community-driven projects, there is a lot that could be done for our current group of volunteers: improving the documentation, issue and pull request triage, workflows, communication, and more.

In the end, it’s unrealistic to do everything and it’s difficult to know what to prioritize. We have to consider moving slower with purpose, thinking more long term, and caring about the health of the project. Our needs should be specific to the nature of the project itself.

Our main goal is to make the process of developing JavaScript easier. We act as a bridge between the standard itself and the JavaScript developer ecosystem. Our “feature requests” come from both of these groups, implementing new proposal ideas as well as making it easier to use and communicate feedback. Our funding and sponsors should similarly come from the developers and companies that rely on this tool—not only to enable their current workflows, but also to shape the future of JavaScript.

Why did you sign up for GitHub Sponsors?

GitHub Sponsors complements other funding platforms that I use, such as Patreon and Open Collective. When I originally left my job to pursue open source full time, I mentioned that if GitHub ever made their own sponsorship platform I would move to that instead, and it’s finally here!

There are some very clear reasons why:

  • Most developers are on GitHub, not other platforms. This makes it natural for people to discover a maintainer’s work and sponsor them on GitHub versus relying on links to third-party platforms.
  • GitHub isn’t taking a percentage like other crowdfunding platforms (other than credit card fees). This is worth it alone because it signifies the intent in not making this a business model.
  • Longer term, I would expect new GitHub features that cater to maintainers specifically, not just to a generic crowdfunding platform. I envision features improving the team’s continued interaction, as well as a feature to ask for community feedback, similar to Open Collective.

Github is uniquely positioned to make a huge difference in this space just like it has for open source at large.

What do you want potential sponsors to know about you and your project?

I’ve been able to work on open source full time for a year because of community funding—and I’d like to continue moving forward. Not only because I can continue the work I’m passionate about, but also because I can dedicate time to consider the questions and ideas that may lead me in different directions while focused on open source.

I want people to consider that they are sponsoring me as a person—not a fixed or frozen set of ideas. I am more than what I do (“the Babel guy”). Know that you aren’t sponsoring me to only write more code or fix bugs, but to move the future of the project forward as a maintainer.

If you’re interested in the topics (open source, faith, responsibility) and sorts of questions I’m interested in (how can we sustain communities whether offline or online, where does open source intersect with the rest of life, why maintain) and want to support my future learning, I would appreciate your help! Ultimately, I hope that none of this turns transactional with simply giving and taking. My expectations are greater than that—let’s surprise one another and grow together.

Sponsor Henry Zhu


Want to learn more about featured maintainers? Read about:

Check back soon—we’ll be adding new interviews every week. Contact us If you have ideas about how GitHub Sponsors can better serve the open source community.

Related posts