Building Relationships in Open Source

Show Notes:

Sponsor Virtual Coffee!

Your support is incredibly valuable to us. Direct financial support will help us to continue serving the Virtual Coffee community.

Please visit our sponsorship page on GitHub for more information - you can even sponsor an episode of the podcast!

Virtual Coffee:

• Virtual Coffee: virtualcoffee.io
• Podcast Contact: podcast@virtualcoffee.io
• Bekah: dev.to/bekahhw, Twitter: https://twitter.com/bekahhw, Instagram: bekahhw
• Dan: dtott.com, Twitter: @danieltott

Transcript:

Bekah: 00:05

Hello, and welcome to Season 10, Episode 6 of the Virtual Coffee Podcast. Virtual Coffee is an intimate community of people at all stages of their tech journey, and we're here on this podcast sharing insights, experiences, and the lessons that we've all learned along the way. I'm Bekah, and I'm here today with my co host, Dan.

Dan: 00:24

Thanks, Bekah. This season we're diving deep into our back pocket topics from our Tuesday Virtual Coffees. Today's topic, building relationships in open source. We are grateful to be sponsored by Level Up Financial Planning that helps you take your financial confidence to the next level. It's real financial planning to help you reach your goals and gain clarity on what actions you need to take now to maximize your tech career. Level Up even has a podcast where you can hear about some of the strategies he uses with his clients. Check out levelupfinancialplanning. com. You can get that link in our show notes.

Bekah: 00:54

All right, so now it's time to grab your favorite drink, settle in, and let's get started with today's Virtual Coffee podcast. We hope you enjoy this episode.

Dan: 01:09

Yo, how's it going Bek?

Bekah: 01:11

Hey, it's going all right. How's it going with you? We'll

Dan: 01:13

I am doing well. It is the third week, starting the third week of Hacktoberfest. um, yeah, so I hope everybody's having fun. And today we are talking about Building relationships in open source.

Bekah: 01:28

Yes. I think this is, like, one of the things that's most important, but maybe that we talk about the least during Hacktoberfest. It's all about, like, you gotta get those four PRs, but what are the ultimate goals of actually contributing to open source?

Dan: 01:46

Yeah. Uh, you know, and I believe that we on this podcast, especially have talked about, uh, this sort of thing a lot. Um, the value of contributing to open source outside of, I don't know, just making your GitHub profile look, look cool. Right. Um, which is like, which is not nothing, you know, um, don't want to like discount that, but the, the, there's, know, we find open source contributions to be very, very valuable. And one of the reasons is because of the relationships that you can build up over, over your time.

Bekah: 02:20

Yeah, I saw this, uh, thing on Twitter recently where somebody was saying how important it is to build your network, especially if you are just getting into tech, and a bunch of people in the comments below were like, I'm new, but I don't know how to build my network. Like, what does that mean? How do you do it? And there were a lot of recommendations, but I think like, this is a great time to be building your network. Um, because you're already involved. There's a community of people that are all doing the same thing. So, you know, at Virtual Coffee, we're doing it as a small group, but It's a huge event that's sponsored by DigitalOcean, so there are lots of people out there. There are many different communities and organizations that are putting on events, but also, you have the communities, the open source communities themselves. And so, there's plenty of opportunities. Well, you have to get out of your comfort zone. I feel like anytime I try to expand my network or to build relationships I'm getting out of my comfort zone. So you like you might have to put yourself out there a little bit You might have to ask questions, but you know, you can also answer questions, too And so I think that It's important to identify, to number one, realize there's so many opportunities at this point, um, of the month to be able to expand those, but that extends beyond here, and ideally, you want to build relationships that extend beyond Hacktoberfest, too, so maybe the goal is not necessarily those four pull requests, but maybe it's four relationships that you can build during this month.

Dan: 03:53

