Henry Zhu Henry Zhu

Henry Zhu @hzoo

  • Project Babel
  • Location New York City, New York
  • Day job Software Engineer at Adobe/Behance
Henry Zhu
Henry Zhu splits his time between working on Adobe’s Behance team and Babel, a popular JavaScript compiler used by companies like Facebook, Google, and Netflix.


For more background, I cover a lot of how I got started with OSS in this blog post. I wrote: in no way was I able to do anything without the many folks in the community who helped, taught, and inspired me!

When I first heard about Babel, I got really excited about the ways it could improve the development experience. I followed Dan Abramov’s advice: "watching" (really lurking on!) the GitHub repo to try to get more context into the project and its issues. I made my first Babel pull request on March 2, 2015.

Then Sebastian (the creator of Babel) made the issue: Looking for a maintainer for a non-core Babel project, so I reached out to help. Being added as a "collaborator" soon after helped push me to get more involved. I started reading every issue and pull request and began to think about the project as a whole. I didn’t realize that after a short while I had become a Babel core maintainer, rather than just a "collaborator".

The majority of my work on Babel has been in my free time, but in the last few months, I’ve been given the opportunity to spend a good amount time at work working on Babel. Since then, I’ve been able to spend time developing things that would benefit our work: currently babel-preset-env and babili (babel-minify). It’s been awesome to be able learn and contribute to so many other projects due to Babel’s position in the JavaScript ecosystem.

Daily tasks

I believe the list has changed as I’ve learned about new aspects of maintenance!

I’ll work on bugs and features (which is great), but the project health still suffers without contributors. That’s why I'm leaning towards doing more of the pure maintenance side of things like making it easier to contribute, finding beginner-friendly issues, spending timing writing documentation on how to contribute, etc.

There are the regular tasks:

There’s also support:

  • Being available for answers (much of which I need to figure out first) on Slack and Twitter, etc
  • Checking out related projects: integrations like babel-loader, babel-plugin repos, projects that have Babel as a dependency


  • Writing meeting notes, ideas, and discussions for babel/notes
  • Sharing the work of awesome contributors, like Babel plugins and talks
  • Sharing new features, ideas, and related projects with others
  • Reaching out to both community members and projects for help or discussion

And project sustainability:

  • Figuring out where we can improve with automation or better infrastructure
  • Measuring project health for both contributors and maintainers
  • Exploring options for partnering with organizations (GSoC, RSoC, coding bootcamps, and schools)

Lessons learned

Being able to work out problems with so many awesome collaborators has been great. Huge shoutout to our whole team and the greater community of people and tools. I’ve been able to learn so much, including:

  • Technical skills: I learned more about JavaScript and the tool itself which helps me in my job: I can help our team troubleshoot issues with it, work on new features, and teach others about the language which is really cool

  • Empathy: I’ve learned a bit more about caring for your users (it helps that I am a user too). It isn’t just about the code (like all things in life), it’s the people that keep the project moving forward and alive and the community of users

  • Writing chops: I have a newfound appreciation for writing and see the parallels of being a greater writer and a great programmer. For someone who hated English and writing in school, I'm starting to understand its immense importance in our field

"It isn’t just about the code (like all things in life), it’s the people that keep the project moving forward and alive and the community of users."


We have no idea the amount of work that goes into each and every project. It’s not just the contribution graph but the hours of thought that goes into design, code review, and discussion.

It’s easy for us (and me) to forget that maintainers and users are all people. Issues are opened with the highest degree of entitlement. Unpaid volunteers are expected to help with a problem and with grace and urgency. Angry blog posts and tweets are written explaining how project was done wrong or is constantly buggy.

Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. I replaced a lot of time playing video games with open source.

I’ve tried in the last year to cut back on this, even though it’s hard. I try to spend weekends to rest, and on Sunday block out all of time for church and other related activities. I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.

