The Changelog: Software Development, Open Source - First-time contributors and maintainer balance (Interview)

Episode Date: April 10, 2017

Kent C. Dodds joined the show to talk about guiding and supporting first time contributors to open source. We talked about the many ways to be first-timer friendly, how to contribute to open source, the burden and balance of a maintainer, and a few of the projects Kent maintains, including his latest project at PayPal called Glamourous.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. I'm Kent C. Dons, and you're listening to The Changelog. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 246, and today on the show, we're talking to Kent C. Dodds, talking about guiding and supporting first-time contributors to open source. We talked about the many ways to be first-timer friendly, how to contribute to open source, the burden and balance of a maintainer, and a few of the projects Kent maintains,

including his latest project at PayPal called Glamorous. We have three sponsors for today's show, Sent top towel and go cd first sponsor of the show today is our friends at sentry helping you to find and fix your errors in your applications you can start tracking your errors today totally free and support react angular ember view backbone and note free more like express and koa you can view actual code and stack traces including support for source maps, see the errors, URL, parameters, and session information,

and even prompt your user for feedback when you have front-end errors. Head to changelog.com slash Sentry, start tracking your errors today for free. No credit card required. Get off the ground with their free plan, and when you're ready to expand your usage, simply pay as you go.

Once again, changelog.com slash Sentry, and now on to the show all right we're back we got kent c dodge joining us jared now we've been trying to line this show up for a month ish something like that we had to move it one time but we've got him here yep i'm excited are you excited absolutely. And excited because this show was put together with help from our friend Dwayne O'Brien. Dwayne, shout out. Thank you so much for introducing us to Kent. Yes. And Kent, welcome to the show. Thank you. I'm happy to be here. And so we've got this passion and love for open source, right? And open source needs, you know, more community, more contributors.

And I think the way, now I went back and looked and the Medium post that seems to be most famous for you was actually penned back in 2015, which I didn't realize, Jared. Like, I think we linked this up and changed a little weekly recently. And I think I never even paid attention to the to the date stamp like i thought this was a newish movement for kit but he's been doing this for a while yeah it's timeless a couple a couple years at least yeah yeah um yeah it's pretty cool um i i haven't actually done it a whole lot recently but um i'm like i still get people um messaging me and tweeting me

about it, saying that they've started doing it. And I'll like follow the first timers only tag on on GitHub and people are still doing it. And so that's really cool to me that it's inspired people to make their projects more first timer friendly. The first timer is sort of a loaded thing, too, because you're like, well, who is that really? Are they new to software development? Are they new to open source? And in a lot of cases,

it's probably people who are just simply new to open source. Like you would assume that they're so new to everything that you got to spell out everything for them. It's, it's more like, how do you open the door to say you're invited to be a part of this? You know, it's on GitHub or it's on source forge back in the day, whatever it might have been.

But, you know, this invitation basically to say, here's easy ways to step into this project or this community and move this initiative along. Yeah, absolutely. And that's why, like, if anybody hasn't read the First Timers Only blog post, you just search First Timers only, this will probably give you a little bit of good context. But basically, the idea is like, let's, let's just, you know, contributing to any project is it can be hard enough, like, whether you're really experienced or not, there's, like nuances and contributing to projects. And so let's put away those nuances a little bit and make contributing as simple as possible. Because like the hard part about getting into open source isn't necessarily the like the actual code that you'll contribute, but it's figuring out how to work with GitHub or whatever, wherever your project is hosted. But most of the time it's GitHub. Like what is a pull request and how do you fork and what even

is a fork? And how do you and especially like if you're if you're new, like how do you fork? And what even is a fork? And how do you, and especially like if you're new, like how do you use Git so that you can interact with that, with your fork and that kind of thing? And so like just making it as simple as possible to contribute so that people can learn about the contributing portion. And then once they figure out that contributing portion, then they can start utilizing the skills

that they already have to contribute in other ways. So Ken, I'm curious why this is something that's so exciting or something that you're passionate about. I guess we got so excited having you on, we didn't even really give you too much of an intro, but you're a software engineer at PayPal. You've done a lot of front-end stuff. You may know Ken's work from front-end masters or perhaps as a teacher on Egghead. So you publish a lot, prolific on Twitter, specifically in the front-end masters or perhaps as a teacher on Egghead. So you publish a lot, prolific on Twitter,

specifically in the front-end and JavaScript space. Did you have yourself a difficult time coming into open source? And so you're trying to help others get over that bump or where's your motivation coming from? No, I'm glad that you asked. So first off, I'm as privileged as all get out. I'm like straight, white, American. Like I've had computers since I'm as privileged as all get out. I'm like straight white, um, American, like I,

I've had computers since I was really little. And, and so, um, like I, I just feel compelled to help other people who may not be as privileged as I have been. Um, and so that like, that's one of the major motivating factors for me is just, um, making this kind of thing accessible to people because it's been so helpful for me. So like my first foray into open source, I don't even know when I learned what open source was, but I remember I was working on this Java project and I developed like this utilities library that was just useful in my projects. And I've since learned that all of those utilities were available in other libraries and stuff. But I just decided, hey, I'll just put this up on this weird GitHub thing that I heard about. And that was like, I think it's called My Java Helpers or

something like that. I'm pretty sure it's still on my GitHub. But that was like my first, you know, something is on open source. And so like for me, I actually started publishing open source, um, stuff before I started contributing to other people's stuff. Um, and it was never like, like people will often say that it's kind of scary for them to put their code out there. Um, maybe I'm like a big ham or something and I don't, I don't mind pushing my stuff out. I don't care. Like, I, I'm pretty sure that if it's bad, that like, it doesn't make a difference to me. I don't, I don't care if it's bad. Um, and, and people will tell me it's bad and I can maybe fix it or I can just not worry about it. Um, but yeah, like, so I, I made a couple of libraries and then I, I

fixed a typo in some Java doc. doc, and that was my first pull request. And then the rest is history. Just started contributing more and more. I think once you learn the process of contributing, then it just comes back down to your skills as a developer. Yeah, I'm trying to just think back at my own experience, especially around contributing on GitHub, where things got a lot easier.

In fact, I used open source for many years and i even considered i remember i made a patch to a c library at one point which was i was proud of because c for me is a difficult thing memory management and all that i've never been that good at it and i made an improvement to a thing i can't remember what the thing was anymore but i had no no idea how to, this was pre GitHub at the time. So there really wasn't a good, I mean, we talk about the first time experience and onboarding or ramping up. I don't know. There's lots of terms for this, but like getting people involved with open source is still hard, but the pre GitHub era, it was like way hard. It was so, it was so opaque. Like, I didn't even know you could do like it's

