Henry Zhu Chats With Kent About The Human Side Of Open-Source

Kent C. Dodds: Hello friends, this is your friend Kent C. Dodds, and I'm joined by my friend Henry Zhu. Say hi, Henry.

Henry Zhu: Hi Henry.

Kent C. Dodds: So Henry and I go way back. The first time I remember seeing you on the internet was with Babel ESLint. And I don't think I've ever told you this story, but I remember Sebastian was like, "Hey, I can't maintain this project. And all the others, so I can't do this one anymore." And you mentioned, "I could do it." And I remember seeing you and I was like, "This is the first time I've seen this guy. Who is this guy?" He thinks he can manage this project. And so I went and saw that you'd been involved in JSCS and stuff like that. I just remember thinking that. And then of course, now you're the head honcho maintainer at Babel at this point. And since then I've gotten to know you and it's been a real pleasure. So yeah.

Henry Zhu: Same.

Kent C. Dodds: Why don't we just get to know you generally, for those who don't know you very well. If you could just tell us a little bit about yourself before we get into our conversation. I'm sure people would love to know more about you.

Henry Zhu: Yeah, so I'm Henry Zhu. I mean that's kind of a good intro. Honestly, I got involved in open source because of a project called JSCS, which is a JavaScript linter. And it was kind of related to JSLint and then we ended up eventually merged it into ESLint, which is why you have never heard of the project at this point. And so I was in that conversation with Nicholas and the team to help merge the projects. Because you don't see that often in open source. It's always like forking things or whatever. And I think other people were burnt out and they were doing the same thing. Might as well combine forces. And yeah, I think I probably thought the same thing as you. You were saying, "Who's this random person trying to take over this project?"

Henry Zhu: Yeah, I was a random person. And I don't know how I ended up in this position because when I was at Babel ESLint, I eventually maintained that and eventually was one of the few people that just happened to be involved in Babel. And then when Sebastian got burnt out and he left, I just was one of the people that had to step up. I mean, not like I had to, it's just I accidentally was in that position and then I just had to learn all of it and it's not like I knew how to be a maintainer or anything about compilers, honestly. You just somehow made it work. And I think looking back, I don't think I would give someone the access to this now that we know about left-pad and EventStream, all that stuff. Maybe it's a really bad idea. But, somehow it worked out and I guess I'm grateful that I had the opportunity because I'm not that much of a great programmer in terms of everyone else that's doing stuff. It just happened to work out, so.

Kent C. Dodds: Well.

Henry Zhu: Yeah.

Kent C. Dodds: I just happened to know that you've done quite a bit of coding and I would say that you're a great programmer. But lots of programming is persistence as well. But you've done some really awesome things so thanks for that. I'll let you finish your telling us about yourself.

Henry Zhu: Yeah, I guess just real quick, I maintain Babel right now as one of the... I'm the only person working on it full time and when I say full time it doesn't mean I'm like spending all my time doing it. It's just my intention is to spend my... I'd be calling it my job to work on this project because I just quit my job at Adobe, so I quit like last March. So it's been almost a year and a half now and I'm fully funded through the community through OpenCollective and patient [inaudible 00:03:45] on GitHub. And yeah, that has been I guess a dream come true.

Henry Zhu: I know it's a lot of people's dreams to do open source full time. Probably one of the few people that I was able to do it. And so yeah, I've been trying to figure out how to make that work for myself, our team. And then just thinking about open source in general and trying to help other people and other collectives or other projects get funding. Or not even money related, how do you deal with the emotional side of open source, dealing with just being a maintainer and managing that with your regular work life, all that stuff. And then just on personal stuff. I'm pretty into video games, board games and ping pong. Yep.

Kent C. Dodds: Nice. Yeah. What are your favorite board games right now?

Henry Zhu: I've been pretty into Seven Wonders and then lately a lot more, you could call them party games because not everyone's like super hardcore into board games. But Codenames is really good. Dixit and recently I got this game called The Mind, which is really great. And I actually wrote my last newsletter just about that game because I thought it was interesting. So I might come up with a blog post about how I think that relates to other things. It's really cool. It's a game where, just I guess, to explain it, it's a game where you are supposed to technically read people's minds and it sounds weird, but essentially it's just a deck of cards from one to a hundred and you deal out cards to each person and there's multiple levels. Each level like level one you have one car in level two everyone has two cards, but you're supposed to play the cards in order from ascending order but you can't talk to anyone.