I'm still trying to understand burnout. Even though it’s been a struggle at times, I just feel blessed to have been able to take part in all of this. As a Christian, I believe my prayers for wisdom in maintenance and grace in discernment really showed in my interactions with others, and I hope that my experience has helped or inspired others to get involved in open source.

"Even though it’s been a struggle at times, I just feel blessed to have been able to take part in all of this... I hope that my experience has helped or inspired others to get involved in open source."

Favorite moments

Being able to meet other developers whether online, at meetups, or at the few conferences I’ve been to has been such a joy for me, but one moment stands out: learning about Guy Fieri!

Editor’s note: We love the moment Henry’s referencing, so here’s a little more context. Jordan Scales, a JavaScript developer, wrote a satirical Medium post, where he joked that Babel’s heavy dependencies were due to a photo of Guy Fieri being secretly installed on everyone’s computers. The post led to Babel maintainer James Kyle proposing a “fix”, Jordan’s reverted pull request that officially made him a Babel contributor, matching Guy Fieri sweaters, and, finally, a meeting between Jordan and Henry in real life. Ah, the unifying power of open source (and fried food).

Good advice

  • Don’t shoulder the burden on your own. It’s better to have help than total control. You can always naturally scale up as your project gets bigger or more popular, but I would suggest adding other collaborators as soon as possible
  • Separate yourself from your project, even though it can be very difficult to not take things personally
  • You can only do your best! Try not to lose sleep over a bad release, bugs, hundreds of open issues, complaints on Twitter, and an overwhelming amount of support questions
  • Continuously reach out to people to become contributors. Actively determine what needs to change on the project’s end to help facilitate that
  • Learn from criticism. Each piece of feedback could mean a potential change to the documentation, a bug in the code, or just a need for better error messages.
  • Help each other. Talk to other maintainers about their issues and struggles
  • Document everything. It doesn’t have to be public if it’s just your ideas or thoughts, but meetings and discussions should be public if possible
  • Tell people (tweet) what you are working on while you are doing it rather than only after. It shows you the process and that we all make mistakes

The greatest contribution need for Babel

I think the greatest need for Babel is just more contributors. For a project that’s downloaded ~6 million times a month, there’s still no one who actually works on Babel full-time, and only a handful of contributors. Someone (or more) working on Babel full time would be great: if not code, then project management. We’d also love to have:

  • Contributors from big companies. Babel runs over all the JavaScript code of a lot of websites. We’d love help from other companies in addition to eager volunteers. In particular, we’d love more contributors from standards committees (TC39). We’ve seen progress from those conversations.
  • Contributors doing things that aren’t necessarily code. We can improve our documentation, DX with less dependencies and config, easier setup (babel-init), integrations with other tools (automatically configured via create-react-app, and more
  • Contributors from underrepresented backgrounds. We’ve been accepted as a Rails Girls Summer of Code project and are looking for teams to join us, or anyone really, if they’re looking for mentorship

What will your story be?

Learn how to run a successful project

Open source is made by people just like you. Learn how to contribute, launch a new project, and build a healthy community of contributors.

Read Open Source Guides

An easier way to contribute to open source

Every Friday, invest a few hours contributing to the software you use and love.

Contribute on Open Source Friday

Meet other maintainers

Brett Cannon

Brett Cannon made his first open source contribution more than 15 years ago. Now a Software Engineer at Microsoft, he’s still a core contributor to Python, a project he has contributed to for more than a decade.

Russell Keith-Magee

Russell Keith-Magee created BeeWare to fill a gap in his own process. Today, BeeWare is the go-to project for supporting Python on every platform.

Tim Graham

Tim Graham started contributing to Django as part of a college research project. Now he helps maintain the popular web framework full time as a Django Fellow.

Get started for free

Public projects are always free. Work together across unlimited private repositories for $7 / month.

Sign up for GitHub

Subscribe to GitHub Open Source updates

Add your email address to get occasional open source updates in your inbox.