basically like you know generate a patch with some version and then email it to somebody that you know might be a project maintainer like whose name is on the source forge page or something so it was so opaque back then that i kind of grew up in open source alongside github as they added features so like the pull request was a new feature that came out and so i didn't really have to learn it because I was like, Oh, they announced it. And then I checked it out.

And I, point being is since I've been along for the ride of GitHub itself, I don't often look at it with the fresh eyes. Cause to me, it's so much easier now than it used to be. But the fact of the matter is, is it's still really hard. There's still a lot of things to to get over to get that

first contribution you also have a lot more things changing nowadays too like you've got uh the the most recent prior president of the united states advocating for people to learn code like normal people when i say that i mean people who've never thought about touching a computer or their only computer has ever been on an iphone or something that. You know, they're, they now have like this invitation to say, well, you can actually learn to code and there's a new way you can do life, you know, as an engineer or even just someone who is a drive by contributor.

Like you've got these people who are now being invited into this unique folder. And they're like, what is even the source? Not even let alone open source or whatever. They're just like, how can I, how do I jump on this train? Right. Absolutely.

Well, there's so much opportunity in our industry and there's so many people that need access to those opportunities, um, you know, or I'm making a good living. And I mean, not just the, the, the salaries that we can demand because we're, because of the situation that we're in, um, in our industry, but also just the freedom of life. You know, the, the, the, you can work from anywhere. It's just a great and enjoyable thing, right. As a career. And so we have people motivated, you have opportunity, and then you have this movement around open source as a resume or like this, you know, certain companies, you know, demanding that you have a GitHub profile, which is attractive for them to hire you. Can't curious what your thoughts are

on that whole, uh, thing of like GitHub as resume or open source as resume. Yeah. I'm glad that you asked GitHub as a resume is interesting. Uh, the, the real problem, um, that I have with like people saying you must have an active GitHub for us to even like interview you is that like it's inherently privileged. There are some people who go to work and they work on their closed source stuff and then they get home and they have to take care of their, you know, suffering spouse or, you know, their seven kids or whatever it is. And they are like totally dead by the end of the day. There's no way they could contribute to open source. And then there's like also people who love coding and they're really super good at it, but they're not really interested in doing it 24 seven. And so like it's like I would look at somebody's GitHub to see if they have anything and peruse the issues that they've been commenting on. Like, is this person cordial? Is this the kind of person that I want in on my team?

But if they don't have anything there, like they still have the like the stock avatar or Um, I'm not going to count that against them. I'll, I'll just assume that they have been unable to contribute. Um, or maybe that's just not their thing. Um, and like, it does say something, um, when somebody like is really into open source and, and, um, like, I guess it can say that they don't know how to balance their life. Um, but like, it's really hard to read that from a GitHub profile. So, um, yeah, like it's just kind of a fuzzy area. So I would definitely never say you must have an active GitHub profile to, uh, be of any interest to me because it's just way too overloaded with privilege.

That's like saying you gotta be, you know, you gotta live in a certain city of a certain state. It's no different, you know, it's,'s it's it's sort of silly because you're limiting you know your potential like there could be great software engineers that you mentioned out there that just they they do the balance they work eight they play eight they sleep eight right and they don't have time for open source or they just never made time yet. So they haven't played that role. And, but they're yet they're great. Right.

I mean, there's a, there's plenty of people who are mechanics and they're great mechanics and that's their job. And they go home from being a mechanic and they don't want to work on machines anymore. That's right. Until tomorrow.

Right. And then tomorrow they're going to go back to being a great mechanic tomorrow. And if you just completely said, I don't hire any mechanics who aren't also hobbyists, Until tomorrow. Right. And then tomorrow they're going to go back to being a great mechanic tomorrow. And if you just completely said, I don't hire any mechanics who aren't also hobbyists, so passionate that it consumes them 24-7, you're cutting yourself out from, I agree with you, Ken, it's a completely privileged thing because some people, maybe they do want to be a mechanic as a hobby, but like you said, they just can't because of life circumstances.

But you eliminate a huge swath of your of your talent pool by saying, well, you also have to be a hobbyist. So, yeah, absolutely. And there have been times in like in my contributor graph, I have a pretty, pretty heavy contributor graph. But like there have been times that I've taken a couple of breaks for like a month or so. Um, because I just like, you need a break every now and then there's nothing wrong with that. Um, and so like, and especially if you were to say, I will only hire people with active GitHub profiles, like you're, you're going to wind up with a situation where people get burned out on stuff. And it's just, it's not really a great situation to be in. Also, like a real challenge that I have like occasionally and I've seen is that people will get so excited and into open source that they neglect their work duties. And so like even if you have if you say, OK, I only want active GitHub contributors, what are they actually going to be contributing to when they get into your company?

So you need to hire for much more than that um so like yeah that's just another thing to to think about yeah there's so many factors i mean hiring is hard um so it's easy to armchair uh hire but it's hard to actually hire well. Tell us about yourself in terms of, I don't want to get too personal, but your work-life balance. Because you work for PayPal, you told me offline that you have open source projects with inside PayPal that you're doing. So you have open source opportunities at PayPal,

but you also have your front-end master's courses, you're teaching, you're doing websites like these, you're doing talks. How do you hold it all together? Yeah, I actually, somebody or several people have asked me that on my AMA. Um, and so I've, I've got like a pretty detailed outline of what my, my schedule looks like, but yeah, it like, it does take a lot of time. Sorry. And you maintain it, schedule because i feel like every time i don't really maintain it but it's not like really detailed it's basically like this is kind of generally how it how i make it work um but uh for like first off i um like i don't really

have a ton of hobbies outside of coding um i i really enjoy coding and that's just kind of what I like to do. Um, and, uh, so, and then my wife is super supportive. So if I'm working on a, um, an egghead course or, or a front end masters workshop, and I'm like really coming down to the wire or something, um, she'll kind of, uh, step it up and, and take care of things. Uh, while I finished that up, um, I, I have three kids and so that, yeah, there's a lot of effort around that. And so shout out to Brooke. But yeah, and like, I, I try to wake up early every morning to get a couple hours in working on my workshops and those kinds of things. And, and generally, like the stuff that I do for my workshops, inevitably will lead to some open source tool or something like just this morning, I was working on my testing workshop for front end masters. And I have this tool called split

guide that makes it really easy for me to have like, here's what the your exercises are. And here's what the final version should look like. Um, and so it's just a tool to make developing or like creating that experience really easy. And, uh, there was just a small issue in that library. So I really quickly, uh, made a patch and released it. Um, and I have the whole release process automated as well. So I, I can like automation actually plays a huge role in my ability to, um, uh, to do as much as I do. Um, but, uh, yeah. And, um, so like my contributions are like more often than not incidental, uh, to the work that I'm doing. So like,

