Henry Zhu // @hzoo

Henry: There’s a conviction, a positive, dream or vision that you have about things. I mean, that’s not true for everything, but I think for something like a startup or in this case, open source full time, I don’t see what else would convince you, your rational brain to actually do something like this.

Brian: That’s Henry Zhu, maintainer of Babel, and this is The ReadME Podcast, a GitHub podcast that takes a peek behind the curtain at some of the most impactful open source projects and the developers who make them happen. I am bdougie aka Brian Douglas…

Kathy: And I am Kathy Korevek.

Brian: Every episode, Kathy and I invite a maintainer or open source developer into our studio to explore their work, their story, and where the two meet.

Kathy: In this episode, we speak with Henry Zhu, maintainer of Babel, a Javascript transpiler. In our conversation, we discover how Henry first got into programming, what it means to be a maintainer of Babel, how he builds community, what are the challenges that he faces and, of course, the triumphs.

Henry shared his story with us, starting right from the beginning.

Henry: My parents are in software as well. People like to say that says something, “Oh, it’s in your blood,” and stuff like that. But, what I usually point out is that they did not really encourage me to do programming because they were concerned--I had some health problems early on. There wasn’t anything serious. It’s not cancer or anything. It’s just I think a lot of kids now they grow up with allergies. So I had that, especially peanuts and those kinds of things. And even back then, people weren’t as concerned about those as before. I remember going to school and people would bring food all the time that had peanuts in there. I remember going on the airplane flights where they still serve it.

But, I had Asthma. I have eczema still. So a bunch of those things kind of just add up when you’re a kid and I think it’s easier to kind of look back and be well, that’ll suck. And it did, but I honestly, a lot of it did help shape who I am in the positive way of just being able to write to other people that are dealing with stuff.

So I kind of learned that I liked programming on my own. I think it might’ve been through...I mean, people will say this, like video games and, “Oh, I want to be able to make things,” I think, early on.

I think you just want to be creative and it seemed that you only needed a laptop or something small to be able to try things out. And I think I was interested in that. So I think I was looking into stuff like Flash animation, which is funny. Because I ended up working at Adobe, but then I never really learned how to use any of our stuff.

But I guess, because tech is so... I’m not going to say it’s not to be important, but just like such an important ubiquitous part of our life now that like... If you say you’re a programmer, people think certain things about you. “Oh wow, you work at this place.” Or “You are doing this...” There’s an aspect of, I don’t know, like influence, I guess.

Kathy: Does that change when you say you’re an open source programmer?

Henry: That’s a good question. I think half the time people don’t know what that is. Right. My distillation is, it’s Wikipedia, but for code or something like that, which tends to work. You just try to use things that they know. Because my definition I think tends to change based on who I’m talking to. But, then they’ll ask you like, “What do you work on?” It’s a fun little deep dive into what open source is or how they think of it. And the question of “How do you make money? Because you’re doing it for free.” And I think that’s the cool thing where, I feel like a lot of jobs, if you just say you work at someplace--”Oh, that’s cool.” But then, when they start asking questions that they might not normally ask for a normal job. And they have a lot of opinions on that or it’s more relatable because it’s not really technical, like some of the questions.

Kathy: Henry did go on to becoming a programmer, and a well known open source one. Open source is ubiquitous in programming but very few programmers choose to contribute directly with technical contributions. It was at his first job that he discovered an interest in continuing to open source through his co-worker and now his GitHub sponsor.

Henry: His name is Jonathan Neal and he worked on a project called Normalized.css. And it’s funny because I actually reached out to him recently and I haven’t talked to him for five years, since he convinced me to do open source. And all he did was just say, “Hey, you should try it out.” And to me, it was like, one person was telling me, “Hey, this is possible.” Because I think I stumbled into it, with like “Oh, there’s Bootstrap.” And then I tried it out and it’s like, “Oh, this is open source. People actually work on this stuff. I wonder who it is?” And he was like, “Oh, you can do it too.” I just needed someone to tell me it was okay, I guess, which is kind of interesting, right? Someone that you knew in person, not just someone online that was kind of... If I tweeted out right now, “Everyone should do open source.” Maybe that would help some people, but I think a lot of times you just need one person to be there for you, to say, “It’s okay to start.”

