How to get into OSS

Hello, JS Party! Welcome back! I’m here, I’m your host this week, Kball, and I am so excited today, because we have a special guest joining us for today’s episode. We have Ujjwal Sharma, a.k.a. Ryzokuken, who is one of the Node core collaborators. Ujjwal, how are you doing?

Hey Kevin, hey Nick. How are you guys doing? I’ve been doing great, and it’s so great to see you again, Kevin, and great to meet you. Hi, everyone!

Awesome. And as you hear from Ujjwal, also joining us is our favorite panelist, Nick Nisi.

Hello!

I shouldn’t say “favorite”. All the panelists are my favorites, I love all the people I get to talk to in here, so it’s good.

For sure.

So today’s topic - we will be talking about getting involved in open source. This conversation came out of an in-person conversation I was having with Ujjwal at NodeConf Colombia; we talked about how this is actually a common question that people have, so hopefully we’ll be able to answer some of those questions today. But before we dive into that, I’m gonna scratch my own itch a little bit and ask Ujjwal the origin of his online moniker. Long-time listeners know this is something I’m fascinated by, the way that the names that we call ourselves influence our behavior… So Ujjwal, what’s the story behind Ryzokuken?

Actually, I guess you’d be surprised… I remember there’s been a lot of places I’ve been asked, because it’s so fascinating, and people are like “Okay, is this anime?” But no… I mean, if you know, there’s quite a bunch of people we have in India, and there’s quite a few people I share my name with. This was something that I’ve been frustrated with when I was growing up, and I decided to pick something that was random, that was never taken. That’s pretty much how it started. I would just gargle some text until I found something that sounded cool to me, to the 14-year-old me, and voila; I found it on GitHub, and Twitter, and everywhere. That’s the best part about having an absolutely random nickname. If you see Ryzokuken anywhere, that’s gonna be me.

That’s pretty good, yeah. Kball… I’ve gotta have a couple different varieties. Even though I’ve never heard somebody else who calls themselves Kball in person, online it’s not that uncommon. So do you go by Ryzokuken in person at all, or just online?

[04:00] It especially helps when people can pronounce this better than my original name, and also people that I knew purely out of communities, so… It wouldn’t be outlandish in Node circles, for example, to call me Ryzokuken, because these people have worked with Ryzokuken, not Ujjwal. But yeah, I could use those interchangeably.

Awesome. Okay, so let’s dive in a little bit to our actual topic; thank you for indulging me. So let’s talk about our stories of how we got involved with open source. Before we start giving advice, let’s just start from history. Maybe Ujjwal, can you kick us off? How did you get involved with open source?

Sure, thanks. This is something that I’ve been trying to speak about, something that I’ve been asked heavily. It’s really interesting - open source personally has been really fascinating to me personally since I was younger, because open source software has been one of the biggest sources of education for me. Some of the biggest pieces of software available on the internet right now are open sourced, and you could just read the source code of Node.js, for example; that’s so exciting. But also, especially being a student from somewhere so far away from San Francisco - it’s literally 12 hours of time difference - I realized at some point as a student that it was easier for me to get work on a big open source project, as opposed to, for example, getting a big internship. But it doesn’t really matter; if I could prove my worth working on different stuff on Node.js, it could be equivalent to working on some big corporate project, for example.

The way I put it sounds very selfish, me starting out with open source software, but we have this saying, “Came for the code, stayed for the community.” Over the years I’ve received so much love, so much appreciation and I’ve met so many amazing people like yourselves at conferences, in open source software projects, that it has grown on me. And not just like as a factor of my career, but as a factor of my life that’s gonna change any time soon.

But talking about how things worked out - I’ve been working on and off on open source projects when I was getting into university, and immediately when I got into university, somebody told me about this amazing project that Google runs, called Google Summer of Code. It’s a project that is intended to get students into open source, and I was like “Why not?” So in order to get deeper into open source, I started working at local communities, at communities inside my university, and then moved on to other communities outside.

At that time I was writing a lot of Ruby on Rails, for example, and there were not a lot of people who were writing Ruby on Rails open source, because it’s inherently application development; so I eventually found out an amazing community - huge shout-out to Public Lab, by the way… Some of the friendliest people I’ve ever met doing open source; they were so welcoming.

So it was through programs like Google Summer of Code and Hacktoberfest - really small things - and through the welcoming nature of the community that I got started. And later on I realized that I could actually get paid to work on this, I could actually be a Google Summer of Code project member, be a student and work on that.

In my freshman year in college it was my first year of involvement with Google Summer of Code. I worked with them on a Node.js project that really was a defining moment in my journey in open source.

After that year, I was so impacted by that project that I wanted to give back to the community, so I decided to be a mentor for them, and mentor three different students. Then I moved on to a project that was more up my current interests, because I was working a lot on Node.js and JavaScript, so I started working on Node.

[08:13] A bunch of helpful people along the way kept leveling me up, including Tierney, who we met at NodeConf Colombia. One of the most amazing people I’ve met. Overall, it got me started and gave me the enthusiasm, while Anna was helping me a lot with the technical aspects of the project.

That’s what the whole deal is about - just meeting new people and learning from them all across the journey. Everything has blown up ever since I’ve met these amazing people. I’ve been working on v8 and TC39 things these days mostly, and I also double up as a maintainer on Electron, helping them with the upgrades working group. So that’s it for me. I’d love to hear about your stories.

Yeah, you have a way cooler story than I do.

Same.