um, there are a couple of projects that I'm using at PayPal that like we have something that's like it's this isn't a super experience. So I'll just go and make a contribution to something or like I'll be reading the docs for Babel or something and like, oh, that doesn't look right. Let me fix that really quick and GitHub's editor makes it really easy. And so, yeah, lots of really incidental contributions that are normally related to what I'm working on already. And yeah, and then just like being pretty strict with my time. I don't play video games. I just do coding stuff and it's fun to me. I enjoy that.

That's fine. I mean, not everybody who is a software developer has to be a gamer. Yeah. Right. Although if you are a gamer and you're not playing Breath of the Wild, then you're missing out. So I'll just throw that out there because it's amazing. You know, on the note of balance, though, Kent,

so you'd mentioned your schedule and stuff like that, the things you're involved in, and we're talking about you know being inventational and you know being polite and providing good on-ramps for first-time contributors and guiding them if we see that they have the default avatar and things like that you know there's a flip side to that though is like you've also got first-time contributors and to some degree where you're a first-time um you know creator of an open source project and in some ways you're kind of like the same thing, but at an org level and someone like you who's done some stuff in open source and have your own projects out there, you know,

there's, there's that balance as a first time contributor, but also as a maintainer and providing those ramps for people to come into play. How tough is it as someone who creates open source to balance, not only the roles of being a maintainer, but also being the inviter and the, the guider that, that person who's essentially helping attach training wheels to people to get them involved in open source. Yeah. Um, so are you saying kind of the balance of like, well, if I were to just do this myself, it would take like five minutes, but if I'm going to spend time helping this person, it's going to take like two hours. Or is that kind of what you're doing? Being the maintainer, being somebody who's,

who's got to be the leader, you know, potentially even be the person who does meetups or go speak conferences, but also be thoughtful enough to say, here's how you can first time contributor. Here's where to put code and things like you'd mentioned in that article back in 2015, how do you balance being a main chain, but also being that person too? Yeah, that's an interesting question. I guess I don't really see them as separate. I feel like, um, my goal in my open source projects is first and foremost to solve the pain that I'm feeling. And then, uh, secondly to, um, uh, like if I can take that solution and make it generally applicable, I can save like hundreds of hours of developer time or thousands or tens of thousands. Um, and, uh, and that's, that's pretty cool. That's a really awesome feeling. Um, and so, uh, if I'm going to do that though, um, I, I have enough open, open source projects now to realize that, um, I can't spread myself too thin on these

or I'm, I'm not going to be having any more fun. Like it's, it's just not fun anymore. Um, and so, um, like I, I see building a community around projects as an essential part of maintaining projects. And so the only way to do that effectively is to have a good code of conduct that's enforced. I've luckily never actually had to enforce my code of conduct, but I have one and it's very clear that there is one. I have really good contributing guidelines. Sometimes I'll even have a video that demonstrates how the code is set up. Often my projects are fairly small. And so they should be pretty straightforward. But I also like I do a lot of things to to encourage people to contribute themselves. Like if somebody files an

issue, it used to be that I would be like, sweet, time me. I'll show you like how fast I can fix this problem. And I remember fixing it. Like I said, I'll have this released in five minutes and it was nine minutes and they were like, Oh my gosh, it's amazing. And I used to feel so cool about that. But now, uh, that's just a recipe for disaster. What you want to do instead is, is invite the person who filed the issue to make a pull request to do it. And more often than not, well, maybe not more often than not, but pretty often I'll have people say, oh, I just remembered this is open source. Yeah, I'll do that. And even if it means guiding them and like it, sure, it takes you more time to guide somebody to figure out how to do something.

What you have at the end of it is another person who's familiar with the code, who's interested and invested. And there are a lot of things that you can do to increase people's investment in your open source projects. And the more invested you have other people in your project, the more likely you will be able to live your life of leisure and let other people manage your project. And, and the, like in, in steps in automation and that kind of thing as well, which is also really, has been a really valuable thing for me. Like I have a generator that will automatically generate

all the, all the files I need for my projects that are like really common for most of my projects. And so like that automatically creates the code of conduct and creates the contributing guidelines that are like really nicely spelled out and especially helpful for beginners. Um, and like it, um, and then I have this automated release for all of my libraries so I can actually merge a pull request and it gets released, uh, released when I'm on my phone. Like it's, it's, that's pretty awesome. Um, and so, yeah, like being a good maintainer of a project, um, in my mind is not separate from being a really cordial and friendly person, um, because your effort to build a community, um, will improve, um, uh, improve the maintenance of your project in the long run anyway. Yeah, we've had the fortunate situation with changelog.com,

which has been open source since, I don't know, Adam, October? October, yeah. Yeah, October. Which is interesting because it's open source, but it's not like a little library or even a tool, right? It's our website. And it's a product that has a product direction. And so it's a different kind of open source project

than many, of course, they take many shapes and forms, but we weren't expecting too much contribution because it's our website, right? And we know people use the website. And so we thought we'd have some interest and it was, you know, it's written in Elixir, which some people are interested in seeing like an Elixir application or a based application in that's in production, like what it all looks like to glue that together.

And so we open source it mostly because, first of all, we live open source and it'd be weird if our stuff wasn't open source. But secondly, was more as people could, you know, look at it, file issues against it as a headquarter, so to speak. But we weren't expecting too many people actually just contributing. Yeah, to contribute. And we've been happily surprised by many people hopping. I think we're up to like 20

plus contributors at this point. Fixing bugs, adding little features, really cool stuff. And so I've been trying to think of ways. Some big features too. Yeah, one that was really cool and maybe Adam you can grab the fella's name so he can say thank you on the air while I describe what he added is

he added kind of a persistent play pause button so anywhere you are on the site so we have a persistent player in the footer or in the bottom part sticky footer where any page you're on if you're playing an episode it follows along and continues to play

well he was getting annoyed that when he would go to a different page where that same episode would be in a list view or something it wouldn't be synchronized with the player and so he had a feature where no matter where you are it shows if it's played or paused the current episode stuff that we wouldn't even think of

I didn't find that person's name i was i was grabbing the one for the fix for one five seven and one five eight i thought you were mentioning uh mavimo is his name he's from italy marco is his first name oh yeah an italian last name which i can't pronounce but that's the one i thought you were wanting to shout out but even the the play pause was pretty cool too i want to shout them all out i want to shout them all out we'll do a shout out show one day for sure yeah because one of my points I was trying to make

is like when these people come along like how do you show that you're actually grateful besides merging it and saying thanks and so like one thing I thought of is well we'll go over to we'll find their twitter name go over to twitter and we'll thank them there with links back to the pull requests and stuff and try to get like, try to

