Maintaining an OSS Project (Babel) By
Henry Zhu
[ Applause ] >> All right.
Thanks, everyone, for having me.
It's my first time in Europe and in Berlin.
It's been pretty awesome.
So this talk, I'm going to be talking about my experiences with maintaining Babel.
And just a little intro for me.
My Twitter handle is left_pad and I maintain Babel and a bunch of open source projects.
I really like games, 7 Wonders.
I haven't played the Babel expansion yet.
But looking forward to it.
I also like Korean BBQ.
I took Sean Larkin of Webpack, his first time in California.
And I'm addicted to open source.
This is just� I went to a restaurant in New York City and I just� that reminded
me of the GitHub contribution graph.
So this talk isn't going to be about wanting to get people to contribute to open source
or becoming a maintainer.
Just to give you a picture of what it's like to be a maintainer.
Maybe give you some more awareness to what that's like.
So how did I get started in open source?
I'm from Atlanta, Georgia.
And my first introduction to open source is through hackathons.
You know, the first project I made with JavaScript was just vanilla JS.
I didn't know about any libraries or things like Bootstrap or Angular.
Eventual I learned how to use, you know, npm and download libraries like D3.
My first pull request to GitHub was to the con academy.
And I used this Website called first PR to figure out what it was.
And I actually realized that it wasn't merged because I didn't know how to use read base.
I just had all these commits there.
When I first started working I met this guy called Jonathan Neal and he encouraged me
to get started in open source because I was using Angular at the time.
I tried to figure out how to get started.
I read all the contributing docs.
I read through all documentation again, I went through all the issues.
But it was really hard for me to find a place to get started.
Well, I found that there was an issue about updating the linting config.
Oh, just updating some JSON.
I went in, made a PR for that.
Except I found how it had to learn how to use npm shrink wrap and all this crazy stuff.
Eventual I ended up being the number 22 committer on Angular.
And that was only because I updated the styling.
I didn't do any core changes.
So all these changes were manually fixed by me.
Because we didn't have autofixing or anything like that.
And it was really cool because Igor, one of the maintainers, he even reached out and emailed
me and asked if I wanted to get a Tshirt.
And then I wanted to contribute more to Angular, but then I realized I had no idea what was
going on in the code base.
I figured because I was working on the styling I should check out the project I was contributing
to.
And so I found JSCS, which is a linter.
And that repo was really cool because they had help wanted label.
And that was� it made it easy for me to contribute.
So my first PR to this project was just adding this table of contents.
Over time I ended up doing more things to this like bug fixes and new rules.
And eventual I got an email that said, oh, you can be on the core team, which is really
awesome.
And even better than that, a few months before that I actually got an email to work at Behance,
where two of the maintainers worked at.
So I moved to New York.
Right now I work at Behance where I do JavaScript and work on Babel.
So how do I become a maintainer?
Basically� Sebastian was saying he was getting burnt out and he wanted to maintain that.
I found a different project and I was working on linter.
So it made sense, oh, I can figure out how to contribute to that.
And he wrote a blog post a while back talking about his problems with open source in the
community and getting burnt out.
And so, you know, he started working on it and all these contributors came in.
I just happened to be one of those people.
And� yeah.
And then I feel like I didn't even realize I was a maintainer until he basically told
me, like, you know, you slowly did more and more stuff.
So it just kind of creeps up on you.
And you realize, oh, I'm a maintainer now.
But the problem was that I felt like I was a contributor the whole time I was being a
maintainer, and that led me to only doing the things that I thought were easy.
So I would fix docs or may fix bugs.
I would never look into the code and figure out how to make core changes.
And it's funny because people were asking me all these questions, I didn't know the
answer either.
I had to look it up and send a message.
Okay.
This is what it is.
But I guess nobody knew that I didn't really know what it was either.
[ Laughter ] Yeah.
So then that led me to think that the project wasn't moving forward.
All we're doing is maintaining what someone else already created.
And I felt like at any point that Sebastian would come back and tell me what to do or
what the vision of the project was.
And only recently where I was like, oh, okay.
We are the maintainers.
We should figure out what the priorities are, what the roadmap is, how to move forward.
And a lot of that led to just thinking about, like, why do we do open source in the first
place?
When you get really involved in something, whether it's work or open source or anything
else, you know, we start thinking that's where we get our worth from.
When it doesn't go well, we start thinking, like, what are we working towards?
Yeah.
So this makes you think this everyone thinks that maintainer know everything.
And they have the answers to everything.
But we're just other developers that, you know, figured out how to look it up.
[ Laughter ] So yeah.
How do we actually measure success in open source?
I think we glamorize all the downloads� we have like 8 million downloads a month and
all these stars.
But then at the same time, like, you know, there's one.
Everyone's using open source now.
But what was the cost of that, right?
We have all these people that are volunteering to, you know, spend their time working on
this thing for all these companies and people that, like, what are we actually getting out
of this?
So it's like where I think that it's not just like the work that we put in, but how we do
it, right?
That I want to make sure that when we do ask people to join open source or become maintainers
that we figure out how to do it sustainably.
[ Laughter ] So I just am going to talk about a few stories.
So GitHub issues.
A lot of people use GitHub issues.
A lot of people switch off of GitHub issues.
We're probably the only project that switched and then went back to GitHub issues.
A while back Sebastian posted about how GitHub was not a good, you know, use for managing
issues.
And so we moved to this thing called Phabricator.
A lot of people complained about it.
Some of the positives.
There was a lot less back and forth.
People had to say what version they were using, the input and output.
It was a lot easier to actually reproduce issues.
It also led�to more people talking in PRs because we had to disable the issues.
And they had a lot more features like merging certificates and reactions and all that stuff.
But it ended up being that there was a lot more negatives.
All the previous GitHub links are not available.
If you had a blog post link to GitHub, it fails.
If you're coming to the problem, where's the issues?
That led to people doing a lot of weird things like emailing me directly or making a comment
in the commit of the repo.
Or making issues on the Website repo rather than the actual repo.
It also led to less issues.
It feels like it's good, but I heard from a lot of people that they didn't even want
to do it because they didn't know how to use the interface.
And also, over time, GitHub made a lot of improvements so that it felt reasonable to
move back.
So we had to make more code to convert all the issues to GitHub.
It was insane.
I didn't do any of the work on this.
Daniel, one of the team members, he had to write all this code to turn SQL queries into
GitHub API calls and make sure it doesn't ping anybody, and make sure it redirects to
the new GitHub URLs.
We made a battle bot and it imported 772 repos and basically copy and pasted the issue contents.
And when we finally do this, everybody was excited.
Me too.
Because I had felt like in the other interface I started not looking at the issues either.
Stopped caring.
All right.
More frustration.
So npm packages.
We had Babel preset 2015.
And I was like, well, it's 2016 now.
So I guess I should make a Babel 2016.
And I found out that someone already made that.
But this person was really nice and they said it was their pleasure to let, you know�
give the package up to Babel.
And now I just thought, well, what about the next year?
And then I go to� and I found out somebody already made that too.
But then this person didn't really want to give up the name.
Which actually kind of hurts our project because it makes it sound like the package naming
was official.
And so that was like a long back and forth.
And like a month later we were able to get the project.
But the real solution is to use what npm has now with scopes so that everything under the
add Babel name would be official.
We haven't done that yet.
But we're looking into it.
And the next thing would be that we should just stop making preset ES2000 specs because
then we'll have a hundred config values.
And it looks like people who know what the packages are willing to try it out.
Okay.
So I think some of you might have seen this blog post.
And in it Jordan talks about how Babel has this picture of�
[ Laughter ] Guy Fieri in it.
And there's nothing you can do about it, right?
It was fun.
And then James made this PR that added this.
And I was kind of surprised at first but, you know, went with it.
It was cool.
And then you get cool comments like this.
Which is really awesome to read.
And then we see this.
Marco made this.
And then I was like, okay, let's change the color scheme.
And then I met Jordan for the first time.
[ Laughter ] [ Applause ]
And then� yeah.
So� and then I was like, Jordan you should write an April Fool's blog post.
You can be the chief marketing officer.
He was busy so I just made up this other thing based on Wikipedia.
Okay.
So I have been talking a lot about open source and where it's heading in that we should make
it sustainable.
So how do we actually do that?
One way is by getting more contributors.
So what we're doing on that front is trying to focus more on like beginnerfriendly issues.
Making, like, actually explaining what you need to do.
Not just being like, hey, if you know all these terminologies and these words, then
you'll figure it out.
We're also participating in Google summer of code.
So we're going to have two streams working with us.
And also Rails summer of code.
And we can also partner with a lot of other organizations like schools or bootcamps or
companies.
If you are a company that's using Babel, then if you want to sponsor, just let me know.
And� yeah.
Even� so my company is really awesome.
They're letting my work 50% of the time on Babel.
And the only reason why we have this is because I was able to work on it at work for two weeks.
And we're also partnering with TC39.
It's the committee that works on JavaScript.
And Babel is a big part that have, right?
Because we write all these stage zero plugins before it's actually in the spec.
And the reason why we can� it's a good idea is because then people can actually use the
syntax before we decide it's a good idea.
And Logan was able to go to the last TC39 meeting in March and I'm planning on going
in May.
We set up an open collective.
And so what is the future of Babel?
Now that I feel like I am a maintainer, then we� we're working on an actual roadmap.
We're trying to split up into teams, delegate, and we're trying to partner with a lot of
different people.
So I think once we figure it out, like, we have a level of control.
We can do a lot of awesome stuff.
So� yeah.
Look out for Babel 7.
Thanks.
[ Applause ] >> Okay.
We can just have a couple minutes� break while we get the next speaker set up.
So if you want to go check out some of the amazing things outside, go get some fresh
yogurt.
Go get some coffee.
You've got two minutes to do it.
So run, run, run.
>> Thank you.