Maintaining a popular project and sponsored time

Henry, you said that you’ve become an accidental maintainer of Babel… How did you start contributing to Babel and then eventually become a maintainer?

So I started contributing to Babel through another project that I was maintaining. It was called JSCS, it’s a JavaScript linter. Through that project, I learned about what are called AST’s (Abstract Syntax Trees) and I realized by working on a tool that dealt with how code is structured and helping to figure out how to create errors and fix them, I realized that Babel was very similar to how that worked.

I eventually found that Sebastian, who was the creator of Babel, he wasn’t able to maintain the Babel core and some other side projects, so I got involved in a smaller project called Babel ESLint, which is a compatibility layer between Babel and ESLint. Slowly, through that, I made more bug fixes, started maintaining that, and slowly just… You kind of step down, and then I kind of felt like “Oh wow, I’m one of the few people maintaining this project.” I feel like I only realized that months into doing it, because at the time I felt like he was gonna come back at any point, so it’s like, “Oh, I’m just kind of like the interim maintainer.”

There are other maintainers now though, right? Did they come on later, or were they around at the time?

So when Babel 6 got released, a bunch of us started helping out, like Logan, but some people come and go. Amjad was a big part of Babel while he was at Facebook, but he left us to do a startup. Right now we have, I guess, three core maintainers. We have Logan Smith and Daniel Chandler, and everyone else are just other collaborators that we’ve picked up over time.

I’ve actually heard from a couple people, they think that Babel and Webpack are maintained by Facebook because it’s associated with React, and I’m constantly saying “No, they have nothing to do with that…” So the project really is held together by independent contributors and not by some company, right?

[03:54] Right. That happens all the time. I got invited to a Google conference called BlinkOn, and Sean (at Webpack) was also there… And for all the people I talked to, I was like “Oh yeah, I work on Babel”, and then at least ten people are like “Oh, do you work at Facebook?” I was like, “No, I’ve never worked at Facebook.”

So yeah, I think in their minds, because the way people use Babel is through React, everyone just thinks that it is a Facebook project, but… Yeah, it’s totally not under any company, and it’s not even under where I work either.

Can you talk a little bit about – because I think Babel is your first maintainer experience, right? …going from a contributor to a maintainer, and just how that felt in terms of any impostor syndrome you were feeling about it, or any fear of having to manage a very large and complex project.

Well, actually technically it’s the second project that I’ve maintained, because I did end up being on the core team of JSCS, so I did help maintain that. But I guess in that role I did feel like I was more a contributor, even though I was helping do releases and stuff… But yeah, now it’s kind of feeling like I’m the one leading it, so yeah, there definitely is a lot of impostor syndrome in that.
I always remember how I started, not knowing anything about the project. I found out about it after it was called 6to5 I didn’t even know what ES6 was, all that stuff… So it was really interesting when I got involved; I started joining our Slack room, where people ask questions, and I wouldn’t know the answer to any of these things, but I guess I cared enough to look it up or figure it out for people. But every time I would answer, I’d say like “Oh, I don’t know actually know what I’m doing either, but here’s what I think…” Slowly, you just do more and more, and then you look back and you’re like, “Oh, I guess I did learn some things…”

I’ve gotta wonder, why did you care so much for a project that you didn’t really know that much about?

That’s a good question… When I first started, I didn’t actually even use it; I just thought it was so cool that there was a project that could transform code. And it’s ironic, because – so I didn’t major in Computer Science, and I was interested in coding because of other things, like visualization and statistics, because I majored in Industrial Engineering, which is more about that kind of stuff. But then I found D3, and that kind of library, and then I was like, “No, I don’t wanna learn any build-level tools, and compilers are too complicated.” But later I was like, “Oh, I am working on a compiler”, but it’s only now where I’m understanding what that is, through the experience of working on this project.

Partially, the reason why it was interesting was because I was learning JavaScript on my own at the time, and I didn’t even know that there was all this new syntax, and I think most of us are really excited by the idea that – and at the same time, in the linting project a big focus we were trying to figure out was how to do auto-fixing. A lot of linters, all they do is just tell you what’s wrong with your code, but it would be so much better if you didn’t have to manually add white space or change some syntax if the tool could do it for you.

So this is before auto-fixing was a thing in ESLint, or even recently Prettier. What happened was I was contributing to Angular, and I manually fixed all their styling bugs, running like tens of thousands of like through Find and Replace, and I was like, “I wish there was a better way to do this automatically.” And when I realized that doing the auto-fixing was pretty similar to how Babel was doing compiling, it got me really interested in it.

[07:57] And do you think that coming at it from that perspective of “I’m writing an auto-fixer”, not “I’m gonna work on a compiler” was part of what allowed you to get into it? It sounded like you were a little bit scared off of the idea of working on a “compiler”, and it might have helped that you didn’t even consider it a compiler at the time…

