Community is Everything: Open Source with Henry Zhu (Part 2)

[00:00:10] T: Hi, everybody. Welcome back to Enjoy The Vue. I’m Tessa. Today we have Ben Hong, Ari Clark, guest panelist Vikas Ashoka, and special guest, Henry Zhu.

Last week’s episode, we closed on what are the responsibilities of an open source maintainer? This week, we're continuing our talk with Henry, starting with what responsibilities do open source maintainers have in terms of shaping the future of the projects that they maintain?

[00:00:41] HZ: Instead, we should be thinking about how to remove options and make things simpler. The incentive is to add things, because it's easier to tweet about, or market. Spending the time to think of an actually better solution that's simpler, takes a long time that doesn't have output. I think as a maintainer you're like, “Well, I don't see the benefit of this.” I’d rather fix a bug, because it makes me feel better that I did something incrementally.

I think that's a struggle that's really hard to get over. This is true in any job, right? Fixing bugs might be easier than trying to refactor, or just literally come up with something new. Then now that I’m in a role where I’m not really writing as much code, I’m always thinking like, “Am I even doing anything?” What am I even doing for the project, being a “leader”? Going on podcasts, talking to people that supposedly has nothing to do with code from the outside, but to me, it says a lot about the whole open source is not about code, it's about other things.

[00:01:38] T: Yeah. I’m curious to hear more about these ideas, or the struggle, especially when it gets away from you. In increment, I think you wrote about how the users of Babel really wanted to use unsolidified features in JavaScript and how it was a struggle for you, if I understood correctly, about whether you should encourage that or not and how to deal with it, because regardless of how you would handle it, people were integrating the next version, even though it might change and break things going down the road. When that happens to you, what's your thought process there, or how do you deal with that?

[00:02:17] HZ: Yeah. Actually, that's a really good specific example of the problem we're talking about, of how open should you be and how close should you be to feedback or contribution? What we're talking about here is basically, the idea that most languages don't really allow you to have any feedback to where the future of the language goes, I think. Just think about Java, or Python, or whatever. They have committees and you can talk to them and e-mail them and stuff like that, but it's not as – I use the word democratic, I guess, as JavaScript, where there is a sense where you could propose something, and bring it up to the committee, and then even implement in Babel. If you get enough people using it, it'll probably go in, even if it takes a few years.

That's a lot more, I guess, possible than other languages, where you might not even think that's an option. I think, most people don't think that, but one of my, I guess, goals with Babel as a really high-level is helping people understand that you can have an impact on the language that you use and also the tooling that you use. Instead of just using it and just, we talk about the ivory tower a lot, but it's painted down from the TC39 gods, or something. It's like, no. They're just regular developers too.

I’ve been to some meetings. I’m just a developer as well. Most of the time, no idea what's going on. That's another admission that you don't have to know exactly what's going on to make those contributions. I guess, I’m hoping that, because we have this tool that allows you to use proposals before they come out, new syntax, I think that's a good thing. You can see the bad side is, well, what if the extreme opposite would be that everyone has their own proposal, they don't even ask anyone, they make their own plugins and then JavaScript becomes this monster of you go on GitHub and there's just all the syntax, you have no idea what's going on.

That's the fear that people have, of allowing anyone to say whatever they want, because most people just don't know how to write a programming language, literally how to add new features. You could say that's gatekeeping, and be like, “Well, who are you to say who's allowed to do it?” That's the whole point. We want people to contribute, just like we want people to tweet. We want people to make comments but, at some point, you need some kind of barrier. It just sounds bad saying that – or boundaries. We have these things everywhere. We just, I guess a lot of times, they're implicit. I mean, maybe making them implicit is a good thing, but we just don't like the idea of doing that. It's a hard decision to draw a line for any of this stuff. We talk about borders for countries, or membership, or citizenship. These are all things that are like, well, I think that's what I mean by assumptions. We all want as many people as possible to do that.

If you thought about the idea of design by committee and you have a 1,000 people trying to make a language, it probably won't work really well. People already hate the idea that TC39s, like 50 people or whatever it is, instead of one. We also know the problem of people always say that BDFL isn't good, or something like that. Yeah, this does get into this –