Henry Zhu: So if you have the one you have to play it right now. But if you have the 10 you should probably play it soon, but you have no idea who is supposed to go. And so you know you can be kind of lenient with like how you communicate like body language. But it's really fun because there's scenarios where it's like it just seems impossible that it happened. But say I played 19 and someone played 20 and then 21 and then 22 and nobody said anything. It just happens, right? So there's really cool moments that you can have and it's not, it sometimes doesn't even feel like a game. It's just like a way to bond together in this shared experience. Yeah, it's really interesting.

Kent C. Dodds: That's fascinating. So it's like a collaborative game. You all win together kind of thing.

Henry Zhu: Yeah. Yeah. Or lose together.

Kent C. Dodds: Yeah. That's a fun game. That sounds very interesting. You'll have to bring it to the next conference.

Henry Zhu: Yeah! Are you going to React Rally? It's, yeah.

Kent C. Dodds: Yeah, are you going?

Henry Zhu: Okay? Mm-hmm (affirmative) Yeah. I'll bring it then.

Kent C. Dodds: Yeah. Fantastic. Well by the time everybody listens to this, that'll already have happened.

Henry Zhu: That's true.

Kent C. Dodds: I'm sure we had a great time. But yeah. Cool. So I always love talking with you because you have a really unique perspective on the world of open source being a full time open sourcer person. And recently you haven't been doing a whole lot of coding with the open source work that you've been doing, which is interesting. And as a maintainer, I know that most of maintaining a project is not coding but pretty much not doing any coding, recently. I wanted to ask you a little bit about your strategy there. How do you maintain a project or even contribute to a project without actually coding?

Henry Zhu: Yeah, so that's a really hard question because... And this kind of gets into, not even open source, like how do I parallel with people that are not maybe streaming now is that when you get to a point where, "Oh maybe I should be a manager." That kind of thing. I think it's the same problem and I've never been a manager. I've always just been a programmer at a company. I never really thought about getting promoted and all this stuff. And I think that transition is hard because what happens is you go from... I think we tend to value our work based on how many commits or pushing out features like shipping things, right? And when you become a manager you're not writing code either, probably not as much at least.

Henry Zhu: And so your evaluation is around people, how they're doing, how do you bring move them up towards the goals that they want. And so I'm basically doing the same thing with our own team. And before I was like, you feel good about like making commits, fixing bugs, merging PRs, all these things. And now I don't have that anymore. So how do you even measure if you're doing well and you always feel bad because you always want to go back to writing code. Because it's not just easier because you're used to it but then also easier to measure. And so it's been kind of hard. It's definitely taking this whole year to feel like, "Okay I don't feel guilty not writing code." Basically. Not even because I think I should be writing code, but then other people might think I should be writing code too. Because I think we all have this expectation that maintainers should be writing code. But then also maintainers know that, not even just the code, but triage and merging things, releasing process, onboarding, marketings, documentation, testing, making videos, giving talks.

Henry Zhu: There's a million things you can be doing. And they all help the project. And if our goal is to make it sustainable for a long run, I don't think... Well the way I was thinking about is I don't think long run it would be good if I just spent all my time fixing bugs and making the issue count to zero when I know the rate of which is going to go up, and the users that we have, it's just not possible for one person.

Henry Zhu: So if anything, the way we should be spending money or the way I should spending my time is to figure out a way to get more people involved. Either in new contributors or companies or getting more funding. These other things which take a lot longer time and the feedback cycle is a lot longer, but I think it's worth doing. That's what I've been trying to do with the podcast or giving talks. Trying to be more experimental even. Just try new ideas. And you have to be okay with failing and doing that. And that's hard because there's no standard or like, "Oh I'm supposed to do it this way." And that's kind of scary, right?