Yeah, absolutely. You know, we, we talk a lot during Hacktoberfest about how to find, you know, how to find places to contribute. And we've talked about And there's, there's lots of resources for that. Um, I think one of the best ways to build relationships in open source is to become a, uh, repeat contributor to a project. Um, and there's value for that on both sides. You know, there's value just for, for you as a contributor. Um, if you get more and more familiar with the project, your work will be better and, you know, probably easier, or you'll be able to take on more challenging tasks. You know, projects or issues. Uh, and obviously if you are helpful and you keep coming back to help, um, you're the maintainers of the project will, will know you and trust you, uh, as well, which can have just tremendous benefits, uh, down the line and, and they can't always be predicted. We, it's not a transaction, you know, It's, you know, it's building trust capital, like we talked about. It's, uh, it's that sort of thing. Um, and expanding your network and, there's just so many benefits to this sort of, this sort of thing. I think it's, I honestly, I think it's one of the, like the, the, the, you know, I'm like, none of us like to talk about like building your network, you know, obviously, but the, it kind of comes for free here with, you know, with contributing, right? So if you think of it as, you know, if you hate networking, you know, you don't like, you're not good at it, all that sort of thing, which I'm not either. Um, the, but you like doing development stuff or any, any kind of open source work. Um, it's, it like comes for free. As long as you are like, you know, actually trying to be helpful and not trying to get something out of it and, uh, are respectful and all that stuff. Um, the network comes built in, uh, lots of times.

Bekah: 05:44

Yeah, and I see, so years ago I used to listen to this podcast, um, and it was about screenwriting. And one of the pieces of advice that I've always carried with me is look at the person who's one step ahead of you. And so, in terms of like screenwriting, they're saying if you're trying to sell your screenplay, look at someone who's just done the thing that you're trying to do right now. Because it might not seem like the best person, maybe you want to talk to that movie executive or whatever, but that's not the person that you're going to connect with or build a relationship with. They're at a very different stage, their time is very limited, and so, but that person ahead of you. It's going to remember you if you build that relationship with them. And eventually they might be that new movie executive, or they might have some pull over what gets made. And I think the same thing that applies here. You know, we often have this feeling of like, well, I have a question. I need to connect with the maintainer. The maintainer is not answering my question. But in some ways, that's kind of like the movie executive role. Like, you bypass all the other people that are working on and supporting the project. Depending on the size of the project, and you went to the person at the top, but maybe, you know, one of these ways to build relationships and goodwill is to, you know, see, okay, this person has already done a contribution here, I'm going to talk to them, I'm going to go into the community, and I'm going to ask a general question, I'm not going to at the maintainer in the comments or in discussions or whatever, I'm going to Build relationships with people who are where I want to be next and I think that you can learn a lot in that way and it also will eventually build you goodwill with a maintainer. Yeah.

Dan: 07:29

not working, all that stuff, which can be very frustrating, you know, uh, there's lots of ways to go about, uh, you know, Helping, helping yourself, helping the, the project. And usually adding a maintainer is never one of them, you know, um, the maintainers are going to see everything they're subscribed to the repository. Like, trust me, you know what I mean? And so, um, when you add a maintainer, you know, it, it can, it'll limit maybe the amount of people that respond to you, you know, maybe some people might respond, Don't like think they should, because you are asking the maintainer, you know, um, that, that sort of thing. And it's also just a, you know, I mean, it's just kind of a sign of impatience or, uh, a little bit of lack of respect, even if you aren't being like, even if you aren't, uh, you know, your words aren't rude, right. I mean, like we can all like pick out like. Oh, this person is just like plainly being rude, you know, and you don't mean to be rude, but there are ways to like, do this sort of thing, like add a maintainer, even if your request is politely worded, you know, um, it's, it's like kind of pushy, right. Or something like that. And maintainers lots of times have enough on their plates to not want to, um, have to deal with people being like pushing themselves into their face, you know.

Bekah: 08:48

Yeah, I, um, was listening to this podcast, The Secret Sauce, with, uh, the episode with Evan Yu, who's the creator of VIEW, and I think VEET, right? Anyway, he was talking about the importance of, like, how do you get to be, it was, like, maybe on the core team or something like that. And I think that, you know, this kind of, like, extends what we're talking about here, because one of the things that he said was there was this, uh, younger contributor who, um, first what he did was really understood the project. He understood the vision. of what he was contributing to. He understood the style of code that he was supposed to be submitting, right? And then he created pull requests that reflected that he had taken the time to understand the project and the requirements and he consistently submitted Quality pull requests. And so Evan noticed this and then, you know, this formed a relationship. So, you know, I think one of the things when we talk about relationship building we can think about is also you know, if you're doing all of the right things That can be noticed by other people who maybe you haven't had a conversation with or a maintainer that is out of your reach, but if you're consistently, um, submitting quality work, then that for sure will be noticed and that can help build the relationship and your credibility as well.