Brian: Yeah. I was going to say that’s huge having that mentor, having the person to shepherd you into the project, it makes the biggest difference between just sort of randomly grabbing an issue and hoping for the best. So what was the introduction to Babel that eventually made you decide to do it full-time?

Henry: My short thing is that, when I got into programming again, it’s through games and then I got into data visualization a little bit with D3, briefly. Because I was like, “Oh, this is cool.” I cared about data. It’s so funny. I’m talking about data all the time, right? I think I wanted it to be doing statistics and data mining or whatever it’s called--machine learning, all that stuff. And then I realized I care more about the people side of it. I don’t want to use the words “optimize people,” but how do you help people be more effective at what they do without necessarily the numbers stuff? So I went away from that and I was like, visualization is cool because you can see the effects of moving things around.

And then when I was working at that company in Georgia, we were using a linter, a JavaScript Linter called JSCS. And Atlanta is just a spell check for your code. And it tells you when, either things could be wrong or you can have different spacing or quotes, stuff like that, right? And people tend to use, at least in JavaScript, we use ESLint and Prettier. So that was an old version of that. And the way linters work are very similar to compilers. And so, somehow through GSDS, I found out about ESLint and through ESLint, I found out about Babel. And then I slowly found out how they were related. Babel converts code, your input to output, but linters just read your input and throw an error. And so the first part of it is very similar. It’s just a little bit more added on.

Brian: The discovery of Open Source would eventually change the course of Henry’s life. He was hired at Adobe, for what seemed to be his dream job, but eventually quit to do his dream job, maintaining Babel full time.

Henry: Yeah. I guess some people would ask, “Why did you decide to quit? Because that sounds like a great gig,” and it was. And that’s a huge conversation into... I guess it was a pretty personal decision to do that. And in a lot of ways it’s not… what we use, like “the right thing to do or the smart thing to do” in the moment if you saw everything on paper. But that’s sort of... Even talking about the allergy thing, you kind of have to take a risk. Like some level of risk, right? Otherwise, I would just not eat anything, and same with this. Otherwise, we’re just going to stay at our job forever. And I almost... At this point I feel like there’s times in your life where not leaving is its own risk. Because I think other people are like, well, “Aren’t you supposed to stay in your stable job?”But you know, they could let you go, your team might get removed or various--anything can still happen. It’s just that we’re trying to hold onto this sense of confidence and stability because of what we’re used to. And I was like, in some sense, leaving is its own form of stability, which seems kind of counterintuitive.

Kathy: Talk a little bit more about that. I’m curious. What gave you that confidence in knowing that that was the right thing for you?

Henry: Yeah, that was definitely really hard. It is very emotional. If I was trying to calculate all these things: how much money do I need? I did all those things. My parents were very concerned. They’re like, hey, make sure you can sustain yourself and figure out how you deal with insurance and healthcare and your apartment and all of these things. But I felt like, even when I figured all that out, all that stuff didn’t help me make that decision in the end.

And so that’s why I feel it’s still a leap of faith. You can pretend that you have all this certainty through the numbers, but I think the way we usually act is pretty emotional, right? There’s got to be, what I would say, there’s a conviction, a positive… dream or vision that you have about things. I mean, that’s not true for everything, but I think for something like quitting your job, to do something on your own, like a startup or in this case, open source full time, I don’t see what else would convince you, your rational brain to actually do something like this.

Kathy: Taking that leap, from a full time, consistent job to working for yourself is a big one and not for the faint of heart. But it’s in those moments where we veer off from the expected path that we really grow. When Henry left Adobe, he became the maintainer of Babel and it was a huge learning curve. There are so many lessons he learned along the way, like this one.

Henry: Actually just one off the top of my head of getting into Babel: You don’t actually need to know that much about a project to get involved in it. Like I said, I knew a little bit about linters through my experience working on the other project, but I didn’t know anything about compilers. I didn’t study computer science in school. I never took a class on it, I’ve never read the books on it. I think most of the people on our team have never studied it either.

Brian: Do you think that’s an advantage though? An advantage that there’s no CS degree or nothing, sort of, institutional knowledge blocking you from building something like that.