Yeah, I totally think that’s why I’m doing this today… Because it was accidental, I was able to face– like, I didn’t even know what I was doing, and then I felt like if I did, I would have that fear and I wouldn’t have done it in the first place. So kind of being ignorant of what everything was helped out a lot, actually.

What’s been surprising about being a maintainer for this project?

One thing that I can think of right now is just how unimportant the code is, being a maintainer. In the end, what are actually doing? We’re helping other developers, and it’s so important to have communication with people, and just care about both the users, the contributors, potential contributors…

Recently, I’ve been talking with a lot of different teams, or going to conferences and meetups, and seeing the benefits of having a more structured way of doing things, I guess. It’s weird that in open source we’re just a bunch of volunteers, so then everything happens organically, which is really good, because not everyone has time. But then once a project gets to a certain point, you kind of don’t really know where you’re going, you’re kind of just like reaching in the dark… So I’m kind of seeing the benefits of having a plan.

You talked a lot about how the code doesn’t matter there, and a lot of what you’re doing is just making it easier to use or to contribute to… As a project gets more grown up or it has more users, there’s a natural tendency for it to just become harder to contribute to; the code gets bigger, it’s more complicated. Do you find that a lot of what you’re doing is just keeping it easy to contribute to, as well as reducing the complexity?

Yeah, I feel like – I mean, a big part of this is just because I wasn’t the one that wrote this code, and most of us joined after the codebase was kind of established. So most of us are concerned about the readability and maintainability, and the reason why I care about it so much is because I don’t really understand it myself… So I’m always thinking of like “How can we make it easier to set up?”, having documentation, asking other people to think about documentation… I feel like a lot of what I wanna do is just give people more of an awareness of what does it mean to be a maintainer, and I think a lot of it just like how do you approach the project, and your attitude towards the project.

I think as a user you’re just talking about “Does it work?”, and as a contributor you’re just finding some random issue to fix, but as a maintainer you’re thinking about the overall project, and I guess a lot of things that people wouldn’t even think to consider.

It’s interesting that – I think for some projects it becomes a problem when the original authors aren’t present anymore, they’re not involved, because you’re trying to sort of like back-track and figure everything out… But it seems like it can actually be an advantage in terms of you have to take the same mindset as people who are coming to the project cold, and you have to put more emphasis on documentation and making sure that things are easily understandable. I think it just really speaks to the value of a certain skillset for maintainers in particular that might be different from what the original authors needed, or different from what a contributor needed. It seems like it’s just a totally different skillset. And for projects like yours, and for Webpack, just seeing that some of those projects have founded a growing community not through just the writing of code, but through all these other functions.

[12:17] Yeah, I think I’m going to agree with that. We put a really big emphasis on getting people to contribute, but I feel like we don’t really talk about what does that involve, and we’re so quick to saying that open source is really good and that you’re gonna get a lot of benefit from it, but then– I always thought everyone should be an open source contributor or a maintainer, and I think everyone can do it, but yeah, in the end maybe it’s not what people want… Looking through issues and all these things that seem like busy work, or… It just turns people off. But yeah, maybe we can figure out a way to make that more enjoyable.

There’s always a couple people that love it, and…

Like you!

No, I’m not one of those people… [laughs]

I mean Henry, definitely not you! [laughter]

Okay, right! [laughs] So you had a talk recently at JSConf EU, and one of the key points was “Maintainers aren’t special.” I wanted you to get a little bit more into that and what you mean by that, because I think that that’s a really interesting point.

Yeah, I guess part of it was just that I was saying that maintainers aren’t special from a technical point of view. I had the same feeling when I wanted to get into open source; just because I just didn’t know anything about it, so then you just assume that maintainers are code geniuses, or they created the project, but now being a maintainer, looking back, you’re like “Oh, I was just the same person as everyone else when I started. I didn’t know anything.” But I guess when you do become a maintainer, it’s not really technical, it’s all – I guess it’s just to encourage people that if you wanna contribute to open source or be a maintainer, I don’t think there’s anything stopping you if you aren’t experienced in open source or aren’t experienced in that language or the codebase. I feel like if you use that project at work or in your side-projects, then you already have enough context into how it works, and as you’re willing to help out with that project, that’s all you really need.

I guess one thing was that when I started, I didn’t really have like a mentor or a lot of people that I could talk to that would help me get started. I think recently a lot of projects have been trying to focus on that, with meetings and Hangout notes, and maybe talking to people one-on-one. But before, when I started, it was just kind of like looking at issues and finding something and figuring everything out on my own. So there was no guided experience for that.

Yeah, you’re sort of demystifying the maintainer role, right?

Right. And I feel like it’s easy to do, just because I know – like, I’ve been there. And I think a lot of maintainers would say the same thing.