amplify your appreciation. So that's felt. And so that's one idea. Yeah, that's great. That's actually, that's a really good idea. I know the Babbel folks do that as well. Um, this is something else that's really, um, I think is really good for helping build the community around your project. And it's something I have strong feelings about as well. So I actually have a couple of projects that are like a product, not like a tool or library or something. And getting contributors around those is really valuable. And I actually myself had a podcast until just last year, like November, called JavaScript Air. And the website for that was open source as well. And what I did was I added a page, javascriptair.com slash contributors, where it listed all of the people who made contributions and their links to their pull requests and that kind of thing. And that I think

really gets people excited about contributing. And then you tweet out like this person is a new contributor to the site and it's really exciting. And for open source projects, like often, especially for small projects, you won't have a website. It'll just be like your readme. And so actually it was the first time I did something like this was a project that actually was a website. It's called Repeat To Do, just this little app that I built for my wife. But when people, just random people started contributing things and I wanted to express my gratitude. And so I had a little table in the read me that listed who the contributor was, what their, like gave their avatar and what their contribution was, um, as a way to like, and this wasn't free, like this took some time, but it was

a way to say like, Hey, I really do appreciate the contribution that you gave. Um, and here's some evidence of that. And everybody in the world can see like that you, you contributed to this project and I'm really grateful for that. Um, and I found that as I, um, have been doing that, I actually made a specification for that. It's called all contributors. And as I've been doing this on all of my projects, people are so much more excited about contributing to the project. They're so much more invested in the project because they can see their name and their face on like in a prominent place on that project. And that's, that's an exciting thing to me. And it's not hidden behind the like contributors on GitHub, but it's somewhere prominent where people can see that. And so like they'll contribute more when they see that their contributions are appreciated like that. Yeah, absolutely. That's awesome. I think, in fact, I'm over here, Adam, getting convicted

that we're not doing more for our contributors. We always can, you know, we never do enough, possibly. Right. Absolutely. And I think what you're kind of getting at is the recognition, but you're also creating a sense of community around it where it's not like one person and these drive-bys happen to help out, but it's still about Kent, right? It's sharing the love and creating community around it. I want to continue this conversation. We're going to end our first break. Specifically, you have this all contributors repo. I think there's more to be said about this, and you have a lot of insights, Kent.

So let's pause here, and we'll come back with more about how to recognize and attract contributors. We'll be right back. If you're looking for trusted freelance talent, ready to join your team right now, I mean like within the week, call upon my friends at Toptal, T-O-P-T-A-L.com. And as a listener of the show, you might actually be one of those developers or designers looking for awesome freelance independent contractor type opportunities where you can still be a remote worker.

You can still have the freedom you have right now, which means you can travel anywhere. You can be anywhere and do what you do. That's also an opportunity. We love Top Top. They've been supporting this show for a very long time. They're really good friends of ours. If you want a personal introduction, I'd be glad to give that to you. Email me, adam at changelog.com. Otherwise, head to toptile.com. That's T-O-P-T-A-L.com to learn

more. Tell them Adam from Changelog sent you. And now back to the show. All right. We are back with Kent C. Dodds talking about all things open source, especially around community contributions, first timers, these kinds of things. And by the way, in the break, we found the fellow's name who contributed that very cool feature, Christian Franco. Yes. Shout out to Christian. Thank you so much for hopping on. And I love the way he did it, too. He opened the issue and he kind of he was like he was sharing his idea, you know and he, you know, he wasn't just like saying, here's the pull request. Here's the, it's like this, the idea had took, you know, took about roughly this amount of time. And, you know, do you think this is a good idea? And I like, I kind of like that approach too, because it gives us a chance to sort of product develop together rather than saying, you know, just send a PR, which is sort of like you hear that often. And it's sort of, sort of sounds condescendingly like, oh, you got that idea. Great. So the PR do the work, you know, just send a PR, which is sort of like you hear that often. And it sort of sounds kind of sending away like, oh, you got that idea. Great. Send a PR,

do the work, you know, just send a PR. It sounds sort of nasty even sometimes. Yeah, it totally does. Like, so especially for people who aren't like, or who are just getting started, especially for something like your, your project where like lots of people could be just getting into software development that maybe they've never done open source before, but they're trying to learn about it. And so like hearing just open a PR can be really kind of scary to people because like, I don't even know what a PR is. What the heck is PR? Like, what is this? Um, and so I actually have a website called make a poll request.com and it, um, directs people to a free course that I have on egghead about how to make a poll request. So like, instead of you can feel free to make a PR,

you'd say, feel free to make a poll request.com and then they can go learn about what that is. And if they already know what a pull request is, it's fine. They just keep moving on. But yeah, like it's just so much more friendly when, when you give people a resource and it's not that hard to do especially like with GitHub, like the saved replies thing and whatnot. So yeah, totally. Let's, let's give people the resources and enable them to to solve their own problems. I think that's really important. So let me ask you this.

And this is maybe slightly off topic to some degree. You know, we asked you before, what's your motivation behind this? And then here's this free course. It's 38 minutes long, but it probably took two weeks. I don't know, maybe a week. I have no idea how long but whatever it is it's enough time where you've got your day job you've got your family you know how the how do you benefit from the time you invest in this and what makes you do it oh that's that's a good question um so yeah it definitely took more than two weeks uh these these courses take quite a while um but so one of the really awesome so it a while. And it's free.

It's not like, hey, we'll pay royalty for this free course. I don't know what your... Actually, that is what it is. Okay. I have to give such a shout out to Egghead.io because they have like half

of their stuff, maybe more of half of their stuff is totally free. And they still pay royalties for that free stuff. They see, especially like the open source stuff, they see it as like a public service that they're paying for, for everybody. And so like, yeah, that's like super, super awesome. And like, I gotta be honest,

like I've got a bunch of courses on Egghead and my like how to contribute to open source is not like the my top ranking course or anything like that. But like just the fact that Egghead is willing to make that absolutely free is just super cool of them. I have like the flip side course as well, how to write an open source project. I don't really talk about maintaining or anything, but like the tooling around things and stuff like that. And that's totally free as well. And so like props to Egghead for being so awesome and hosting this and funding my time so that I can devote some time to making these really great resources. That's, I didn't expect that

answer uh but that's that's cool i like that very cool definitely a shout out to i get on that let's come back to back to the balance piece back to well not so much back to balance back to creating community back to um your all contributors uh idea and given that back to the, those who get involved, we talked about creating community and I feel like that's something we've, you know, we've done for a while, but we're kind of doing better.

Most recently is like, if you're going to try and do something successfully, you know, you've got to have a community and there's many ways to in quotes, create a community. You can't just throw it in the microwave and put it on high for five minutes. You know, you've got to do something specific. So what are the easiest ways to what are some of the ways I think you suggest to begin to create and nurture a community?

