Find Your Next Open Source Contribution

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of Learn With Jason. Today on the show, we're bringing back Brian Douglas. How are you doing, man?

BRIAN: I'm doing fantastic. It's a new ‑‑ it's Tuesday, so we're starting a whole new month and everything.

JASON: Yeah, I can't believe it's already March. It's been just ‑‑ it's been too much 2022 for two months.

BRIAN: Yeah, stuff is happening, and it just won't stop, I guess.

JASON: Who is ready for naps? Give me a "Z" in the chat if you're ready for a nap. [ Laughter ] But, yeah, so for folx who aren't familiar with your work, do you want to give us just a little bit of a background on yourself?

BRIAN: Yeah, yeah. Yeah, so, bdougie is what I go by on Twitch, bdougieYO and bdougieYO on Twitter as well. Brian Douglas is my given name. If you need to Google me, I've done well in the SEO there. My day job is I do dev rel at GitHub. My actual title is Director. We are focused on encouraging folx to use features that people have never used before. People like the API and soon to be packages and co‑spaces. I have a talk on Co‑pilot coming up. Looking forward to that. Will be my first dive into that. So all things GitHub. Also, I'm a big fan of open source. So I've been working on this project, like, mostly off and on, but now really on in the last, like, six month called Open Sauce. It's a path to your next open source contribution. We've developed a couple ‑‑ I say we because we have open source contributors, like 60‑plus that have been helping me contribute and make this project work. But really just focused around encouraging open source contributions but connecting folx to repos that are doing a good job.

JASON: Nice nice. Yeah, and, I mean, I've loved watching the work you've been doing over there. The Open Sauce stuff is super fun. Between pizza emotes in the chat, you've definitely made an impression on the community, I think. It's always fun to kind of watch what you're cooking up. And so, I mean, open source is one of those things that I feel like once you're in it, it feels very different than before you're in it, and depending on what part of it you get into, it can also feel very different. So for somebody who's ‑‑ let's start with somebody who is brand‑new. What ‑‑ not what is open source. I think we can take for granted that open‑source software is software that anybody can use. It's got permissive licensing for that. But what is open source in terms of its impact on our industry and community?

BRIAN: Yeah. It's a very hard thing to explain open source in general, but open source at its root is the code you can view. It's open source code, but there is also some other mantra around licensing or engagement or sort of best practices and ethics. But at the end of the day, like, open source is, like, people freely giving access to their code and also community as well. And the thing that I've ‑‑ my intro to open source came from I wanted to build a project. I found Ruby on Rails as a way to do it. I found a lot of the libraries I could instill in the Ruby gems were open source and installable and available for me to build the stuff I was trying to build. Ended up building that with very little programming experience. Then I've always had that same approach of, like, if I want to build something, I just Google or ‑‑ well, pretty much Google. Yeah, eventually you'll find a stack overflow or some sort of form, an answer for the question you're asking. And the benefit is, like, a lot of the ‑‑ your guests here, I ended up organically finding the guests on Learn With Jason. And watching the video. And watching how things are built in the open. So, yeah, the whole mantra of open source, I'm pretty fluid in what it really needs to mean, because as a person who had a non‑traditional background who just wanted to solve a problem and continue to solve problems, I enjoy how open folx are of sharing the sort of secret sauce or the secrets into programming and libraries and packages.

JASON: Yeah. Yeah. And open source has had a ‑‑ I feel like everybody working in web dev probably has a how open source impacted my career story, right?

BRIAN: Yeah.

JASON: And I know for me, like, open source was a huge, pivotal part of how I got anywhere, honestly. I started out by, you know, I also have a non‑traditional background and I learned from people in, like, the W3 school's forum who were just willing to donate their time and send me some code snippets. And, you know, got the real kickstart to my career was when I discovered JQuery, an open‑source project. It unlocked the door which allowed me to build my agency. I did a lot of WordPress work in my agency. That's another open‑source project. It's kind of incredible if I look back through my progression in this industry how much of it fully relied on open source. And, you know, as I got further in my career, too, it shifted the other way where I started releasing open source. I started working on open source. And, you know, that opened all these, like you said, you end up meeting all these people in the community that we look up to and who are building these cool things. They're all in open source. And so you end up crossing paths. And you, you know, you kind of build a network this way. And that's a whole other thing, too, because, like, open source is, like, that's sort of your job. Like sort of. I mean, GitHub is a company that's heavily reliant on open source as a business thing. And so how has open source impacted, like, your career and even, like, the careers of people around you? It feels like this is a pretty ‑‑ a pretty big rocket booster in your circle.

BRIAN: Oh, for sure. Yeah, I would say that for my career, like, my first really, really foray into open source where I was contributing back into the system was I was trying to build a quick integration for ‑‑ with web sockets for inviting folx to my Slack room or my Slack channel. This was, like, 2014‑ish, 2015. Don't remember the year, but this was also as Node was, like, had the split ioJS and regular Node. The next‑level features. It was sort of a split in the community. Mind you, I only just started doing Ruby. So that was my first job, Ruby on Rails. I started doing Node.js because I found it was easier to do web socket‑type interactions. From googling, I found the GitHub repo that solved my problem. A wraparound specifically for Slack web hooks. Something I knew nothing about at the time. I was in a framework mindset. Everything was given to me. Never had to look outside the framework. My reach‑out to the maintainer of that project is I didn't know how to get it to run. I went to his profile. Saw his email on his GitHub profile and emailed him. Not realizing GitHub issues. I didn't know GitHub issues was a thing. The company I used for, we didn't use issues, we used JIRA. That was the other reason why that existed. So I reached out to him. He actually responded back to me and said, hey, actually do this, this, and this, and mind you, it was Saturday, like, midnight, and he kept responding back to me super late. I stayed up until 4:00 a.m., solving this problem, getting it to work. I was like thanks so much. By the way, I'm about to head over to a K Pop concert in Thailand. He sent me an image of him at the concert eventually. Wow, this is amazing. Open source, not only can you get code, but you can also get free mentorship.

JASON: Yeah.

BRIAN: So that experience kind of set my entire career off. Where I was never shy around ‑‑ for asking questions. I learned how to use GitHub Issues. I stopped emailing maintainers directly. Please don't do that. Don't DM folx. Do it out in the open. The one thing I learned is when you ask questions in the open, people are more, like, they're more amenable to answer you because they know they can always point to that answer in the future. If you're DMing somebody, a lot of times it's hard to get into open source or find out the secret sauce, which is Open Sauce. If you don't got sauce, then you loss, is the quote that I have on my website. Yeah, basically the impact that I got was, like, it has taught me that I can just reach out. Folx are accessible. As long as you're providing value. So the value is ask a public question. Not on Twitter but, like, in an issue or in a forum where people would actually answer and point back to it, like, that's valuable.

JASON: Yeah.

BRIAN: So I spent a lot of time teaching a lot of my new contributors in the project I just built how to interact with a project, how to ask questions, how to stop DMing. I don't mind taking DMs up front to make people feel comfortable, but eventually I've got to teach you how to walk. So we're gonna walk into a public channel together, ask your question there, I'll tell you exactly what question to ask, I'll answer it in public, and now everybody who is watching is like, oh, I didn't know that. Let me take that information and better myself.

JASON: Mm‑hmm. For sure. So you actually just kind of touched on something where, like, we're talking about the parts we love about open source. But there is the kind of negative connotations of open source where you've got people who are severely overworked. They're kind of just getting verbal abuse all over the place. They're getting pulled in all directions and kind of, you know, feature demands and that sort of thing. So how do you encourage people ‑‑ or, you know, you're talking about how do you ask a question? What are some things that you definitely don't want people to do in open source land or some etiquette that you feel is 101 for somebody who is going into open source?

BRIAN: Yeah, what's the ‑‑ if you want a friend, you got to be a friend. And some etiquette is usually around just being a good participant in the space. So, like, a lot of times people reach out to me and, like, I'll tweet out good first issues for my project. And folx will respond and be like, hey, is this good for beginners? And usually the answer is yes. If it's a good first issue, my thing is I want to have an answer in the issue, otherwise it's not a good first issue. How are you gonna expect someone to solve this after a couple weekends? So as far as folx approaching open source, like, being friendly but also searching to see if the question's been asked, a lot of times people discount ‑‑ I don't know if we're moving away from stack overflow life. I don't think we are. But people discount, like, checking stack overflow for questions that they're gonna ask. One of the best things you can do is actually ask the question on stack overflow, take that link and drop it in the Slack or the Discord because you have a captive audience. You have people who have answers who want to also answer those questions, but they don't want to answer them in a synchronous fashion where everybody's like, oh, you know what? Turns out I can't write test in Vite. How do I write test in Vite? The answer is Vtest is the answer. One thing that I'm learning right now because my project is written in Vite right now. That was a thing we had to talk about over and over again. Now we have the answer we can link to in the conversation, in thread, in the issue. So a lot of times if ‑‑ like in Open Sauce, we get to go back and forth on questions and concerns and the future of the projects or the features and what would be cool. Eventually, we got to take that to the repo. Even, like, my day job, my whole thing is, like, if you want to make a decision, send an email or open an issue, but if you just want to have, like, a conversation, definitely take it to Slack or Discord. Figure out what the variables are synchronously or async, but eventually, like, let's make this record, like, put it somewhere where it's searchable.