Henry: Yeah, there’s definitely a trade off, it can be good and bad. So I think the general sense would be if you’re new… being naive, it’s a good thing. Because it will let you try things that other people would say is impossible or that’s just dumb or a bad idea. You’ll do it anyway because you want to learn something or prove something to yourself or other people. And that’s why these projects come about. And all the older people might criticize that, “We’ve already done this before.” Well, yeah, we’ve done this before many times. This is just the newest iteration of it. And that’s just how things move along. And maybe in JavaScript, we like to complain that there’s always new things happening, but that’s true of anything I guess.

But yeah, I guess the other thing is that if you are new, you might not look into the history, so you could be reinventing the wheel and it would be nice if the people that have been around longer and the people that are new would talk to each other more. We’d probably learn a lot more, but, that’s a huge...That’s an interesting topic too.

Brian: There was a good blog post about this, Steve Klabnik, who’s from Rust fame, as well as Ruby and Rails. He wrote about how the Ruby community rebuilt everything that was in Java. They just wanted not to be Java, the entire time, to the point where they just built everything that was in Java including the JVM, which is the RVM, that sometimes you could spend way too much time not being the thing that you’re trying to not be and then build up the entire library system and standard library that already exists in another language.

Henry: Yeah, that is interesting. And you might say that’s a waste of time, but I think you have to look into assuming that the people that did this.. I mean, it’s a lot of work to make a whole language from scratch. So you would hope that they have certain values and things that are opposed to the previous work. So if they cared about flexibility or expressibility of a language and that’s not true in the other language, then they would have to prove that out. And it’s not necessarily a waste of time, because they probably weren’t going to contribute to that language in the first place. So I wouldn’t fault them for not helping with the old stuff.

Kathy: I have this idea that there are people out there who are using Babel when they don’t even know that they’re using it. And I wonder if you’ve ever encountered anybody who is like, “Oh my gosh, I totally use that.” And, how do you feel about that?

Henry: Yeah, yeah. Actually all the time. I think in some sense it’ll happen more as time goes on. Given the nature of our project, it’s a build tool. It’s not a framework. You’re not looking at the documentation all the time. So unlike a React or a Vue, you’re not writing. You know how people would say, “We write React components and you’re looking for a React developer.” No one’s saying that we use Babel and we’re Babel developers. No one says that. It’s just already implied. And so that’s why it’s never going to be top of mind. And the only time you notice Babel is when it doesn’t work. And so everyone’s always going to have negative opinions on it, for the most part, unless you’ve never encountered a bug and that’s probably true for 99% of people. And so like, “Oh, this is great.” But some people try to push the limits of how these things work. I don’t feel bad in the sense that… no one has to know who I am. That’s not an obligation because they use it, that’s true. But at the same time, that hurts my ability and our team’s ability to sustain the project. If nobody knows who we are, how are we going to convince anyone to fund us or sponsor us?

You need some level of awareness, if that makes sense. So I like to say that there’s these two extremes of knowing a maintainer. Either you don’t know they exist, right? And it’s in your stack, but you don’t even know that there are volunteers working on this thing. You think it’s a company, you think Facebook’s working on Babel or... It’s a black box. The opposite is when they finally meet you. “Oh yeah, this is Henry. He works on Babel.” And they say, “Oh wow. I use Babel.” And then suddenly you’re this celebrity that is this programmer God. And they don’t even know how to talk to you anymore. And it’s like, dude, we’re still people. That’s hard.

BRIAN: Babel has been sustained through a variety of means like GitHub Sponsors as well as Patreon, and Open Collective. But the other part of sustainability is attracting community contributions that will keep the project going. It is more than just contributing code, but contributing to the project holistically and not just looking for a good first issue.

Henry: If you think about it in open source, they need to be able to make contributions or whatever. But then if we do think the project isn’t about code, I don’t want to say it’s a feeling, because that sounds bad. But you could say that they have some kind of passion in something, or maybe you see a lack in your project and you see that they could help out in that way, right? So it doesn’t have to be that they made a PR, which I guess that makes it easy. You know, this person made a few PRs and they got merged and they’re continuing to respond. That’s a pretty easy win. Let’s just add them in and ask if they want to continue to contribute. But, if it’s for documentation or making content like videos or livestream, all these other things, then it’s almost like you need to go out of your way to look for these.