Yeah, so I guess I’ll go next. My first exposure to open source was a little negative, honestly. It was a long time ago; my first job out of college I was working at a company that was doing high-speed interconnected devices… And I was not directly working on this code, but one of the things that we needed to do was get drivers into the Linux kernel. And dealing with getting code into Linux – and back then that was pre-Git, so we were using originally BitBucket, and then Mercurial… And maybe that was right around when the transition to Git was starting to happen; I don’t know, it was a long time ago… And I wasn’t directly working on it, but I just know that the person who was in charge of interfacing with Linux (or with the Linux folks) was constantly frustrated and tearing his hair out, and just not happy. So that was kind of like “Okay… Is that what open source is about? I’m not sure I wanna touch that…”

A few years later I got into more direct web stuff. I was using Ruby on Rails, I kind of went down that road; I was building mostly applications… And at some point I realized “Hey, when I’m using one of these open source libraries tied into this, if something’s not working right, I can actually not just complain about it, I can contribute a fix.”

So some of my first touches into open source in a positive way were small libraries on the Ruby side and a little bit in JavaScript. I wasn’t actually doing anything big, I was like “Oh, I have an itch. I’m trying to use it in this way, it’s not working; I’m gonna file an issue, but then I’m also at the same time gonna submit a pull request that addresses that issue.”

That’s something that to this day I’m involved in ways like that, where if I’m using something that – or if something’s broken, if I have time (which sometimes I do, sometimes I don’t), I will not only file an issue about it, I will also try to put aside time to file a suggested fix. And generally I’ll say, “Hey, I’m new to your project. I tried to follow your guidelines. I may have failed. I’m okay if you wanna do this in a different way… I just wanna make sure this issue is fixed. If you want me to do it, tell me a different way to do it, I’ll do it.” Because it’s really about getting the result.

The first time that I got really deeply involved in open source - and probably my window into the open source community - as an opportunity engine was when I was working at ZURB, which was four years ago I started there now… Crazy it’s been that long. And ZURB was the company behind ZURB Foundation, which if you were a fan of that project, you’re probably sad right now, because that project has more or less been abandoned. There’s hope that it may come back… But anyway, they were the drivers of that, and at the time, they were sponsoring employees to work on it directly. So I spent a bunch of time working on it, and then I led the project for about a year and change… And that was really enlightening, because suddenly I was actually working as a maintainer, I was interfacing with people all over, I was helping, I was teaching, I was recording video content tutorials, all these other things… I was project-managing, but also implementing and doing a lot of development, and it was fascinating and fun.

[12:13] I got to go to conferences associated with it… It was this great window into “Whoa, this could actually be something transformative for a career”, and I got to work with and I made relationships with people all across the world. I’m still in close contact and friends with people in India, with people in England, and slightly less contact, but still in contact with people in France, and other people… All through these relationships I made in open source. So that was eye-opening.

End game - ZURB ran into financial problems, laid off a third of the company, including me. It is no longer investing in the product for the open source projects largely because they can’t afford to, and it’s been a long struggle to try to get it pulled out, so that the community could actually support it well… And we could go off on a tangent for a while, talking about corporate-started open source projects and how to pull them out of the corporation in a way that’s sustainable… Because I sort of started that process; before I got there, there wasn’t even really a core team that was outside of the company, and by the time I left, there was… But then even when you cut the sponsorship, the fact that there was a core team wasn’t enough, because there were still so many things hooked into that company.

So there’s still some recent progress, some hope; that core team is still in contact. There’s a lot of discussions, and there has been some progress made for pulling out, but it’s been kind of in stasis ever since.

Now my open source involvement - since I’m doing my own consulting, I’m not paid to work on open source anymore, it’s when I have time. And most of it is “I was doing this thing and I ran into an issue, and I’m gonna fix it… Because I can.” Occasionally curiosity-driven… I got a commit into Vue core, which was pretty cool, because I was just trying to learn how Vue worked. I got a couple commits into Node core because I went to NodeConf Colombia and Node does an amazing coding exercise with people… I’m working in open source much less, and much more on the community side with JS Party, and writing, and trying to do that sort of thing, but… Yeah, that’s kind of my long and meandering story of tiptoes in, whole-hog in, and now I’m back to tiptoes and doing little bits, and… It would be cool to get paid to work on open source again. I’d like that.

How about you, Nick?

Yeah, so my story is a little bit different than both of yours. It starts off with a lot of impostor syndrome, as these stories typically do. My first job out of college I was doing a lot of Java work. I didn’t really like all that much, so I kind of gravitated towards the front-end and I got introduced to first Prototype and Scriptaculous, and I started doing some stuff on the job for using that. It was really cool. Then I discovered jQuery, and I was just blown away. I started really getting into that, and you know, following John Resig, and just deep-diving into jQuery a lot, really enjoying it… And I wanted to contribute, but I never felt like I was good enough, or that I’d be able to contribute anything, and I never did.

But I left that company and joined another company where we were doing a lot more with open source, with Ruby, and they were using Dojo on the front-end… And when they did a big seed round, they wanted everyone who was remote, including me, to relocate, and I didn’t really want to. So I started thinking about something else I could do, and that’s when I reached out to my current employer… Because we had been using some of their open source software, including Dojo and dgrid, which was a next-generation (for the time) grid widget for Dojo. It was really cool, and I really liked it, and I had submitted one bug report to it that was actually a valid bug, so I was really excited about that… And I reached out to them based on just having used their open source a lot, and ended up joining there.

[16:03] So I’ve been at SitePen for about six years now, and I really enjoy it, where I get to typically spend a day a week contributing on open source. Sometimes more, sometimes less, but on average about a day a week, where I’m actually on the job, contributing to Dojo or other projects; I’ve contributed to CodeSandbox and TypeDoc, and Intern testing framework, and a couple of others. So now that’s what I do.

I’d say the interest that I had getting into it came from the community that I saw around jQuery, and then attending meetups locally and just talking to other people about what they’re excited in. I knew some people who were contributing to different things, and just wanting to emulate them and be cool like these people that went to the meetups. That’s kind of how I got started into it.