JASON: Sure.

BRIAN: Otherwise, we're gonna have the same conversation next weekend.

JASON: Yeah, I think some things I've noticed just as I've been doing more and more open source is, like, when somebody comes to me with a question, there are definitely questions that I'm more interested in answering than others. That's not necessarily due to the content of the question. A lot of times it's in the way the question is asked, right? So one of the things I'm always interested in is, like, building a good ‑‑ a good sense as open source citizens of just how to not be a jerk about the way you ask a question. And I'm very guilty of this. You know, when I was earlier on in my career, I would phrase things like, this should be simple. Why isn't this working? And, you know, as the person who wrote the code that's not working and apparently is not simple, my immediate gut reaction is, okay, write something else then. Like go build your own library if you don't like this one, right? As opposed to somebody who is like, hey, I'm really trying to figure this out. Here's what I tried before. I think I'm maybe holding this wrong but I can't get it to work. Can somebody please show me what to do? I'm immediately like, oh, no, no, no, let me show you what you did. Here's the code that will actually solve this problem. It's such a subtle thing, but the same question asked two different ways is gonna get a very different answer, and one of them is gonna get you on my crap list. [ Laughter ]

BRIAN: Yeah. Yeah, it's the ‑‑ so, I used to do sales before switching to full‑time engineering. So career transition, learned how to code. I shared a bit of that story. There was a book that everybody in sales reads which is "How to Win Friends and Influence People." I mention this with a caveat, it was written 100 years ago. Super racist, super misogynistic. Take the gems where you can. Hopefully we can find a new book to recommend.

JASON: Read it with a sifter.

BRIAN: Exactly. I raid the book and I read it quite a few times. The gems I took from it is how to, like, in engineering, you've got to convince other people your code's the best or convince them that your code needs to be merged, so you're constantly always trying to sell your code. So in the inverse where you find issues with the code that's been written or you find issues with the library, the inclination, really, at first is like, man, this thing sucks. I can't believe these developers did these. This is gonna ‑‑ let's go use this other newer, flashier JavaScript library. But my approach and the thing I try to redirect folx into is, like, don't dog the person who wrote the code. Like it's better ‑‑ leading a horse to water, that whole analogy. That's basically what came out of that book, which is essentially, like, take the problem and then make the person who you think you're trying to convince think it's their solution. Like you come up with the solution. But be of value. And, like, usually what I do ‑‑ I have a YouTube video on my YouTube account called "How to Get Your PR Reviewed." And the way I set up the structure of my PR messages. If you're not thinking about what you put in your PR or what you put in the issue, you're doing it wrong. You got to start with, like, talk ‑‑ basically SCQU is a my structure. Situation, complication, question, answer. Turns out you can't write test in Vite because you can't use jest, you have to bring in Babel, which defeats the purpose because Vite is so nice and lightweight. The complication is a bit of that, like, I tried doing this on this specific use case. Doesn't work. Here's the question is how can we write test in Vite? The answer which we eventually came to is Vite Test. Had no idea it existed. Somebody came through with the answer. What's the step of implementing it. In my PR, I'll walk through that in my PR message, and we can then look at my code that answers, like, all those answers and the complications, you can now see the story of the code.

JASON: Mm‑hmm.

BRIAN: It's the same thing with issue. If you don't have ‑‑ if you don't put an issue but you don't have the structure of why you're opening this issue. I had an issue open about Progressive Web App, making the project a Progressive Web App, and very, very brief and terse issue opens. Like, uh, could you give me a little more? Can you show me some value because I want to see someone's actually invested in the problem. Otherwise, I've got to close this thing because I don't have the bandwidth to convert this thing to a Progressive Web App after converting it from Astro to Vite. If you can show you're invested in this problem, if not, it's a won't fix. Sometimes as a maintainer, you have to be a bit terse and a bit sort of, like, basically lay the hammer down on some stuff that's low effort.

JASON: Right.

BRIAN: That can feel like the questions you don't feel like asking because it just wasn't set up properly. Like that's the stuff I'm trying to teach my core Open Sauce community, how to go interact with other projects. I had one contributor who opened up a discussion on Remix, like, eventually they decided not to move forward with his solution, but, like, able to set up the stage enough that they can get the issue read. And get, like, some sort of conversation going. That's success. Because, like, once you start opening up issues that look valuable to other folx, I can go into your GitHub account and actually look at all your open issues and check that out. So if I see that you've opened the same issue about adding a ‑‑ to three different projects, then I'm just gonna ‑‑ like the value of that Goss down. I'm gonna see you're essentially spamming projects with the same sort of pitch. I would prefer, like, if you just come to me as an earnest contributor. I'm happy to, like, work alongside you. Give basically the same value that I got when I first contributed to my first project. Of the person responding to my email. Like I'm totally down jumping on a Zoom, pairing, answering questions, but it really has to be sort of, like, again, if you want to be a friend ‑‑ sorry, if you want a friend, you got to be a friend type of deal.

JASON: Yeah, I think that really does sort of point at a lot of the issues that I've personally encountered where, you know, I ‑‑ if somebody is coming to me and their participation in a space is low effort, like, you know, I've never seen you before and you just came here and you asked me for something. The thing you asked me for, you don't have a good description for what you want. You're just telling me, like, I need this. I have no incentive or motivation to show up in that space. Like, you know ‑‑

BRIAN: Yeah.

JASON: How do I know that you have any investment whatsoever in this project? And, like, you know, I've been burned before where somebody comes in and they're like I have this problem. I go and fix the problem and go back and say, hey, here's the solution to your problem. I migrated off to this other tool because you were too slow. Cool. That's a great use of my time. Thank you for not telling me any of that. And, you know, it's very, like, you know, that's ‑‑ I think that's where the burnout for open source maintainers comes in, is the ‑‑ if we as the consumers of that open source aren't going in with that sense of empathy and saying, like, look, I'm trying ‑‑ you're doing something I like. I'm getting a lot of value out of it. And therefore, I want to ‑‑ I want to be part of the community that improves it. I maybe don't have the time or skill to fix the thing that needs to be fixed, but I want to give you enough of a roadmap that you understand that, "A", this isn't some, like, like you said, I'm not just spamming repos and, "B", like, I'm invested enough that I was willing to at least, like, run through the problem and create the reproduction of, like, hey, here's where the bug happens if you run this code. You'll see it. You know, like, anything that points me as a contribute tore the fact that you spent more than two minutes saying, like, it's broken. Fix it. [ Laughter ] Right?

BRIAN: Yeah.

JASON: Yeah, it makes such a big impact on my own sense of, like, engagement with a given set of issues, is how earnest and helpful people are being versus how demanding and you said terse. I think that's a good word.

BRIAN: Yeah. Did you ever do test‑driven development back in the day?

JASON: I have done test‑driven development. And if anybody ever asks, like, for an interview or something, yes, of course I do test‑driven development. But no, I don't do test‑driven development.

BRIAN: Okay. Yeah, the whole mantra around TDD is fail fast. So you write a test and you get the test to pass. And then you move on to the next test. And I think it's the same thing when approaching projects and even contributors too as well. So, like, I'm looking to get you to exit out of the project as fast as possible. So, like, I'll ask the question, hey, are you willing to put this, like, contribute to this? Do you want help? And I'll show you the ropes of, like, how to get this plugged into the project. If the answer is I don't have time, it's like, cool, awesome. You can now move on. I'll move on. We'll keep the issue open for a bit but, like, perhaps this issue's gonna get closed in a couple months because I just need to know how invested you are. The other thing that I usually do, because a lot of my projects are sort of React‑based and have some sort of UI component to it. My first question is, like, hey, have you signed up for this? Have you logged in with GitHub on the website? So, like, the Progressive Web App question, I actually have a video I'll be publishing just when I walk through the PR and, like, how to make a good contribution. Because I reached out to the person in DMs. I was like, hey, thanks so much. I would love for you to contribute, but also this is kind of, like, a ‑‑ it's a pie in the sky idea. Like we also ‑‑ we only had 48 people sign up for the thing. So we had 48 people, users on the platform. Low chance that any of those 48 folx are gonna need a Progressive Web App. If they did, they probably would have mentioned it. My question to the person who opened the PR, have you actually logged into this thing. Have you logged in on the web? Can you provide metrics or speed tests? We're using Astro. It's extremely fast. Yes, Progressive Web App would be great but also it's not a paved path for Astro. If I were to implement that, that would be more weekend cycles and lunchtime development than I would spend on something that my 48 users aren't using. So...