Oh, well, yeah, there are lots of different things. But like one of the top things I would say is make sure that you have a code of conduct for your project. For some reason, this is controversial. I don't know why, because it seems so obvious to me. that people can feel welcome, whether or not they fit the mold of the developer that the world has created, I think is really a valuable piece of stuff of like building your community. So code of conduct.

And like there are a couple other things that I think are really useful too, like having some sort of roadmap for your project. Sometimes people just want to contribute to open source, whether or not they are experiencing specific pain with a library or something, they want to just help out in some way. And so whether your roadmap is in the form of issues or some like a markdown file on your project, having something where somebody can go to and see what are some things you want to do in the future. Or maybe like even like really useful are things that you definitely don't want to do in the project and some reasons for why not.

That can be really, yeah, pretty useful as well. Also, it's like having a really easy setup for your project. Like if you have to install a bunch of different global things for your project, uh, that can really be a barrier of entry for people coming into your project, um, and trying to contribute. And often you'll have somebody, um, try to set things up and they fail and it makes them feel like they're stupid or something. And so they don't even bring it up to you. And so you don't even know that you're, you're missing out on contributors because, um, they, they feel dumb and they don't want to admit that or, or

whatever. And they just move on to something else. Yeah. I'm that person. I will not, I will, like, I want to help, but I don't want to be the idiot. How do I not know this? I'm, I'm the imposter here. Totally. Yeah. And so like making it as simple as, okay, get clone this thing. And where,

where you have like, get is, um, um, a link to what get is like, make it so simple, you know, that the really advanced person can skip over that link.

Um, but the, the person who's new to programming or new to your project or new to get, um, that link will be invaluable to them. Um, but the, the person who's new to programming or new to your project or new to get, um, that link will be invaluable to them. Um, you know, sure there's Google. Um, but like if your goal is to build a really good community around your project, you want it to be as friendly as possible, lower as many barriers as you can. Um, and so, yeah, like get cloned this project, change your directory into that project that you cloned, and then run this one script that will set up everything. And that script works on every platform, Windows or Mac or Linux, whatever.

And if you can make your setup that simple, then you're going to have a much easier time getting contributors to your project. And then like automating code quality. you're going to have a much easier time getting contributors to your project. And then like automating code quality. So if you're doing JavaScript stuff, ESLint or like whatever project that you have, like try to do something to make it really easy so that when people are like contributing their patches or whatever, you don't nitpick on them on code style or, um, on like really obvious, uh, bugs, um, or whatever, like just try to, um, make the pit of success bigger, um, so that you can focus on the right thing. Yeah. Yeah. That's, that's like one of the major goals in getting contributors is um making that pit of success bigger um and so like and especially having your setup instructions be like like often

i'll see people say just clone the repo and then make your changes and then run the test and the real problem with that is if i clone the repo where the tests are already failing and that's like totally that happens all the time. And then I go and make my changes and then I run the test just to make sure I didn't break anything. I suddenly have a bunch of tests that are broken and I think that it was my problem. And so I'll spend two hours on it trying to figure out how my changes broke the test only to find out that the tests were broken to begin with. Um, and so having really clear setup instructions that I can validates that everything is clean and good before people even start making their changes is more valuable than we think. That's all great advice. Once they get to the success, now, once you fall into the pit of success, when I'm not picturing that, and it's pretty cool. Cause I'm so used to the despair. I'm now picturing that and it's pretty cool. It's a party in there. Because I'm so used to the despair.

I'm wondering what a bit of success looks like. But getting back to your all contributors idea, once they have that contribution and they've made that value, they create that value for the project and for the community, that reward, that recognition, it's very important to to expand that beyond just the

person who gets their pull request merged and so that's kind of your idea between all between behind all contributors which is a specification for uh recognizing everybody not just people who submit code and i think that's probably one where it flies under our radar pretty, you know, the most, like we don't think about it cause it's all about getting that merge or, you know, becoming a contributor on the graph. Um, but the fact is in any successful open source project and community, there are many people who are not contributing code or contributing less code and have all these other responsibilities. Um, I'm thinking specifically like Webpack has become a bit of a model open source project recently because of its success, you know,

financially and really because its value is bringing to the front end community. And I bet if we ran the numbers, Sean Larkin would have, you know, maybe the fewest commits compared to a few of the other people who are on the core team. And so you'd think that his contributions aren't as important because he has less commits. But the fact is he's been paramount in a lot of their recent success and helping to bring new people on. And of course, that project is so large.

They have documentation repos, and I'm sure he has lots of commits there. So all I say all that to say, like, what's, what's a way that we can get past that blind spot of if you're not contributing code, you know, you're not getting recognized. Yeah, like, it's, it's such a big problem that we have in our mind that open source is all about the code, but it is so much more about the people. Um, and like, like just imagine, um, web pack if, if Sean Larkin hadn't, um, started, um, like working on, on getting the word out or helping people, or like I have courses on, um, egghead and front end masters about web pack. If, if nobody had done any community work or like instruction work or anything like that, if it had just been toias working on the code, that project would not be nearly as useful or successful as it is. contributed code is I think you're almost, you should feel obligated to do this because they're making a just as big an impact on your project as the code itself. And so like documentation or

tutorial, like blog posts, or even examples, example repos or something like that, answering questions on Stack Overflow, or Gitter or Slack or whatever, or in the issues. Doing stuff like that frees the maintainers time up so they can continue working on the code of the project. It all accumulates together to make the product and GitHub is really good at recognizing people contribute code. That's pretty easy with the product and, um, and GitHub is really good at recognizing people contribute code. Like that's pretty easy with the, with the get graph. Um, but it's really, really hard to automate the

recognition of, um, people who are contributing in sometimes even greater ways, um, uh, throughout the community. So that's what all contributors is, is about. There's a CLI to help make it a little bit easier because, um, especially for something like Webpack, this would be a huge maintenance burden. But like most of the time for my projects, I will ask people to add themselves to the list and there's just a script they run. It's really straightforward for people. I've never really had people have trouble with that. And it's added minimal overhead for the maintenance of my projects and a great amount of gain. And it makes it so much less about myself as the project creator and so much more about other people who have contributed to the project. And that makes me feel, um, you know, like, yeah, I don't know. It makes me feel better about, um, having the project under my, um, my username

or like, it just makes it feel so much more right, I guess. Um, because we're recognizing people who are contributing in any form. Can we dive a little further into all contributors then? So you mentioned it's got a CLI and you've got, it's a specification. So it's one, it's like, here's how you can do it. But then there's also the CLI part, which is on NPM, which you can use to automate some of this stuff. And you mentioned that you're pretty excited about automation. I'm not sure what word you used earlier in the first part of the show, but all I know