[00:05:22] T: That’s benevolent dictator for life, right?

[00:05:25] HZ: Just different governance, structures in open source. Something that most developers have no idea about, or experience with. You do your open search project by yourself and then it gets popular and then that's a bad thing, because now you feel you have to do something about it.

I feel we almost need some weird – I don't think we need training, like I’m going to make a manual, this is how you do open source. When you're successful, do this. It's just more, culturally, everyone wants to make their project viral, but then after that happens, it just becomes a burden. I don't want to discourage people from doing open source. It's just like, be more real about what the reality is of what you will feel when it happens.

You might not feel that way personally, but I’m just saying that just generally, that's what happens and cycle of burnout and stuff like that. That same thing, it's like, even saying something negative about open source may be part of the same idea of being open. It's really hard to bring up these conversations, other than I think through a podcast or talk, because people will just assume you have bad intentions or something. I don't know.

[00:06:29] BH: Yeah. One of the challenging things that I think you bring up, Henry, is that a lot of us when we joined open source, we're joining us individual contributors. A lot of us can know what that's like joining a company, a new team, and so you're eager to work on tickets, and build things, or fix bugs. Then I think to your point of when you move into that maintainer role, or in the instance, in my experience of joining the core team, you almost are in more of a manager role now and less of an IC, but you have individual contributor responsibilities too.

I think maybe, that's part of the difficulties, is there's no one there to help you with the transition. To your point, other times in a company, if you're going to become a team lead and manage five people, you've had people help you with manager training, or those things to help you transition from one to another. I’m wondering if you found any resources, or processes you went through to help you transition. Because my background's in psychology, so it was a little bit easier for me to make that transition from more of an individual contributor to more managerial.

Yeah, be curious if you have any thoughts on that?

[00:07:27] HZ: Yeah. I’ve never had any formal training in any of this. I think that's one of those things where you have a lot of self-doubt where you're like, “Am I doing a good job?” How do you evaluate yourself? Are your peers even going to do that? Other maintainers, you don't have a boss telling you.

I think that those things are things we normally don't want anyway. We don't want a boss telling us what to do and those things, right? We don't want to go to trainings that sometimes are not even helpful at all. A lot of us would like to say that the experience that we have by doing it is a lot more helpful than watching some videos, or listening to some talk. True, I think you definitely need both. I don't want to say like, “Oh, I did a good job.” The project still exists, so I guess I had some part to do with that.

I don't think anyone can really say, “Oh, you did a good job or not.” There's no book you can read, or other people to follow. You're on your own project. Every project is different. I think that's hard. I think maybe one thing I’m thinking about a lot too is just, we really need certainty. We really need this standard that we're doing the right thing and we don't have that. I think, maybe it's an illusion to think that we had that in the first place. I think that's what I mean, by faith has a lot to do with it. Not religious faith, just faith in general, of sometimes you got to take a risk. Sometimes, the things that you're working on, especially the things are important, there's no answers. No one's really figured it out and you're probably going to make mistakes.

I think, maybe the struggle with some of the stuff is that we just assume that everyone is fixed in their way of thinking, or how they do things. Whether they're smart, or not, or whether they did something wrong or bad, people change. If you think about code, even though the code runs, if someone doesn't understand how the code works, I think I mentioned this in the talk, the code in some sense is dead, because the people that wrote it maybe aren't there anymore and it's a lot of work to rebuild the knowledge that a maintainer has. That's why they're so valuable. That's why it's so hard to replace someone, anyone in your company.

They could have spent their whole time documenting every single thing in their head. They don't even know the things that they should be writing down. The way that comes out is through talking to them and working with them. When they leave, if your project only has three people and one person leaves, it feels the whole project is over sometimes.

[00:09:45] T: Yeah, it's interesting. You mentioned influencers on podcasts and it sounds like you have all the downsides, or I guess, the more work-heavy aspects of it, like this community that you're perceived as being responsible for and this almost, obligation, or public expectation that you'll keep on pumping out content.