I wonder how we can make that kind of stuff clear, because there’s also different kinds of maintainers, and the way that you had come into it was barely knowing anything about the project at all, and doing a role that other people weren’t doing… And there’s other projects where the maintainer is sort of like the one person who’s still primarily writing code and managing issues and everything… But I feel like there must be so many other projects like Babel that would have benefitted from a maintainer like you, that does that type of a role.

[15:53] Yeah, there are so many different roles… I think another thing is just the definition of a maintainer isn’t very – it’s kind of vague, and we could do a better job of explaining what are all these roles… It’s weird that it’s kind of like a startup to me; you’re kind of like the CEO of this company that doesn’t make any money, but you have to do marketing, and social media, and writing a release, and dealing with regressions, looking it through, triage issues, and talking with other projects, other companies, your developers… All these things aren’t even writing the code at all.
Then also psychologically, how can you manage all this stuff and how do you prioritize what’s important? Because I think one problem is because there’s so many things that you could be doing and not enough people, you get overwhelmed with what you could be doing… And every single thing that pops up becomes the priority, and you have to learn to – I guess not really ignore, but know that you have to focus on the direction of the project.

Yeah, it’s always hard to transition from – you know, you start out as an individual contributor, and then you become more of a not just maintainer, but also like a leader, and you don’t have infinite time, so you have to start to focus, and inevitably, you start focusing less on the things that you started doing, and more on the things that nobody else can do… And it’s hard to identify what those are, right?

Right. That’s like a skill - I’d wanna call it a skill - that I’m trying to figure out now.

Do you think that projects do a good enough job of encouraging people with all these different skillsets to show up?

Do they even know?

Yeah, exactly…

They know they need this…

Yeah, I feel like that’s definitely the first step. I think I’ve mentioned this in my talk… My talk was about awareness - we’re trying to get people to contribute when they don’t even know what to contribute to. I think it’s all in our head, and this is why documentation is so important. And I don’t really have a good way of doing that, figuring out all the different things, and I think if you just sat in a room and tried to figure out all the things that you could do, you wouldn’t really be able to come up with anything. I feel like I do a lot of things on the fly, where like if I see there’s a need, that we should write something or we should make an issue… I guess that can be stressful, that everything seems to be responsive rather than practice… But yeah, maybe we just need to get more people thinking about it.

And I wanted to understand – I think in the beginning of the talk you had said something like “The purpose of this isn’t to convince you to contribute to open source.” Why did you say that?

Well, I guess one thing was I felt like a lot of people already gave that kind of talk, and maybe I felt like that’s in some sense pushing too far. People aren’t even ready to the point where they wanna do that, so just simply telling my story might be enough for people to be interested enough, and then we could show them those other talks about more practical steps on what that means. It’s more like, in some sense, just empathy for what maintainers do. That was my goal.

When you think about the reasoning behind people contributing to open source, do you mean a reason to get involved at all, or a reason to sort of increase your involvement? I meet people often who are like “Once a week we’ll probably send a pull request to something”, and it’s just part of their job. And when you say “Do you do open source?”, they’re like “No…” [laughs] They don’t consider that open source.

[19:53] Yeah, I think more the latter, like “How do we get consistent contributors?” A lot of people can make that docs change, or fix a typo, and you look at the contributor graph and you have a thousand contributors on your project, but most of them only made one commit… So why is it that some people will stay, why do people end up investing in a certain project, or care about open source in general? Trying to figure that out.

Henry, you’re really active in Babel, you’re doing a lot there, and like you mentioned, it’s not even your full-time job, you have another job… Is there anything that you do to kind of keep healthy and avoid burnout?

Looking back, I think this is a pretty big problem. Even before I started working at – so I work at Behance, which is part of Adobe… I guess I’ll go into more history - so when I was involved in JSCS, I was working at a different company in Georgia, and I just got more involved… I would go home right after work and I would just work on that project. Eventually, when I became a maintainer, I got an email from one of my co-workers, and they were like “Hey, you should come here to work at Behance, because you’ve been doing really good work, and we already basically know that you’re qualified doing your open source work.” Because of that, I was like “Wow, this is really cool!” I was so excited about working at a company where they cared about open source, and that was what I was interested in. So when I went here, every day I’d just go home and do open source.

Then eventually I felt the pressure of wanting to satisfy other people’s needs, or staying late when you make a release and there’s a regression, and then you’re like staying up till 12 trying to fix the bug, or people complaining… And just kind of forgetting my own health, and mental health as well. That’s actually when I felt like, “What do I wanna really wanna do?” and I was reaching out to my boss about being able to work on it at work. When that happened, I was really excited.