is you like it a lot. So that's why you created this. What are the sources? How does it automate some of this, you know, in quotes, burden on whomever's doing this to give that thanks? How do you make it a little faster, a little easier, a little bit more, a little less painful to add contributors and recognize the areas in which, based on the specification, how they contributed and the value they bring to the community? Yeah, good question. So just to give a little bit of context, the all-contributor specification says that you should have a table

in a prominent place for your project. Most of the time, this will be the readme, just toward the bottom, that lists all of the people who have contributed. It has their avatar, their name, and then the types of contributions that they've made. And we do that with emoji. And so like you have a computer for code and a wrench for tools, and there's infrastructure and documentation and stuff like that. And so like creating that table and markdown is pretty tedious.

And yeah, it's really hard to maintain something like that. And so instead, there's this.allcontributorsrc file that has all the metadata about the project. And then the CLI will give you a prompt that says, okay, what's your GitHub username? What are the contributions that you've made? And then it'll add you to the contributors to that RC file. And then it'll generate the table based off of that. And there's also a badge that you can have as well. And it'll generate the badge

that says like the number of contributors. And so like when somebody is contributing to one of my projects, I have very detailed like step by step. Here's how you set up the project. Here's how you contribute. And before you push up your changes, add yourself to the to the table by following or by running the script. And then as far as like, yeah, like that, that process, it's, it's really, really simple for people to do. And sometimes people will forget and I'll just ask them to, uh, if they want to do it, then they can, um, uh, they just run that script. They update their pull requests. And I've had a handful of people who are like, Oh goodness

gracious, I fixed a typo. I'm not, I'm not going to put myself on there. And that's totally fine with me. I don't like, I'm not gonna to put myself on there. And that's totally fine with me. I'm not going to... The thing is, all contributors shouldn't be a burden, like an additional burden on the maintainer, or at least it should be as little as possible. It should be more helpful in building the community around the project. And so if somebody doesn't want to put themselves on there, that's fine. But I do have a dream of one day having a GitHub bot that will like you'll be able to add a label to an issue or like add a comment or something like that.

It's like add this person as a contributor. And so you don't even have to clone the repo or run the CLI or anything. And like I see that as something that would be fairly straightforward to do. Uh, it's just a matter of taking the time to do that. Um, so if anybody listening wants to do that, that'd be awesome. So essentially using the GitHub issues as a, as an interface essentially to, yeah, to do that. Like you, you could say, make a new issue that says, add this person to the contributors table. Um, and then the bot would do that and close the issue um and it like happened just like that i mean i want that that's that's super cool i finally scrolled down so we'll link this up in the show note to this repo all contributors of kent's but i finally

scrolled down to the bottom and saw the table and it's super cool it's got everybody's avatars and their names and then like you said little emoji for their contributions, like the book, if you've done docs and what's the eyes, the eyes are if you've reviewed pull requests. Now, Kent, yours has more emojis than everybody else's. And there's one that I'm confused about because it's the woman holding her hand up and she's not in the key. So does that mean you're actually, um, so I need to update this, but that little woman holding her hand up used to be answering questions. But I've gotten some feedback that that wasn't like that. That was gender specific. And so I changed that. So and and I'm happy to do that. You'll you'll notice the emoji. It's it's like um totally gender um neutral um and um like i i've gotten as you can see here i've gotten quite a few contributions from people um asking for those kinds of things and and happy to do that well i we got to set this up on our repo adam and i think i would love to see this on more repos get up read me it's because it kind of a, because the avatars were there and they're nice and big.

I don't know. It brings a humanity right to the, to the project's homepage that is usually missing. One thing I love, I've always loved about GitHub is the code always comes first. And that to me was a revelation because I didn't back on the source forge days. I didn't know you could even look like I thought open source was just kind

of free. And like when you download the thing, you can look inside there. I didn't know back could even look. Like I thought open source was just kind of free. And like when you download the thing, you can look inside there. I didn't know back then that they had it. And so I loved how when GitHub came out, you land on it and you see source files, right? And that's great. And I love that.

But it's still about bits and bytes, right? It's still about code. But this brings a human angle right on the front page of the project if the home page happens to be a github readme so it almost is i don't know you relate to it a little bit just by seeing that table so well at the same time too it seemed like uh github at something seems like they made code the most prominent thing they made the readme the first class second class citizen right it was still second but it was the first class of anything like they kind of popularized how

important a readme dot markdown file or whatever format you're doing it in i think text or markdown was the the default ways but those two things kind of like made it here's the code and here's whatever else you want to put in it and most often that was like hopefully instructions and now with something like all contributors you've got not just the contributors tab in github which is code graph only it's everything else yeah and and that human aspect too is is really valuable because um often we'll we'll look at code and it's just code and we kind of easily forget that this code was created by somebody who had a problem and they tried their best at making a solution.

And so when you go to the issues, you'll be like, I can't believe this doesn't support this thing. Like pretty much only people who are not very nice do that. But that's easy to do. And when you have people's avatars, these are the people who put forth some of their own time to make this available to you. It makes you appreciate the project

and those people's efforts quite a bit more. Yeah. We're coming up on time for our second break. We've talked quite a bit about, you know, sharing the love back to those contributing and creating a community around it. And let's take this break when we come back when I start talking about managing an open source project. Now, you mentioned that you did a video, I believe, on Egghead on creating a project on GitHub, I believe. But let's talk about the managing side. So let's break when we come back we'll talk about that our friends at thoughtworks have an awesome open source continuous delivery server called go cd head to go cd.io slash change law to learn more

go cd lets you model complex workflows promote trusted artifacts see how your workflow really works deploy any version anytime run and grok your tests. Compare builds. Take advantage of plugins and more. Once again, head to gocd.io slash changelog to learn more. And now back to the show. All right, we're back with Kent T. Dodds, and we're talking about some fun stuff. And the next thing on the list, Kent you give lots of talks right and you've got this

talk uh you've given it all things open uh which is actually where we met face to face had breakfast which was super awesome but you talk about you know scratching your own itch open source getting into it managing your own open source project uh you know great you finally ship your your first thing you're excited about it and then now the burden of open source sort of hits you. You've got PRs, you've got bugs, you've got things that start to happen and start to come out of being a manager of an open source project. And I don't know if you caught this, but recently we had James Long on the show. That title of the show was actually called The Burden of Open Source.

And it was based on this blog post he did recently, which is why I'm frequently absent from open source. Sort of got into this this thing where he was scratching his own itch, released his thing, and it became super popular. He's got family. He's got other expectations outside of his, you know, code life that he just wasn't ready for this burden of being a maintainer. And so this is sort of like this. I'm not sure if that's the only thing you're abstract this painting, but it's certainly part of it. So help us navigate what you're talking about here around managing an open source project and maybe even the burden of doing so.

