Last-minute guide to Hacktoberfest (there's still time), featuring GitHub Star Of The Year, Eddie Jaoude

Last-minute guide to Hacktoberfest (there's still time), featuring GitHub Star Of The Year, Eddie Jaoude

The month-long celebration of Hacktoberfest is nearly over but don't threat! There's still time to get involved and potentially earn a Hacktoberfest T-shirt. In this episode, GitHub Star of the Year 2020, Eddie Jaoude shares everything you need to know to get involved in these remaining days.

Who is Eddie? Eddie Jaoude is an open source advocate and leader of the EddieHub open source community. He believes OPEN SOURCE is NOT just about code, it is about people, communication and collaboration.


  • Introduction (00:00)
  • What is Hacktoberfest (01:13)
  • Is it too late to get involved? (01:50)
  • Open source can catapult your career as it did for Eddie (03:02)
  • Genuinely meaningful ways to contribute to open source that don't even involve writing code (07:10)
  • Where to find your first open source project (09:21)
  • How Hacktoberfest measures your contributions (14:32)
  • "It's always about adding value, not amount of lines that have changed" (15:43)
  • Challenges you might encounter and how to overcome them (18:52)
  • Maintaining your own project and taking part in Hacktoberfest (20:23)
  • Quick-fire questions with Eddie Jaoude (22:35)


Alex from Scrimba (00:01):
Hello, and welcome to the Scrimba Podcast. On this weekly show, I speak with successful developers about their advice on learning to code and getting your first junior developer job. Have you heard of Hacktoberfest? It is an annual event that runs through October, and encourages you to contribute to open source projects. Since October is nearly over, you might be thinking it's too late to get involved. I'm here with special guest, Eddie Jaoude, to assure you there's still time.

Eddie Jaoude (00:29):
Even if it is the last few days of Hacktoberfest, you can still do it. It needs four pull requests that add value to any project. And remember that open source is not just for Hacktoberfest. It is all year round.

Speaker 1 (00:42):
Eddie's mission in life is to help people contribute to open source. It's the basis of his community, EddieHub, and the reason why he was officially recognized by GitHub as their star of the year in 2020. In this episode, you will learn how Hacktoberfest works and how to make your first contributions. Eddie started his open source career very humbly, fixing typos. Now he's the GitHub star of the year. You are going to learn from the benefits of all his hindsight. So let's get into it.

Eddie Jaoude (01:13):
Hacktoberfest is a month long excitement and energy towards open source. And the idea is, if you contribute four pull requests or more that add value to a project, you get a t-shirt or you can plant a tree. And I've been pushing this year for hopefully more people to plant a tree. And the way to get involved is, you register on the Hacktoberfest website. It's run by Digital Ocean. And it keeps track of the pull requests that you make. And your pull requests have to be valid pull requests. So they have to be merged and accepted. Or if they haven't been merged and accepted, if they get given a label Hacktoberfest accepted, then it still counts.

Speaker 1 (01:50):
We'll be releasing this episode towards the end of October and the end of Hacktoberfest. Do you think it's too late for people to get involved or is there still time?

Eddie Jaoude (02:00):
There's definitely still time, but as we were discussing before we hit record, it is a marathon, not a sprint. So I think a lot of people get very excited at the beginning and do their four pull requests on the first day. And then other people do their four pull requests on the last day. To be honest, if people want to make the most out of open source that can help you with not only learning faster, growing your network, getting the career and job that people want, then you really do little and often, a bit like brushing your teeth, is what I always say.

Eddie Jaoude (02:31):
So it's not too late. Do get involved. Even if it is the last few days of Hacktoberfest, you can still do it. It needs four pull requests that add value to any project. And remember that source is not just for Hacktoberfest. It is all year round. And I think it is important for people to continue. It's a shame to see people get this new skill, this new motivation and not continue it. And I really hope this year, we can encourage people to continue into November, December and into 2022.

Speaker 1 (03:02):
Although the t-shirt or the concept of planting a tree is exciting. That might not be the purest motivation to contribute to open source. There are so many more reasons and benefits to do it. What are the reasons you are so excited about open source, Eddie? And why do you think it's so important that everybody else gets involved?

Eddie Jaoude (03:18):
I love this question. This is a great question. So I really believe that open source is not about code. What we say in my community, the EddieHub, there is collaboration first, code second. And really, when someone wants to make a contribution, they raise an issue. And that involves coming up with an idea or finding a bug. And that gets you a green square. And the conversation starts there. And then people, when they want to make the changes, will raise a pull request. And a pull request is effectively like an issue, but with some changes to the repo with it. And I specifically say changes not code, because it could be documentation, it could be automated tests, it could be so many other things. And then once that's been raised, then there's another discussion about the changes. So really, it's discussion, changes, discussion.

Eddie Jaoude (04:04):
And so that's why I love open source because it is really about collaboration. The code is just a side effect of the collaboration that happens. And it's just so great to see people collaborate together and learn so much. I mean, when I interview for my clients, I love to look at people's GitHub profiles. But I don't look at it for the reason that people think. People think I look at their latest code. Is it the best code I've ever seen? That's actually something I don't look at. What I actually look at is two things. One, can they communicate and collaborate with people? So I want to look, how do they raise issues? How do they raise pull requests? Not the changes in the pull requests, but do they explain why they made certain changes? And then I want to see how they comment on other people's changes. That's why it's really important for people to review other pull requests. Even if they're not the maintainer on the project, they can still give their feedback.

Eddie Jaoude (04:53):
And then the second thing that I look for is, I do look at their code. But I'm not seeing if it's the latest and greatest, I'm just looking that is it better than it was three months ago? Is that person still learning? But that's less of a priority because someone can learn tech, they can be taught it, but communication, collaboration is much harder. Does someone have the right attitude? And it's really, really a great way to see how they collaborate with people on the platform. It is a social platform. And so, people should really get involved in the conversation.

Eddie Jaoude (05:21):
And I'm so passionate because where I've got to, people who don't know me, I'm GitHub star, I'm GitHub star of the year. EddieHub just won the GitHub community award for the year. I've done all this, achieved all this, the clients that I want, the projects that I want, I travel the world as digital nomad. I spent summer in Portugal. Then I spent winter in Bali. And the reason I do this is because of the open source work that I've done. It's opened so many doors for me. And I've been doing it for over 10 years. And over 10 years ago, we didn't have Git. We didn't have GitHub. It was a different landscape back then. And so now we've got these great platforms. And I think it is so much more fun for people to get involved with the gamification, with the green squares. And that's how it gets started. And I think people look for the green squares, and then they look for the t-shirt or planting a tree, and then hopefully that sparks their interest and then they want to do more and they want to get involved.

Eddie Jaoude (06:10):
I mean, I have two regrets in my life, in my career. And one of them is not getting involved in open source sooner. So hopefully people don't make the mistake that I did. Although, like I said, it was over 10 years ago, but I wish I started sooner. And the second one, which is kind of relevant, is not learning in public. So sharing my learnings in open source projects, sharing it on Twitter, sharing it on YouTube. That, again, has opened so many doors for me. And I really want everyone listening to understand that it doesn't have to be the best work in the world. And if you are learning, then to be honest, even if you think it's the best today, tomorrow, you won't think it's that great because you would've learned something new.

Eddie Jaoude (06:49):
I look back on my code two weeks ago and I think, hey, what idiot wrote this? And it's me. And it might even be a blog post I've written, or the way I've made a video. We're all always learning. And that's why it's so fun to be in tech. And so, they can learn and grow their network by learning and sharing in public. And I think it's just so important. I wish I started that sooner as well.

Speaker 1 (07:10):
There are just so many benefits, from improving as a developer, learning, practicing. But also, as you say, you're effectively learning in public, leaving a little trail of everything you've done before, a way to measure your own progress and feel motivated, but also show employers that you're serious and that, well, you can walk the walk essentially. It's one thing to show a piece of paper that says you can do it, but why not just show them that you can actually do it. Not just write code, but collaborate on code as well.

Speaker 1 (07:36):
I love the point you made, that contributions aren't necessarily the same as writing code. You can discuss things and GitHub issues. You can contribute to documentation. You can create demo applications. You can be a user that just shares your feedback. And I think that a lot of this happens around GitHub. It's a wonderful platform for these things. And I think there is that allure to only focus on things that give you the green square. By the way, at one point in time, this might be interesting to people, you only used to ever get the green square for creating a commit. But in recent years, GitHub sort of evolved that, didn't they? So you also get green squares for pull requests and for creating issues. And maybe some other things I'm not aware of. Is that right, Eddie?

Eddie Jaoude (08:13):
That is correct. So now also GitHub discussions. So starting a GitHub discussion gets you a green square. And yeah, it's interesting. Because you raise such a good point that it is adding value. We always say to add value, but we don't say add code. Because value could be, has someone raised a bug? Can you confirm that the bug exists on a different platform or different version of the browser or the compiler or whatever's being used? That's also adding so much value. I've known some people in the EddieHub community get job offers from some of my clients and some of the other companies that sit in our discord because they've created demo apps. And they said, "Actually we love the way you've done it. We love the way you've explained it, the way you documented it. Can we pay you to do this more?" And I'm just thinking, that's amazing. And hopefully in the near future, we get to share some names and actual case studies of where this happened. But for the moment, it's a bit on the quiet.

Eddie Jaoude (09:05):
But I love your idea of sharing demo projects, of using certain tools or maybe using them in the way that's recommended, maybe using them in the way that's not recommended. There's so many different ways. And I think it just sheds more light on the area. And I think that's really important.

Speaker 1 (09:21):
Let's talk about some ways that people can find their first open source projects to contribute to.

Eddie Jaoude (09:26):
There are a few ways that I definitely recommend. So one is, people should look at the projects they're already using. So that maybe the libraries, the framework, the dependencies that they're including in their project. That's a really good place to get involved with those projects, because people are already familiar with those projects rather than trying to pick one up from scratch. But if they don't want to contribute to those because they may be very big or very fast. And fast moving projects are quite hard because you might raise a pull request, and then by the time it gets reviewed, by the time you get back to it, there might be some conflicts.

Eddie Jaoude (09:58):
So another way, people can contribute to their friends', their colleagues', their community projects. So we actually have, again in the EddieHub community, we have a channel called Good First Issue. And people can share links to their repos where they have Good First Issues to get people involved in their project. So that's another way. So do join a community. I'm obviously biased. But join multiple communities. I think it's really important. I'm sure Scrimba has lots of open source projects as well.

Speaker 1 (10:29):
We are doing this thing right now where every week at Scrimba we release a challenge and ask people to submit their solutions. And then they all get featured on this webpage that my coworker builds. And she's actually made the website where the projects are displayed open source, and started inviting people to contribute as part of Hacktoberfest. That's really cool. But yeah, I totally echo your point. Be part of multiple communities. The EddieHub sounds like a great place for people in open source specifically. But there's always going to be a little bit of overlap.

Eddie Jaoude (10:52):
There's lots of overlap with communities. And then they all have their focus. That's what I always recommend people to join multiple communities, because you'll get different benefits, different perspectives. And that's really, really important. And another way people can find projects to contribute to is, they can go to the top of GitHub, the bar right at the top, the dark bar. It has issues at the top, an issue link. Click on that. And then it will list the issues that you've created. And then there's these extra buttons, issues that are assigned to you, issues that have mentioned you. And there's a search box next to it. In there, clear all the search items. And people can search for label, colon, Good First Issue. And then they can put a space, and then they can put language, colon and the language they want it to be, Python, Java, Ruby, JavaScript, TypeScript. And it will list all the issues that match those languages and that label of Good First Issue.

Eddie Jaoude (11:44):
And people can put multiple labels. They can put Good First Issue and also Hacktoberfest, if they wanted to. And that's a great way to search the whole of GitHub. There will be lots of results. So the next question people ask me is, how do I choose? If I found like a few projects, how do I choose which one to contribute to? There's a few bonus tips here for everyone listening. Look at the project's code of conduct, look at the license. Make sure it is friendly. You can actually go to the insights tab on the repo and then go to the community link, down the left. And it will show you, have they got issue templates? Have they got code of conduct? Have they got a contributor's guide? Then if they've got ticks along all of those, go have a look at them and see what the project looked like.

Eddie Jaoude (12:23):
And a second bonus tip. Once you've narrowed down the projects you want to contribute to, go to the pull request tab. Go to closed pull requests, and you'll see a list of all the closed pull requests. And some will be closed because they were merged. And some will be closed because they were closed. Look at the ones that were not merged and that were closed. That will have a red icon to the left. Click on a few of those and see why they were closed. If they were closed by the author, that's fine. If they were closed by the maintainer, that's also fine. But check if the maintainer left some helpful feedback why they closed it. Was it a feature they didn't want? Was there another reason? And did they recommend some other issues for that contributor to contribute to? Whereas if it's just been closed with no comment, no feedback, maybe that's not an inclusive project, and maybe there's a project you don't want to contribute to.

Speaker 1 (13:14):
If you are enjoying this episode of the Scrimba Podcast, please do us at Scrimba a favor and share it with your friends on social media. Word of mouth is the single best way to support a podcast that you like. So thanks in advance. On the Scrimba Podcast, we like to bring you a balance of experts like Eddie, as well as newer developers who recently got their first junior developer job. My guest next week, John McKay, AKA Jono in the Scrimba discord community, is one such success story.

John McKay (13:43):
I got offered a position, not as a junior, but straight away just as a software developer, but in the guise of a 20 month training course. So the next 20 months of my life is a training course whilst actually working. They've realized that a lot of the people who tend to go into this industry, historically, were computer science graduates. And they realized that if everyone comes from the same point of education, everyone has the same ideas. And they wanted to break out of that kind of trap.

Speaker 1 (14:14):
Remember to subscribe to the Scrimba Podcast in your podcast app of choice, be that Google Podcasts, Apple Podcasts, Spotify, Overcast, Pocket Casts, even import the RSS feed, if you like. This way, you'll be sure to hear the episode of Jono and support the show.

Speaker 1 (14:32):
There is, on GitHub, the Good First Issue label, which I think represents issues that the maintainers are willing to help you get started right. They might be more patient. They might help you on board. They might even have a really great contributing [inaudible 00:14:46] to help you get started. If you were to participate in Hacktoberfest and get the four merged pull requests that you need to be eligible for the reward, it needs the Hacktoberfest label as well. Is that right?

Eddie Jaoude (14:59):
So either the project needs to have a Hacktoberfest topic or the pull request needs to have the Hacktoberfest label.

Speaker 1 (15:06):
Oh, that's good. So people can look out for that?

Eddie Jaoude (15:07):
Yes they can. And they can filter projects for the topics. But please, people, do not hassle maintainers if they haven't got those labels or topics on their repos. There's a reason why they might not want to participate. Maybe because they just have so many notifications that they don't want to add to that. And it's unfortunate, but still get involved. If you like the project, still get involved in it. And Good First Issues usually have a good description and a step by step guide on what to do to get that issue done. And I highly recommend people do, to maybe start with Good First Issues, but make sure you don't stay on it.

Eddie Jaoude (15:43):
I see some people staying on Good First Issues for months. And they're not challenging themselves any further. Yes, they're getting the green squares, but they're not challenging themselves further. So do make sure you move and challenge yourself to slightly harder and larger contributions each time. And a contribution isn't about the size. I had someone want to contribute to one of our projects and say, "Hey, I'll do the contributing guides. Give me three weeks. I'll make two pages. It'll be amazing." And I was like, "Whoa, whoa, whoa, whoa. Little and often and add value." So it's not the size on the amount of changes in the pull request. I recommended that they create the file and put one line that they could do today. And we'll get that merged in. They said, "Oh, well, it's just one line." I said, "Even if the one line said, any question, please start a GitHub discussion. Or come and chat to us in our discord and provided the link to our discord. That's already providing value, because it's always about adding value, not amount of lines that have changed." And I said, "Well then tomorrow, someone else can now add another line to the contributing file because you've created the file. It's there. People can now communicate and collaborate on it."

Eddie Jaoude (16:50):
Another tip, when you are raising a pull request, if something isn't, say, formatted correctly, or it's not adhering to the linter rules, and you want to reformat those files. Great. But don't put that in a pull request that contains your feature file or your bug fix or whatever it is, because it is important to have pull requests that focus on one thing, I've seen good pull requests with good changes get stuck for months because they've got five other changes in there that are still being discussed. Whereas, the value of those other changes haven't gone in. And it's okay to make multiple pull requests.

Eddie Jaoude (17:24):
Okay? Yes. You don't want to spam the project with one character change in each pull request. But it needs to be focused on a topic. So if you're reformatting various files because they don't adhere to the formatting standards of the project, then that would go in one pull request, if it's one file or 10 files. And then if you're fixing documentation, then that would probably go in another pull request. And if you're adding a feature or fixing a bug, then that would go in another pull request. And I think it's important for people to find that balance between not adding too many pull requests and issues, but then having them focused as well.

Speaker 1 (17:58):
I totally recognize that temptation and that aspiration to want to make an impact and make an impressive pull request. And maybe even feel like you've arrived. Like, look, I'm here. Here's a huge contribution. It's great to have that aspiration. But frankly, it's not only going to overwhelm the most experienced people, but when you're in a position to collaborate with others, it's a lot for them to ingest and process, and then eventually merge. To take your advice, if you make the pull requests and even the commits as atomic or small and singularly focused as possible, it makes it so much easier for the maintainers to then get a good idea of how the code has evolved, how they can integrate it into the main branches, it's now called, and even leave feedback. Because if they are to leave feedback on a humongous pull request, it's just too much. What do you think some of the likely challenges that somebody might face are when they first try and contribute to a project?

Eddie Jaoude (18:52):
For example, one might be, they say the project is quite big, how do they understand the whole project? People shouldn't try and understand the whole project. Usually projects are broken up into modules and then components. And a lot of the time, we just need to understand the changes we are making and the code around that, and the project around that. Hopefully, most projects have automated testing, where people can confidently make a change and then be aware if they've broken anything else in the project.

Eddie Jaoude (19:16):
And also, people like to think, I need to get help. Can someone jump on a call with me? Can one of them maintainers jump on a call with me and help me with this? And a lot of maintainers, I think, used to do that, but then that person would take the value of learning of how to contribute and how to use that technology and then disappear. So if people do want that help, it is there, but you need to add value a lot to the project and the community to get that. So I have some people message me and say, "Hey, Eddie, you jumped on a call with that person and helped them with their issue." I say, "Yes, but that's their 50th issue. And they did 49 issues that added so much value to the project. But now they will want to do something a bit more challenging. I know they're committed to the project so I'm going to give them an hour of my time to pair with them and work on that issue they want to do that's a bit harder and more involved."

Eddie Jaoude (20:01):
And so, if people do want to get that almost like mentoring unofficially kind of situation, then don't try and contribute to a different project every time. Focus on a few projects, and build up that rapport and collaboration and community with the maintainers. And then after some time, if you want to challenge yourself further, then you'll get more help.

Speaker 1 (20:23):
You make some amazing points. And I totally see the value of, I don't mean to make a pen out of it, but committing to a repository, like committing to see it through and becoming familiar with the maintainer and the other contributors. Because you build that depth of knowledge that allows you to move faster. You end up creating more significant contributions over time. Oh man, imagine how great that would be to, one, at first, struggle to contribute. But a few weeks or months, then you can then help someone new contribute to the project. That's a whole topic we haven't delved into, and probably won't have time to today. But another great way to be involved in open source is to actually make your projects public.

Eddie Jaoude (20:59):
As a maintainer, you will understand the flip side. So when someone raises a three word issue and you think it makes sense, and you raise it and you don't understand why the maintainers and community start asking questions, and there's like 30 questions and discussions in this issue. When you're a maintainer and you get the same in reverse, and then you start asking questions and it's back and forth, back and forth, and lots of notifications over and over. You realize that adding context to your issue in pull requests is super important. So the skills needed to be a maintainer is, anyone can do it, but you'll learn so much by doing it and it'll make your issues, your pull requests, be so much more valuable.

Eddie Jaoude (21:39):
And that's another thing I look for going back to when I, say, interview for my clients. Another thing I look for is, are they a maintainer? Most people are a maintainer, whether they've customized their GitHub profile, or they're learning in public. But I also want to see how do they respond to pull requests that get raised on their projects? How do they respond to issues? If they're good or bad, doesn't really matter. But I want to see, do they say, thank you so much, but this is something I'm not doing at the moment. And then close the pull request. That's also fine. But you can tell that that person has that empathy and has an understanding for the effort that's gone into those changes. And it will make their contribution so much better.

Speaker 1 (22:15):
I think we've spoken about so many awesome things in this episode. I hope people listening towards the end of October now feel confident and empowered to go and find a project, contribute to it. Of course, if you need support, it will be there, and the Scrimba or the EddieHub community. I'm also hoping to link everything in the show notes. So if you're looking for something, please check out the show notes. I'll be sure to link it. Eddie, just to wrap up. If you're up for it, I would love to throw you some quickfire questions. What do you say?

Eddie Jaoude (22:42):
Let's try it. Let's do it.

Speaker 1 (22:44):
All right, man. Question number one. GitHub or GitLab?

Eddie Jaoude (22:48):
GitHub. 110%. Sorry, GitLab.

Speaker 1 (22:51):
I mean, what was I expecting? You are the GitHub star of the year. Here's my second question. How does it feel to be the GitHub star of the year? That's an amazing accomplishment.

Eddie Jaoude (22:59):
It was definitely a big surprise. I've got a reaction video on my YouTube channel when they made the announcements. And I was just super surprised. I was so shocked. I'm still shocked now, to be honest.

Speaker 1 (23:09):
Man, you should be so proud. In just one word. How does open source make you feel?

Eddie Jaoude (23:14):
Warm and fuzzy inside? That's not one word.

Speaker 1 (23:18):
It's good. It's good. I'll take it. That's good enough for me. What is the biggest mistake you see new contributors make?

Eddie Jaoude (23:26):
Not reading. It's really strange when I see people ask a question, and you write a whole paragraph. And then they say, "Yeah, but can you answer my questions I have." And then you copy and paste a few words out of your paragraph I've just written. And they say, "Oh, thanks. Great." You're thinking. But I literally just copied and pasted that from what I sent above.

Speaker 1 (23:46):
Finally, Eddie, just to finish up the podcast. Maybe you can take us down memory lane and tell us about your first open source contribution.

Eddie Jaoude (23:54):
Okay. It's going back over a decade. So just to remind everyone that there was no Git, no GitHub, no pull requests back then. It was a very different landscape. You had to sign up for that person's server. And I say server, I didn't say Git server, but it could be SVN or CVS server. Give them the SSH keys, sign lots of forms. It was a different landscape back then. But I'll be honest. My first pull request was fixing a typo. And if I'm going to be super honest here with you and everyone listening, my second, third, fourth, I think fifth and sixth and seventh, I say pull requests, contributions. There were no pull requests back then, were also fixing typos. And I did it for the same project.

Eddie Jaoude (24:34):
And they were so welcoming that I started doing more, and I started adding more code coverage to their project. And I started doing bug fixes, just really small bug fixes. And before I knew it, I found where I wanted to go, where I wanted to spend my time. And I realized it was getting involved in open source and getting others involved too. So everyone, get involved. Any questions, let me know.

Speaker 1 (24:57):
I love that, from very humble beginnings, fixing typos. That could be the person listening to this episode. But a while later, you're now GitHub star of the year. What an amazing transition and an amazing way to end the podcast. Eddie, thank you so much.

Eddie Jaoude (25:10):
Thank you for having me. This was awesome.

Speaker 1 (25:11):
That was Eddie Jaoude. GitHub star of the year and founder of the EddieHub open source community. You can find all Eddie's links, including a link to his community, in the show notes. This episode was edited by Jan Osinovic. And I'm your host, Alex Booker. You can follow me on Twitter, @bookercodes, where I share highlights from the podcast and other news by Scrimba. See you next week.