It was weird – the whole point of that was so that I wouldn’t have to do it at home, but then even in the first few weeks or months I was working at it at home and at work… And then I was like, “Wait, what am I doing?” I don’t know, I guess I felt like for me it kind of just naturally happened where I was like “Why am I working on open source?” and even though it’s really fun, obviously that’s not what defines me and that’s not who I am, and there are a lot of other things that we have to be responsible for, including our health.

[24:09] When I was able to just realize that, it became so much easier to just make that not a priority anymore. I don’t know, I guess it’s hard to say, because I feel like it kind of happened recently, where I was just like – I didn’t ever feel like I was going to get burnt out, because I learned to… Yeah, it’s like how do you separate yourself from your work? I think we invest so much time into something - it doesn’t have to be open source… Like your regular work, or different hobbies and things like that, and you become kind of obsessed about it. But yeah, I think either your body tells you or someone else will tell you that you’ll recognize like, “Yeah, that’s not everything.”

That’s a really big component of it, this feeling of responsibility that you have, that is essentially infinite, like an infinite amount of work to be responsible for, and to other people… Do you think that you sort of unburdened yourself with that feeling of responsibility, or did you just say you prioritized your own mental health over that feeling?

Let’s see… I think it was kind of both. In the end, because we don’t have that many people, there is definitely that responsibility in the sense that no one else is really working on it, so you kind of felt like if you’re not doing it, then who will? But I think we have to realize that maybe that’s just because people aren’t aware of that, and I think that’s what Sebastian was kind of struggling with as well. He was able to step down from the project and then people took up the project, and that happened to be me. So you kind of have to know that you’re still responsible, but somehow not worry about the state of the project if you’re gone. It’s like, why do people not take vacations and take breaks? I feel like people don’t say “Oh, I’m going away…” We make a big deal about “Oh, I’m not working on open source”, when it should be normal. I’m not doing it on weekends anymore, or taking a vacation, but because there’s so few people, you have to say like “Oh, I’m not gonna work on the project today.”

I think there’s something here about – I’m just sort of musing out loud, but I hear… About people that do any kind of creative work - you have to find the balance between being really passionate about the creative work that you do and caring about it and loving it, but then also knowing at some point that it doesn’t really matter. There’s some sort of separation between like “This is not my core identity or self, even though I can feel very invested in it.” It’s like a really weird balance to find… Like, not being so into it that you’re hinging your happiness on it, but not being so removed from it that you just don’t care about anything… And knowing both of those things.

You said to me before this idea that everything is fake, or it just doesn’t really matter… Is that what you were getting to?

I think the “everything is fake” – that was more about the whole “Maintainers don’t have to be super technical or start very technical.” When people ask questions and I answer, it’s not like I already know the answer in my head, that somehow I have all the information about Babel in my hand and JavaScript’s. Even today someone made an issue and I responses immediately; he was like “Oh, I guess you memorized the ES6 spec”, and I was like, “No, not really…” I just learned about how the code works and I tested it in Chrome and it’s the same bug, so it’s not a bug. I mean, it wasn’t like I already knew it; I had to look it up, too.

It’s really interesting when people ask “How does this work?” or “Why is there this error?” and it’s like, the information is in the readme. And it’s okay for me to tell them that, pointing them to docs and stuff, but maybe it’s not accessible enough for them to find it or to read through it, they just don’t have enough context.

Yeah, I routinely tell people, like, I have to look up the documentation for API’s that I wrote. I forget them. [laughs]

Can you just for context back up a little bit and talk about how you split your work at Behance to work on Babel and then work on your full-time job? Because you contributed to Babel as part of your job, right?

Yeah.

How did you get that setup to happen?

I’ll talk about it a little bit… Basically, I kind of just – one day I was like “I wanna get a meeting with my boss and some co-workers about open source, and wanted to figure out what we were gonna do with the project. Maybe I was like I should figure out how to do if full-time”, so I asked them about doing it full-time and they were totally okay with me working on it part of the time, as kind of like an experiment, to see what would happen. I think at the time it was just kind of unknown, and you know, it’s not very common for people to be able to work on it at work right now… So it was more of like, let’s see what happens in terms of “Are we getting a benefit from me doing this for the company? And also, if I finally do work on it at work as part of my job, do I even like it?” Because it does seem like some people might start working on it at work and then realize that that’s not what they wanna do, because maybe they feel more stressed out, or they end up liking just regular work more.

For me, I guess recently, we’ve – and it was really hard in the beginning, because what happened was I would have a project to do for Babel, and then I would also have work… It’s really hard to do a 50/50 split, where maybe it’s like “Half the day I work on Babel and the other half of the day I work on regular work.” It ended up being more like, “Okay, for the whole week I’m gonna work on mostly Babel stuff, and then not really do that much work”, and then when we have like a deadline or we really need something done, then I’d be working on that instead of Babel, and there would be like a lot less of open source work.