JASON: Yeah. You know, that's actually a really good point because something that ‑‑ just as, like, a point of career literacy as well, is, like, if you can't connect the problem you're solving to actually need, then you're kind of ‑‑ you're just playing, right?

BRIAN: Yeah.

JASON: It's fun to play. I build stuff for no purpose all the time, but I'm also not bad when nobody uses it because it wasn't built for that purpose. It was built to entertain me. And I think sometimes if you're not thinking through who does this benefit, why does this need to exist? You're building things to entertain yourself, but under the impression that it's gonna be very useful to lots of people and then, you know, it can ‑‑ it violates your expectations when you, you know, put it out there and somebody is like, who is this for? I don't know, but it's definitely useful. It kind of hurts your feelings when you realize you built something that was ultimately useless, right? And, like ‑‑

BRIAN: Yeah.

JASON: ‑‑ useless things serve a great purpose, but you want to be clear in your own planning, like, am I building this because it sounds fun or am I building this because it solves a problem? Hopefully, the answer is both, right? That's the best‑case scenario. But it's also perfectly okay to build something useless to learn and then just stick it on a GitHub repo somewhere. Hey, I built a useless thing. Use it if you want, but I don't know what it's for. I have a bunch of those if you go through my GitHub. [ Laughter ]

BRIAN: Yeah, I have a ‑‑ I currently own socialcarding.com. And it's not useless yet. I built it because the site I built, we embedded social cards as the cards on the side. You know what would be really cool? Instead of going to Twitter card preview or whatever it is to see if the social card works, I'll build my own. So I have that now. I've used it a few times, but it actually got really helpful when I needed to save the social card image for something else because I can download images from it. It's a quick and dirty Next app. One of the things I wanted to bring up too as well around this approach of approaching open source and even, like, providing value is the title of the stream was, like, finding good first issues. Or something in the description I gave you. The one thing, the secret sauce is actually opening issues. If you're looking for good first issues, the best good first issues is you using the tool or the library. Finding a limitation when you're getting started. It could be onboarding. It could be installing. It could be setting it up into whatever X, Y, Z project it is. Just go use it and open up the issue if there is an issue. What usually happens is, like, hey, here are some screenshots of how I got stuck. Maybe there is something I'm missing. But here's the issue. And usually what happens, every experience I've done this with, the maintainer comes through or some contributor's like, oh, yeah, actually, this is the fix. Here's the line of code. Here's what I would write. If you want to fix it real quick, like, open up a PR. I've gotten countless numbers of contributions where people just gave me the answer.

JASON: Yeah.

BRIAN: In coding interviews, in boot camps, like, the mantra is you have to go find your own answer or you got to do it on your own. Don't look at the book for at least two to six hours. Once you get to the six‑hour mark, now you know you're a developer. But at the end of the day, like, most maintainers are, like, the good first issues are the things that they just don't have time to do but they could do in, like, 30 minutes. So I've basically gotten my contributions to things like React Native, it came through because I was an early user and had a problem. Someone gave me an answer. I was like, oh, cool, I'll just open up the PR. And now I'm in the ‑‑ I'm in the vault as a React Native contributor one time because somebody gave me the answer.

JASON: I love that so much. It really just does point to the fact that, like, there's no ‑‑ I feel like people look at open source as ‑‑ sometimes as, like, a strategic thing and networking thing, a career‑building thing, and like all strategic and networking career‑building things, when you start peeling back all the layers of strategy, it just comes down to, like, be engaged. Be helpful. Like be kind. And you'll advance. That's really, like, every, you know, like, go out, participate, show up, be helpful, ask good questions. You know, act in good faith. Like all of those things are just being a good person at the end of the day.

BRIAN: Yeah.

JASON: You show up and you are treating people with respect and you're trying to be helpful and, you know, you're just doing things that are interesting to you. And that combination of treating people well and doing things that you're interested in is going to lead to growth. And if you, you know, like you said, if you're using a project and you find an issue with the project, going and opening that issue is gonna, you know, first of all, you're getting in touch with the people who build the project. You're gonna get an opportunity to contribute. That's great. Good for your career. It gives you a little more insight into how the thing works. Well, now you're a better developer. That's good for your career. And all you really did was chase an interest. And, like, try to be ‑‑

BRIAN: Yes.

JASON: ‑‑ helpful. And I think that's the solution.

BRIAN: The one more secret sauce tip. I used to play high school football back in the day. I was in the newspaper once. I'll share an image on Twitter when I find it, but the ‑‑ I played wide receiver. The one way to get yourself in the game is, like, standing right next to the coach. Because usually what happens is someone gets a longshot, throw it down the field, and CNN they're tired. Usually what happens is that person gets pulled out and whoever is standing next to the coach gets pulled in. The other analogy is I spent the last two weeks with my kids because my wife had to go deal with some family issues. For years, I've been second‑string quarterback when it comes to parenting. And then out of the blue, I'm pulled into first string because obviously I'm a parent. I'm the dad. I can do the work. And obviously passed with flying colors. Both kids are still alive and happy. But what I'm getting at is the ‑‑ in open source, it can be just sitting in the Discord watching conversation happen. And, like, you don't have to, like, say, hey, I'm here. I want to be a contributor. Tell me exactly what to do. Put me in, coach. It's just, like, literally just standing there. As you see the questions being asked, like, take note of the questions that the ‑‑ the constant questions that are continually being asked, and eventually you'll find the answer because they'll be given eventually. And the one best contribution you can probably make today as an open source potential contributor is, like, write a blog post. AJC Web Dev, Anthony, sometimes he's hanging out in these chats as well. He would sit in different Discords, specifically the red board community, and just, like, be super helpful. He does this other series on dev.2 where it's, like, a first look at Vite or a first look at React version 18. He'll just be the first person to write the blog post for whatever technology that comes out, and, like, give the first look. Walk through the onboarding. Walk through the documentation and give some feedback. Unbelievably valuable. Like I've talked to ‑‑ I've seen Dan's tweets as well for React. A lot of folx just don't even use the next, latest releases. Like they wait until everybody else has done it, which means as they ship new releases for, like, Vite 2 or Vite 3 or V3 or whatever, you can be that person to test it out, provide some feedback up front. As long as you keep showing up and providing value, you could ‑‑ not join the core team but be sort of, like, first person pulled in when conversations are happening or first person to pull in when RCs are being chatted about. So, like, there's so much opportunity. And it's just ‑‑ there's something in the chat about life is 80% showing up. Like I think sometimes if you're available and you have, like, some cycles, showing up in community is valuable. And do it while you're at work too as well. I would not shy away from contributing and being involved in open source while you're waiting for a test to pass or you got some down time.

JASON: For sure. Yeah, I think, like, you know ‑‑ and a lot of companies now ‑‑ and I think the number is growing. Are starting to really embrace the impact of open source. And, like, how important it actually is. And in some cases, like, with GitHub, it's pretty obvious that that's a strategic move. Like open source is built largely on GitHub. And that is a great ‑‑ what's the business word? Synergy, right?

BRIAN: Yes.

JASON: But then if you think about, like, all these companies that, you know, their not software companies, but they build on open source, they're using React every day. They're using Redux. They're using NGRX and Angular and all these tools that are open‑source tools. So getting involved with that as part of your day job is helping your day job, and it's helping you kind of make ‑‑ you start to have more influence and more ability to, like, direct things because you'll have a better understanding. So it's a great career growth move, both community wise because being active and, like, helpful in the community is just a great ‑‑ I mean, that's why I know you, right? Because you're somebody who is always visible and super helpful and ready to jump in and help people progress. And so, you know, now you're, like, one of the people that I think of first when I think about good community building. And I don't think that you did that strategically. I don't think you were sitting somewhere with a whiteboard like, all right, how do I become an influencer on social media? You know what I mean? I think that's just who you are, and that genuine engagement shows up. But also it worked. Like we've got people at work that they're not necessarily on Twitter, but they are super engaged in open source. And they are now, like, really influential in the way that we architect things at work. They really drive our roadmap and they drive our internal tech decisions because they know what's going on and they're plugged in. They've got these back channels open. So, you know, whether your aspirations are community focused or career focused, being just, you know, like you said, show up and pay attention. You don't even necessarily need to, like, actively participate. You can just be an observer. There is still huge opportunities to just grow from there.