Dan: 10:15

Yeah. I mean, absolutely. That's the ways that you approach these sort of things, you know, I mean, I mean, this goes back to like being a good open source, you know, citizen, I suppose. Um, but it's all, you know, this is all, I know the benefits are all like tied up together, right? Like if you want your pull requests to be accepted, if you want your issue to be assigned, all of that stuff, um, you know, there's lots and lots of ways to, uh, help your chances of doing that, but it also, so like, which like will get your pull requests merged, you know, like there's, there's lots of ways to improve your chances of that happening. Right. And. It also improves your, your network and your, you know, it improves the relationship and, and especially like I said before, if you are, I mean, we've both said it a million times, but if you're a repeat contributor, um, and, It's just, it's honestly, as a person who is maintaining projects, whether it's open source or not, or work or anything, um, knowing that you can trust somebody else to work on this project that you've created, uh, is such a good feeling, you know, and it's so valuable. and becoming that person, I think is also a good feeling. I like being the person who, you know, Somebody can trust, you know, uh, a lot, you know, and, and so that's, it's why it's, it's, it is kind of nice to find some of these smaller projects maybe, or different projects and work your way up. So like going back to what you were talking about before of, of looking at the person like one step ahead of you. Another way to think about that is, um, finding smaller projects that aren't maybe as exciting. They're not flashy. Like it's not, I mean, put it on your resume if there's room, but like, it's not like, Oh, I contributed to. React, I contributed to this thing, you know, but there are millions and millions of packages out there or projects or open source, anything. And finding ones with smaller communities where you can kind of build a little bit of a network. Um, I think it's a really, really good way to do that too. And you never know, you never know what, what is going to happen, you know, down the line. But, uh, even if nothing else happens, you have maybe a friend and somebody who kind of know, you know, knows your name at least a little bit and also like a lot of experience and Et cetera. There's just like, it's just so many benefits at it. You know, it's, it's hard to, I don't know. It's hard to stop talking about the different ways that it is good.

Bekah: 12:37

Yeah, I think, you know, another way that you can build a relationship is offering to help in ways that might not be obvious. So some of the obvious ways of helping are submitting pull requests of triaging issues. Um, that's kind of part of the regular flow of open source. So if you're new to open source, That might not be obvious to you, but that, that's something that you'll learn and you'll grow in. But other things that are less obvious might be, Hey, um, can I help as a code of conduct responder in your Discord? Or can I write a blog post for you? Or, you know, what help do you need? Like, asking the maintainers, because sometimes, you know, uh, there are people that sometimes need help writing a newsletter or raising money or raising awareness. So that can be another way to build, uh, trust capital to be a way to build those relationships. Um, and those are some things, those are things that you can continue to do beyond Hacktoberfest. Um, I would say like another way that I've seen recently to get involved in build those relationships. is through Reddit. And I, I don't recommend Reddit very often because anytime I post in Reddit, if it's not cat Reddit, then people just like sloy on me immediately. So beware, that's your warning. But there are a lot of people that like ask for help on their projects. And it's the kind of projects that you're just talking about, about Dan, like the small projects, like Hey, I have this project I'm really excited about, but I have no contributors. Like, how do I get contributors? And, you know, a lot of times I'll respond to them and be like, hey, maybe you should write some issues, or there's not a contributing guide, or something like that. But, um, sometimes that's where people are reaching out for help on their projects, and it's a more visible way than you would find on, like, in personal discords or whatever.

Dan: 14:33

Yeah. It's really interesting. Is there a specific subreddit

Bekah: 14:37

Yes.

Dan: 14:38

that you would recommend

Bekah: 14:40

I would say the open source subreddit is where I've seen it, um, and then maybe like slash github too.

Dan: 14:46

Okay. Nice. Yeah. Who knew? Not me.

Bekah: 14:51