I’d like to take a brief tangent and revisit this idea of – well, you didn't really put this way, but this is how my brain interpreted it, this potential for having an urban dictionary for JavaScript or something, where anybody can decide where the future of the language goes as it evolves in use.

[00:10:20] HZ: I like that.

[00:10:21] T: Make it happen. I want to see that fire.

[00:10:24] HZ: Urban.js.

[00:10:26] AC: Oh, God.

[00:10:27] T: Yeah. Because one thing that struck me when I was learning JavaScript and Ruby, I guess it stood out a little bit more even, was that everything is really dependent on knowing English. A few weeks ago, you tweeted an experiment about aliasing variable names and things to other languages. I’m curious, when you have ideas like that that don't really fit into maybe what people see as your main responsibility, like Babel or something, how do you find the time, or how do you fit that in? Is it an internal struggle to justify doing those things for yourself?

[00:10:59] HZ: Yeah. I would put it that way, because even if you're paid, I guess – if you're not at a company. Like we said, no one's telling me what to do. There's an internal fear of people saying, “Why are you spending your time doing this?” I don't know if anyone would actually do that. Of course, if I actually did something bad, yeah, it'd be good if someone told me. It's like, what is our freedom for? I’m like, if the freedom I have in doing open source to maintain Babel is just fixing some bugs, I feel it's not a good use of my time even. Why not think about these things?

The things that are actually going to change how we're going to do programming is something different, not the same thing. We could all just implement a bunch of proposals. It's so obvious enough, those are the things that you should be paying for. Someone should just be paid to write some proposals, write code mods to switch people over when decorators are not there and people are still trying to get rid of them. Browsers should be just paying people, either us, or they just do it themselves to make these transforms, because they have an incentive to do this, because if people only use Babel and then the output is the ES5 version that Babel will transformed, we're not even running the code that is native in ES6 native code that they wrote in C++ or whatever it was.

Those are supposedly faster, if they keep optimizing it. The code size is less. When they want people – they should want to make Babel take advantage of preset EMV and compile less code, basically, but that's not happening. If you think about it, we have no incentive to do any of this stuff. I was just thinking about, it's like, why are we doing this? It's just because we want to and there’s, I guess, good will that is dying in people's minds maybe. I don't know. It's a cynical way of thinking about it. Yeah, in terms of the side project thing, it's like, I’m trying to I guess, give myself the freedom to think differently, because culturally, we came up with this definition maintainer that if you think of maintainer, it just means fix bugs, make releases.

I guess, maybe one way of combating that is just instead of saying that code isn't all there is, I should just do it myself. It's hard to do that, because you need some encouragement from other people like, “Hey, this is a good thing. I like that you're doing this.” That's where internal motivation, external motivation go hand in hand, where it's like, you might have a lot of conviction and that's the right thing to do, but if you see that no one cares, you're still going to feel not good about it, even though you shouldn't be doing things for people's validation. It's good to have a community of accountability and friends to help you, in anything, honestly.

[00:13:38] T: Yeah. How do you balance accountability as opposed to your own ability to determine what's right, or what you want to be doing next? Because I feel it's really easy for those lines to get blurred. Either internalize what everybody else wants you to do, or just be like, “I’m not going to listen to anybody. I’m always right.” How do you find that balance?

[00:14:00] HZ: I don't think I found it, so I’ll just say that. What's funny is I say that and other people are like, “Wow, you totally look like you have.” I was like, it's so weird because internally, I don't feel that way. I don't know if that's good or bad, it's just how I see myself, I guess. Yeah, I think it is easy, our culture somehow is very individualistic, but then also, group-oriented at the same time in different ways. The way we think about our choices, we’re the whole free, rational choice people.

Yeah, I am myself and I can do whatever I want. Then just think about the current time, like a pandemic and the choices we make affect other people and this is the obvious thing that, I guess, not everyone thinks is obvious. I don’t know. It's hard to think that at the same time, I should have the freedom to choose things, but I should take into account how people feel. Even if you don't know how they feel, just how that affects other people. I think, it's a hard decision now, because it feels almost every decision you make can be a negative thing, even the idea of buying something from a big company and you're like, “Oh, that is a bad thing.” Something recently is taking money from companies.