Because, the thing that you’ll probably normally see is the people making PRs, because you’re on GitHub. But I mean, in that particular sense of the PRs. But if they’re on GitHub for different reasons, like they’re commenting, maybe they don’t notice. Or they’re in your Slack or Discord or on Twitter. And of course that’s another amount of work that they have to do. I don’t know how much of that can really be automated. Honestly, I think GitHub could probably signal certain things to people, but that doesn’t mean they have to suggest that people do it. Being able to show that to maintainers could be helpful if they happen to see it.

Kathy: Yeah, totally. I was listening to your podcast and there was something you said about the differences in different communities. When you’re on GitHub you’re kind of thinking about work even though you’re interacting with this broad, big community. And then when you’re gaming, you’re still interacting with a big community but there’s just this different feel to it. And there’s this thing with gaming where, back when a lot of games were being developed, you could go and be mean to other characters and then game developers started to give you different incentives to be nice. And I wonder if there are things within your community, within Babel, that you try to incentivize people for, that you look for, how other people are treating each other.

Henry: I don’t know if there’s anything in particular I did to make it easier for people to be nice to each other. I rely on the fact of either meeting in person or doing one-on-one with people to kind of build a personal relationship with people. It’s really easy to just chat through a text kind of thing, Slack or something. And you can do all your work, which is very transactional, right? But slowly you get to know people. And I think that builds trust. And unfortunately we can’t really meet people in person anymore. So there’s that. Unfortunately the platforms that we use are very transactional, in terms of everything’s about the numbers and notifications and how many PRs are open, that’s what’s emphasized and that’s the culture that we’re in. And it is really hard to push back against that kind of thinking because that’s what’s measurable.

Gaming has historically dealt with a lot of toxicity in its own environment, so they have to make all these tools. But the example I made of an actual design that a game did to make things, not possible to do this, is a game called Journey on PlayStation. It’s normally a single player game, but you can play with other people. But they purposely didn’t allow… You can’t text anyone. You can’t chat with them on voice. The only way that you interact is you kind of find them when you’re doing your own thing. But then, in the game you can jump around and glide. But when you touch the other person or you’re near them, then you get your jump ability back.

So you have an incentive to always be with them because you want to be able to fly farther with that person. And there’s no way to troll them or do anything negative. So it incentivizes you to always think of them as someone that’s helping you. You can choose to go off on your own, but I think most people do tend to stay together for the duration of the whole game. And it’s a pretty short game too. And the cool thing is at the end of the game, they tell you who the person is. Write their screen names, if you want it, so you can reach out to them. Otherwise, it’s just “Bye,” and we’ll never see them again.

Kathy: Building community is about communication. Tools like Discord or GitHub Discussions can really help. But, regardless of those tools, how we communicate is key, not only on GitHub but in our society as well.

Henry: Maybe that’s why people are trying to find smaller groups of people where they can talk to certain things. So like the Vue idea, they supposedly worked on that in private, right? And then people would call them out and they said that was really bad, but there’s a reason why they did that. They are still figuring out what Vue 3 is supposed to be. If they just told everyone that, then it’s just going to cause miscommunication. And so they’re like, “Oh, why isn’t everything open? Isn’t it open source?” And I think people have a very specific definition of what open source is.

Kathy: What’s your definition?

Henry: I don’t know if I can put a definition anymore. In the terms of... it depends on the context. You could say the baseline is that yeah, your code is out in the open. It’s free. That’s the base. But sort of like when we say that open source isn’t just code, there’s this whole ecosystem around it. In the sense, it’s like a worldview that shapes how you think. And so if I want to bring in faith, you could say that being in a religion is just believing in God. You could say that. And that is true, but that reduces the faith just to belief. It reduces the faith to just your mind. It doesn’t relate to how you live your life.

And you can say that’s the same as you go to church on Sunday or you go to church on every Christmas or something or something like that. Or I’m always on GitHub every day. Where are you spending your time? What are you thinking about? I think those questions shape what you might believe open source to be.

Brian: Yeah. I think the correlation that I would make from that, with the church and religion is that I could be a user of Babel, it doesn’t mean I’m part of the community. And it also doesn’t mean I’m a contributor or a maintainer, but I happen to know how to change the sort of flags inside the Babel JSON or what not. So I think maybe that’s like the correlation we can, I guess, land that home.