I learned, I learned about reddit this year, so.

Dan: 14:54

Nice. Yeah. All right. Um, that, no, that's really interesting. And like that kind of thing, cause I feel like the kinds of questions that people are asking or, you know, requests for help, like that kind of thing, it's hard to, I mean, maybe you could, maybe you would see it on Twitter or something, but it's, there's not like another place I can think of where it's all collected and it's not just one community, but you know, like lots of people, um, on one, on the, on that topic. And it's less like, You know, it's not just issues or whatever or some, or, or stack overflow where it's just like specific questions, you know. Um, that's really neat. That's a good, I like that.

Bekah: 15:29

Yeah, the other thing about the, you know, again, those small projects and answering a request like that, you often have one on one time with a maintainer, uh, that you wouldn't get with those large projects. But, um, You know, I think that this is all, like, valuable experience, and kind of on the other side of things, so we're kind of looking at it from the contributor's perspective, but I think there's a lot of folks out there who are in a maintainer role, or who are in a, an experienced or senior plus role, whatever, that are also looking to, like, provide support for people and to build those relationships. And so, um, you might see, like, there's someone willing to spend some time with you. But I think, like, maybe we talked in episode three, I think, about big M mentorship versus small M mentorship. What do you think are some good ways, uh, to mentor someone during Hacktoberfest?

Dan: 16:21

Um, so I guess, let me clarify your question. Do you mean just a person like we do in Virtual Coffee, or do you mean as a maintainer and a, and you're talking about a potential contributor,

Bekah: 16:34

Oh, that's a good I hadn't thought about the latter, but let's go with that.

Dan: 16:37

Uh, yeah, because, because that's like, because that's an experience that I've run into a few times. And I, you know, a lot of it is tied into Virtual Coffee as well. Um, so I, I do kind of know the person already, but it's like first time contributors, that kind of thing. Right. And so there are a lot of things that you can do, I think, to. to help people through that without creating a ton of work on your side, right? Cause maintainers, you know, like we don't want to, some things are worth spending time on, you know what I mean? But it's, if you can streamline it different ways, you know, and so, uh, a very good readme, I think is, you know, top of the line, also like a contributing guide and they don't have to be Like, especially if you're on a small project, right? I don't think I wouldn't say contributing guide is a must for people with smaller projects where they don't expect like lots and lots of contributions. I think I would put all that in just in the readme, right? You can just have a section in the readme about it. Here's what I expect or something like that. But laying all that stuff down, um, is, is important and will save you time in the future and also is a point where you can, if you get somebody who is trying to help, but they don't know how, right. Would it, so there's like people that have come in that. know better or should know better, but don't read the readme. Don't read the contributing guide or just like blasting issues or comments or whatever, pull requests. Um, you know, those people, you, you can politely, but kind of firmly say, Hey, please like do this this way or whatever. But there are, you run into people, especially like around Hacktoberfest where there's lots of first time contributors, um, where they are trying and they don't, they just like are stuck or they don't, they don't know what the best thing to do is that kind of thing. That feel, okay for people to like not know how, um, is I think really, really valuable and making it a safe space for somebody to learn. And so I think there's, there's ways that you can make your project or your community or anything like that a safe space for people like that as well. And, you know, part of that goes back to having a good readme. And instead of being like, To read the docs, you know, like, Hey, like, you know, you can answer a question, like, in a more respectful way and say, you know, okay, well, like, I would try it this way. Here's like, here's the read me section. You know, this is what I try. And let me know if that doesn't work, because it is possible you read me as wrong too. Right? Um, I've run into that with, uh, Yeah. Yeah. With IU, um, who we talk about all the time here, um, and is amazing, but she is on a, not but, but she is on a Windows computer and I hadn't tried any of our stuff on Windows. And that's not like Windows computers are fine and valid, you know what I mean? And it was just like this thing that didn't work on Windows. And, um, and so it was, you know, I think the readme was incorrect, right, for her. And, But we took a while because it was like, she was starting out, this was like years ago, but she was like starting out and we weren't sure, you know, where the problem was, all that stuff. Uh, and so it turned out like she learned some stuff and also I corrected the readme or well, she helped, we corrected the readme together, you know, but like the, Um, you know, being willing to, uh, to help people a little bit is, I think goes a long way towards that sort of thing, you know? Um, and it can get hard and it's hard to do if somebody files a pull request, right? That, you know, they followed all the directions, but you like, don't like it, right? That's one, that's a situation I've run into a bunch. Uh, have you run into that? Like where, they satisfy the requirements of the issue and you just don't quite like how they did it. Right.