I think that’s just hard to do at any company, but I think recently I’m trying to figure out a better balance of how to split that work so that maybe I can work on more things that are less blocking for other people, but are still tasks that I need to do. That way, if I am working on open source it’s not preventing someone else from doing something. But yeah, that’s still a work in progress, and we’re still figuring out exactly how that aligns…

I think you touched on something interesting there, where it’s a really different kind of work to work on a product and with a team, and sometimes that mental health balance includes a lot of that work. I know Doug Wilson who maintains Express, he does that only in his own time, and specifically does not want a job doing it, because he likes working on a product with the team for his work, and then he gets something very different out of maintaining this incredibly well depended on library.

Does the company he works at use Express?

No. It couldn’t be further away. I don’t even know if they’re using Node… [laughs] It’s literally that far away from what he’s doing at night, and I think that he really feels like these are just separate things that he’s doing, and he gets a very different thing out of both of them.

[31:56] Yeah, I guess that’s the same with Tobias of Webpack (sokra)… Well, now he’s doing it full-time, but before he was doing… I think he was doing C# or something at work, and then in his free time he did anything Webpack, which is totally unrelated. Then at work here, we actually use Babel, so we were going to figure out like, “Okay, can I work on something that will benefit our company, and then the project in general, so that we both benefit?”

I think we don’t wanna make it like a company thing, where it’s like – kind of like how Google has certain projects and you think of them as Google… Babel isn’t like Adobe Babel, or anything like that.

It’s just striking to me that everyone has a different arrangement that works for them… It really comes down to personality, right? Maybe for Doug, he just finds a different kind of pleasure in his open source work and he just really doesn’t wanna associate it with work, and for other people it makes sense to have it there… Yeah, there’s like no formula.

Yeah.

I’m wondering about – so you have your work on Babel, but then you have other maintainers that you work with… How do you figure out how to work together, what types of tasks each of you will take on - how do those team dynamics work?

Yeah, that’s really hard… Because obviously I don’t wanna tell people what to do, and we wanna encourage people to work on the things that they enjoy. I don’t think anyone – we don’t have anyone that’s like “Okay, you should be doing this”, and stuff like that. I think just because no one’s really stepped up in that way, I kind of took on that role of trying to figure out what the roadmap is and what we should be doing, but in the future it’s more like, “Okay, we should start having meetings”, which we just did…

Actually, when I went to TC39 I met this guy Nathan Hammond and he just offered to help us set up meetings. He’s not even involved in Babel at all, but he wanted to – I guess after hearing my talk and talking with him, he was able to set up the meetings and the notes and all this more community stuff for the Ember community… So he said he’s gonna help us in the next month or so about getting us started to do that kind of thing. I think with that, that’ll help us just communicate more…

It’s funny that for such a big project that we haven’t really had meetings, that a lot of things just happened because someone was interested in it. A lot of our communication right now is mostly over just Slack… But that doesn’t really work when – people aren’t on Slack all day like me, so…

Just sort of thinking more broadly about work on Babel - how do you and the rest of the team figure out what types of work on the project needs paid support and where you need contributors? Because I’ve seen you advocate and experiment with both, right? Like, needing more contributors on Babel, but also asking companies to support you financially. How do you figure out where to draw that line?

I don’t know, I guess even just talking with my company… Money makes everything complicated, so I think setting up a Patreon or Open Collective - I think all this stuff is really good, but at the same time I think Maggie of Moment(JS) she brought it up really well, that a lot of people that do open source or maintain open source, they already have either a full-time job or a part-time job, and it doesn’t really help to get some money from funding, because you’re already getting paid, and it’s not like you need money for open source to live or to do well… And that’s why people have a hard time spending the money from these crowdfunding things.

[36:05] If you are a freelancer or in-between jobs or you’re contracting, then I don’t see any reason why you wouldn’t do something like that if you need that money, but otherwise it’s kind of weird… Thinking about like “Why would I wanna spend the money?”, it’s like “We can use it to buy T-shirts and all these things for community”, but that in the end isn’t the blocker for open source. The problem is that we don’t have enough people, so either we should get core people to have more time, or we add more people to get more involved.

I guess I would wanna emphasize more companies getting involved with the projects and being more invested, unless they’re willing to actually sponsor enough money so someone can be paid full-time. I don’t know if it makes sense, but I almost see it kind of like black and white, where in-between getting money doesn’t seem to help the project much, in my opinion.

One thing that the Node.js project does that I think is probably the most effective thing that they’ve ever spent money on is this thing called Code + Learn, where they send core committers to an event - usually like alongside an event and then a room full of people, they try to get them from zero to actually sending a pull request to core and getting into core. And if you look at the base expense, it’s like a couple thousand dollars to send each of these people to this event, and they maybe work with 10 or 12 people to be effective… And these are 10 or 12 people that may not stick around, but it’s surprising how many actually stuck around and how well that’s worked.

