The One Who Got Hired to Work on Open Source

Tim Neutkens is the co-author and lead maintainer of the React-based framework Next.js, as well as the co-author of the MDX library for dynamic markdown documents. We caught up with him at the December 2019 edition of dotJS and asked him to share with us how he found himself in the world of open source and how that led to him being offered a permanent role working on Next.js.

Learning through practice

I started building my own websites, basically starting out with WordPress and doing pretty simple websites for friends of the family, or friends who had businesses they wanted to promote. After high school, I had to do this internship because, in the Netherlands, you have to do a pre-bachelor thing to go on to do a bachelor’s in some cases. So I did this IT management degree, which included half a year of internships, and I ended up at this digital agency, and the people there were basically like, “We actually don’t know if you can program because you were doing this IT management stuff, but we’ll give you the chance to prove yourself.” I started there when I was about 17, and I just started programming stuff internally, building internal tools. And then, eventually, they offered me a job and I decided to take that instead of doing a bachelor’s in computer science.

Discovering open source

We were using all these open-source tools, like WordPress and Magento, and we were building a lot of custom plugins for WordPress and I ended up putting some of them online, on GitHub. That’s how I got introduced to this approach of, “Oh, you can put this stuff out in the open and people will find it useful in some cases.” Then, in my free time, I just got more involved in other projects that I found really interesting. I ended up working at ZEIT [now Vercel] to work on Next, but as a result of that I ended up co-authoring a bunch of libraries that ZEIT was building internally, or I advised on several projects. One of them was actually already out—it was called Hyper. I started doing good first-issue-type issues, which is what maintainers mark as, “These are the easy ones that you get started with in order to contribute more to the project.” They were things like changing documentation or updating three lines of code within the codebase. But they really helped with learning how this codebase works and also learn more about JavaScript because I wasn’t doing JavaScript at the time. Starting to contribute to open source meant that I basically… It might sound really weird, but I didn’t have to know everything that made up this framework, this tool, I just had to know where to fix bugs and then apply that and then get gradually into contributing more to the project and discovering how it works.

When it all comes together through open source

While I was at ZEIT, Guillermo [Rauch, the company’s CEO] had an idea, which was let’s make a markdown format that can actually hold dynamic elements—he had been thinking about that for two years or so. Then there was another person, John Otander, who over the weekend, had built the whole implementation for that library—we call the format MDX. And so I saw that post and I reached out to John, and I was like, “Hey, do you want to work together on this stuff?” Because there were a lot of optimizations that could be made, like massive improvements in how the actual architecture of the thing worked. So I reached out to him and I was like, “Hey, I can actually help on this because we need it for ZEIT.” And he was like, “Yeah, sure, let’s collaborate.” So it was a really good open-source story because we put the actual spec for it out in the open and then someone else—someone completely random, we had never met him before—just went in and was like, “Oh, I built this thing over the weekend because I found it interesting and I was super-intrigued by the idea.” Then we refined it over time—we did many weeks of development on it together and ended up with an implementation that performed well and can still be improved over time.

Getting hired to work on Next.js

I was about 20 at the time, and I had worked on Next.js—the thing I now work on full-time—for almost a year by then. And I was working on it pretty much full-time while also doing my job, so I was doing a crazy amount of hours on the project, just because I found it super interesting. It wasn’t as popular as it is today, but for me, it was just really a learning thing. So eventually they made me co-author of Next after I made a significant amount of contributions to the project, and then, eventually, I sent a message to Guillermo, like, “Hey, if you ever are looking for someone, then please reach out to me because I would be pretty interested because you’re working on all this open-source stuff that I’m helping out with.” A few months went by and then he reached out to me. He was like, “Hey, do you want to come to San Francisco, to attend a conference we’re organizing”—which was the first edition of ZEIT Day—“as a guest?” So they flew me out to San Francisco, introduced me to the whole team, and then Guillermo offered me the job. For various reasons, I ended up not taking it. I waited another six or seven months, and then I was like, “I really want to do this thing—to work on Next and actually make it work—I’m sure I want this.” So I joined ZEIT at the end of 2017, basically two years ago now, and I was the only person working on Next full-time at the time. And I basically ended up maintaining it by myself for over a year, until we started hiring more people onto the team, and then I became the lead maintainer. I am now in charge of deciding on the roadmap and making sure that everyone is working on the right stuff that we want to put out. And I’m talking to customers, or people who use Next, and I’m like, “Hey, is this going to work for you? Why is it going to work for you? Why is it not going to work for you?” And then I can relay that to the team and tell them, “Oh, actually, these companies are doing this in a completely different way from how we have been thinking about it just because we don’t know their insights.” So it really helps that I can go out there and talk to others to see what they’re doing or what they want to do and get that feedback back to my team.

Seeking help from experts

In terms of scaling the project itself, I knew a lot of JavaScript already, mostly from when I started contributing to Next itself, because I had worked on Hyper and other projects. But then I learned a lot about compilers, how they work, how Babel works under the hood, for example, or how Epic works under the hood. I contributed a bunch of stuff to both projects to improve memory usage, and basically, there’s just a lot of… I think the realization I came to when I started scaling up the open-source stuff that we do is that a lot of projects out there are being maintained but they could also use some help from people who have a lot of expertise. So the specific things that we learned from Google Chrome engineers are mostly related to how to reduce bundle size and optimize the way that JavaScript is output to browsers. So, say what we currently have in Next is maybe one JavaScript bundle for a page, the Google engineers started investigating how they could apply to a chunk of pages. So, basically, if one module is shared between two pages, how to make that a separate JavaScript file that’s only loaded when those pages are requested, instead of putting them into a common bundle where you’re shipping this massive chunk of JavaScript to all users.

Not letting yourself be distracted by negativity

One thing I would advise myself, going back, is to not give too much weight to people’s opinions, because it could be that it’s just one person being super-vocal on GitHub or Twitter, or I don’t know where—Reddit, or something like that—and they could be really unpleasant. They might mean well, actually, but they could be communicating in a really harmful way, but that’s still just one person, and there are thousands of people using your software and so there are some who don’t have any issues, or they’re not telling you about their issues, but mostly, people who have issues will actually go to GitHub and submit an issue. So it’s really about learning how to deal with all that.

The UI frameworks trend

I guess the thing I’m most excited about is the pace at which improvements are being made, without all the standards that people already use being affected. So, for example, UI frameworks like React, Vue, Angular, Ember, Svelte—those have really taken off and gotten really big. Almost everyone’s using them. They improve the whole experience and make it accessible for beginner programmers, but also for companies that want to build really large apps. Basically, we saw that a lot of people use React, Vue, Angular, Svelte, for example, or Ember, and that was further verified through MDN—Mozilla Developer Network, I think. They basically did a survey of 28,000 people, and 72% of them said they were using a UI framework like the ones I mentioned. I hope that Next will be around for a while—with the framework churn, the ways things go in JavaScript world, it might not—but I really like what I’m doing right now, so I hope that I can continue improving people’s lives by making better developer tools.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Illustration by WTTJ

Photo: Welcome to the Jungle

Follow Welcome to the Jungle on Facebook, LinkedIn, and Instagram, and subscribe to our newsletter to get our latest articles every day!