085 - Getting started as an open source contributor with Gift Egwuenu

The open source space is consistently improving, with a growing number of initiatives and projects built in the open. Front-end developer and consultant Gift Egwuenu shares insights on the importance of open source as well as how you can get started as a contributor, including: 

• How to make your first open source contribution
• Ways to overcome awkwardness and conflict in the open source process
• Tips for finding and making meaningful contributions to the projects you love 
• And more!

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Josh Ruggles:

Hello, and welcome to All Hands On Tech. I'm Josh Ruggles. Today we get to hear from front end developer and consultant Gift Egwuenu, as she discusses the importance of open source and how you can get started as a contributor. Let's take a listen.

Gift Egwuenu:

Hello everyone. I am very excited to be given this talk on how to get started as an open source contributor. And this is because I can relate so much to this being somebody that actually started and gave her first contribution sometime in 2018, I'd say. So in this talk I am going to share with you how to get started with contributing to open source, areas where you can make contributions, if you're interested. And, what to keep in mind when finding a project to contribute to. Without further ado, I'd like to give you a brief introduction about myself. Seth already did the honors, but has he said, I am Gift Egwuenu. I am currently working as a front end developer at Passionate People. I also create content for developers. So I create content on my personal blog, as well as on YouTube. I am on social media with the handle lauragift, if you would like to connect with me, I'll be happy about that.

So going forward would like to cover a couple of things throughout the course of this webinar. I'll cover what open source is, if you're not already familiar with it. Why you should actually contribute to open source. I will also cover house to make your first open source contribution. Ways overcome awkwardness and conflicts in the open source process, especially as a new open source contributor. And also share with you some tips for finding and making meaningful contributions. And finally, specifically for maintainers, how to make the process for new contributors more open and welcoming.

So, to kick this off, I'll start with what is open source. I know this is a very familiar theme to a lot of us. But, for people that are not already familiar with the term open source, open source is a term that's originally referred to as open source software. And it's really means that a code or a software is designed to be publicly as accessible anywhere. And you can use it, you can modify it, you can distribute it and use it as long as you abide by the license that is attached to the open source software. When you think about open source, it's actually different from when you consider free software. So it's not really free, but it's open for you to use. And comparing this to another kind of software, which is a closed source software, closed source software is a privately owned software that cannot be modified or used publicly.

So, open source currently is very, very interesting as a community and also as a specific area in tech. Open source means that developers or people in tech come together in the open to collaborate and share and build software that provides value to us as developers. A lot of software and libraries are currently open source. I could give you some examples. For instance, you know about popular Vs Code. Vs Code is an open source software. There is another example, like View and React. These are all open source software that you can modify the code. You can contribute to them. You can use them as you would want. And going forward, there are some reasons why you might consider contributing to open source.

As a developer or a designer, regardless of what specific area in tech that you are in. I know that a lot of people that joined this webinar might be developers. But I just wanted to point it out that open source is not specific to only developers, I should just put it that way. So are you thinking about contributing to open source, but you're not set in what you would get out of it? I would like to share with you some reasons why I feel like open source is a beneficial thing for you to get into. The first obvious reason here is it helps you view the tools that you love using. So I mentioned already two open source software that are popular, that a lot of us use for our day to day activities like VS Code, MPM, or if you're a JavaScript developer, React or View. So if you enjoy using these tools and you feel like you want to give back to the community, and I think contributing back to the projects is one way you can, is one thing you can get out of contributing to open source, because you enjoy using the two and you want to give back.

Another reason is it helps you improve and grow your skills. This could be your technical skills or your soft skills. And I'll explain why. A lot of times, if you are a developer in this case, you learn a lot from reading the source code of the tool or the software that you use. A use case could be that you are, if you just developer like I am. And I really want to learn more about the language. I just want to learn. I just want to up skill in that area. One way you could actually do this is by checking out the source code of the language they actually write in. Sometimes it might be overwhelming because as a beginner, you might not even know what is happening in the code base. But it really helps to just check it out sometime and learn from other people that are, when you check out issues, check out conversations that happen in the projects, you get to learn a lot.