Yeah, absolutely. That was a great episode, by the way. And it also makes me think of Nolan Lawson's blog post that he gave a couple weeks ago about what it's like to be an open source maker. Yeah, it was in the same timeframe. We should have had a roundtable panelist show around that, honestly, but that was a good call with James. Well, I think we could get hundreds of people on the show to talk about that topic, right? Because we've all felt it in one way or the other. Yeah, Like sometimes you'll, you'll just throw something out there and you don't

think it's going to be a big deal. And then all of a sudden, um, tons and tons of people are using it. And, and, uh, yeah. So if you haven't read that, that blog post from Nolan that like, I recommend people look at that. Um, but, uh, like it, it helps you empathize a little bit better, um, with, with maintainers. Um, butize a little bit better, um, with, with maintainers. Um, but yeah, so there's definitely a pain with, with managing open source projects. And like, I, I've had a couple of projects that have been pretty popular and taken a lot of my time. Um, and it can be, um, yeah, really draining emotionally and, um, mentally and physically,

um, on you. Um, and especially like I'm a family man. And so trying to balance work and life and open source and like the fun part of open source, the reason that we do it, that can be challenging. And so pretty much like the premise of managing an open source project, that talk, which unfortunately, the all things open recording, there was a problem with it. So I'm still looking for a conference to give that out to get a real recording. But yeah, that talk is basically if you set up your project in a good way, then you can distribute the effort amongst the community that you've built around the project. And so I give a lot of like several must haves and a couple of like, this is really useful for this reason kind of thing.

I talk about like how to structure your documentation so that you get users. And actually, I kind of base things off of this contributor pipeline thing that I got from Michael Rogers, healthy open source blog posts, where basically you have this big circle of users and a smaller circle of contributors. And then a smaller circle of commuters and then an even smaller circle of the technical committee or like the people in charge of making decisions when there's some sort of dissent or something. But like your goal is to make each circle bigger so that you can spread the requirements of that open source project across the community. And so the more users that you have, the more contributors you're going to get. Well, potentially, and that's kind of the goal is to set up your project up for success in that conversion process, because there are some projects that are just really, really heavily used. But because they don't have a great setup for community around that project, they aren't doing very well at converting users into contributors and then into committers. And so stuff like having really good documentation, having places for the community to work together,

like chat or using Stack Overflow effectively and having really good workflow for issues and pull requests and that kind of thing. And actually one tip that I don't see enough, but I think would be really great for people to do more

is if you have a domain for your library or your project, making like short URLs or maybe subdomains or something that redirect, um, can be really, really helpful for the community. So for example, uh, with Angular formally, um, I started getting a lot of, of requests for help, um, support kind of things. And so I created a subdomain called help.angularformly.com and that redirected to a JS bin that was all set up with

Angular Formly and everything that you needed. And it had instructions on how to get help. So like fork this JS bin and then make your changes to demonstrate what you're trying to accomplish and then post that to Stack Overflow. And then we have people who subscribe to the Stack Overflow RSS feed for the Angular Formly tag and they can answer your question. And then we have people who subscribe to the Stack Overflow RSS feed for the Angular formula tag and they can answer your question. And then what's really cool out of that is, like most of the time, people will solve their problem while they're creating that JS bin.

They'll realize, oh, it's actually something in my app that's messed up or something like that. And so like that saved tons of time. But the general idea of having some short URLs that are easy to remember, because once you start using them in like the chat or whatever, then people will remember those really easily and start sharing those with people themselves. and the process of helping with the community, make that process as easy as possible so that other people start taking those responsibilities. And then you can get some of your life back. Also having a really, really good getting started guide or some sort of guideline.

If you get the same kind of questions from people, you add that to some sort of FAQ or something. Um, yeah, there's like lots of little things that you can do, um, like automation and that kind of thing to make your life as a maintainer much easier, um, and kind of pass the buck on to the general community. Um, and then like at the end of the day, um, if you're not happy with, uh, the way that things are going in your open source project and maintaining it, then, uh, hand it off, um, give it to somebody else, um, to, to maintain.

And if nobody else wants to do it, then that's like, this is the way that code works. Um, if, if somebody's not, uh, like if somebody doesn't need to use the project, then they won't use it. If they do, and it's not serving their purposes, then they're going to have to contribute in some way or fork it or whatever. And what do you care if they do? If it's not bringing you happiness, then stop doing it and move on to something that does. So anyway, lots of words that I just said. Knowing when to quit is a tough thing.

It's easier. I actually heard this recently, um, from the fellow who runs, uh, Jupiter broadcasting. He said, quitting something is harder than starting something. And that could not be more true than anything I've ever heard before. Uh, it's just, it's so hard to quit something, but knowing when to quit is, is almost just as hard to recognize. It's like, that's just tough stuff, but, uh, well, and, and like you, you want to, you want the project that you've poured so much time in, um, to be useful to people. And so this is part of the thing that compels us to, um, to forego things we'd rather do, um, so that we can make this more useful to people.

Um, but this is why building a community around the project is so useful and giving commit access really freely and early to people, just like give it out liberally. Anybody who makes a non-trivial change to your code base, give them commit access. There are ways to secure things a little bit with GitHub and goodness gracious, we have Git.

Yeah, you can roll it back if you need to. This isn't subversion, you know, it's something really hard. Um, so, so what you're saying is, is, uh, loosen up on the keys and better balance the responsibilities of running things. Yeah, absolutely. I I've had some projects that I've completely handed over, um, to like several projects I've completely handed over to somebody else and they made it so much better than I ever

would have had the time to do. And it's because I gave commit access freely and early. And when somebody gets those keys, unless they're like a super jerk, which I haven't yet experienced, but like I could see that happening. But like once somebody gets those keys, they suddenly feel really strong responsibility. And especially if this is somebody who, um, hasn't done a lot of open source before, or maybe this is the only project they've really contributed to, they take so much responsibility and they're so excited, um, to, uh, to have a project to say that

like they're a major contributor on. Um, and so, yeah, just give those, uh, that commit access to people. And I realized that sometimes you want, like you want to make sure that the project continues to solve the original use case that you set out to do and you have a direction for it. Um, but like it, it's really a decision between you having, um, the micromanager control over the project and you having your life as a human being, an individual. And you just have to kind of weigh things. And I would say most of the time, the community can make a better project than you can by yourself. And so just feel free to give that commit access to people and let them run with it. I've got a small story that isn't exactly truly relevant here, but I want to share a very small version of the story.

Let's hear it. Let's hear it. The relevance is what you just said there, which is responsibility can really level up somebody pretty quickly. And what I mean by that is when I was in the military, I was what they would call a slow speed soldier at the first. I was, went through bootcamp. I wasn't trying to excel.