BRIAN: Yeah. And the one thing about being at work, too, as well. I constantly have the sort of concern and question around, like, open source, it feels like it has to be your free time, it has to be your nights and weekends. And, honestly, it doesn't have to be. If you're in the state of California, you could do open source all day, every day. The company can't tell you no. That's in the state of California, but there are other ways you can sort of have the conversation with your manager, your team of just saying, hey, I actually want to participate. I found the bug. I'm gonna go contribute back. Because what I found in my first‑ever engineering job, just giving talks and participating in the local community, I was able to recruit more people on the team. And it's the same thing when I worked at Netlify. Giving a conference talk on stage was actually a really good recruiting tactic, once we got to series "A" and, like, our network was tapped out. Just be being in the field made it super helpful to find other people to work alongside of us. So, like, you could provide value, not only to open source, but also to the company that you work for by being a contributor and a participant in the community as well.

JASON: Absolutely. Yeah. So, so, so many good things to come out of this. All right. So I could talk about this in the abstract all day, but I'm really excited to actually dig into some of what you've been building. So let me switch us into pair programming view here. We'll go to camera 2. All right. And so ‑‑

BRIAN: All right. Here we are.

JASON: Before we ‑‑ are we ‑‑ no, okay. Sorry, I got, like, a weird echo there. Okay, now, before we get started, let's do a quick shout‑out to the sponsors. We've got Jordan here from White Coat Captioning doing the live captioning today. Thank you very much, Jordan, for being here. That is made possible through the support of our sponsors, Netlify, Nx, and Backlight, all kicking in to help make this show possible, honestly. And we are talking to bdougie today. So that is bdougieYO on Twitter. Make sure you head over there and give a follow. Let me drop this in the chat. And really, that's kind of what I got, to lay the foundation here. So you're talking about ‑‑ you're talking about doing a lot. I can see a link here to Open Sauced. So Open Sauced is your project that's really kind of built around this, right?

BRIAN: Yep.

JASON: So how, like, how does one get started here? If we're talking about, like, really moving in?

BRIAN: Yeah. So, usually, the ‑‑ so, Twitter's great to follow as well. I'm not as active on the Open Sauced account. Every now and then, we'll do events. I'm hoping to pick up events moving forward, hopefully closer to summer. But the best place is actually the Discord. So, like, if you go to opensauce.pizza, there is a link to the Discord. More than welcome if folx are interested in finding out good projects, first good issues or just talking about Open Sauce in general, feel free to join there. Say hello. Again, if you want to be part of the community, definitely get involved. Say hello and provide insight when I ask random questions or drop a PR for review. Would love insight there. But the one thing I wanted to talk about because I've actually ‑‑ one of my first appearances on Learn With Jason was when I first started taking opensauced.pizza seriously. I mentioned it on a whim ‑‑ actually this site. At the end of a stream. Oh, yeah, I've been doing this thing. Latest by our CRM for contributing to projects. Since then, I've developed hotopensauced.pizza. Eventually, we're going to merge everything under one umbrella. Making design and also infrastructure decisions. We might utilize Redwood to centralize everything together because it's becoming a beefier project. Hotopensauced.pizza is essentially finding trending projects. When I say trending projects, this is only for Open Sauce users. So there's obviously change log nightly and GitHub trending, but hotopensauced.pizza is for anyone using Open Sauce to track their contributions and saving repos for later. Those are the projects that show up on this list. There are a lot of JavaScript questions and awesome for beginner‑type projects here. Then we have some of the staples within the industry, like free code camp. Shout‑out to Zach, full‑time open source contributor or maintainer at this point. So that's what this is.

JASON: This is really cool. Yeah, it's been a while since I've seen all this. I don't even remember there being login functionality when we originally talked.

BRIAN: No, when we originally talked, there was no login, yeah.

JASON: So, how does this work? Let me see. I'm just gonna jump in here. I'm gonna log in using my GitHub account. Makes sense.

BRIAN: Yep. So we're using Supabase for auth. Which is also go true under the hood.

JASON: Go true is an open source that started at Netlify. Now Superbase is using it. I think they've done a ton to improve it. They've been super active on that.

BRIAN: Yeah, it's awesome. Sorry, go ahead.

JASON: Well, I was just gonna ‑‑ I'm poking around here, getting a sense here. So if I'm in here and I'm like, oh, yeah, I want to up‑vote, Eleventy.

BRIAN: You can go to my votes. You should have 11ty now. We actually have the issue up for profile pages. You'll be able to see this on your profile in the future. But for now, this is the lowest ‑‑ what do you call it? MVP of profile pages right now.

JASON: Mm‑hmm. And so these ‑‑ are these, like ‑‑

BRIAN: They're the most recent, yeah.

JASON: And you're pulling this, you said, from, like, I am ‑‑ so I am an Open Sauced member.

BRIAN: Yeah.

JASON: Now. Because I've logged in. So if I go and make a pull request somewhere, the project that I opened a PR against would show up in this list?

BRIAN: Yeah, eventually. We're not that far yet.

JASON: Eventually.

BRIAN: At the moment, we're just tracking star data. So if you've starred a project after logging in, like, that will show up on the list. We do have a Cron that is very slow, just for rate limiting purposes. So it might take a couple days to show up on the list. But we're basically going through seven members at a time, checking their latest stars, adding it to the list if it's unique.

JASON: Yeah. This is ‑‑ this is very ‑‑ this is ‑‑ I mean, this is fun. Like I love ‑‑ I love the discussion that, you know, you're just kind of building a good way to let a community of people who are engaged share the projects that they're excited about. And it's, like, it's such a simple idea and it's so good.

BRIAN: Yeah. And it's the ‑‑ the whole notion here is, like, it's one thing just looking at all of GitHub and saying, oh, cool, I can find cool JavaScript projects or I can wait until the newsletter or someone tweets about it, but there are active people who are looking to get involved with open source and there are also folx who, like, are levelled up and have now become, like, stable contributors to certain projects. My idea is, like, I only want to talk to the people who are learning how to do open source and then graduating from that path to then go back and teach the people behind them. So that's ‑‑ that's basically the future of this. Is that we will have ‑‑ if you go into the GitHub repo and ‑‑ I don't think you can see our project table because ‑‑ actually, you go. If you go to GitHub.com/opensauced. If you go to the actual org account.

JASON: Okay.

BRIAN: And then click on "projects." There should be a project for 1.0. Okay. I guess you have to be part of the org to see it. Apologies on that. If you go back to opensauced/hot, you will then be able to see the issues. We have a couple issues marked for planning. So that first one. And actually, the second one is profile pages. Yes. Yeah. So this is where ‑‑ this is our quick mock‑up of what profile pages will look like. I like the idea of being able to highlight stuff like your blog posts that you've created for a project. So if there's, like, a project, what projects has ‑‑ I keep picking on Vite because it's top of mind but, like, if you wanted to do a quick blog post, hey, here's how to do a quick thing in Vite, submit that to the community and then we'll highlight that. So we'll have opportunity to, like, tweet that out, get more readership, but also this will help elevate other people who want to get involved. So I've got a plan to eventually create a forum. So, forum being the dev.2 parent company in platform. We started the process of doing an Open Sauced forum, but the challenge there is moderation. So I actually backed off a bit until I can confirm, like, having moderation in the forum first.

JASON: Yeah.

BRIAN: But we're planning towards that eventually.

JASON: Nice. Okay. So let's see. We've got ‑‑ yeah, some issues here. Man, yeah, all right. So this is ‑‑ and this is cool, too, because it's pulling in GitHub data and also you're gonna layer in, like, your own, like, non‑GitHub contributions to the community. And that's ‑‑ yeah, I like that. This feels like something that ‑‑ go ahead.