Another thing that I've seen a lot happen for me in regarding to open source is, while I'm working on a specific program or a tool, a lot of times when I find that I am trying to fix the problem, the first thing that comes to mind for me is to go to the projects and check the issues. Because, a lot of times people already have the problems they are trying to fix and they've already reported it to this project. So, that's another way you can benefit from open source I would say. It helps you learn a lot about the program that you're using. It also helps you grow your tech skills. And an addition to that is it helps you with other skills like communication wise. So if you're contributing to a project, you have to communicate, right? You have to share, or basically talk about the contribution you want to make. So if you're looking at improving your soft skills, like communication, collaboration with other people, then this is also something you can get into.

Another reason is it helps you to find mentors and also teach others. I've learnt a lot from people that I follow in the open source space. Even if I don't call them like my one-to-one mentor, I think I've learned a lot from a lot of developers that develop in the open source space than I have ever learned from reading books. Because when you follow these maintainers or even contributors rights, they are always sharing what they are doing. If they're working on this specific thing and you follow them, for instance, on Twitter, you'd always see what you're working on. Or you follow them on GitHub, you can always follow the things that you're also working on. If you're also interested in teaching people, open source is also one way you can do that. And I'll explain it further in the coming slides.

Lastly, it helps you build a professional network for yourself as well as a portfolio. Right now, I think GitHub is now becoming one of an essential for your developer resume. A lot of times when you apply to jobs, you always see that they are asking you to put in your GitHub profile link. Why are they asking you that? Because the company or the recruiter wants to get a sense of your previous contributions, if you've contributed, or just see the kind of technical skills that you say you have on your resume. And what even puts your foot at the door is when you find that by checking your GitHub profile that you already contribute to open source. That's another interesting way. And generally it also helps you build a professional network. Because, in the process of being part of the open source community, you're getting to meet more people, you're getting to network with more people. So I think those are some reasons why you should consider contributing to open source.

So, now that we've covered the reasons that you should contribute, why or how can you actually go about contributing to open source? I think one popular thing that people tend to relate open source with is, once you are contributing, then obviously you're going to be contributing code to an open source project. That's this definitely true, but I'll also share with you other ways that you can actually contribute to open source. Open source can be done in so many different ways. You're not just locked into contributing code, changes of code features to a projects. The main goal of contributing to open source is that you are improving the projects or the software that you're contributing to. And, you're also creating value in one way or another.

I already mentioned one way to contribute to open source is via contributing code. So you can make code contribution to a software or a tool that you really enjoy using. You can raise issues. So if you find that you're currently experiencing a weird bug, that's it's important for people to know about it or the maintainers to know about it. You can raise an issue on the GitHub repo of the set projects, or you can actually contribute features. Or, sometimes there are a lot of open source project that have specific tags for new contributors. So, those are the issues that if you're interested, you can pick up. And a lot of times this community or this project have guidelines for contributing that can be helpful for you. So, one way of getting into open source is through contributing code.

Another way is by design, so true design. So if you're a designer, you're also welcome in the open source space. Design in open source is another untapped area. I feel like a lot of projects really needs the eyes or the work need a presence of a designer in the projects. For instance, you're building out the project, you are basically a developer. A lot of the contributors in the team are developers. And you want to create logos or creative style guide or just do user research. This is when the help of a designer is needed. So if you're a designer and you feel that you don't have anything to contribute to open source, that's not true because you actually do. So, there are a lot of projects that require the expertize of a designer as a contributor. So that's one way you can participate.