Kent C. Dodds: Yeah. And there's a bit of the unknown and then that peer pressure that you mentioned as well. It's tricky, especially when people are financing your decisions. You feel an accountability toward those people and making sure that you're doing right by them. Which, as a maintainer of projects, I know that, yeah, you can spend a lot of quality time on the project without actually writing any code.

Kent C. Dodds: So you mentioned a bunch of things that take up your time as a maintainer of the project that don't involve writing code. What do you think? Let's say that I'm a new person in the open source world. I want to get into contributing open source. I'm probably thinking, "Okay, I need to write some code to..." That's kind of the default is when people say contribute to open source, they're thinking code. What would you say to somebody who's just starting to get into open source as a good way to enter that realm? Like maybe somebody comes to you and says, "Hey, I think Babel is a cool project. I want to get involved." What are the kinds of things that you say to kind of help them get into the open source?

Henry Zhu: Yeah, I mean, I think you've talked about this a lot too, but in the there's no... Because the defaults code and there's so many things to do. Think of it as a company or just a volunteer project. I know there's no blanket statement I can say about what you could do, but I think honestly the best thing to do is just to talk to that person and figure out what they like, what they're good at, what their background is like. I would say something like, "If you already have a coding background and you're just writing code at work already, then maybe your first contribution could be code because you're..." The open source coding and that is not that different. I like to say it's like when you join a company, all the code is on the [inaudible 00:12:00] too, right?

Henry Zhu: You have to get onboard and learn all this stuff. It's just that you're getting paid for it and someone's supposed to be your mentor. But honestly it's the same thing with open source. The code base is also unknown. It's just more visible and in that sense it shouldn't be that different. Although it will be harder because you have to find someone to help you. And maybe, I don't know, for some reason at your job you're more willing to figure out how things work and it depends on the complexity of the project, obviously. Maybe if you think that this project is really big, then maybe it's better to find a smaller project. Or the big project has smaller scope projects for you to look at. I think otherwise I would look at some of the skills that you already have outside of coding or maybe you don't even have a coding background at all. Maybe you're in finance or you're doing business or you do art. I think there are other opportunities to make a difference on the website, or all these different ways. Yeah.

Kent C. Dodds: Yeah. It's multifaceted. The things that open source projects need. Yeah. So you mentioned if you're into finance or something like that, then you can contribute to open source. Which made me think of my next question of why would somebody want to get into open source if they're not going to be contributing code? One of the things that I say to people about when people ask me if I can be their mentor or something as they say, well I never really had an official technical mentor. I just used open source as my mentor. And then I had hundreds of people who were responding to my PRs and stuff like that and mentoring me in the open source world. And so that was one of the benefits that I got by contributing code to open source. What would you say are some of the benefits to contributing something other than code to open source?

Henry Zhu: Yeah, I mean I would say that it's a good way to get involved in open source as a project because... I mean, this is assuming that you want to get involved the first place. So maybe, why would you want to do it in the first place? Well, I would say that it's a type of, I don't know, what do you call it, a thing that some of the values that at least are shown through the project are different than in the world where it's you gave it away for free. It's so funny, even at church, I'll tell people... They're like, "What do you do?" It's really hard to explain what I do now, but if I just say open source, I'll be like, "Well I write code and I give away for free." Or something like that.

Henry Zhu: And they're like, "Why would you do that? How do you make money?" And all these questions come up. But people are very interested in that because there's not a lot of things like that. And so just because they want to get involved in the community that's bigger. You could say it's used by lots of people, that kind of thing. You're giving back. I think that's a good reason. And if they want to get into tech, I would say, "One way of getting involved without having to necessarily say I'm going to get a degree, all this stuff, is to do open source."

Henry Zhu: I guess I'm just saying that being involved in the community is a lot more than just making some commits. There's understanding who's involved, getting to know those people at a personal level, especially when there's so few people, and a lot of them are very available. Not that you're going to bombard them with questions, but slowly getting involved. It just takes time. You can't just show up and then expect all this stuff to be given to you. But if you're there people will notice and will talk to you. Most maintainers are more than willing to get to know people, especially if they're going to stick around because so few people do in the first place that anyone that shows up we're like, "Wow, we totally want to help you." Right?