Kathy: Since you brought up church, I was going to ask how they’ve been able to support you as you’ve been on this journey.

Henry: I mean I feel like other than just going to therapy, maintainers, just like all people, we need people to talk with. And I think unfortunately the way that we do it a lot of times is to rant about it on Twitter. And then that doesn’t feel good, complaining about how you’re in this position of doing open source, and then people will think you’re not grateful for it or whatever. You tweet little screenshots about people saying mean things, but really what you need is to know that people care about you, they appreciate the work you’re doing. And also that you’re not alone. So I wanted to have this idea of, we should have what I called, Maintainers Anonymous, right?

It’s getting together and just talking through things. We don’t have the answers, right? But just knowing that other people are out there might help you to sustain yourself. And I think when you go into a therapist or being in church, it’s an opportunity for you (assuming it’s a safe place for you to talk), you can be vulnerable, you can share the struggles that you’re dealing with. And a lot of times they’re not that different from work-related, personal issues too, right? Within people or friend groups or your own family. I think that’s really helpful, a consistent group of people that you can meet up with and do that. Unfortunately, I think church in the current state of things has its own problems, the same because of the pandemic, of not being able to meet in person. And I think that there’s a lack of intimacy, just like we’d started doing our meetups and conferences online and it’s like, is it the same?

Brian: I’d ask too as well, taking that same correlation of church and how it operates in, you’ve experimented with small groups and how that’s working and potentially doing in-person house church, that same correlation to open source and your community. I know you made the jump to do this full-time. And I know for me, like work, you tend to have your small group, your community at work. So that community didn’t exist for you for work. It potentially was in open source. So did you find community in a similar way through contributors, collaborators, or Maintainers Anonymous as you mentioned before?

Henry: Yeah, I think with open source it’s, unfortunately and fortunately, the whole point is that it’s distributed and remote. So, everyone on our team does live in a different place. And I think there was a point where... maybe that’s why I decided... I didn’t really like going to conferences much. But then I started doing it the last two years or so until COVID, and being able to meet up with a lot of the maintainers that are on the team in person for the first time, which was pretty great. And I think just meeting once in person really helps build that connection when you finally meet online as well. Yeah. It’s weird saying that the answer is, “just meet in person,” but that’s how I feel.

Kathy: Well and then you get to see how tall people really are. When I first met Brian, I was like, “Oh wow, you are really tall.”

Brian: I was going to add, too, as well. So we actually met in person a few times, but I think probably the last time we met in person was Maintaineratti last summer, for GitHub Satellite, there was an extra event. And at that event, what I took away from that is a bunch of maintainers, similar to Maintainers Anonymous, talk about all the insights of their projects. And one thing that I took away from it was that most maintainers, they start with the code thing, but they quickly move into all the other things, which is the community, the developer relations, the sort of getting everything coordinated and releases, and RFCs. So I’m curious, today, how do you maintain that? As well as, even… again, we’ll continue to use this church analogy. Sometimes you could be looked at as this sort of embodiment of the project, maybe the “messiah” of Babel. And so how do you sort of combat that and be able to still be able to delegate and feel like people are involved?

Henry: That’s a good analogy because I mean, at least in Christianity, it’s supposed to be all about Jesus, not about the cult of personality. That’s totally a problem. I don’t know. There’s definitely a lot of delegation. And then also letting people have the spotlight. And it’s really hard because I don’t know how things happen, but why am I the one that people, for some reason, associate with the project, rather than all these other people on the project? And a lot of it might be because they don’t really want to be in front. They do only want to do the code, and I don’t want to push them to do things they don’t want to do.

But sometimes I’ll ask them, “Hey, you should give a talk or you should be on this podcast,” or something like that. And getting them to think a little bit more holistically about the project, because I think that that will help them be a better coder anyway. And yeah, I’ve kind of stepped away from doing the main, I guess, coding as much, even though there’s plenty of work to be done everywhere. I guess it’s sort of, it really is an awareness, right? It’s like when you start off, like what you said, Brian. It is all about code. And then slowly as you get part of the community, you meet more people, you see that there are all these other parts that are probably not even being done. And then you see a lack and maybe you want to contribute in that way.