It's funny. If you think about taking donations, if you don't actually do this, it never crossed my mind. I was like, “Well, who is that coming from?” You just think like, “Oh, I just accept it from anyone.” Then you're like, “Well, what if someone gives you money that you don't you like?” You have to figure out are you going to reject it, or not.

Obviously, if there's a legal activity, you can't, but you don't like this company, or other people don't like this company. It's just a hard thing to think about, versus maybe at the end, you should just stop doing all this and just go to a company and get a salary. Even that, it's like, well, the company that I work at, are they always doing the right thing? It's like, I don't know. We have this purity type of culture too, where it's like, everything has to be perfect, I guess.

Right now, yeah, it is true that almost everything we do can be harmful. We have to make decisions and I guess, accept that there will be consequences. Yeah, I think it's really easy, that line of thinking to turn into I don't want to do anything. I’m just going to sit in my room thing, even if you have the privilege of doing that, but yeah.

[00:16:15] VA: Something this conversation is bringing up for me, thinking of funding and this bonus on you the maintainer, what the maintainers role is and institutions, I think I heard you and Nadia talking about this on your podcast. I’m curious how you think of this dichotomy between you are this group-oriented activity working in open source, but also, this individualism of having a Henry Zhu brand.

Some model that I thought was really interesting that Nadia brought up in the conversation I heard was should maintainers and as a result, should GitHub and other organizations, promote more of a creator-focused culture? Should there be a Henry Zhu brand, where Henry Zhu is sponsored, like Twitch streamers, or YouTube artists, or even folks who make tutorials for stuff like Babel?

[00:17:09] HZ: I think this is something that she was trying to get at at the end of her book. I think in the podcast, she was mentioning that, in some ways, this has already happened in all the other places, like streaming and YouTube and stuff. We call them creators, but then in open source, maybe we have this good and bad, the whole meritocracy thing, and the whole code is what matters, so why do you care about the person behind it? I think that's good in the sense of it doesn't emphasize people and it shows that it's a group effort.

The bad thing in some sense, in terms of funding, would be that, well, the more you make it about the group, the more it feels like no one knows who you are. I think, one of the reasons why sponsorship works is because of the fact that para-social thing makes it look like you know them really well. You see their face, you hear them all the time. If you give a talk every once in a while, like some people are well-known. With a YouTube channel, they're always talking every week, or day, or something. There's a community that is built around this person. You could call it a cult or something.

I guess, in some sense, that's good. I think we all have this weird reaction to that. We talk about secure worship and stuff like that all the time. It'll just naturally happen, I guess. How do we balance those two things? We're like, how can we make sure that we know that these individuals are distinct people and they have different views on things and have their own stories that are very personal, that maybe some of them should be out there? At the same time, it's a group thing.

I think, one problem that we have now is, well, I’m able to fund myself for Babel full-time at this point and that's still a struggle. I’m doing this with other people. If I want to be individualistic, then, yeah, I don't need to care about how much money they're making, or if they're going to stick around. The only reason why I can do this is because of these other people, not just because of the code, but even mentally and just emotionally, we get to help each other out in that way. I have an incentive and I want to help them. It's hard. That social capital doesn't really transfer, I think. If I tweeted, “Hey, you should sponsor Nikola, or Brian, other people on our team,” it doesn't mean anyone's going to actually do that.

I don't even tweet it by myself, because I know that just because someone saw that they're not going to pay money just to sponsor you. I don't feel I want to advertise that, I guess, because if they only did it because they saw that, they're probably going to not donate in the future anyway. They're going to stop pretty soon. I’m okay with not getting a few dollars just because they didn't see. I rather have people that really want to support me and I’m actually doing something they want, versus just that was cool or something. That's just my thinking around that. Obviously, there are people that like saying the whole subscribe thing. If I made a YouTube channel, I don't want to do that.

To me, it's like, if you really care, why do I have to go out my way to say it. If anything, all these other YouTubers are saying it for me, but for themselves. Everyone knows. I just don't see why it's necessary.