Henry Zhu: And so yeah, even recently, we've had a few contributors that we added as a triage role, which is really nice that could help finally edit this [crosstalk 00:16:03] permissions model. Yeah, so to explain, normally you can either be like an admin, which lets you do anything. And then there's like commit access, which lets you merge PRs. But there's no access to let you only like say close issues, label issues, those kinds of things. So we're trying to figure out like, "Oh that's one way of slowly letting people get involved without overburdening them with responsibility or feeling like they don't deserve certain things."

Henry Zhu: So sometimes you might even add people, just give them commit rights really early, but then they don't use it cause they don't feel like they're qualified enough. So I think that's a stepping stone to help them feel more confident about themselves. Sometimes I'll give people access and then that means like, "Oh you can merge things now." And maybe I'll even suggest they do it. But then they're scared and that's normal. Because you never have done it before, you're scared you're going to make a bug or release all of this stuff. I think it's how do you help them get to that point? And that's one way of doing that.

Kent C. Dodds: Yeah, absolutely. And as a maintainer, you really want to give them that responsibility because when somebody has that gift of trust and responsibility given to them, they often will stand up for or rise to the challenge and become more involved. And so it's great that GitHub has added that new more stepping stone more... I don't know. Yeah. That role.

Kent C. Dodds: So we talked about contributing by triaging issues, which is a huge, huge help. That's so much of maintaining. And then also their support channels. So you a Slack channel, which I haven't been there in a little while, but when I was there were people posting things on there all the time asking for help and I seen lots of opportunity to get help or to help out and lift their... Designing the website or building the website or making examples for the website and also doing podcasts and the things that you're doing. I feel like there are just so many opportunities that you can contribute. And all of these things are kind of building around the open source project. How are these things, actual contributions, how does this make the project itself better? Because we're not actually contributing to the core code here so we're not actually making the software itself better. But by contributing to the things around the software, how does that make things better indirectly?

Henry Zhu: Yeah. So, that's a really good question. I think that that's what the aspect of community is all about. That inherently you have to be able to... The project is going to be broadcast in certain ways and so even through all those channels there are ways to contribute through that way. And so how are people going to know about Babel? How are people going to know how to contribute to Babel? It's going to be through the docs or videos or giving talks or doing podcasts. That's why now I have finally, "Oh maybe we should do a Babel podcast." Just because we talk about all these things by ourselves and like maybe all the conversations we have could just be recorded and we'd be interesting people because maybe we assume all these things that people would like to know about.

Henry Zhu: And it doesn't even have to be like the compiler. It could be about open source. What it's like. What are the things that we deal with on a day to day? What questions are we asking that we don't understand? All these questions we just brought up. How do we get more people involved? How do we get people where to stay? How do we find out what's best for the people? How do we onboard them? How do we organize all this, all the different areas of their project. If you have the podcasts and the docs, can people even find it? Is it organized in a way that makes sense? We could have copy editing like the way that we write things isn't like having a linter for your [inaudible 00:20:23]. So blog posts, all those things. Making it more cohesive I think.

Henry Zhu: And also probably the most important thing in terms of longterm thing is what's the vision of the project and making sure people actually understand what's this about, where is it going, those kinds of things. And those don't even... You can tweet things, you can write blog posts. But ultimately it's almost like, yeah, the culture [inaudible 00:20:47] of the project and what do people, when they hear about, what do they think? Is it positive? Is it negative? Do they understand what the difference is between say a compiler and a polyfill? Those kinds of things. And I don't think people do, that means we're not doing a good job of showing that. And there are other ways of trying to... So I think it is true that you still have to understand a lot about it, but I think being able to talk at a high level is really important.

Henry Zhu: If anything, me being able to talk to people at church or just other friends that are not in tech about what Babel is, and they don't know anything about JavaScript, and they still kind of get it, is a good thing. And it helps me communicate better with just any developer, honestly. I don't have to say that it's a compiler. I could just say it's a translator and I can talk about... I mean the name is Babel, those kinds of things. Maybe it's easier because we work on that, but I think being able to communicate better is really important. Yeah.