Nice. And then I think an interesting way to look at this or talk about this for each of our stories is to talk a little bit about how open source has impacted our careers and our career growth, because I think that’s one of the big topics around “Oh, should I open source, should I not…?” In some ways, it’s giving away free labor, but in other ways it can really amplify and change your career trajectory.

I wanna hear for both of you, but for me, that was when I started really being able to go out and speak at conferences… And not just go to conferences as an attendee, but actually become a speaker. It gave me credibility for writing, for promoting my own material. I’d say through a meandering way is how I ended up on JS Party; I was at a conference, speaking about the foundation, and I met Adam from the Changelog. Then a year and a half later or two years later he was like “Hey, we’re doing this thing around JS Party. Would you be interested?”

So for me, I don’t know that it’s changed any of my programming job opportunities, but it has absolutely shifted my ability to go out to conferences and speak and be sort of a public figure in the tech world… From nothing, to - I wouldn’t say I’m a celebrity, but I can actually go to conferences and speak now, and I’m on JS Party, so from zero to one, right? Maybe not where you might wanna get to, but it got me started.

I completely agree. These are the kind of tropes that we hear a lot, especially on Twitter… You’d see somebody be like “Oh, I’m getting burnt out trying to work on open source apart from my day job.“Maybe open source would not work for you, maybe you wouldn’t like doing it, or for a variety of other reasons. And also, I agree that sometimes certain projects, certain work on open source could be free labor essentially, but it’s quite the opposite that has worked out for me, I guess. I think it’s more about which communities you work in, and which projects you invest your time and effort into.

Taking the example of Node - it’s an open source project which is run by volunteers, but the Node.js Foundation has done a tremendously amazing job of trying to make sure that they do the best in their power, essentially, to help out people. I’ve been directly affected by quite a few of those. For example, my first exposure to speaking and conferences was when the Node.js Foundation was pretty much like “Hey, do you wanna come to Berlin?” and I was like “Sure.” That was the first time when I went out of my city and met amazing people at a conference, and essentially that’s what later pivoted into me being like “Huh, maybe I could try to speak… I don’t know, these people seem amazing.”

So yeah, I’m probably a little biased personally, but the impact that has been created by open source software, by community work in my personal career has been super-inspiring to me personally.

[20:02] It’s kind of weird, I kind of went all-in, especially with a lot of these things, but it has worked out quite well for me. There’s also projects like v8 and Electron who care a lot about the people who work on these projects, and the communities are so wonderful that literally there’s been a lot of phases where I’ve not been paid to work on open source project - that’s usually been the norm - but I’d still never stop working. I’ve reached a point where I don’t even care about the code anymore. I’m just there for the people.

I feel like your story is kind of amazing. If I’m not mistaken, you said you got started basically as you entered college, or university, and if I’m not mistaken, you have not exited university yet and you’re already speaking around the world, and you’re talking with companies in all sorts of countries about maybe working with them, and things like that. That’s incredible. I think when I graduated college I had zero contact in industry.

Yeah, it is super-crazy. As I said, I still cannot thank these people, thank these events enough for what they’ve enabled me to do, essentially. And as I said, somebody might call it free labor, but working extensively on open source projects, going all-in – in a month or so I’d be like everybody else; I’d be a senior year student at university, but the difference is that I’ve done enough work in the open at this point that people don’t ask me about my technical work anymore… Which is kind of cool.

I really like the fact that I’m already deep into the ecosystem, I already know amazing people, and open source is pretty much the only thing I have to thank for that.

How about you, Nick? How has open source – I mean, you mentioned you got a job, basically, through open source connections, or interest in open source.

Yeah.

Anything else that has really impacted for you?

Well, I’ve pretty much been at the same company since, so career-wise I’m enjoying it, and I get to work on open source quite often… So that’s great. I also get to help people with open source. I’ve done a lot of fixing bugs in other projects, or being able to point people to specific pieces of source code. I guess it really has helped me overcome impostor syndrome a little bit, specifically with being able to jump into a codebase that I am unfamiliar with, and kind of trying to quickly come up to speed on what’s going on in there, try and quickly find something that I can work on or something that I can do… And I think that that was one thing that I really struggled with in the beginning - “There’s this project, I wanna help. What can I do?” It’s really about just finding a way to contribute, and that can be a doc fix, or adding tests, or something simpler than that… But really, has it impacted my career growth? In confidence I’d say that is yet to be seen.

Alright, welcome back. We’re gonna talk about different ways to get started in open source. I think one of the things that’s really important to talk about is that this doesn’t only mean code. There’s a lot of different ways that you can get involved in open source. I’ve got a list that I’ve gotten into my head, but Ujjwal, since you’re often answering this question for folks, why don’t you take a stab at it? How would you recommend folks get involved with open source?

Yeah, this is something that I’ve been asked personally quite a bit, and I guess a little shout-out… You’ve just talked about the Node.js Code & Learn, and Node.js has been trying to do a lot of [unintelligible 00:24:45.01] projects to help people get into the community, and one of the projects that I’ve been working on these days is called The Mentorship project. There’s ten mentors from across different areas in Node core, me being one of them, and I’ve been mentoring an amazing, quite talented individual to work on Node.js, as are the rest of my colleagues.

Now, I’ve been dealing with this very recently, but I guess one of the big things to overcome is the stigma, and as Nick pointed out, the impostor syndrome that a lot of us might have when working with open source. For example, I’ve heard all sorts of stuff, like “Oh, it’s just documentation fix.” And for example, just picking this up, I’ve found documentation fixes to be in fact some of the most difficult fixes in Node.js. I could tweak values all day, I could not write good documentation starting out; I’m still barely good at it. And that’s the thing.