BRIAN: Yeah, sorry. I was gonna say ‑‑ so I was the technical lead on the stars.github.com site. If you are a GitHub Star, say what's up because you can see this, but it's behind a login. If you logged into the stars site as a star, you could actually submit your contributions through blog posts. So, like, it's the same idea, except it's gonna be more broader for Open Sauced. I probably should tell the Stars Lead that I'm doing this. Basically, it's the same idea of how we showcase Stars' work and what they're doing in the community and what they want to showcase. Same thing with Open Sauced, except it's open for everybody. You can submit. Specific to ‑‑ contribution specific to projects. As much as I'd love your intro to open source stuff, you can definitely share that. If you're contributing to a project in a way that is gonna benefit broadly. So, like, first looks or, hey, I found my hairy issue. Here is how to connect this thing to that thing. That's kind of the stuff I'll be sort of sourcing and reaching out to folx to submit for.

JASON: Nice. Very, very cool. All right. So looking at this, we're in the hot and ready here. And ‑‑

BRIAN: Yeah.

JASON: ‑‑ if I'm looking for one of my first contributions or I want to get involved and actually kind of do something, where do you recommend somebody goes?

BRIAN: Yeah. So at the moment, it's ‑‑ there's no feature in ‑‑ the intention that we want to have.

BRIAN: Test, 1, 2.

JASON: We also just lost our caption foray second. Did my internet just tweak. Everybody, did y'all just lose the signal for a second?

BRIAN: You did flash for a sec.

JASON: I think I might have had a weird internet hiccup. So, sorry for that, everyone. But it looks like we're back. Jordan, are you good? Yes, Jordan is good. Okay. So, sorry, everyone, for the weirdness. Who knows what's going on. It's raining super hard in Portland today. So I guess we'll just be happy that the lights are still on. [ Laughter ]

BRIAN: You've got a good mic to not be able to hear that rain outside.

JASON: Yeah, I have a lot of ‑‑ so many post‑processing things going on on this mic right now. Okay. So you were saying ‑‑

BRIAN: Yeah, we're probably a few ‑‑ quite ‑‑ [ lost audio ] notifications in the project about things. And then clicked ‑‑ click the first icon. That basically says you've read the code of conduct. So now you're unlocked.

JASON: Which I now have. All right.

BRIAN: Yeah, it's pretty standard.

JASON: Project share?

BRIAN: Project share is where our project notifications are going. Right now, we're sort of piping through ‑‑ every now and then we'll have someone share their project, but we're also looking at our cool/GitHub projects. Which is a wealth of information of, like, hot and trending projects. It's actually more submission based. So if you didn't know about this, definitely follow that Reddit forum. Because you'll find some early, early projects trying really cool things out.

JASON: Very cool. Very, very cool. Okay. And so is there, like ‑‑ you said something about finding good first issues. Is there a place where people share those here?

BRIAN: Yep. There is also GFI ketchup, which I think is under the open source org. I should probably do a better ‑‑ it's a new chat that I was testing. So it's not organized properly, probably.

JASON: Do I need to go to the roles for this?

BRIAN: Under the Open Sauced org ‑‑ oh, you know what? I need to unlock it. I was testing it and we were testing it with contributors only. So let me just open it up real quick. Good catch.

JASON: We're launching live, everyone. [ Laughter ]

BRIAN: Now I'm, like, struggling to remember how to add roles. No, looks like the ‑‑ oh, there we go.

JASON: Anthony's in the chat saying hello. What up, Anthony?

BRIAN: Okay. Now you should see that pop up now. So just below. There we go.

JASON: There we go. All right.

BRIAN: Apologies on that. We literally ‑‑ I just launched it yesterday publicly, the actual integration. So just the other thing I mentioned in our email beforehand, but I've got the Ketchup app, and what it does is actually when you label an issue good first issue, it's the only feature we have right now is good first issue. It will actually pop it into this Discord with the intention it will be a notification on hot.opensauced.pizza. Right now, we're testing the integration and then we'll connect it to the app itself.

JASON: This is super cool. I'm a big fan of these kind of multi‑platform notifications. I feel like, you know, whenever I want information, like, I would probably, you know, I would mute mobile notifications, but I like having a Discord notification channel because it doesn't ‑‑ my Discord doesn't make noise because I basically stay in the streamer mode at all times.

BRIAN: Yeah.

JASON: And so, like, I can just browse this channel whenever I want, as opposed to my phone vibrating when I get a notification, or, you know, you do, like, Slack Ops or email or all those sorts of things. Everybody wants their content in a different place. I like that it looks like you're kind of set up from the get‑go to put it wherever somebody wants to get it.

BRIAN: Yeah. Yeah, and if you click on that issue itself, you'll see the project that's actually powering this, these notifications. It is a ‑‑ so this is the issue I marked. The next thing I'm gonna do is actually I'm gonna mark PRs for ready for review. I really believe in crowd sourcing PR reviews. My success in this project but also other projects I maintain is a lot of times ‑‑ and the reason why people go to Reddit and other places to notify people of their projects is because it's hard working on stuff alone. Because you lose interest or there is less excitement. If you can get someone else to look at the code you're writing, even if you're the only one writing code there, it's been extremely helpful when trying to figure out some weird ‑‑ I remember years ago React router, every single year I had to relearn how the world works. Just tweeting out and being like, hey, how do you do this in version 5? What's a new hotness? I don't have time to keep up with all the changes. So I'll just tweet out. Not everybody has 10,000 followers like myself. Weird flex, but, like, I could tweet out a PR and be like, hey, can someone take a look at this PR? And I'll get reviews. I love that I can do that. What I'd love to do is give that to all Open Sauced users. If you want a PR you want to get reviewed, mark it a label, ready for review, and get another notification to the Open Sauced Discord. Any project that has installed the Ketchup app will send notifications to Open Sauced. The goal is eventually to build up enough of a content stream of people who need review for PRs, but also good first issues, but also identify what cross‑collaboration opportunities are. We're working down a path of ‑‑ we're gonna eventually have enough context and data for folx to jump into open source. And a really good first contribution is reviewing PRs as well. Just want to throw that out there.

JASON: Absolutely. You know, I talk about this every once in a while it comes up, but one of the things about learning to code is that a lot of it is immersion, right? And you learn the basics by studying and you learn the more ‑‑ I don't even know what the right word is. The, like, the nuances, the art of it, I guess. The instincts. By watching people who know more than you or who have more experience or different experience. Because they're going to do things and they're not even going to be thinking about it. It's just some little automatic habit they picked up years ago, and you'll watch them do it and you'll go, wait, why did you do that? They'll say, oh, because of this, this, and this. And you'll go, oh, my goodness, I just learned something huge. I feel like that's the same reason I watch cooking videos. Is not necessarily because I need somebody to show me how to make whatever dish it is, but I want to watch an expert chef and see the little things that they do differently than I do and why their food tastes better than mine, right? And PR reviews are a great way to get that, like, hey, why did you do it this way? A lot of times when I do PR reviews I, like, I celebrate stuff. I'm like this is, like, what a great section of code this is. It's so much cleaner than I would have written it. I ask questions. Like this ‑‑ I don't get why you did it this way. What was your reasoning here. And then I learned something. Then there is the stuff you catch that's like I'm pretty sure this is a bug. That's the truly useful ‑‑ then it becomes a two‑way street, like, I'm helping but I'm also learning and, you know, I feel like you pick up a lot of little stuff like that. Yeah, the thought process. That's what Imati has just said. Yes, the thought process behind why people build the things they way they build them is so, so valuable.

BRIAN: Yeah, you're missing an opportunity if you don't go through that process. Mention it enough it actually entices people to actually look into. Oh, yeah, yeah, you made this approach, turns out Fetch is embedded in Node. Why not go ahead ‑‑ I have a big pet peeve which is, like, why ‑‑ never ask the question of, like, why didn't you do this or why didn't you do that? Because a lot of times they chose the path because that's the path they discovered. And usually the "why not" is I didn't know. Instead of being like, why didn't you do this? Hey, great job. Also wanted to mention there are cool features in Node that are now embedded. Hey, just wanted to mention in addition to the great job you did, if you wanted to clean this up, here's a quick snippet or sample or another place in the code that we're doing it this way. As I was mentoring newer devs on my team, I'd always try to approach the problem ‑‑ sorry, the question of, like, hey, you did it wrong. As opposed to, like, hey, you did a great job. I also want to show you another cool way of, like, approaching it. So that way everybody feels like they're all learning in the process and it's less about, like, condemnation.

JASON: Yeah. Yeah. Like I've heard the term on ops teams of, like, blame‑free problem analysis, right? Where you're not saying, like, you did something wrong. Or this was your fault. But, rather, you're just trying to understand how it can be better next time. And this is ‑‑ this is very different from, like, you know, that's in the context of, like, there was an incident. Something went down. But I think in PR review, you can bring the same spirit in there. The goal here isn't to show somebody how smart you are or show who's the better developer or worry about who made mistakes or who didn't, but, rather, to just say, man, these computers sure are neat. I'd love to learn more about doing more neat stuff with them with you. [ Laughter ]