Kent C. Dodds: Yeah. One thing that occurred to me as you were saying some of those things, I've got a couple of things I want to talk about. So one was that when you're a software engineer and you're writing code, you think that like it's awesome that you can optimize the performance of this one branch of code and you're going to save, when you're talking about a project like Babel that's used by hundreds of thousands of projects, you're going to save a lot of people, even if you shave off 500 milliseconds, you're going to save a lot of people a lot of time. That scales very quickly and so you feel really good about that and that's a huge contribution. And it occurs to me that if you can improve the documentation in a way that speeds people up in learning and applying the cool tool, then you also save a lot of people a lot of time.

Kent C. Dodds: So maybe you give a talk that shows here's how you do this. Or you could build another tool around the tool to make it easier to use for a specific use case. There are lots of different things. So in that case that would be contributing code but maybe not to the core project. But there are a lot of different things that you can do that do make a substantial impact on the project. And maybe there's not really an easy place in Babel to speed it up even 25 milliseconds. But there are gaping holes in the documentation or something where you could speed up a lot of people by factors of 10 over that or something. And so where the needs are, is where the contributions are needed, I guess. And I think there's a lot of opportunity out there for people to contribute code or in various other ways.

Henry Zhu: Yeah, I think it kind of just gets to this issue, in my mind, of as a maintainer or any maintainer, we have to do a better job of showing people what's possible. If all we do is talk about code and we show, and we reward people for coding, then people are going to be like, "Oh, I'm going to write code." But maybe I should be more vocal about the fact that I'm not writing that much. Not that I'm doing nothing at all, but I'm not focusing on that. And that's totally fine. There's plenty of things to do. The fact that I can be full time and not do it shows that there's a lot of things that could be done. And hopefully that is helpful enough to people to say that, "Oh I can..." How do we get people to think a little bit different? Change their mindset around consuming open source and to say that...

Henry Zhu: We've been talking a lot about contributing and I think a lot of it has to do with knowledge and I've been thinking a lot more about this idea of process knowledge. They think that knowledge isn't just a bunch of bits. It's not just the information that's there but the process behind it, like the metadata and all that stuff, might not be in the docs and maybe we need to write it down. Or there are things that are just not expressible through the docs and you just learn it during the process of being involved in projects.

Henry Zhu: So a very easy example is when you're playing sports, you have a mentor that just guides you through it. Or you're learning to cook something. There are things that you pick up through the process of doing something that you can't take by just reading something. You have to be in the community, you have to be involved, you have to like it. And maybe even and you'll learn a lot more just showing up, and hopefully they'll show up with you, than simply reading a book or something like that.

Kent C. Dodds: Mm-hmm (affirmative). Yeah. I think that's very true. So we're kind of coming down in our time. There are two things that I want to make sure to talk about and one thing that we haven't mentioned that I just wanted to bring up for people is if you're a maintainer of a project and you want to encourage people to give these kinds of contributions, I'm not going to go too deep into this, but I just wanted to mention all contributors. If you go to allcontributors.org it's a great place that shows you how you can give back or encourage that kind of contribution, non code contribution, so definitely take a look at that. Then that's all I'm going to say about it. But I'd be remiss if we didn't at least mention that.

Kent C. Dodds: The one thing that I definitely wanted to bring up before we run out of time here is you have this podcast called Hope in Source, which is like open source, right? I love that. I think that's great. But it's talking about faith and its relationship and not necessarily relationship but the correlation, I guess, between faith and open source. And I'm curious, I want to hear just a little bit about your thoughts around that and how that applies to the kinds of contributions that we're talking about.

Henry Zhu: Yeah, so I started that podcast to... Because it wasn't like, "Oh I'm someone of faith." So then I'm trying to figure out what's related. It's just I got involved in open source and then after I was like, "Whoa." I didn't realize in the end there's a lot of similarities, and there's a lot of parallels, I guess is the word. I think just at a fundamental level that open source, a big part of it, is about service, about serving other people in the community, giving back, not expecting anything, that kind of thing. And I think that is the kind of ethos that we want in our faith communities, whatever it is. And I think, in my own church we serve in certain ways. We serve our own church, we serve the city, that kind of thing.

