My First Hacktoberfest — Experiences of Contributing to Open Source as a First Timer

As a software developer, contributing to open source projects had always been on my bucket list. It‘s a great way to collaborate with other developers, hone your skills, and give back to the community. But as a newcomer to open source, I found the prospect of making my first contribution quite daunting. Where do I start? How do I find projects to contribute to? What if my code isn‘t good enough?

This past October, I finally took the plunge and participated in my first ever Hacktoberfest. If you haven‘t heard of it before, Hacktoberfest is a month-long celebration of open source, organized by DigitalOcean. Essentially it encourages developers to make at least 4 pull requests to public repositories on GitHub during the month of October. In return, you get some free swag like a cool t-shirt.

For me, Hacktoberfest provided the perfect motivation and structure to venture into the world of open source contributions. I had been putting it off for a while, but the time-boxed nature of the event and low barrier to entry finally got me to take action. And I‘m really glad I did! In this post, I‘ll share my experiences and lessons learned from contributing to open source for the first time through Hacktoberfest.

Finding beginner-friendly issues

One of the hardest parts of getting started with open source is knowing where to begin. With countless public repositories out there, it‘s easy to get overwhelmed. I found that the key is to look for projects and issues that are specifically flagged as being welcoming to new contributors.

On GitHub, repositories will often use labels like "good first issue", "first-timers only", "up-for-grabs", or "beginner friendly" to indicate issues that are suitable for developers just getting started with open source. There are also sites like up-for-grabs.net, FirstTimersOnly, and GitHub‘s Hacktoberfest issue search that aggregate these types of issues across projects.

So I began my Hacktoberfest by scouring these resources and finding a few issues that matched my skill set and piqued my interest. For example, I came across a JavaScript project that needed some help improving its documentation and adding usage examples. As someone who loves writing and explaining code, it seemed like a great fit for my first open source PR.

Learning the contribution workflow

Once I identified the issue I wanted to work on, the next step was to actually make the contribution. If you‘re new to open source, the logistics of submitting a pull request and going through the review process can seem foreign compared to your normal development workflow.

Here‘s a simplified version of the steps I followed:

1. Fork the repository containing the issue to my own GitHub account
2. Clone my fork of the repo to my local machine
3. Create a new branch for my changes (e.g. git checkout -b improve-docs)
4. Make the necessary code/doc changes and test them
5. Commit the changes (git commit -m "Improve docs with usage examples")
6. Push the branch to my forked repo (git push origin improve-docs)
7. Open a pull request from my branch to the original repo
8. Engage in discussion and respond to any requested changes
9. Once approved, the PR gets merged!

It took a bit of practice, but I eventually got the hang of this flow. Using clear and descriptive names for branches and commit messages, keeping changes focused, and being responsive to feedback were all key to getting my PRs merged smoothly.

Baby steps – my first merged PRs!

Following the process above, I submitted a few documentation improvements as my first couple PRs. One added a code sample and explanation to the readme, while another fixed some typos and unclear wording. The maintainers were very appreciative and welcoming to me as a new contributor, which gave me the confidence boost I needed.

Were these massive, groundbreaking changes? No, not at all. But they were still meaningful improvements that made the project more accessible and useful. And more importantly, I was learning the ropes of contributing to someone else‘s codebase for the first time.

As I got more familiar with the workflow, I started to venture beyond documentation and look for opportunities to contribute actual code as well. Nothing crazy, just small enhancements and bug fixes to continue building my skills and reputation in the community. Each PR I submitted gave me a little burst of excitement and sense of accomplishment.

A different kind of contribution

One of the great things about Hacktoberfest is that contributions don‘t necessarily have to be code. You can also participate by writing guides, improving tutorials, creating example projects, and other educational content.

In fact, one of my favorite contributions was writing a tutorial article for freeCodeCamp‘s open source guides repo. If you‘re not familiar with freeCodeCamp, it‘s an amazing community that provides free online courses and resources to help people learn to code. They also maintain a crowdsourced collection of guides on various programming topics.

Browsing through their guides repo, I noticed they didn‘t have any content yet on building chat bots – which is a topic I happen to have some experience with. So I decided to fill that gap by writing a comprehensive tutorial on creating a simple chat bot using the Botkit framework.

The process of contributing to the freeCodeCamp guides was incredibly streamlined. I simply forked the repo, created a new markdown file in the appropriate directory, wrote my tutorial content, and submitted a PR. The freeCodeCamp team was very supportive and even featured my guide on their main site which was a huge thrill.

While it wasn‘t a code contribution, I found writing that tutorial to be incredibly fulfilling because I knew it would help other developers learn something new. And that‘s really what open source is all about – freely sharing knowledge to empower others.

Lessons learned and advice

Looking back on my first Hacktoberfest, I‘m grateful for the experience and proud of what I was able to accomplish as an open source newbie. More than anything, it gave me the confidence to know that I can make meaningful contributions to projects and be an active participant in the community.

If you‘re on the fence about getting started with open source yourself, here are a few tips I would give based on what I learned:

• Don‘t underestimate the value of small contributions. Every little bit helps, even if it‘s just fixing a typo or adding a code comment. The key is to start building your comfort level and reputation.

• Look for projects and issues that are specifically tagged for beginners. This signals that the maintainers are willing to guide you and answer questions as you get up to speed.

• If something in the project is unclear or you‘re unsure how to proceed, don‘t be afraid to ask! Maintainers would rather have you ask for clarity than submit a PR with incorrect assumptions.

• Try to keep your PRs focused on one specific thing. It‘s better to submit a few small, targeted PRs than one massive change that touches many parts of the codebase.

• Write clear descriptions and titles for your issues/PRs. Explain the problem you‘re solving, the approach you took, and any open questions you have. This context is crucial to help maintainers review your submission.

• Be open to constructive criticism and feedback on your work. It‘s an opportunity to learn and improve. Don‘t take it personally if your first few PRs require a few rounds of revision.

• Remember that contributing to open source is as much about communication and collaboration as it is about code. Be kind, respectful, and empathetic in your interactions.

Onward and upward

In the end, participating in Hacktoberfest was an incredibly positive and educational experience for me. I‘m grateful to all the maintainers and reviewers who took the time to guide me and help me improve, as well as to the Hacktoberfest organizers for motivating me to finally take the leap into open source.

My Hacktoberfest t-shirt arrived a few weeks later and I wear it with pride. But more valuable than any physical swag are the lessons I learned, relationships I built, and satisfaction I got from giving back to the community in my own small way.

If you‘re a developer who has been considering contributing to open source but hasn‘t yet taken the plunge, I highly recommend using future Hacktoberfest events as a catalyst. Trust me, it‘s a lot less scary than it seems! Just remember to start small, ask questions, and be open to learning.

I know my open source journey is still just beginning, but I‘m excited to continue building on the momentum from my first Hacktoberfest. I‘ve already scoped out a few more issues to work on and hope to keep growing my contributions from here on out. Thanks for letting me share my story and happy coding!