If you go to projects like Ember - they’ve set up an amazing website. I was just talking to one of the core team members from Ember about it, Chris Manson… So Ember has this website where you could essentially see all the different areas you could get involved at. There’s initiatives, like we’ve been talking about, “Help wanted”, “Good first issues”, and “First-timers only”, which you could use to your advantage, essentially.

But apart from that, that usually covers the code part of the spectrum, and little about documentation maybe, but it’s really important to look at the community work that is going on around the project any given time… And as I see it, it’s sometimes really hard for people to understand how that could be useful. It’s hard for us personally to make people understand how they’re creating impact, especially because there’s no reliable metrics to judge that. If you’re still closing issues and triaging bug fixes and helping us clean up the mess that we make on GitHub, there’s no metric to judge you on that and say “Thank you, you made XYZ commits.” So it’s hard, but it’s really invaluable, and the people who do it - I know I appreciate them a lot, and pretty much everybody appreciates them.

There’s two sides of this - you don’t have to be a hotshot coder to write code that runs Electron. Honestly, for example Electron - that’s probably one of the more frightening things I’ve been through; I was like “Oh, I work on Electron, and Slack going into an IPO. Hey, is it stable enough?” But at the same time, if you don’t feel like getting involved in code, that’s perfectly fine. There’s people who run, for example, local chapters for Node School. That’s such an important task. There’s Vue Vixens chapters across all major cities at this point, there’s Angular meetups and whatnot…

[27:52] So I think that’s one of the good ways to get involved into these communities, Tierney being an amazing example - he started out with inclusivity and outreach on Node.js, and ended up being the chairperson in the community committee. He still works extensively for the community committee, and the kind of impact that he has created in other people’s lives, even if you discount every single line of code he’s written, is astonishingly high. For me personally at least, it’s been amazing to interact with him, for example.

So yes, get involved in whatever you feel like. Absolutely none of these areas are better than the others. Do you think that we could run Node.js without the community support? Absolutely not. And I guess that’s something that I want to shove into people’s faces; I wanna go up like Big Ben and shout it across the roofs, that “No, documentation is important. Community work is important. We need you, more than ever.”

Yeah, one of the things I saw the Vue.js project do, that I thought was really cool, is that they have core team members whose focus is the docs. There is a core team member whose focus is on the docs. And in fact, at a Vue Conf that I went to a year and a half or two years ago, they were calling out that one of the big drivers for why Vue.js has been so well-adopted is because Chris Fritz did an amazing job on the documentation, and that that was one of the biggest things that they saw as a reason underlying the phenomenal growth.

If you’re a software developer, you might think “Okay, but that’s not my skills. Maybe I shouldn’t be doing that”, but then you feel too intimidated to get into the code… Writing docs is actually also a phenomenal way to learn the codebase. So if you feel impostor syndrome around “Oh, I don’t know if I can touch this codebase”, you can still be creating incredible value on the documentation, as you learn the codebase. Because if you go in and something’s not clear, you may have to dig deep into the code to understand how to describe that properly.

Similarly, things like tests. So I went to the Node.js Code & Learn that you hosted in Colombia, and it was the first one of those events I’d been to… And almost all of the issues were around “We’re gonna increase code coverage. We have a code coverage tool, and we have something where it’s like, okay, this line is not covered.” And you think “That’s trivial. How helpful is that?”, especially when a lot of them were these little corner case branches… But solving those issues was a great entree into the code, because you had to go down and understand a little bit about “How is this actually working? How are all these pieces wired together?” And you have to build the project, and you have to go through… So these tiny, tiny-seeming things actually become wonderful onboarding ramps into the codebase, AND they’re helpful to the project.

So yeah, I feel like there’s no contribution that is too small, because part of the point is it’s teaching you about how that project works… And it is helpful to the community. The fact that the docs are amazing is a big driver, and I see in the chat that Ember has a whole team around learning - that’s another thing, learning. I’m looking at the Vue site, because once again, Vue is the framework that I’ve been the most connected to recently… And on their Core Team page they have callouts to community partners that include a bunch of people that just do education stuff; some of it is free, some of it is paid, but communication is a huge deal, and it’s something that a lot of times the core developers of a project may not be very good at. So if you’re good at that and you can go and help with that, if you can help teach, if you can help communicate, if you can help write documentation, those are not only good entrees into the codebase, but they’re incredibly valuable contributions to those projects and to that community.

[31:59] Yeah, definitely. It’s definitely easy to make a computer understand code, but it’s a completely different feat to make humans understand that code, and that’s where documentation really shines.

When we look at getting started, maybe let’s talk about how would you pick a project? It’s easy to say “Okay, I’m excited. I feel like, okay, I’ve got a low barrier - I can contribute to docs, I can contribute to code.” But how do you decide where to contribute? What project, what community?”

Yeah, that’s a very interesting question, and it’s one of the most important questions that you ask yourself. People really underestimate how important community fit is. You could start working at any project. For example, we talked about Linux kernel, which you didn’t find a good fit for yourself. But there’s a whole lot of really talented, really amazing individuals who work on the Linux kernel project, and they find that a good fit for themselves.

So I think it’s really important to understand what your fit is. Look at these projects, like – Node.js has been around for over ten years now, Electron for a little bit less, and v8 for more than that… But if you look at the initial phases of these projects, a lot of the people who got involved early on were people who were really interested in the technology. A lot of people who got early on involved into Node.js were interested in streaming, and event-based APIs, and runtimes. And people who got involved in v8 were interested in parses and optimization.

I’d actually go on a leg and say that’s not really the case anymore. I look at myself, and I look at some of the other younger contributors who have only been involved for the last year or so, or maybe just a little bit more… And I see people who essentially join the community. Me, for example - I’ve learned everything about the Node.js project, I’ve learned C++ essentially via working on the project. I’ve found amazing people on Twitter doing amazing things, and I was like “Huh, I really like these people. Maybe I could somehow find a way to work on them… Start writing tests, and then start writing JS code, and then start writing C++ code.”