Henry Zhu: And so that's what got me thinking about that. And even in terms of funding or asking for donations, fundraising, this idea of membership into something. Being committed to something for the long run. In terms of religious institutions, they've been around for a long time. They have thought about maintaining a lot more than anyone in tech. I think it would be a good idea for us to pay attention to why things stay as they are. And even this idea of tradition. I think now we kind of shy away from tradition or think it's bad, but I think it's important for us to understand why things are there in the first place.

Henry Zhu: I brought this up on other podcasts but there's a concept called Chesterton's Fence and it talks about if there's a fence in front of you, which is talking about tradition or liturgy, that you might just be like, "Well there's a fence, I'm just going to get rid of it." But his point was to say that before you get rid of it, probably someone put that fence there for a reason. It wasn't just there, right. It was like some person put it there. And so before you get rid of it, you should understand why they put it there in the first place. And that would make you be able to have a decision around whether you should remove it or not.

Henry Zhu: And it's the same thing if you keep it there, you should probably understand why I was there in the first place too. Because what happens is when we get into our rituals and liturgies and traditions, maybe we tend to create new meanings for them, which is not bad, or we forget why they were there in the first place. And then at the end we won't even do it anymore because it was like, "What was the point of this again?" So I think it's important for us to think about those kinds of things in open source too. We have our own liturgies there too. We have meetups and conferences. They're annual. People meet up there. We have OctoberFest. There are different things that are like that in open source. I mean you think about how are those going well and how are those not going so well and what we can do to improve on them.

Kent C. Dodds: Mm-hmm (affirmative). Yeah. So there's a lot to be learned from religion and faith, communities of faith when applied to open source. Yeah. I think that's very true. And you don't have to believe in God to participate in open source, but having a community of people and I just think... Yeah, I agree. It's fascinating the relationship or the correlation there, the parallels between those two and if anybody wants to dive deeper into the subject Hope in Source is a great podcast. To look into. So as we wrap things up here, Henry, is there anything else that you wanted to touch on before we conclude here with our call to action and wrap up?

Henry Zhu: I mean it's kind of the same stuff. I think that something I've been thinking a lot more about is just, I mean we talked about non-coding a lot, but I think I've been trying to get into more other fields that are not literally coding but are related. So this idea of like trying to be more interdisciplinary. Things that I thought had nothing to do with open source. I mean faith is one of them. After that that's kind of why, now that I think about it, it makes sense.

Henry Zhu: I decided to make another podcast called Maintainers Anonymous. And the whole point of that podcast is to at first it was interview other open source maintainers, but then later I was like, "Oh I should just talk to anyone that what I would consider as a maintainer." Which is very broad now. Someone that takes care of something for some common good. And so some of the recent episodes I interviewed someone that works at a museum, someone that works at a library or you could be a gardener, you could be a parent. There's all these different people that have different experiences in their life and different vocabulary, right? All of this stuff. And I think it's important for us to learn from. I want to, so that's why I want to talk to those people. Yeah.

Kent C. Dodds: Yeah. I think that's great. So people just go consume Henry's content. It'll all be good. Cool. So just as our grand takeaway from this conversation, which I have really enjoyed, it's... You probably hear my brother's screaming out there. But yeah, so the call to action is I want people to try to find a way to do one thing to contribute to open source without writing any code. And so like we talked about a lot of them, write a blog post or, triage some issues or go to the support channel and answer some people's questions. But if everybody who listens to this podcast did that for any open source project, that would be like a huge amount of work done to make the world a better place. So yeah, that's your homework for [crosstalk 00:32:20] episode. Cool. So Henry, how can people get in touch with you if they want to?

Henry Zhu: Yeah, I guess you could go to my website. It's henryzoo.com but it's Z-O-O. And then I'm on Twitter too. So left_pad. Yeah.

Kent C. Dodds: Nice. Cool. Well, Henry, it's always a pleasure to chat with you. I've enjoyed our conversation. I hope that the people listening enjoyed it as well. And yeah, we'll see you around the internet. Thanks everyone.

Henry Zhu: Thanks.

Kent C. Dodds: Bye.