BRIAN: Yeah. Yeah, yeah. One of the skills I found out early on is writing blog posts. I was pretty prolific in writing blog content when I was a junior engineer. I've sort of fallen away. Better cadence on the GitHub blog recently. But for years, I spent a lot of time not doing it. What I'm getting at is convincing other people in your PRs that you might the right decisions or why you made those decisions. Sometimes you can take that context and go write a blog post and share it somewhere publicly. It's a weird flex because you can get validation outside the company you work for, but that validation can help support decisions made moving forward. If people are like, uh, I don't know about this Typescript thing. Maybe we don't want to invest in this project now. You write a blog post and everybody's like, hey, yeah, I did Typescript and we got all these wins within the first six months. That becomes a great validation to be like, okay, team, we're gonna invest in Typescript. Let's rewrite the entire app. Hope you don't do that. Don't do that, please. [ Laughter ]

JASON: Yeah, sometimes you just got to burn it all down and start over again, right?

BRIAN: Yeah. That's exactly why I feel like ‑‑

JASON: Around promotion time, right? That's when we start from scratch.

BRIAN: Yeah. Or when you have ‑‑

JASON: Don't do that, chat. But, no, I think ‑‑ but you're absolutely right. That's something I hadn't even considered that's just an excellent point. Is how much discussing your code helps you understand your own reasoning and improves your ability to communicate in a way that, you know, if we talk about, like, I keep looping these back to career. And I know that's not really the heart and soul of what we're talking about today, but thinking about career advancement, like, once you get past senior engineer, all of the advancement after that is based on how effectively you work with other people. Like senior is, like, can I give you a project, walk away, and you'll get it done? Great. Yes. That's senior. Staff, principal, so on, those are, like, hey, can I give you an ambiguous problem and you can go convince a group of engineers to follow you or you can design an architecture that will survive the marketing and product reviews and make it to production in tact. That's all people. That's all communication. And being able to reason through your code and thinking about why did I make the choices I made. And, you know, how can I ‑‑ can I have conversations about the code non‑defensively, like, if somebody questions my decision, am I upset that I got questioned? Or am I stoked that somebody's invested in making it better? And, you know, each of those things ‑‑ and, yeah, being able to pull out blog posts. What a ‑‑ that's killer. That's such a good idea.

BRIAN: Yeah. Yeah. And I hope you don't mind, I saw Charlie dev dropped a question about a major tech company and PRs being scrutinized.

JASON: Yeah, go ahead.

BRIAN: It's the investment of the code and putting it in. This might not be a great answer. Definitely ask a ton of people and other people at companies as well. Chat, also jump in if you're interested in providing your own anecdote. I've been spending a lot of time watching Paul Graham and, like, YC conversations on YouTube. Actually, specifically, like, Peter Thiel, for whatever reason, showed up in my feed. I've never seen him talk about anything, but decided to start watching some, like, pitches. But what I've learned from VC pitching for start‑ups is that you have to de‑rest the investor. Because they just want to know like, hey, will you successfully make this thing happen or are you gonna take the money and go twiddle your thumbs and buy an office in San Francisco ‑‑ lease an office, rather. So, like, with code, it depends on, like, how mature the team is or how junior the team is, but at the end of the day, you're, like, de‑risking, the rest of the team and your manager and your company by them accepting your code. Because usually in the concept of open source, I've got some pretty great contributions, like this driveby distributors. And a couple of them came by recently on my newest project. Then I have to make the decision, like, I've never seen you in the Discord. I've never seen you on Twitter. I don't know who you are, but yet you've given this awesome code. I 100% guarantee you're gonna disappear. This happens as well ‑‑ I made a TikTok about senior devs going to F.A.N.G. companies after mentoring junior engineers. Over and over again you see your senior dev leaving to go to a better company and now you're it. A lot of times in open source and even in companies, you want to make sure the code you're accepting and you're considering is gonna be maintained. Moving down the road. So if you're making some, like, heavy‑hitting decisions, that could be challenging for a team to even, like, wrap their brain around, which is why you can sort of de‑risk by write a blog post or de‑risk with helping out with documentation or de‑risk by having syncs based on the decisions you're making. Hope that's helpful. It's a whole other can of worms based on, like, level, skill, gender, bias, and stuff like that. I hope some of the thoughts I shared was helpful.

JASON: I think that's, yeah ‑‑ and I also think, like, there's a difference in a PR review where I've noticed that there are people who are just extremely thorough in their PR reviews. And they're doing it from a place of constructive feedback. And they see themselves as mentors. They see themselves as stewards of good code and all that. And then I've also had people who are really, really intense with their PRs as a form of, like, gatekeeping. Because they feel like they control the code and want to make sure it's done exactly their way and all that kind of stuff. So I think that, you know, for Charlie here, the question that I would maybe start framing things from is, do you feel like the PR reviews are coming from a good place? And if the answer is yes, then, yeah, you're probably just getting, like, a great amount of team support. If it feels like people oar trying to keep your code from getting into the code base, then there is another set of questions to start asking around that which is, like, you know, why? Are they nervous about you? Are they unwilling to let anybody's code go in? Is it only certain types of code that will come in and cause problems? Like, you know, where are their triggers? Because sometimes it can just be, like, I know when I was at IBM, there were devs that I thought had it out for me, and when I dug into the history, I found out they got burned super hard by, you know, some project that another team got involved in, and then that team got moved and they got left with a bunch of code they didn't understand. They had to work really long nights and weekends to get it back to a point where it was functional. So they were super protective as a result. Had nothing to do with me, but I was feeling personally attacked. We were able to back that out and figure out how to work together. I had other people who straight‑out had it out for me. They didn't want my code in their codebase. That's what it is, right? It's important to dig in and understand where the motivation is coming from for those really intense PRs so that you can navigate it from more than just this doesn't feel right, but more of, like, okay, I think I understand some of the history and context and motivation for why I'm getting these types of PRs. Because then you can make better decisions. Like you said with de‑risking, de‑risking is such a powerful thing for somebody who is nervous, who feels like they got burned by code in the past. And then there's a different kind of de‑risking which is, like, the I'm not here to try to take over your project de‑risking. There is the I'm not here to try to bring you the future de‑risking. I'm just here trying to get something done. You know? There's all sorts of interesting ways that you can discuss and talk about the code you're trying to do that can, you know, help people get on the same page and feel like we're just trying to build software. We're not trying to ‑‑ we're not playing Game of Thrones here.

BRIAN: Yeah, there was another notion back when React was kind of taking over in the mid‑2010s about résumé‑driven development as well. And, like, a couple of us on the engineering team, like, we ended up leaving a couple months after this, but we did ‑‑ we did do, like, some heavy‑hitting React tries and changes and stuff like that as we were interviewing other places. The start‑up was going under. We saw the writing on the wall. So we did do a bit of résumé‑driven development, too, as well. Do that in open source. Like go find an open‑source project to contribute to. If that's the case. Which I think is undersold opportunity if you're at a company and like, oh, man, we're still on Angular 12. I don't know what the version of Angular is. I want to go try the new Vue. The best place to do that is find a project actually using Vue, go make a contribution, and see if you like it. See if you can learn something from that experience and stick around so you can learn outside the job. Do it on Fridays. Do it during lunch. I'm gonna continue to say this. I'm a big fan of writing open source code at work because I think there is a value can provide back to the company. But if you are concerned about your manager or whatnot or time you put there, have that conversation. Or come work at GitHub.

JASON: Yeah, right? I mean, this is the thing, is it is probably one of the wildest job markets I've ever seen right now.

BRIAN: Oh, yeah.

JASON: So many opportunities. If you want your job to look a certain way, you've got negotiating power right now. And I think that companies are pretty willing to work with us. Because, you know, it's so much more expensive to hire somebody new than to keep your existing talent. So if you're the existing talent, just, you know, be reasonable, obviously. Like you don't want a Lamborghini as a company car, but some time to work on open source 10% of your time, that's a perfectly reasonable ask and one that a lot of companies are willing to support now. So it's one of those ‑‑ you can definitely advocate and make that stuff happen because, yeah, I mean, a lot of us, we got kids. We got families. We got stuff we want to do that's not on the computer. And you shouldn't have to give up your nights and weekends to do the things ‑‑ this is all advancement. It all benefits your company, right? It's not like you're out here ‑‑ I'm not trying to learn how to play the drums on the company clock. Oh, thank you for the gift subs, Charlie. I appreciate that.

