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 in order to go on to do a bachelor 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 in computer science.
Discovering open source
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 really 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
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
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!
Follow us on Twitter to stay tuned!
Illustration by WTTJ
Tech Editor @ WTTJ
- Add to favorites
- Share on Twitter
- Share on Facebook
- Share on LinkedIn