Another way is should community building. And I think this is also another great way of how to get into open source. So, there's a community behind every open source project. If you really think about it, MPM, JavaScript, PHP, every single open source community has it. Every single open source project has a community backing it, right? And how do you contribute? You can contribute by answering questions on Stack Overflow. The issues on the repo, you can put in your own suggestion or just answer some questions that you feel that you can answer. Or, just putting your own suggestions on Discord or Slack, depending on the community that they have. You can always participate in that. Apart from answering questions, you can also write articles about the said software or open source project. So if you find that you learn something new or you have a fix to a particular bug that a lot of people are also having, you can write an article about that. That's also counts as an open source contribution, if you think about it. Speaking at conferences, organizing workshop conferences for the specific projects also counts as open source contribution.

And finally, this is another part, I would say this is backbone of any single projects. There's a term that says writing documentation. If your project does not have a good documentation, then it's not really a good project, right? Because documentation helps people, helps developers onboard and use the projects. And if it's not well written, then it's not going to be a great experience for developers trying to use it. So one way you can actually contribute to open source is true documentation. And a lot of projects are looking for help with documentation. When I did my first contribution, I actually contributed to documentation. So I think there's a lower barrier to entry there than if you're looking to create and contribute to a code base directly. So, you should definitely look into these areas that I've shared, contributing to code, community beauty, documentation, documentation. And I also shared design. So if you're a designer, you should also consider. These are several ways that you can contribute to open source.

Now you've learned that there are more ways than one to contribute, and maybe now you're ready to make your first contribution. Or, if you've already been making contributions before now, you even want to contribute more. There are a couple of things you should keep in mind, and I'd like to share that with you. So how do you go about making your first contribution? Sometimes for beginners now it can be overwhelming because fine, you know a project you would like to contribute to, but you don't know where to start from. So I'd like to share some pointers or things you should have in mind when you're trying to make your first contribution, or you're trying to contribute to projects for first time.

The first thing of course is for you to find a project you'd like to contribute to. And this is quite interesting because there are a lot of platforms that helps with this. I'll share some of them later in the slides in case you're looking for a project that you'd like to contribute to. And for some people they would peak that they want to contribute to your project that you use every day, right? So if you're using a tool every day, you might decide you want to do that. Or you could also look at platforms that have bugs and fixes from different projects and that are looking for first time contributors. So if you've not made a contribution before, and this is your first one, I recommend checking out some of these resources that I have here. So this would help you to find a project that you would contribute to.

Now, once you found the projects you want to contribute to, the next thing you should consider doing is to understand the structure and the setup of the project. If possible, try to clone the project, try to just look around and see if they have a Read Me, if they have a contributing guide, if they have a code of conduct. You should definitely check out all of this and get as much context required as possible before actually making a contribution. Because it would not be nice if you find a project and the first thing you do, maybe you see that there is an open issue and you can fix it. And you just open a pull request without reading the contributing guide. And then they have a process already laid out and you did not follow that process. That's not a good way to start, right? So it's very important for you to look up the contributing guidelines, the read me, the license that they have and so on. It's quite important. Also familiarize yourself with the processes used in the project. A lot of projects have a well-documented Read Me on how to set up the projects locally. You can try doing that. Or you can just read up on, they also have a fully documented contributing guideline. You can also read that.

Finally, now that you familiarize yourself with the projects, this is when you can start browsing through the issue tracker to figure out where help is needed. Or, if you already have something in mind you want to contribute, maybe creating an issue about seed first before actually contributing to the code would make sense as well. So, the issue trackers of some projects are well-documented with tags, labels on specific things. For instance, there is a label called Help Needed. So you can search for that and see if there is a specific thing you can actually contribute to. So those are some things you should consider when you want to make your first contribution.

In the process of contributing to open source or just being part of the open source community, it's very common to have conflicts or just have awkwardness happen in the process of contributing. So how do you avoid this from happening? A lot of times, when you think about open source, open source is a wide community of people. People from different continent, they have different backgrounds, different life experiences. And you're trying to communicate to these people. You have to have it's in mind that they are not like you, right? So how do you avoid conflicts in the process of contributing to open source? I think the formal thing for you to think about when contributing to open sources, it's not just about the projects. There are people behind the project as well. So when you think about dealing with people, two things comes to mind for me. First, you should always try to have clear communication when you're communicating with contributors or even maintain on a project.