As a project goes on and grows and gets more mature, and you develop your community - so it’s more about community than the code, at some point… Because I think, along those lines - that’s how I try to explain to myself - the amazing press coverage and the amazing community… I ascribe to the amazing Rust community, the success they’re having these days, is that they spend a lot of time building an amazing community, and they’re starting to reap the benefits of that.

So unless you have a welcoming community, unless you have somewhere where people can find a good fit for themselves, where people can feel at home… You know, technical superiority, as some might say, is a far-fetched goal, because you will miss out on a bunch of amazing people.

If you look at the direction projects like the Linux kernel is moving to, you’d see they’re starting to realize that they need to work more in inclusivity, and they need to work more on how to get people to feel more comfortable working on their project.

I think there were some really key points in that. One is making sure that you are actually interested in what that project is doing. You sort of said, “Oh, that’s super-important, that early on they’re interested.” I think that’s super-important as you go. If you don’t want to be a user of this project, you will not be a great contributor for it… Because you won’t have, in your mind, like “What are the use cases? What are you trying to solve?” and you probably won’t maintain interest.

The community is so huge, and I think there’s some good tells out there to try to identify what’s gonna be a good community to join. Chris in the chat mentioned “Read the code of conduct when choosing. And if there’s none, avoid.” I think that is actually a really good piece of advice. Not necessarily because every code of conduct is going to be perfect, but rather the fact that they have a code of conduct means that they actually care about how people interact. They have thought about it, and they’re not just assuming that things are gonna work out, which tends to lend itself to bad actors.

[36:25] I think further than that, you can often get a sense for how people interact by looking at existing pull requests. If somebody who’s not a core contributor puts a pull request up, do they get a positive response? Do they get constructive feedback? Do they get taken down in an extremely negative way? Are pull requests and issues by people outside of the core project merged/addressed, or are they ignored?

There are a lot of tells that you can look for to see “Is this a community that is welcoming to others?” I think that’s a really important thing if you’re joining a community. You want a community that is friendly, you want a community that is helpful to newcomers, that’s not gonna make you feel bad, and you want a community that’s open to others coming in and starting to contribute. If the only PRs being merged are those by the core team, this might not be a good project to join as a new contributor.

Another place you can check - a lot of projects have set up their own communities on Slack, or Discord, or Spectrum… So there’s lots of different places that you can check, and you can go look at the history of that chat and kind of get an idea of what the community is like, and also jump in and ask for help getting started; that’s a good place to get real-time asynchronous feedback, with contributors and other enthusiasts of the project.

I will say, if you’re in the JavaScript world - and if you’re listening to this, you’re probably in the JavaScript world - some of the most welcoming projects I’ve seen out there are Node.js and Vue.js. They are both incredibly welcoming to the community. It sounds like Ember is as well, but I have not directly been involved with that… But that’s another one you could look at.

Yeah, and this Code & Learn that happened at Node.js Colombia - is that similar to the one that happened at Node.js Interactive in Vancouver, Kball?

I did not attend that one, so I don’t know.

I’m just curious…

Yeah, I’d say that the Node.js Code & Learns are coordinated events, and they happen more or less in the same way. I think the final details rest on who are the final [unintelligible 00:38:25.04] people who are organizing it… But I think it’s really important to keep in mind that the community at large is involved in that. It’s like, I could go on and physically help out a bunch of people, but without the support of the community sitting at their homes, merging PRs like crazy, and running CI servers every once in a while, it’d be impossible. So it’s more like a whole team effort, but we try to do those as much as possible.

I’ve personally been trying to do those more and more in regions which have been traditionally underrepresented, in Node.js core. For example, I was really happy to organize the first ever Code & Learn in Russia, a couple months ago… Which is crazy, right? Russia has an amazing community of programmers, and a bunch of really amazing JavaScript developers; why don’t they have enough people working in Node core? Because maybe they’re not getting enough attention, so now they are. And I’m planning to organize a second one soon… But yeah, I think Code & Learn is a really important tool to impart people to contribute to this codebase.

Nick, you talked about the impostor syndrome, and that’s been something that I’ve been personally dealing with a lot, especially when I was initially working with the community, when I would constantly think that I’m not good enough to solve an issue. And not only that. That’s actually fairly better than thinking what I used to think, that “Oh, I don’t even need to ask them, because I’m just a waste of their time.” Now, Code & Learn goes the extra mile of saying “You’re not a waste of their time anymore, because they’re literally at the same location, and it’s literally a part of their job for the next couple of hours to help you. They’re there to help you.” And I think it bridges the gap, the asynchronous workflow that GitHub offers.

[40:17] I mean it’s great, but sometimes you’ve gotta just sit down with the person and talk about the problem, which would give you a great insight into not only the codebase itself, but into their problem-solving processes.

I think it’s one of the most powerful things that I’ve learned, more than the codebase itself - it’s “How do certain core collaborators in Node (or in v8, for example) approach certain problems and deal with them?” So I personally think that it’s a great initiative. It could be scaled up much more, of course, but where it is, as it is, I think we’ve been trying our best to spread the love.

Yeah, I was really impressed by that event. I didn’t participate in it, but just from what I’ve heard, the ideas that everyone would submit a pull request to Node - that can really help break the surface tension of getting into open source, which is really cool… But it’s also fascinating being able to manage that on the Node side, saying “We have an idea of enough pull requests that we can get everybody started and going.” And they don’t have to be huge ones, but they’re going to be significant to the people that are doing them, which is great, because it’s going to help the project, but also going to help everyone involved just level up their game with Node, and just get into that project. And they may never make another commit again, but they may contribute more in the future, and that’s huge.