I think the piece that’s missing and why I haven’t seen a lot of smaller projects do this is that there’s also infrastructure and just organizing and setting that up… It’s really hard to replicate. You’ve got $12,000 annually that you could totally send the people, but it’s setting up that and organizing that’s the real blocker, right?

Right. That is totally something I would wanna spend the money on. That’s really investing in community - finding people, investing in them… There’s not enough work yet being done to keep people; we are really good at welcoming and including people initially, but how do you reach out again and again and again. Maybe the second time or the third time – you know, people are busy, they’re not thinking about the project as much as you so I think totally spending money on that kind of thing was what I had in mind.

The other thing I had in mind was - for us specifically, Babel itself was sending people to TC39, which is the same expense… Flying people out to some city and then the hotel. And that does cost a fair amount of money.

Henry, you mentioned that you went to TC39… Why don’t you tell us a little bit about what the motivation for you going was, and for Babel sending people in general?

I think for me when I was going I was wondering “Yeah, why do I wanna go?”, and I felt like for me it’s not really about what I would get out of it, but just telling people there that – I think most people knew that existed, but what was the project about, who works on it, that most of the people volunteer, and how we can help influence TC39.

I don’t know, it was a very (I’m gonna say) lucky opportunity again, because this meeting happened to be in New York, so I didn’t have to figure out and make travel plans. It was at Google, which is also on 15th, I think, so I just walked over there. And then my company - they let me go for those three days last week.

And also, they have like an agenda that tells you what they’re gonna talk about, and this meeting they had this thing called Vision Talks… They invited a few people to talk about the future of JavaScript and stuff like that. And I just asked Dan, one of the TC39 members, if I could give a talk, and he was like “Oh, it’s perfect… You could do a Vision Talk.” So I did a short talk in like a day, and then I was able to present on Wednesday, which was a really good opportunity, because I felt like if I just went there, I don’t know if it would really mean that much, because there’s not that much time to talk with people, and people are busy working on different proposals and stuff like that.

I think just being able to put our name out there to get people to think about Babel is important to me. I kind of felt like – what’s it called? No taxation without representation, where we have our users, who are like “Oh, why isn’t this syntax in Babel?” or “Why is it slow?” and stuff like that, and then we have the implementers who are like “Oh, why don’t you implement this proposal either?” So I just felt like people were complaining about the project but not really letting us talk or communicate on what the state of the project is and all that stuff. So I think it was really helpful in that sense.

I’ve gotta jump in real quick, as the non-JavaScript person here, can you just briefly explain for listeners what TC39 is and why it’s important?

Yeah. TC39 is Technical Committee 39, and it’s a part of ECMA, which is an organization that does standards. There’s the JavaScript standard - ECMAScript is JavaScript… And it’s basically a group of individuals that represent certain companies that are invested in the language and wanna improve it, and write the actual specification of how it should be implemented.

These companies are like Facebook, and Google, Netflix - a bunch of big companies that wanna move the language forward. I think they meet every two months at one of those companies, for three days, and they talk about different proposals on web syntax that should be added, or different changes that need to be made. It’s been going on for a really long time. Actually, I think it’s this year JavaScript will be 20 years old, which is pretty crazy.

[44:00] I guess another thing is that right now the process is pretty different from what it was before ES6 or the sixth version of JavaScript, because there was a single editor and he did all the changes in a Word document, and you had to submit patches or emails to figure out how to change things… But right now the spec is on GitHub, which is pretty crazy. And now there’s a whole staging process about how you move a proposal forward in the language.

So everything is a lot more streamlined, but I think they could do a lot better job of incorporating more of the community as well, since it used to be just like ten people, or something.

Yeah, and one thing to note about it is that it’s a member organisation and there are dues that are paid, right? So it really is heavily focused on larger companies that can understand enough that they have the strategic investment to send people, and then sending people is also not cheap… I mean, they do like five meetings a year or something, it’s crazy.

It’s really easy to justify being there if you write a VM, right? And it’s really easy to justify it if you’re Facebook or Airbnb or these companies… But as they’ve sort of expanded - and as JavaScript has expanded, a big part of what they’re really building for is for Babel, and they’re building for Node.js, and they know that they’re building for these systems before they actually get representatives in. But their view of what these tools are and how they get built out and how easy or hard it is to get features in is wildly different from anybody with actual experience in those tools.

For the longest time, it’s been very hard to get people from these tools into those meetings, because it’s expensive. So this is like a great use of funds that you raise and things like that, because you can actually send community people to this kind of stuff.

Yeah, I think I would categorize the people at TC39 into developers, more like the people that write JavaScript, and then (like you said) implementers, the people that implement JavaScript in the browsers, and Node, like Chrome and Firefox… So they’re writing the C++ code that is in the browser. And then the third category I’d say are the people that are more focused on the language itself and writing – they’re very experienced in programming languages in general, but they might not write JavaScript.