Or at least you’ll point it out. And we’re never going to finish any of it. Just like the inbox zero stuff. It’s the same in all the non-measurable things too. And you have to learn to, and I haven’t really learned this, but you have to learn to be okay with not finishing everything.

Brian: Are there Babel disciples? Are you setting that up?

Henry: No, I haven’t set it up like that, but I do think this, the idea of membership is really interesting. So church has membership and you might have to go through a class. It’s just a way of showcasing commitment and responsibility. And I think that would be beneficial to have in open source. It’s not to kind of do an in-group, out-group thing, but it’s more of like, okay, we can rely on you for this. And maybe that requires even the aspect of terms where you don’t feel like you’re going to serve forever. And unfortunately the way things work culturally now is that you feel like you’re going to have to be in... If maybe I feel like I have to work on Babel for my whole life, even though obviously I don’t have to, I can leave at any point. There’s a lot of thinking around that freedom and what that looks like.

Kathy: I think it’s safe to say that all of us, whether we work in a traditional job or we work for ourselves, have thought about what it would be like to leave. It’s just part of being alive, questioning what would it be like if...And I am sure Henry has felt that way.

Henry: There’s definitely many times where I’m just like, “I don’t know if I want to do this anymore.” I even felt this recently with the pandemic, of all these things are happening, what am I even doing that’s going to help with this situation at all? I’m just doing open source and it’s this really random tool that has nothing to do with healthcare and all that stuff. You can argue that’s in all these websites, but it’s a very secondary thing. This is interesting, I read this essay from CS Lewis of all people, and he actually had this thing called Learning in Wartime and he was talking about how… I think he gave a lecture to a bunch of students, they’re studying literature or something, and this is during the war.

They asked him the same question, “Why am I studying the arts and math, when this war is going on? Is it even worth working on?” I think that’s the same feeling that we have. He was saying that if you thought that way to the extreme, then you would never do any of these things. It’s never worth it to study literature because there’s always something bad happening. We are always going to be in this conflict, whether it’s war or something else, people are going to die and all this stuff. You have to, I guess step a bit back. It doesn’t mean you don’t think about the thing at all, but it shouldn’t be the only thing focused on your mind because that will overwhelm your senses--you know, the whole doom scrolling thing, right?

How do you balance what you’re living for and what you’re willing to die for? I think the thing that you’re living for is not solving this war or the pandemic or whatever, that’s just a thing that will pass away, but we need to worry about it in the moment. It can’t take over everything. I guess the summary is honestly, think long term. It’s like you have a hope inside of you that things will get better. It’s still worth working on these things. I think we’ve been talking about that the whole conversation. You can’t know things for certain, and so you kind of have to take that risk. That means you’re risking failure, and you’re risking being wrong. That’s the leap of faith.

Brian: Excellent. I was just going to say that I drew a lot of those correlations in our conversation, between how you’re managing community and your church, managing community and Babel, and sort of doing this whole open source thing. I think the conversation in just general, I truly appreciate you being so open with us and being able to share your maintainer story, I guess.

Kathy: I’ve been thinking a lot about the spaces we occupy as we continue to talk to each other on Zoom. I’m in San Francisco, Brian’s in Oakland, and you’re in New York. But we’re all talking to each other, we’re here with each other on Zoom, but where are we? And I met you online today and it was really, really great to meet you. Thank you so much for doing all of this.

Brian: To learn more about Henry and his work on Babel, you can check out his feature on The ReadME Project, GitHub’s ongoing effort to amplify the voices of open source software at github.com/readme. His site, Henryzoo.com or tune into his podcasts, Hope in Source and Maintainers Anonymous.

I am Brian Douglas, and I am a developer advocate here at GitHub.

Kathy: And I am Kathy Korevek and I work on the product team here at GitHub. The ReadME Podcast is a GitHub podcast that dives deep into the challenges our guests faced and how they overcame those hurdles. In sharing these stories, we hope to provide a spotlight on what you don’t always see in the lines of code, and what it took to build the technology that inspires us all.

Brian: It has been such an extreme pleasure to spend time with you. All music here has been produced by the wonderful Dan Gorelick, using Python, the programming language for everyone.

The ReadME Podcast is produced by Sound Made Public for GitHub.

Please subscribe, share, and follow GitHub on Twitter for updates on the podcast as well as all-things about GitHub. Thanks for listening!