A scenario could be the you're trying to improve a specific area of the documentation. And you have like a better idea of how it should read for, especially you as a new person using the projects. Instead of going forward with what you think is the best possible improvement for that, it would be nice to actually have a conversation. Open the pull requests you want to open about the specific area, but also give context to why you are changing a specific area of the docs. It makes sense to do that, right? So they know where you're coming from and why you want that change to happen. Clear communication could also happen in areas where you're actually having conversations about probably you get a comment on a specific [inaudible 00:20:16] that you raise, or you get a comment, or you comment on somebody's PR. Or, there is an issue that you made a comment on. Always try to make sure that for every single communication that you're making, it's actually very clear. When you think about communication in the open source space, a lot of it is non-verbal right? And context could be lost in the process. So one way to avoid conflict is make sure that you're communicating in a very clear and succinct way.

Another thing to also consider is to treat people with equality and respect. Like I said earlier, first think about the people. There are actually people behind the projects and not just... We are all human. So when you're communicating or when you're contributing to a project, you should also remember that people are behind this project. If you're trying to make a case for a specific thing, or you want to talk about something, just try to think that you're talking to somebody. So be sure to treat them with respect. Be sure to be polite. It's very important. And yeah, those are some ways that keeping in mind these two specific things, you can definitely avoid conflicts in the process of contributing to open source.

I'd also like to share with you some tips on how to make meaningful contributions. The first tip here is, I've said this a couple of times already, but is just to show that it is actually very important is for you to read issues on discussion. So if you find a project that you really enjoy, or you like, and you like to contribute to it, but you don't have a specific thing you want to contribute to yet. I would advise you first watch the repo. So on GitHub, there is this setting where you can watch a repo and you get updates on what's happening in the project. Or, you'd spend some time reading issues. Right no,. GitHub also has something called top discussion that some project has, and this allows developers as well as maintainers to have discussion about, for instance, new features coming to the project or existing features and so on. It's important for you to be engaged there. So read issues, be part of conversation in the project.

Another thing is when you are creating a contribution or when you're making your contribution, make sure that you always provide context. A lot of times, for instance, if you're trying to make, I give an example before of trying to improve the documentation, and he just sent the pull request without any description of what you're actually improving. It doesn't give the maintainer the urge to merge it in because they don't know why you decide to make that change in the first place. So for every single contribution that you're making, please try to provide context so they know where you're coming from and why you want to make that change.

For bigger projects, I've seen that they already have a template. So if you're making a pull request, you have to answer some specific questions. For some projects, you have to even sign a CLE. You cannot just contribute, right? So a lot of times there are already processes in place for some projects. But this does not apply to every project you may want to contribute to. So just having it in mind that when you contribute to a project, it's very important for you to provide context on what's the change you're suggesting is all about. Another thing that will help you in this process is to always remember to be kind. Like I said, there are people behind the project. So when communicating with other contributors or maintainers, be kind to them and communicate in the best way possible.

Finally ask as many questions as possible. If you find that you don't understand what's happening, there are no stupid questions. There is no question that is irrelevant, rights? You might not understand something, but somebody else understands it. Even regardless of if you're trying to contribute to the project, maybe you're working with the tool itself, and you find that you don't understand a specific part. I think it's important to ask questions. So you could just raise an issue in the project or search. A tip that I've learned over the years is the first thing, a lot of people go to Stack overflow, but you can also go to the GitHub issue and search. Because, a lot of times you find that your problems are already encountered by other people and it's all in the GitHub issue. So it's important to always ask questions.

And now this area is specifically for maintainers. As a maintainer, how do you make your projects more open and welcoming for contributors? There are some maintainers have real impact in shaping how the project goes, right? And when they put in efforts to make sure that the project is actually open and welcoming to new contributors, I think that's already a great process in place, right? Being a maintainer, how do you create a space where contributors can feel welcome? There are several different things that you can do. I've highlighted a couple, but specifically for new contributors, it's very important to have useful documentation. Document, for instance, how to set up the projects in your local computer. Or, what's the history of the project is like. It's important to have useful documentation because this helps you understand the background of the projects when help is needed. And you as a maintainer already have context because you've been there from the beginning of the project. So is important to have this documented somewhere as well.