Bekah: 20:17

Right. Yeah, that's tough. I mean, because I, I do a lot of documentation maintenance, for me, that it, I have actually run into that quite a bit, um, because there's, it's, we don't have a style guide, um, it's something that can be kind of hard to communicate to other people and to say, like, okay, here's This is how we need to revise it and and to be honest with you This is maybe not like the best way to approach it But sometimes I've just gone through and revised it myself and then merged it in so I mean they still get credit for the pull Requests and sometimes I'll mention like hey, you know, I just needed to make some quick updates before this went in Um, or, hey, we were under a time crunch, so I went ahead and made these updates. This is why, if you want to meet one on one to chat about it, then let me know. But, yeah, I've definitely run into that, and that does get really tricky to be able to communicate that, especially in an asynchronous environment, to try and explain, like, nuances of things, and the approach can be, um, a hard conversation to have and communicate.

Dan: 21:20

Yeah. Yeah. It's tough. You mentioned having a style guide. I think that's, this goes back to anything that you can get down in writing that you can point to, you know, um, will help the initial stuff. And it also helped this sort of situation. It's the same with programming. I mean, like having a style guide for code is, or can be really important as well. Right. And that doesn't necessarily, like always It's not always like, oh, your indents and your commas and your semicolons and that kind of thing, because nowadays that can be handled, um, programmatically, right? Lots of times, but there are like more like high level style things where if you have some opinions, you know, um, If you can get them down, I think can be really, uh, really valuable. And it's not, there's not, you're never going to cover everything, especially with the writing, you know, but, um, like you said, but trying to, there's like different ways to handle it. I've done the same thing. Um, as, as, as you were, I've just like made the changes, um, and merged it, you know, and I've also tried to work through like, okay, here's why, you know. It can be hard. Sometimes it's hard. It's a hard balance. Uh, I want people to learn, right? And so it's like, okay, do I, it will take me longer, me personally, longer to A of all write this out and then suggest the changes and then, you know, hope, hope that they're, Like review it again, you know what I mean? Um, but if I can do it in a way that they'll actually learn, and it's not just like, change this to this, change this to this, you know what I mean? Um, cause I don't think that's valuable. Like I, I, if I, if I, if that's all I can come up with personally, then I'll just like, kind of do it, you know, but if I can somehow get into words. What I mean by this stuff, like why, you know, um, then I'll either try to make the request and do it, or I will make those changes and write it out as like, this is why I did this, you know, and here's the example of what I mean, you know what I mean? Uh, and lots of times to do that, I have to just make the change myself anyway, you know, Have you ever made a change yourself just to do this sort of thing and then thrown it out and asked them to do it?

Bekah: 23:37

No, I've not knocked on down that rabbit hole

Dan: 23:40

yeah. I've done that. Cause I needed, like, I basically, for me, I need to see it to like really, um, describe why or whatever, you know? I need to like And also sometimes to check that I'm right, or, you know, that like, what I'm thinking of is actually what I'm thinking, you know, um, but I've gone down that road where it's all done and then I discard the commit and, and ask for the, you know what I mean? Maybe take a screenshot or something or grab some code, but, um, it's a weird feeling. Yeah. Uh, and it's, you know. I don't know. It's, it's all, you know, and I don't think that, um, being a maintainer means you have to like teach people all the time. Um, you know, like, I don't, we have that in Virtual Coffee. We, we value that. And like, it's one of our goals. Right. But the, I don't think it's any, I don't think it's every main open source maintainer's responsibility to teach people everything. Right. But there are ways that you can help people, um, without, Spending like the, without doing the kind of stuff I'm talking about, you know, where you're, where you're like, where you're doing that. Um, cause that's much more of like a, uh, you know, I, I feel the responsibility to try to help, um, but I don't know that I don't think that's an inherent responsibility for open source maintainers. Um, I do think being a little bit patient and being, you know, kind of respectful and the more, like I said, the more you can get down in docs or guides or whatever, uh, the easier that will be both as ways to. Catch things before they happen and also as ways to point to, you know, you don't have to feel bad if something's written down and they, and it's like, you know, the, in a pull request is not, followed. I don't feel bad. You know what I mean? Like, uh, about saying, no, you know, you gotta, you gotta change this because here's why, right? Um, when I have to come up with the reason why it, and sometimes it's, you know, you get a little bit more