I was doing whatever I had to do just to get through it. Cause I just was like, whatever, you know, I was 18. I didn't have much of a head on my shoulders yet. My dad died, you know, early in my young life. So I didn't have that father figure. So I was just like, whatever, I'm just doing this. But when I got into what they call AIT training, which is your advanced individual training, the drill sergeant called me out and put me as the first squad leader, which is like a

really responsible role. I became a high speed soldier that day because I was like, holy crap, somebody see something in me. They gave me responsibility. Next thing you know, I'm spit shining my boots. I'm pressing my uniform. I'm running faster. All these different things that make me a better soldier happened because that person gave me I didn't earn it.

He gave me the responsibility and it was up to me to lose it. You know, and so I think doing that in our community can have the same effect. Hmm. Yeah. I'd like to stay off topic and say, can, can you share a picture of you in a uniform? Cause I think I know I would love to see it. And I'm sure the listening audience wouldn't mind.

Yeah. Heather's got tons. She shares them on personal social media all the time, but I'll, I'll, I'll find one up and I'll throw it in the show notes this time. Cause I was, I was a cool high speed soldier i wasn't at first i was slow speed not cool at first and then i was like you know what i've got this responsibility and i got much so much better as a soldier i started loving the military i was in my very young career at that point i mean i was

barely even in i hadn't even officially gotten to my job yet but yeah when i did get to my job since we're on this tangent and i'll share a bit more when i got to fort drum new york and i stood before my platoon sergeant i never cussed on the show he said hot damn soldier you are spit shined and polished and he could not believe it he could not believe it he's like i've never seen anybody come in from basic training looking like you do. So what'd you do? Get down and give me 20. And so I just, I had to beat my face. I had to start doing pushups right in front of him.

And I'm spit shined and polished. And everybody was like, I was turning heads as a young, I didn't even have any brass on my collar, which means you have, I had no rank. I was like the lowest private you could be. I was like E1, nothing. And I was getting respect because, you know, I came in as someone who wanted to level up and it all started because somebody gave me responsibility and I didn't, I didn't even

deserve it. I was like the idiot at first. And that's all right. That just took, just urgent gave it to me and, and, uh, I didn't even deserve it I was like the idiot at first and that's all right that just took just urgent gave it to me and and uh I took it wow that was definitely the most personal anecdote I think you ever shared on the show Adam this is a whole new it's a whole new can't you brought out a whole new side of Adam excellent off the tangent now back into give people responsibility yeah hold the keys loosely and the quote going into the show jared for this one is give commit access freely and early so

trust your community give them responsibility they will lead the way they will they will step it up but uh kent you had a couple things you wanted to mention we're getting short on time because of my tangent but we'll extend five minutes so you've got something coming up at paypal that you're announcing uh you got a blog post keyed up what is this about yeah yeah so um like part part of um being able to do open source um or like my privilege i guess is being able to be to do open source at paypal and um one of the projects that i've been working on recently is this thing called Glamorous. And it's taking some very strong hints from styled components, which is the solution for creating React components that come pre-styled, that carry their styles with them. And this idea of components and CSS and JS

and all that. And so styles components is awesome. I love the API, but I decided that I didn't love a couple of things about it. And so I created a kind of something that's similar that solves my use case a little bit better. And so I'm going to go ahead and publish this blog post. And I think everybody is going to hear this in a couple of days. And so like this will be published already, but it's called Glamorous. Go look it up. Yeah. It'll be in the show notes for sure. Are you hitting the publish button like right now as we're talking?

I just hit it. Yeah, that's it. Oh boy. It's done. Yay. Now you have to maintain this open source project. Oh, man. Congratulations.

Yeah. I'll build a community around it. There you go. Just follow your own advice, and I'm sure it'll be fine. Yeah. Very cool. Glamorous. Good name.

Yeah, yeah. It's kind of fun. You'll know the logo. It looks really of fun. You'll know the logo. It looks really similar to the Styled Components logo. Shamelessly inspired and permission granted. Nice. That's good. But yeah, it's like, and the API is really similar, so it makes sense.

But yeah, it's curly braces surrounding some lipstick emoji. So when you see it, you'll know it. But yeah, so then the other thing I wanted to make sure I shared before we wrap up is this thing I have on GitHub called Stack Overflow Copy Paste. And this is the project that I used when I was demonstrating how to contribute to an open source project on GitHub in that course I have on Egghead. But at the end of that course, I invite people to make pull requests to this project as a way to learn the workflow and to follow along with the course. And so if anybody listening hasn't actually jumped into open source before, they just don't feel comfortable with the process or anything, this is a very, very low risk way to get into it because I will be very friendly

and you have pretty much no fear of getting rejected because the whole point of the project is it's a bunch of different JavaScript modules that are basically answers from Stack Overflow questions. So like we've got like a flatten implementation that comes from Stack Overflow, a remove duplicates from array implementation, a sum implementation, like adding numbers together.

So it's like totally bogus stuff. It doesn't actually, like hopefully nobody actually uses this module. But yeah, the whole idea is for people to get into open source, figure out what the process of filing an issue and discussing a solution and then forking and cloning

and creating your pull requests, all of that, that whole process, you can learn from this repo. And this is something that I do because I think that open source is great and I want people to learn how to do it. Um, I'm happy to help. So stack over full copy paste, check that out. What a teacher, man. You never stopped teaching. You never stopped trying to help in however you can to, to get people over that, that next hurdle. I feel like that's everybody,

Jerry, like everybody, you've got a hurdle in front of you. Can't, you've got a hurdle in front of you and somebody out there who knows who's going to be, is going to help you get over that next hurdle. And that's what you do, Kent. That's crazy. I love it. I'm very self-motivated because you find out how much you learn when you teach. And so I've learned a ton from my experience teaching. So it could be a little bit selfish, but thank you. Well, Kent, anything else you want to share? Anything else that's, you know, last minute advice, words of inspiration, next steps, call to action, anything else to share before we

go? Um, no, I, I think it's mostly just like, um, look for opportunities to serve others and give of yourself. Um, it'll make you a happier person and then remember to focus on, on your own, um, mental health and, um, make sure to sure to give some time to yourself as well. Yes. Wise words, my friend. Thank you, Kent, so much for sharing your time today and for being so passionate about what you do and for being a little selfish, too. That's always a good thing. Thanks, Kent. Thank you. All right. That wraps up this episode of The Change Log. Join the community and Slack with us.

Head to changelog.com slash community. Follow us on Twitter. We're at changelog. Special thanks to our sponsors, Century, Top Towel, and GoCD. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. Also, thanks to Breakmaster Cylinder for the awesome beats. If you're one of many people

emailing us tweeting us asking about our theme musics and whether or not you can listen to them or download them we have something

coming very soon it's a mixtape you'll be able to buy it which is super cool to support us and these awesome shows we produce so stay tuned for that

we'll see you again next week thanks for listening.