Yes, totally. Talking about people who would never contribute again - I personally think that’s perfectly fine, as long as we helped in any way whatsoever. Maybe we just helped improve their confidence, maybe we just help break the surface tension, maybe we just help them jump through that one hurdle that was blocking them from working on whatever they feel like. I think it’s a worthwhile attempt.

Also, as I see it, at some point the Node.js people realize that it was much harder to set up the project than to actually make a commit, that in most cases might be trivial. It’s a JavaScript project, you make a bunch of changes. That’s what you do at a day job also.

On the other hand, it’s probably rocket science at times to set up the project, and that’s the deal. Once you set up the project at your local computer, once you know how to make the commits, how to follow the commit guidelines, how to trigger CI, how to wait for review… I think once you get through the administrative/governance related hurdles, the code part or the documentation part itself is kind of simple.

Yeah. It was super-cool to be a part of. It was an awesome event. It was also neat hanging out with some of the folks who ran it afterwards, and being like “We had 100 people”, and after an hour or two after the event closed they had 60 pull requests open… And I asked, I was like “How many of those folks go on to make more?” and they said “Well, you know, we had 100 people. Maybe 60 made a pull request today, and maybe three or five of those will go on to be regular contributors.”

I mean, three or five regular contributors to an open source project is a lot. Maybe not at Node scale, but most projects I’m familiar with, until they get massive scale, three or five is an appreciable percentage of the team.

Yeah, totally. Personally, my goal is always – I started off with a goal of one, and I continue always with a goal of one. As long as I can help one person, it’s a successful event to me. As long as one person – they don’t even necessarily have to start working on Node full-time. As long as one person thinks that open source is something that they could possibly work on, as opposed to feeling kind of dicey about it, I think that’s a worthwhile shot.

Let us talk now about how to level up as an open source developer. How do we go beyond good first issues, and maybe code coverage pull requests, like I was doing for Node.js, and become someone who’s – if not working on it full-time, which for some people would be the dream; I would love to be paid to work on open source. I don’t know if I’d go to full-time, but I’d love to get to do that as a part of my job again… But even just to a level where you’re comfortable; you can contribute, you can jump into a project and say “Hey, I’m here to help.”

Let me throw that out first to Ujjwal, since you’ve been thinking about this and answering a lot of folks’ questions on this - how do you level up?

Thanks for the amazing question. This is a really special question for me actually, because not only have I been asked this extensively, but this is something that I’ve personally struggled with a lot. Again, projects are great, and some projects are more inclusive than the others, and then there’s programs like “First-timers only”, and “Good first issue”, and as we talked about, Code & Learn, or even the mentorship program… But the deal with these programs is that they have a very specific environment, they have a very protective environment in which they want you to grow… But how do you level up from that? How do you level up from your first issue, the metaphoric first issue - which might as well have been like 16 issues, as it were for me - to the second issue, which is a completely different thing… To pick up something all by yourself and enter completely uncharted territory. It’s like escaping the tutorial, essentially.

So what I think is one of the better ways is to get involved in a big ongoing project, in a big ongoing initiative. This helps a lot, because the stakes of the kind of like official mentorship that you had during your first experience - maybe it was a Code & Learn - but at the same time there’s enough people working on the project that you don’t need to be full autodidact. So you can still take inspiration from people… And one of the things that I do - I shamelessly copy people’s PRs.

So what I personally did, for example in Node.js, was that I remembered I was writing a bunch of good first issues, and somebody popped up and they were like “Oh, we need to refactor all the tests.” And I was like “That’s a lot of things. Can you do them all by yourself?” There were like “I love to split.” And I essentially would go about asking them to do a file for me, and then I would follow their steps, and going around that to do something that was not planned. Towards the end, they were like “Well, thank you. This is actually really useful for the project.” That gives you confidence, that gives you the familiarity with the codebase and everything, that then you could be part of bigger initiatives; then you could be part of more self-govern initiatives. Maybe you could start your own initiatives.

[48:13] So this is what I would usually do - if there’s a massive ongoing refactor, for example (those are really common), I would participate in that. If there’s a massive rewrite of code, for example if a project is being rewritten in TypeScript, it’s a great second issue, because it’s unplanned, it’s uncharted territory, but at the same time it’s more or less certain what’s expected of you. So that’s the kind of middle ground that I think of myself - it’s unplanned, but then it’s well-defined, because towards the end you’d be working on things on your own accord; maybe they would not be well-defined at all. You’ll be like “Oh, let’s add ES module support in Node.js”, which is a crazy amount of work.

To quote an example from v8 - I’ve been working on adding async stack traces, for example, to certain functions. Now, async stack traces have already been added for certain functions by the amazing and talented Benedikt Meurer from v8… And what I could do is I could look at his work and take inspiration. I could check his notes, essentially; I could ask him what his approach was. So while it’s still a great thing to do, while it’s still a completely new thing that we really appreciate, at the same time it’s not entirely new in the sense that it’s well-defined what’s expected. So that’s my actual secret recipe that I just handed to you for good second issues; that’s what I do when I try to increase my involvement in a certain project, from newbie to more deeply-involved… And I’d love to hear yours.

I’d love to actually call out one of the things you said there. You talked about copying people’s PRs, and I think at first blush that sounds like “How is that actually gonna help me?”, but I think it ties into something really powerful. I heard a phrase that I like, which is “First you emulate, then you innovate.” Taking work that someone has done - this comes back a little bit to like “How do you learn anything?” You start with a copy and paste and then you tinker, and you explore, and you figure out how it works. So saying “Here’s somebody who’s already done some work that is very similar to other work that needs to be done… Let me take their work and try to apply it in this new place.” So then I start to learn about “How does that thing that they did actually work? How does it interact with other pieces of the system?”, but you don’t have to learn everything at once, because they’ve already done most of the work.

