How it'll appear as a card

How it'll appear as a web page at github.com/customer-stories/hzoo

Customer story

Henry Zhu


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
  • project


  • location

    New York City, New York

  • day job

    Software Engineer at Adobe/Behance

Bring GitHub to work

From flexible hosting to data‐powered security, get everything your team needs to build at their best.

Contact sales