Other reasons why I feel like it's important. I'll go further now. I already talked about writing useful documentation, which is good. Another thing you should consider as the maintainer is to organize the issues. I've said before that the issues in a repo is quite important because a lot of things are put in there literally everyday. As a maintainer, it's also good if you can try to organize the issues. I've seen some open source projects have a roadmap. This is actually very nice, and I've started seeing more people doing that in their projects, or labels. You can create labels for issues. If, for instance, first timer, if you want to welcome new contributors to your projects, you can tag some issues as first timer issue. Or you can tag some issues as help needed. For designers, you can tag some issues. If you need specific help with documentation, tagging them in a doc or documentation would help more people find those issues and work on them, or just contributes to them, right? So it's important to organize issues in your projects.

It's also important to be kind in code reviews. Now, a lot of times people contributing to your project, it could be the first time that you're contributing, right? And this is your first contribution. You don't want to scare them away. So you have to be very kind in code reviews. I've seen some situation where people try to contribute for the first time, but they feel they were not embraced into the community and they decide that they don't want to contribute to open source again. That's already a bad experience and we don't want to do that to new contributors or contributors in general, to be honest. So, always be kind in your code reviews. When communicating with other contributors, be kind to them, show empathy and communicates in the best way possible.

Help onboard new contributors. This also is important. It's important that every single open source project that's looking for contributors to already have a contributing.md file in the projects, and it should be well documented. It could be that you have already set up process for onboarding new people, or you have a specific process for running the projects. All of this should be documented in the contributing guide. And if you have a specific way of creating PR, tagging issues, a lot of that should already be documented. So, new contributors can read up on that and have context on how they can actually make a contribution to the project.

And finally, it's also nice to see maintainers engaged with the community. For some projects that I'm involved in, what makes me happy is when I see some of the maintainers, when I can actually find some of the maintainers, for instance, giving talks, having conversations or discussions in the projects. This also helps a lot to give people the interests because they find that your community or your project is welcoming, right? So it's important as a maintainer to engage with the community. It might be a lot. You might not have the time to. But, for instance, speaking at conferences about upcoming release is also a nice way to engage with the community. Or, having live chats, or sometimes community calls. I've seen some projects have a weekly community call where they engage with the community. So yeah, community is also part of the project. So you should always engage with them.

Making a open source contribution can be rewarding. For me personally, I find that it has helped me a lot in my career, in my learning journey. And it allows you to give back to the community. It also allows you to be part of something better, or part of something bigger than you think. And in the beginning, I said in the beginning, you might think that it's a daunting experience, it's intimidating. You don't have anything to contribute. But, I hope with some of the things that I've shared, you can already see that there is a space for you in open source. And there is actually something waiting for you to contribute to.

And to summarize all the points that I shared during the stalk I shared what open source is, why you should contribute, how to make your first open source contribution. I also shared with you how to avoid conflicts in the process of contributing. I shared tips to finding and making meaningful contributions. And for maintainers, how you can make the process more open and welcoming for contributors. I also would like to share with you some resources that I find are very helpful for you if you're thinking about looking into this more and getting your first contribution in. I'll definitely recommend you check out some of these first timers only, specifically the [inaudible 00:32:06] guides to contributing to open source. It's like a very large resource for everything you need to learn. For everybody that's here watching this. I hope with everything that I've shared, you are more interested in contributing back to open source. It's actually a rewarding experience. And from my perspective, I feel that it's something you can definitely benefit from. So if that's an interest of yours, definitely give it a try.

Josh Ruggles:

Thanks for listening to All Hands On Tech. To see the show notes and more info, visit pluralsight.com/podcast.