Yeah, absolutely. That’s kind of my approach. As I said - I’ve been shameless about this - I think personally “copying” PRs has worked perfectly for me, in that it gets me into the thought process of the individual. It’s like “Okay, here’s what they did, and I could break down their months’ worth of work into small pieces, and be like “Okay, this is why they did this, and this is why they did this.” It’s been amazingly helpful for me to understand the inner workings of certain systems, I will not lie… And that’s mostly how I’ve been getting more and more involved with certain things these days - first I try to imitate. The important part is not just imitation, but post your imitation I guess you need to analyze what happened and why certain things happen in certain ways… And then you could try and make sense of it one chunk at a time. Maybe it doesn’t make complete sense to you at the beginning, but sooner or later we’re writing code; it’s no magic. Sooner or later, all the gnarly details will reveal themselves to you, and at some point you would get comfortable enough to be like “Huh, so that’s happening…”

[52:00] I guess that’s what essentially happened with Node with me also, in that I would be like – really simple things, like “Oh, I need to add a function to the fs module. Now, this person added a function to the net module, and the file they changed is lib/net.js, so guess where the fs module lives? And simple things like that would actually go on to form my framework of understanding of the codebase, because as Nick said, especially with projects like Node, it’s increasingly difficult to get into a project like Node. It’s always increasing in size, it’s crazy hard how big the source code is… And at some point you’ve gotta keep in mind, 50 or so people are getting paid full-time to work on this project. You cannot possibly understand everything in the codebase in a go… So do not. Just give it time, just go through certain things at your own pace.

I think at this point the framework I have of how Node works internally was created essentially brick by brick, by imitating people, and then essentially understanding what they did, and I was like “Okay, this is how this certain portion works. Now I know this.”

I didn’t wanna change topics, but I was just gonna mention - another way that you can get started with open source is by creating a proposal as an issue onto a project. That’s a really good way, to propose some changes, and then you can be the one to implement them too, or just provide feedback if you don’t feel like you’re technical enough. I’ve definitely done that a couple of times, and it’s really worked out well, where I’ve gone in and thought about a problem that I had, and a project was an 80% solution to what I needed, but it didn’t quite either do the things I wanted, or give me the hooks into it that I needed to be able to make it do the things I wanted… And so I’ve worked on writing proposals, saying “This is a problem that I have. Is this something that you would be willing to support? And if so, if you could point me in the right direction, I would be happy to start implementing it.” I’ve gotten started in two open source projects through that route, and it’s been very beneficial.

Yeah, totally. I resonate with that a lot. Going to a project and being like “Well, we’ve gotta do this, but the catch is that instead of doing it yourself, you’ve gotta teach me instead.” In that direction I think Node has an amazingly helpful label that you can use at the repository right now, which is “Mentors available.”

Every once in a while somebody would find an issue that they could easily solve, but they would leave it out for somebody who would like to perform those tasks essentially under a mentor, instead of – maybe they don’t have the confidence yet to do it by themselves, maybe they lack some expertise to do it by themselves, so… Yes, a lot of amazing people at Node would sometimes mentor people for specific issues, and I think that goes a long way in helping impart your expertise about the project to another individual.

Yeah, I like that a lot.

You need to know yourself, and know how you take feedback and how you take setbacks, and things like that… But if you are somebody who is comfortable with failing, and comfortable with getting feedback, and especially if the project you’ve chosen has a supportive community, something that I have both used and seen used with great effect is essentially taking on something that is beyond your capabilities, being very open about that and saying “Hey, I’m gonna try to do this. I am almost certain I’m gonna do it wrong, whether it’s because I don’t understand the project well enough, or because it’s beyond my current overall technical skill or what have you, but I’m gonna do my damndest and I want to lay the door open for every piece of feedback.” Saying that explicitly in the pull request, for example, and saying “Hey, I’m new to this project, I know I did stuff wrong here - tell me what I did wrong and how I can fix it.”

[56:08] If you have a supportive community, often you’ll get back great stuff. And if you don’t have a huge amount of confidence in yourself, that can feel negative, even if they’re supportive. It can be like “I didn’t do it right. I didn’t.” So if you are someone that is still working on building your confidence, don’t take this approach; but if you feel pretty self-confident and you’re good at dealing with feedback, tackle something that is out of your comfort zone by a long ways.

One of the core contributors when I ws working on ZURB Foundation started coming in - he had no idea, and he was just like tackling stuff. He’s like “I wanna be able to have this, so I’m gonna try to do it.” His first pull request got – I think the thread was up at 150 or 200 feedback and comments and iterations, and this massive chain of things… Because he tried, and he got a bunch of feedback; he tried again, and he got a bunch of feedback; then he tried again, and he got a bunch of feedback. It went over and over again. That pull request never got merged, but he learned so much from that that he then went on and started tackling other issues, and eventually he became one of the core team members.

So I think being unafraid – if you can have that level of confidence in yourself to say “You know what, this is not gonna succeed. I’m gonna get a lot of negative feedback, but I’m gonna tackle this, I’m gonna try, and I’m gonna seek out that feedback, I’m gonna seek out that guidance” - that can be a very fast track to learning.

Yeah, that really resonates with me also, because that’s essentially what has happened to me multiple times. I guess it’s also about accountability… At some point I realized that I had also a profound impostor syndrome, and I would essentially game my impostor syndrome by going to a person and being like “Oh, did you know that I’ve been working at a couple of proposals at TC39?” and then they would be like “Okay.” And then I’d go back home and feel super-stressed about it, so I’d just DM Daniel and be like “Hey, please help me work on these TC39 proposals…”