BRIAN: Yeah.

JASON: But yeah. So I think, you know, there's a lot of opportunity out there for just advancement in so many different directions. Like, you know, as a communicator, as ‑‑ in your career and all of those things, and, yeah, I'm very much ‑‑ like I don't ‑‑ I understand where people come from with the résumé‑driven development thing, but I also, like, it kind of feels like all development is résumé‑driven development. You're ‑‑ the work that you do ‑‑

BRIAN: Yeah.

JASON: ‑‑ tells people what kind of work you want to do. And if you're, you know, like, in your company, if you ‑‑ if you want to do more, like, UI design‑style work, get involved in those projects. You show the company that that's what you want to be and they'll think of you first when you ‑‑ when you take those projects. And, you know, the joke I make is that doing ‑‑ like performing well in your job is like winning a pie‑eating contest where the prize for winning is more pie. So when you think about what you're taking on and what you're gonna excel at as a career, you know, as a developer, make sure it's a flavor of pie you like. Because the more of it you do, the more of it you're gonna get, right? [ Laughter ]

BRIAN: Yeah. That's actually a great analogy. And I don't know if I ‑‑ I feel like I've heard that analogy before. Maybe it was from you.

JASON: It definitely didn't originate with me, but I say it a lot. [ Laughter ]

BRIAN: Yeah. But yeah, I stand by that, too, as well. Like definitely make sure the pie that you're getting in return and as a reward is the pie that you don't mind hanging out with for the next two to four years until you're fully vested.

JASON: Charlie is suggesting Reese's cheesecake. Chat, what's your favorite kind of pie? I think cheesecake might be the one. Cookies and cream cheesecake, a good dulce de leche. I think I might only like cheesecake.

BRIAN: Is pie a cheesecake or a different form of dessert?

JASON: I don't know. It's got a crust. Who knows. Yeah. Apple pie. Pecan pie. Ooh, that is a good one. Man, now I just want pie.

BRIAN: Yeah, in Oakland, we've got a ‑‑ I'm, like, blanking on the pie shop, but got a great pie shop, Piticery. They actually went remote a bit during the pandemic. They ended up ‑‑ they went remote and showed up in Whole Foods so they're doing pretty well. They make a really good pecan pie. If you're in Oakland, Piticery has a great pecan and also rhubarb, if you're a fan of strawberry and rhubarb, that's an excellent choice as well.

JASON: Okay. Now I just want pie. All right. I'm getting called out for calling cheesecake pie. Look, they're all ‑‑ at the end of the day, they're all sandwiches. [ Laughter ] So let's see. What should we ‑‑ what should we talk about next? Chat, do you have questions for Brian about open source? Like what are you working on? What are you building? And, you know, where do you want to go next? Let's hear about it. Brian, while we're waiting for the chat to think and type, what ‑‑ like what else do you think somebody should focus on? So we looked at, you know, we've got the bot here on Open Sauced's Discord that's showing good first issues. We've got over here on ‑‑ we've got the hot.opensauced.pizza, if I can find it. Here it is. That is showing, you know, active repos, up‑voted repos. We've got the ability to sort by the most up‑voted. Great. Yep. Keep on ‑‑ wait, did I ‑‑ oh, I up‑voted it by joining. Got it. We've got some good projects here. Vite, that's a great project. Let's go. We've got Open Sauced itself.

BRIAN: Yeah. Yeah. Open Sauced, it's a legacy platform and it's really to track projects. So if you're looking for data on repos of good ‑‑ if you want to find good first issues directly at the source, you can filter there. You can also find out contributors. My whole thing is, like, you want to be able to find out who are the people to reach out to? I will eventually make that easier moving forward. Of, like, some ‑‑ I can do some creative things in the GitHub API. All this is open source. Like code's available and readable as well. I want to do some creative things. If you approach a project, what's some sort of data that is not being sort of surfaced when you walk into a project? And how to contribute. So I want to have, like, a ‑‑ we eventually have a score on repos based on approachability. So kind of, like, walk score. If you're living downtown Portland.

JASON: Oh.

BRIAN: A walk score of 99. But it would be interesting to have, like, a walk score for repos. So there are some repos that you probably don't want to contribute to. So I would say, like, projects like ‑‑ I don't want to point out any ‑‑ there are some projects ‑‑ you mentioned NGRX. Actually, Brandon gave a talk about NGRX when they weren't taking contributions, how they basically set the project up to say, hey, thanks so much. We're working on a big release. You can open issues but please no PRs at this moment because we're focused on this release. There are situations where ‑‑ and it's okay for projects and maintainers to do that. Not every project needs contribution. That should be also clear when you walk into a project.

JASON: Man, a walk score for OSS repos is such a good idea. That's brilliant. That's really thing that I'm looking for, right? I'm always looking for, where's the project that if I show up, people are gonna be resective, supportive, I'm not gonna get yelled at for trying to help, I'm not gonna get treated like I'm not very smart because I ‑‑ because I didn't know all the answers. Like I want to ‑‑ I want to go to projects that are, you know, invested in getting contributors. And so having a place that shows, like, yeah, these people merge PRs regularly. They're good at code review. Nobody's giving them a, boy, these people are jerks score or whatever that button is. That's brilliant. Brilliant. I want that real bad. Please ship it. [ Laughter ]

BRIAN: Yeah, yeah. I could probably ship it in, like, a couple months. I've got all the ideas and stuff, like, up here. I'm slowly creating issues. If anybody wants to jump in there. Even the algorithm for how popular projects are, it's an issue if you want to see how that works. I tried to borrow from, like, TikTok and how the For You Page is. It's very similar. If there is a clear connection where someone also on Open Sauced also likes the same things that you like and they recently liked it. There is also a recency score as well of how recent, like, you approached a project.

JASON: Flies.

BRIAN: All that sort of attributed in the algorithm. I'm open to suggestions as well. If folx want to add, like, hey, this would be cool stuff to put on the profile that's gonna be shipped hopefully in the next couple weeks. But, yeah, the walk score is a thing that I ‑‑ it's probably closer to the summer that I'll get to it, because I'm really focused on user, individual contributor experience right now. So, like, what things can you highlight as an individual contributor for open‑source projects? And then I'll be working on the maintainer experience. So as a repo maintainer and a project ‑‑ just general projects, like, a walk score will be something that we'll highlight pretty up front and center.

JASON: Cool. Very cool. All right. So we got some questions from the chat. Rollers is asking, how do you pick an open source project and not feel overwhelmed? So sounds like this repo score would be part of that. In absence of that, what are your houristics now?

BRIAN: It really comes down to interests. Nothing gets hacked over fast, but the approach is let's get everybody through the gate as fast as possible. And once the gate is closing, everybody walks away and they go back to their daily lives. So it's kind of like Burning Man. Like everybody's into it. But when Burning Man's over, you, like, go home and call your accountant and go make a VC pitch or whatever. So what I'd like to do is, like, make open source more ‑‑ not sustainable in the sense that let's go get money to projects. Because I think that's a problem that other folx are focusing on. But more of, like, how do you approach a project and easily find issues or easily feel like you're a part of the community? And it really comes down to, one, step one is probably use the thing. So ‑‑ and I'm not a fan of, like, how everyone also approaches open source. Go find good first issues. Go look at your package.JSON. I think those are good steps. Go have a conversation. Find the human element of open source. If you were to try to get a job at Netlify today, you'd probably want to interview there. You wouldn't take an offer without meeting anybody from the team or who you're gonna report to. You're gonna talk to somebody. Not every project is built with the same people. So, like, you are valuable to that project. So, like, show your value and your interests by saying hello. Opening up issues as opposed to looking for issues. But then participating in the conversation. So, like, we're openly talking about the future of Open Sauced in public channels. If you have any interest or conversation to provide or any insight ‑‑ because, like, we're making strategical decisions on infrastructure and tools, like, we're gonna radX for our UI. Our current design system is all hand‑built and very slow to get people ‑‑ to teach them how to contribute. We want to build on top of established solutions. But during that conversation, what we did is we had a Discord chat and we walked through all the stuff that people tweeted at me. Again, 10,000 followers, so I tweeted out, hey, what design system tools are you using today? Trying to move off Tailwinds potentially, but what would work with Tailwinds today? So it came up as a solution. We'll move with that and discuss if Tailwinds gets removed or stays with the project. So, yeah, participation. Joining the community. It's always hard, you walk into a meet‑up or go to a bar and go stand on the wall or go stand next to somebody you know and you don't come out of your comfort zone until you're comfortable.