[00:20:07] T: Well, since Henry won't say it, I’ll let our listeners know. Don't forget to visit henryzhu.com to see the latest merch drop.

[00:20:15] BH: Zhu swag. Yeah.

[00:20:18] VA: I’m standing in line at 6 p.m. the night before when it comes out, just so you know.

[00:20:24] T: It strikes me that there's so many different types of maintenance work in open source. For example, even with the advertisers; vetting the advertisers and deciding what goes on the site, working with all of these services allow you to take in sponsorships and donations. That's just one type of different maintenance, versus going through the issues, versus reviewing pull requests and stuff. I’m curious if there's a sub-culture, or a sub-community in open source that's dedicated to more of that side of things?

Because even with YouTubers, they have their editing team, their PR team, their merch team. With open source, it feels like, well, you just do all the things and you can figure it out by yourself. If you mess up, that's your fault. You should have done a better job.

Yeah, how do you manage that? Or do you think that we can move towards a place where those things are more easy to handle?

[00:21:17] HZ: Yeah. I guess, the idea of roles could be helpful. We have that at work too. I feel with open source, it would be nice to say more like, you are a lead, or just focusing on this thing, but it doesn't mean you can't do these other things. Also, you don't want to – the same idea of you don't want to impose things on people. I’m not anyone's boss either, so I’m not going to be like, “You have to do this.”

The bad part of that is well, if we only do what we want then there are definitely going to be things that are untouched, or unmaintained. The whole advertising, or sponsorship thing is just not something we think about. I think the reason why you find all this spam showing up is you see it and you're like, “Okay. I’ll try to get rid of some stuff.” Then later, you don't realize it's a huge problem. Now this has come to light, it's like, “Oh, this is actually a whole task that you have to vet through these things,” of people giving you $1 and trying to show up on your website or something. It makes me question, do we even want any pictures on our website anymore at all, just because you have to deal with this? The pain of that is just not helpful.

Then also, because they think they're going to get SEO benefit and I think most of us put this real sponsored link, so that it's not supposed to. I’m wondering why they are even doing it. If you're a big company giving us money, they don't need SEO benefit for sure. I don't think they really care necessarily that their logo is up there. I’m sure they want something to show that they're doing something, because it makes them look better, like goodwill in the community.

Then also, you might question like, “Well, we're getting money from these people. Isn't that a good thing? At least, we're taking it away from people.” That's what people say. I don't know. It's hard questions. I think these are things that like I said, it's hard to talk about just casually, because yeah, it's hard.

It is assumed that you need to do everything. I think, maybe the reason why I even decided to be a leader, if you even want to call it that, is just because nobody did it. I think, that's how open source works unfortunately now, where the only reason why you get to where you are is because nobody cared about the thing that you cared about and then they're focused on something else. They're like, “Hey, you seem pretty motivated. All right you're a maintainer now.” Great. You just give them a bunch of responsibility.

At first, it sounds like an opportunity and it turns into a burden if you don't know how to manage that. I think that's where the whole over-participation stuff matters and the whole idea of the currency of open source is not the code, because you can reproduce that and consume that as much as possible, and doesn't affect maintainers. The thing that you're affecting is their attention and their time.

The more people that consume open source, it might mean more people making issues and consuming more time, but it doesn't mean that those maintainers have to do it. That's where I mean by saying no, it’s so hard. It's so funny that in the end, it's like, maintainers are so free to do whatever they want and, in the end, the culture, the environment makes you feel you're not free. You can choose to stop answering people's tweets, or issues, or whatever it is. Just say no, right? Stop working on the weekends. Stop working during work.

I think, just saying no as a tweet or something, doesn't show that you empathize and understand the actual feeling that you get doing it. I think that's the real struggle of how do we help people, so that they can do that? I think that maybe needs some help from the platform too, like GitHub and stuff like that.

[00:24:52] T: That's all for this week's episode. Join us next week as we talk more with Henry about what counts as maintenance work. Until next time, enjoy the Vue.

[END]