I think one of the more important things to understand about this community is that – I’ve personally at least received a lot of love, a lot of guidance, a lot of mentorship from this community. I think it’s really important, and one of the biggest, most important things to understand is to realize that it’s okay to ask for help, it’s okay to ask questions, it’s okay to keep asking as many questions as you can. It’s okay to ask a question that you feel is a stupid question because there’s no such thing as a stupid question.

For example, there’s people like Benedikt and all these amazing people at Google who work on v8, and I’d honestly be like “Oh, they’re so busy… Of course they can’t give me a minute of their time”, and then somebody at v8 would spend the next two hours trying to explain to me how parsers work. So it’s just crazy how much amount of help you can receive if you just ask for it. That’s something that should be kept in mind also.

And as you said, depending on what kind of person you are and how comfortable you are with that, I think the point where you step out of your comfort zone is when you make the biggest quantum leaps. It’s crazy – my involvement with the v8 project essentially started with somebody at v8 asking me if I wanted to work on v8, and I just hastily said “Yes”, without thinking what it would entail… And then spending the rest of the summer reading the Dragon Book, trying to figure out how that works.

And as you said, it’s really important to understand that it’s okay to fail. It’s okay to fall flat on your face, because we fail all the time. So if you fall short of where you thought you’d be, at least you – as they say, if you aim for the sun, at least you’ll hit the moon… As opposed to not even trying. So it’s great to aim high, it’s great to get out of your comfort zone - of course, if you are the kind of person who enjoys that kind of stuff.

[01:00:11.23] One thing that I think is worth saying is if you’re putting in the work, if you’re trying, if you’re trying to do PRs and you’re trying to do stuff and you’re putting work into the project, people are gonna be excited about helping you. If you show up out of nowhere and you ask a bunch of questions and you’re not doing any work, people may not do as much to help you… But if you’re putting in the work day after day and somebody gives you feedback and then you come back and you’ve clearly incorporated their feedback, even if it’s not perfect, they’ll keep working with you.

A question that’s sort of related to that that people will ask is “How do you get a mentor? How do you get somebody to help you?” I’ve mentioned a couple different developers over the last few years, and each one it’s because they’re somebody that they are going places. I get excited to help somebody get someplace faster. If you don’t know where you’re going or you’re not trying to go anywhere, I’m not gonna help you. I mean, I’ll help you a little bit, but I’m not gonna keep investing. But if you come to me and ask me a question, and I give you an answer, and then you come back and show me how far that took you, and you’re going and you’re going and you’re going in this project, I’m gonna keep giving, because that’s exciting.

If you’ve been working on this project for a while and you see somebody coming in and they are going for it, you’re gonna want to help them. That’s human nature, I think. We like to help people who are helping themselves. So if you wanna get in, just go for it; and if you fall flat on your face, if you’re going for it, people are gonna pick you up and help you keep going.

Absolutely. I think one of the other sentiments that play out in this space a lot is that, for example, as I was telling you, a lot of amazing opportunities in my life have been created because of essentially working on these open source projects, and especially because of very certain individuals who helped me quite early on, and at some point I realized that I had grown enough to help out another individual… And I was like “Okay, maybe it’s time for me to give back to the community. Maybe I’ll do a bunch of talks, maybe I’ll mentor a person.”

The crazy part about community though is that no matter how much you give to it, it always gives back more. So I’d go to a conference and I’d be like “Oh, it would be amazing to speak at this place about this subject, because it would be good for them”, but it always turns out to be better for me. It always is a win/win. So the best thing about open source is to realize that we (especially in the open source ecosystem) live in a world of positive-sum games. There’s no limited [unintelligible 01:02:38.25] here. We all benefit from helping out each other. There’s a bunch of amazing places that you can contribute to, and everybody would benefit from there. There’s literally no person who’s not benefitting from that, so you should create these opportunities.

Talking about mentors also, as you said, I’d say that I’ve had hundreds of mentors across my life working on these projects, without any of them knowing they were mentoring me. It started with one Twitter DM, and before you know, they were helping me out, full-on, with solving issues one after the other.

[01:03:16.08] I think being on both sides of the board at this point (fairly recently also), what I realize is that as long as you’re making progress, as you said, the mentors don’t care how slow you are. If you’re moving, no matter how slow you are moving, you’re doing great. And as I just said, especially when it comes to open source, you’re already ahead of 85%-90% of other people if you just show up… Because most people would never even show up.

Alright. I think that’s probably a good time to wrap. Any closing thoughts either of you wanna leave us with?

I guess I could just say that if you’re anybody who is trying to get into open source, if you’re anybody who’s trying to get – especially in the JavaScript ecosystem there’s this crazy amount of people out there who are just waiting to help you… Or maybe probably not just literally waiting to help you, but who would be really glad to help you is what I mean. Personally, my DMs are always open. You can find me on Twitter, you can find me on email if you prefer that…

When I talk to people about getting them working on Node.js, a common thing that I’ve been known to say is that 99% of the time I would not know what to do, I would not know how to help you. But 100% of the time I know somebody who could help you… So just reach out. Reach out to me, reach out to any of these amazing people that I mentioned… Reach out to pretty much anybody on the Node.js core team. I do not know of any person in the scene right now who would not be super-glad to help you. We’re really glad if you could start working on the project, and - well, we need you more than you think we need you.

Awesome. Alright, with that we’re gonna wrap up this episode. Thank you, Ujjwal, for joining us. This has been an awesome conversation. Thank you, Nick, for being my co-flier, co-panelist on here yet again; it was good to hang out with you again, because it’s been a little while. Thank you to all of those out there live, listening; you are what make this a party. It wouldn’t be a party without our live listeners. Particularly, I’m gonna call out Chris Manson and Isaac Carter - thank you for joining us in the Slack channel. If you weren’t able to Slack with us but you were still listening live, props to you; you’re amazing, and you make this a JS Party every week.

With that, we’re gonna wrap up. Catch y’all later… This is Kball, signing out!