Bekah: 25:27

Yeah.

Dan: 25:28

internal back and forth anyway.

Bekah: 25:30

Yeah, I think, you know, along the same lines, another good way to build relationships in open source is attending, uh, open office hours. And not every project offers these, but like, I know we used to at OpenSauce, like, offer contributors office hours. So if they were working on an issue and they were stuck or they had questions, then they knew, like, Thursdays at noon or whatever it was they could come in and they can ask those questions or they can get more context on the project and Um, I know that there are a lot of places that do that I think one of the maintainers of nuxt actually Has a calendly with 10 minute slots that people could book whenever they want Um, and I thought well, that's like that's awesome. Like he does a great job of being um, a really supportive maintainer. Not everybody has the time to be able to do that. It's not necessary, but I think that, like, look for those opportunities, too. You know, often they're in the Read Me or the Contributing Guide, or if the, the project has a community page, then it'll share that information there, or they'll share, like, Hey, we're doing this event. Like, show up for the event. And then I, like, I know I did Twitter spaces pretty much every week for a year for work, and, um, I noticed who came every time, you know? And I also was more willing to, like, support that person or help them out, and, because I knew, like, okay, they're interested in learning and growing, and so we've established this relationship, even though we haven't had, like, really a conversation, um, face to face about that thing. Like, there's a lot of asynchronous interactions that went with that. So, like, also don't underestimate, like, the value of telling someone thank you or leaving a comment on the blog post that they wrote to say, like, Hey, I really appreciated this. It helped me to implement this thing in my project. Like, those are all ways to kind of, like, build those relationships with the people in open source and go beyond Hacktoberfest. Yeah. Yeah,

Dan: 27:57

if somebody is stuck and they just, can't get unstuck. They might just, you know, whatever, go to a different project. Right. But if, if you can provide 10 minutes of support and help them through their thing and say, Hey, you know, let them know that they're valuable to, you know, they might keep coming back and you might end up with a co maintainer even. Right. Uh, so I think I loved all this, all of those All the things that people do. It's, it's great. Um, I wish I had time to do like all of them. You know what I mean? Um, both attend, attend everybody else's things and also like provide all this stuff for myself, you know, and also, um, not get fired at my job. So, you know, it's, it's tough balance, but, um, uh, you know, I, I think there's lots of great ways, um, to build those kinds of like relationships in, in open source.

Bekah: 28:44

Yeah, absolutely. And I think, you know, it comes down to communicating with other people and continuing to build those connections. So, enriching those relationships, understanding the other person and their needs, and, and all of this goes just to the human person. Like, we want connections with people. It just happens to be that open source is a pretty good path this month.

Dan: 29:05

Yes. I'd say every month, but especially this month.

Bekah: 29:10

Alright, well, we hope that you enjoyed this episode. We will be back again next week, and we'll see you soon.

Dan: 29:18

All right. Thanks everyone. Thank you so much for listening to this episode of the Virtual Coffee Podcast. This episode was produced by Dan Ott and Bekah Hawrot Weigel, if you have questions or comments, you can hit us up on Twitter @VirtualCoffeeIO or email us at podcast@virtualcoffee.io. You can find the show notes, sign up for the newsletter, buy some VC merch, and check out all of our other resources on our website, virtualcoffee.io. If you're interested in sponsoring Virtual Coffee, you can find out more information on our website at virtualcoffee.io/sponsorship. Please subscribe to our podcast and be sure to leave us a review. Thanks for listening and we'll see you next week.

The Virtual Coffee Podcast is produced by Dan Ott and Bekah Hawrot Weigel and edited by Dan Ott.