I think that it’s weird – Babel I think fits… Like, I would consider myself more of the developer, but then technically the project still implements the spec in some sense, so we’re kind of like both worlds. I think where we’re really good – just like other people that we would invite from the community, we can represent our users better than the folks that don’t actually write JavaScript.

So stuff like this – I mean, it sounds like you’re moving into more of a public role, being able to represent Babel at places like this… What does that feel like? Does it feel like you’re growing into a different set of responsibilities as a maintainer?

Yeah, it’s definitely feeling like that. I’ve never really been comfortable with public speaking and all that stuff, but I think just getting these opportunities helps me grow in that way… And it’s another level, I guess, of impostor syndrome where you’re like, “Oh wow, I’m going to the meeting where people make JavaScript.” I never would have thought that would happen. But yeah, now I’m giving a presentation there, and people are genuinely interested about it.
I talked to a few implementers, and they just didn’t really understand how Babel works or how it was used in the community, and I’m hoping that at least – if I’m not able to go later, that that kind of changes how people think about how it’s used, for those implementers.

[48:04] So tell me a little bit about the Guy Fieri incident… [laughs]

Yeah, that’s a pretty long story. Let’s see… So Jordan Scales, he wrote a blog post on Medium, kind of like a satire, and… I don’t even remember when this was, but I guess this was when everyone was complaining about JavaScript fatigue, and how all of our Node modules are too big, and I guess a big part of that was through Babel. He was kind of making fun of a lot of projects, and one of the projects was Babel. He basically said that there was a picture of Guy Fieri in the source code, and that there’s nothing you could do about it… And it was funny, because a lot of people actually took the article very seriously, even though he worked pretty – I guess there’s a fine line between it being like where people think it’s really real or it’s just a joke… But it was pretty funny, and then what happened was James Kyle, who is contributing to Babel, he made a pull request to Babel that was actually a Guy Fieri in the codebase.

Initially, it was just a URL, just like a string, but then I think someone suggested that I should be the ASCII version of it. So I think Sebastian merged that, and then people made a big deal about it. We never ended up shipping it, because I told Jordan to revert the PR, but I don’t know… Even if it was in the source code, it wouldn’t have been that big a deal, but it seemed like a lot of people felt like we were being unprofessional.

I think that speaks to something that I find really fun about Babel from the outside - you seem to have a pretty strong brand, that’s like this very playful brand. I remember when you created an issue label that was like the shruggie, because it was like “I don’t know what to do with this…” And you have the matching Babel sweaters, and stuff… And it just feels like - I mean, again, just totally from the outside - that everyone’s having a lot of fun. I don’t know how intentionally do you think about creating that kind of brand, because it seems to be a big factor in why people like Babel so much as a community.

Yeah… I mean, I don’t think of myself as a funny person or anything, but I think it’s important in the sense that that makes it more approachable. It is being used everywhere and it’s “a serious project”, but at the same time open source doesn’t need to be just about helping your company make money, it’s also a fun experience, and a lot of people are experienced with open source through their fun little side projects. It’s weird because in some sense I almost feel that because we joke a lot and do that kind of thing that maybe certain people are turned off, or even companies are like, “Oh, they’re not taking it seriously, so we don’t wanna contribute”, which is kind of weird, but sometimes I kind of get that feeling.

But yeah, it’s really fun to take things farther than that, right? We have that little codebase with the picture in it, but then it’s like oh, Mariko, she made that website that’s called Sweaterify, that takes a picture and turns it into a sown version of it, and then it’s like “Oh, let’s make a T-shirt, and we can give it away to people.” So it kind of just builds on itself, and I think people can be really drawn to that. And even in some sense, that can lead to a lot more contributions than something where they don’t really understand how the codebase works. I haven’t really thought about being that intentional about it, because that might take away from the realness of it, but yeah…

[52:18] Yeah, that’s how I’ve been thinking of it - it makes the whole thing really approachable. And even your own personal “brand”, the fact that you always make a point to talk about how you didn’t really know what you were doing when you started, and it’s fine, you’ll just kind of figure it out - I think all that stuff just makes the whole project feel really approachable.

From the outside, Babel looks really successful. There’s a lot of people using it, there’s a lot of people excited about it, it seems to have this very fun Guy Fieri-oriented community… Is it doing fine internally? Because we often see that users don’t necessarily track with sustainability, and in fact can put a lot of burden on the people that are trying to sustain a project… So what is your view right now of how well it’s doing in terms of that sustainability and handling this massive user base?