JASON: Right.

BRIAN: So sometimes it is gonna be a bit of ‑‑ you're gonna have to be a wallflower for a bit until you're comfortable reaching out and saying, hey, I've seen you around. Thank you so much for the project. Had a couple of questions. Can I open up issues? Like what is the protocol? And sometimes that protocol is listed directly in the contributing ‑‑ for Open Sauced you can read through it and have an idea of how you contribute. Our onboarding path is the triage team. If you want to be part of the triage team just say, hey, I want to be part of the triage team. We add you on. Now you can label issues. If you see issues that need to be labeled or get more context or information, your respond is just to respond to issues. And also as new features get shipped ‑‑ we took this from the Node.js team. They have a release team. As we do PRs, I just ask the triage team to basically review the deploy preview on Netlify and just find if there are any edge cases or any weirdness. So funny enough, when I looked at opensauced.pizza, when you had it open, the pizza is really off‑center. That's our canary to know that something is broken. That pizza is way, way off. So something in the design changed or some update happened and now it no longer is absolute. It's, like, floating pizza in the wrong place. So, good first issue right there.

JASON: Yeah, absolutely. And maybe one other thing to add, Rollers, would be look at projects you're already using. I always feel overwhelmed if I try to jump into something new, but if I ‑‑ like I'm using ‑‑ I'm working with 11ity a lot right now because I moved over one of my sites to it. And when I go to, like, read issues and look at the open pull requests and stuff, I actually can kind of see what ‑‑ I understand a little bit more about what's going on because I'm familiar with the terminology and how the system works, but I remember back in the day, I tried to jump in and help on Jest and I didn't know anything about Babel. I didn't know anything about, like, Jest. Somebody just said, yeah, we got this issue. Oh, I want to get involved in open source. I'll help with that. I just hit a wall. I eventually had to go back and be like, I'm so sorry, but I have no idea what I'm doing and I don't understand the code at all. That was a mistake on my part.

BRIAN: Yeah. Yes, it's a mistake, but it's also knowing, like, when you hit that limitation, knowing when to come back. So it's the opposite of what you'd probably do at a job. Don't bother the senior engineers until it's a real problem or something is really broken. In open source, it's actually better to basically raise the flag earlier. Because, like, usually, most contributions do happen on weekends. It could be, like, next Sunday until you can get back to it. So it's always better to give, like, a status update. Like, hey, I did some research. Turns out I have no idea how this parser works. Here's what I found. Anybody who has time this week, like, just let me know if there is any good documentation on the parser. If you want to write something up quick, like, let me know. But I constantly try to ‑‑ when I'm contributing in other people's projects, constantly throw up, like, flags and updates and, you know, update, hey, I tried this thing. In the same comment. I'll edit the comment and basically add an update. Like, yeah, does not work. Let me know if you have any insight or anybody else or you want to point me to somebody else I can chat with. But the opportunity to get mentorship but also connect with other folx in the community and the project, and then you'll individually rub shoulders with somebody who is doing this full time. Then they have, like, unlimited access to somebody who can, like, unblock you.

JASON: Yeah.

BRIAN: Absolutely great. There are so many hairy issues I did. So, Open Sauced, there is a Supabase database. I had to do so much stuff to figure out how to keep it free. 100,000 requests or 100 million requests before you start charging. When I was setting up Netlify Functions to handle the swag shop. Because I didn't want to pay for a $25, like, serverless ‑‑ well, a function service that I could pay for. I'm like, oh, you know what? Netlify Functions I can make it work and coerce. I'm DMing folx like, hey, how could this work? Let me open up an issue. Point people to the issue. And actually Sean who is at Netlify now, working with the Netlify Graph. Also was somebody, hey, I opened up an issue, @SeanGroves. Hey, by the way, how can I get this to work? He'd come through in a couple days. Oh, yeah, take a look at this. Actually turns out it's our bad. Let me go ahead and ship a new release and it will work for you. I'm like, dude, could not even ‑‑ you're unblocking me by the time I wake up, which is super awesome.

JASON: Yeah. So many good experiences with Sean and just open source maintainers in general who are that engaged. That is a good point. The only real issue with Open Sauced is every time I access, I want to eat pizza. 100%. [ Laughter ] All right. So we have time for one more questions and there's a really good one from Charlie that I wanted to ask you. What are reliable ways to find open source issues that relate to the careers we're after? So, like, if a front‑end dev wants to help with marketing sites or, you know, as I mentioned, getting into design. How are you ‑‑ how would you recommend going about locating those to build that experience?

BRIAN: Yeah. So this is, like, I'm very tactical about my approach. I'm very intentional about this. So, like, maybe this is too on the nose. But, like, there is React‑a‑thon happening this May. I usually go to whoever is sponsoring. If I'm looking for future growth opportunities and looking how can I level up my career in a way ‑‑ at GitHub I'm not working on full‑time engineering problems anymore. I'll usually go find something that is cool, something out there, somebody using it and usually stalk that project. Usually I find people sharing it by what they share as sponsors at conferences or in guest speaking opportunities. Who was it? The syntax at FM, usually one of their sponsors is something I'm intrigued enough I'll find an example or a sanity project that is leveraging tools that I want to get involved it. I know I don't want to build another side project and maintain it for a couple of weeks and decide to walk away from it. I'll go into one of their templates and be like, how did you do this? The Next conf, I spent a lot of time trying to dissect how they disconnected their Discord live into their actual conference website. Which now it's a repeatable thing you see everywhere. Oh, yeah, it's cool. So I reached tout Lee and was like, hey, Lee, is that open source? He's like, no, not yet. But a week later, it's open source. So I was able to, like, dig in there and be like, oh, cool, this is how this is gonna work. So I built a prototype for GitHub that we never ended up using because maintaining stuff is quickly ‑‑ if I have to maintain it, it's like, you know what? Actually, didn't work out and we're gonna move on. [ Laughter ] But, yeah, being intentional and finding the companies and projects and engineers that are doing stuff you want to do. Stalking a bit of their projects. Which originally, that was Open Sauced. It was a way to stalk projects without alerting them through GitHub issues or mentions. And hopefully that's a step in the right direction for you.

JASON: No, I think that's ‑‑ yeah, I think that's great. And I think, you know, you also bring up, like, if you want to work on, say, marketing sites, all these open source community projects, like, they need, like, every open‑source project needs a marketing major. Every open‑source event is looking for help with running their website. Go do that kind of work. That builds a résumé. You can go leverage that with companies, too, right? There are tons of opportunities to get involved in this stuff. You'll look around and a lot of this is community effort. Even the Netlify logo was contributed by the community early on, right? So these are things where somebody was like, I want to get involved. They get involved. And it, you know, it really does ‑‑ it lives on and it makes a big impact. So that's a really good way to do it. With that, man, we just breezed through 90 minutes. It doesn't feel like we've even started yet, but it's always so much fun talking to you. I feel like we can go for hours. Do you have any parting words for the chat? Just to send us off at the end of this episode?

BRIAN: Yeah. If you ‑‑ if you want a friend, you got to be a friend. So reach out to me. DM me. I actually answer DMs pretty regularly. I don't ‑‑ this week's a little crazy for tweeting, but I will respond to you. Answer questions. As long as you promise to go join a community. So, whether it's Open Sauced or whether it's this Discord or the Party Corgi Discord, go get involved somewhere, chat and be valuable there by just, like, emojis are a really great way to show value without feeling like you have to go outside your comfort zone. So a like, heart, favorite would be ‑‑ would go a long way to make impact in other people's communities.

JASON: Absolutely. Absolutely. All right, y'all. So this episode, like every episode, has been live captioned. We've had Jordan here from White Coat Captioning all day. Thank you very much. That is made possible by our sponsors, Netlify, Nx, and Backlight, all kicking in to make this show possible. And we've got a whole lot of good stuff coming up on the schedule, so please go and check this out. We've got, let's see ‑‑ I'm out on Thursday, but next week, we're coming back with some automatic image creation from a Figma template. That's gonna be a lot of fun. We've got Cassie Evans comes back. We're gonna do more animations. That is always a blast. Please mark your calendars for that. We're gonna be putting even more on the schedule, so stay tuned. With that, we're gonna go find somebody to raid. Let's see. Who's live? Let's go see ‑‑ let's go see Michael Jolly. How about that, everybody? So, stay tuned. We're gonna go raid Michael. We will see you all next time.