Yeah, I guess I brought this question up in my talk, like “What does a healthy project mean and what does it mean to be sustainable?” I guess there’s a lot of measures in terms of like statistic you could probably get from GitHub about how many issues are opened and closed, and pull requests, and releases… But then I guess in my own biased personal view, just because that’s me, sustainability in the end mostly means how many people are working on it, and do we feel good about what’s going on? So it’s something like a psychological just “Am I feeling well day to day that I can manage it or we can manage it as a team?” And I guess right now I feel pretty good. Maybe it’s a combination of a lot of things, including the – the pressures that I was feeling before aren’t as much of an issue to me anymore.

But do you feel good about it just because you sort of care less – not that you care less, but you feel less emotionally wrapped up in it? Is it like your own mentality that shifted a little bit?

Yeah, I think definitely that was a big part of it. It’s not like I don’t care about the project, because I feel like it sums as maybe I’d spend the same amount of time or even more time than before, but maybe I have a better sense of what the vision of the project is or what things are a priority and what things we should be working on.

I think one problem I really had was that I would wait for notifications, or GitHub issues, or someone on Twitter about Babel, and then I would have to respond to it… And every time you do that, you’re just distracting yourself from the work that you could be doing, and I paid too much attention to that… And if it affects your mental state, then yeah, it shouldn’t be that way.

What happened was I felt like the project wasn’t moving in any direction, it was just kind of there and we were just maintaining it. That’s why we all tend to work on things that we’re used to or we’re good at, and I would fix easy bugs, or a fork on the documentation, things like that. But in the end, it makes you feel good for like that moment in time, but you know in the back of your mind “Oh, the project doesn’t actually move forward”, because we’re not focusing on the features that people need or what we think the direction of the project is. And until we do that, it will always feel like an overwhelming burden as a maintainer.

[55:57] Ballpark numbers, how many people contribute today, compared to when you took over as a maintainer?

I don’t know, I think that’s another problem - we don’t really have a good idea of what that means in terms of like “Is it per day, or per week, or per month?” I feel like when I started, when Sebastian was working on it, it was literally just him. And you can see this, because if you go to our contribution graph, you’ll see that Sebastian has I think like 5,000 commits or something… And then the rest of us have a lot less, way less. This is because it was really – I don’t know why, but people weren’t contributing, so he would fix a lot of stuff on his own, where there wouldn’t even be a pull request… He’d kind of like just make a commit, and it was there. Because he knew everything, and so he was able to fix things in like two minutes after there was a bug, which is like amazing. Then for us it would take a lot longer, and we would make that pull request.

And it wasn’t like he was inapproachable or he wasn’t trying to get people to contribute… There’s plenty of issues of him talking about where you can contribute and all that stuff, so I don’t think it was anything particularly he did wrong in that sense.

Now I think – technically, on our team we have a dozen or so people (or more than that) that have collaborator access… But everyone has different goals and times that they’re able to work on the project.

So was it just like a matter of time then? You’re saying there’s nothing really different about – he was encouraging contributions and stuff, but now you just seem to have more… Like, the risk has been diversified a little bit more. Did you do something different, or is it just…?

Right. I’m definitely focusing on it more, and we kind of touched on this earlier, and I think this is a result of me not being the creator. So it wasn’t like he wasn’t trying, it’s just more like the perspective that you have as the creator of the project is different from you coming from the outside… I think inherently I’m gonna focus more on creating that community just because I’m able to think in the same way as other people, more so than if you are the creator, I think.

And in the end, maybe it’s just because a lot of it is I don’t really wanna do a lot of the technical work anyway, so I would very be willing to defer that to other people, while he was very comfortable with fixing those bugs, learning the spec, that kind of thing. So maybe there’s that, too.

It seems like things are much more diversified now, but you’re definitely still filling in a role there… Do you think that if you stepped down tomorrow that there’s enough people there that care about it to take on the responsibilities that you’re doing? Would the project be alright?

[59:04] I don’t think there’s enough people working on it on a day-to-day, but maybe that’s just because my expectation for how it should work is moving too fast than expected. Before, I was releasing every week, and I kind of felt like that was unnecessary, and now it’s like [unintelligible 00:59:24.17]. I want more people to get involved; I definitely don’t wanna be benevolent dictator for life, or anything like that.

I think we’re at a place where we still need to figure that out. Right now Logan, who’s also one of the main maintainers - he’s kind of just taking a break from work, so even him, it’s like… He gets to choose whether he wants to work on Babel or not, and other people don’t get to work on it at work either, so there’s way more work that could be done. Encouraging contributions is really awesome, and even going to the TC39 was great because we actually were able to get a pull request for a lot of the new proposals that were added last week, like yesterday. That’s only a week later, and that was just through telling people about it. But in the end, the hard part about maintaining it isn’t making the code, but reviewing the code, so there’s even more work that needs to be done there.

I think that’s a good place to close out. Thanks for coming on and talking to us, Henry.

Thanks, this was awesome.

Yeah, this has been great. Thanks, man.