BoredomBusted — Find Your Next Favorite Thing To Do
Discover hobbies, activities, places, and ideas that spark joy. Whether you're looking for something creative, active, social, or relaxing, BoredomBusted helps you find your next favorite thing to do.
Browse our hobby guides, things-to-do collections, and place ideas to never be bored again.
Open source isn't just about coding; non-coding contributions like documentation and feedback are in high demand and uniquely enhance your skills and visibility.
Getting started with open source contributions as a beginner involves writing, fixing, or improving software that anyone can see, use, and build on.
You find a project on platforms like GitHub, make a change, and submit it for review by the project's maintainers.
Unlike personal coding projects, your work ships into real software used by real people – sometimes millions of them – the same week you submit it.
In open source contributions, you browse public repositories on platforms like GitHub, identify issues or enhancements, write code or content changes, and submit them for community review through pull requests, engaging in tasks such as debugging, local testing, and drafting documentation.
This hobby fosters a flow state through clear goals and immediate feedback, allowing contributors to immerse themselves in meaningful challenges, while also providing a sense of accomplishment and social belonging through community interactions.
You think open source means writing code for free software you've never heard of.
You picture a Linux kernel patch, a GitHub profile full of green squares, and a CV line that impresses nobody at a normal job interview.
That assumption is costing you one of the most practical skill-building loops available to anyone with a laptop.
Most open source projects are desperate for non-code help. Documentation, bug reports, UX feedback, and translation work are perpetually backlogged because every developer wants to write features, not README files.
The real value isn't the merged pull request – it's the feedback loop you can't get from solo projects. Real reviewers, real standards, real people telling you when something doesn't work.
Open source contribution is one of the few hobbies that builds a verifiable public record as a side effect. Every comment, fix, and discussion thread is timestamped and searchable.
Django's documentation project – one of the most active in Python – merged 47 documentation-only contributions in a single month last year.
The contributors weren't senior engineers. They were people who'd just learned Django, hit a confusing section, and fixed it.
That's the entry point: you already know where the gaps are, because you just fell through one.
You're probably wondering what "getting started" actually looks like on day one – not in theory, but open-a-browser-tab practically.
Merging a pull request looks so clean: a comment, a fix, a green checkmark. All done in minutes. Your first session won't feel like that at all.
You'll begin feeling baffled by the codebase. Half a dozen tabs open, and even the README seems like a mystery. The empty terminal cursor blinks back at you relentlessly. Imposter syndrome kicks into high gear.
Your first week will be mostly reading – understanding the codebase, skimming the contribution guide, scrolling through closed issues. Your contributions might seem nonexistent, but this stage is both normal and critical.
In the second week, you stumble onto a "good first issue." You might get the scope wrong, yet this back-and-forth teaches more than any tutorial ever could. Growth happens in missteps.
Projects tagging both "good first issue" and "help wanted" offer real entry points for newcomers. Beware of those tagging only "good first issue," as they might go months without updates.
The repository is enormous and the codebase unfamiliar. Doubt creeps in as you question whether your contribution matters. It does. Experienced maintainers remember being where you are, and they'll appreciate your effort.
When to start: Morning
Duration: 1 hour
Cost to try: $0
Success criteria: If you got a beginner-friendly repo running locally and submitted a pull request for one typo or small fix, do session 2.
Big-name repos can impress but trap beginners in unfamiliar codebases. Choose a project you already use or have debugged. Knowing what's broken gives you a real advantage.
Most skip the contributing guide and face PR rejections over small errors. Read it before coding—many maintainers ignore PRs not following their rules.
Feature PRs on unfamiliar codebases often get rejected. Look for issues labeled as good first issue, docs, or test coverage. Small, scoped contributions are what actually get merged.
Search open and closed issues before posting. Closed issues often have the information you need and stop duplicates from being closed instantly.
Comment on the issue first and check if it's free. Wait for a response to avoid duplicating someone else's effort. Two sentences now can save a weekend's work.
Open source contributions happen anywhere with a laptop and internet. The "venue" is the repository itself. For a change of scene, coworking spaces and public libraries provide focus and community energy.
The fastest way to dive in is through local meetups. Search 'open source meetup ' followed by your city on Meetup.com. Focus on 'Tech' groups that host hackathons or contributor nights.
The GitHub community events page, found at github.com/github/community, lists local and virtual events. These are often tied to real projects you can contribute to.
In October, search for 'Hacktoberfest local event ' followed by your city. Digital Ocean hosts an annual contributor drive creating in-person events worldwide.
Find your nearest Code for America brigade at brigade.codeforamerica.org. These structured local groups work on civic tech projects together.
The Open Source Initiative at opensource.org is your go-to for licensing standards and community programs if you are searching for broader guidelines.
At any meetup, introducing yourself with something like, 'I'm new to contributing – I'm familiar with [language], but I haven't submitted a PR yet,' will help you get guidance to start on the right path.
Solving small, scoped bugs is the easiest entry point. You learn how a project works without risking major errors. Fast feedback helps you grasp project details quickly, even if you haven't explored the entire codebase.
Documentation is about writing, not coding. You fix typos, clarify guides, and improve instructions. These contributions merge quickly and are always in demand, making them perfect for beginners wanting visibility without code contributions.
Pick up feature requests and create them end-to-end. It's what many imagine when they think of open source. You'll handle bigger scopes and longer reviews, and you'll need a firm understanding of the project's architecture beforehand.
Design contributions like wireframes and usability feedback are rare and valued. Many projects suffer from weak interfaces because they're designed by devs who aren't designers. Your design skills fill a crucial gap and stand out in a field overflowing with code.
Managing your own fork or spin-off gives you full control. You adapt an existing project to suit unique requirements, handling every update and security patch yourself. It's suited for those who need a project to evolve in ways the original won't.
If you want a related angle, Scripting and Automation is the natural next stop.
If this resonates, Cybersecurity explores a similar direction.
For something adjacent, see Speed Reading.
Most beginners spend months hunting for the "perfect" first issue – something small enough to not embarrass themselves. The real bottleneck isn't finding work. It's not knowing how to read a codebase you didn't write.
The one skill is codebase archaeology – the ability to trace unfamiliar code backward from behavior to cause. Not reading docs. Not cloning the repo and running it. Actually following the chain: this broke → this function called it → this config controls that → here's the real problem.
Once you can orient yourself inside a stranger's codebase in under 30 minutes, the "good first issue" label stops mattering. You can contribute to almost anything. Without it, you stay stuck in beginner-tagged issues forever
Commit to 6 sessions over 30 days – roughly one sitting every five days. That's enough time to push through setup challenges, make a genuine attempt at contributing, and experience how demanding the work gets. Doing less means you're only capturing first-day confusion.
You're consistently checking GitHub when you should be focused elsewhere. That's more than curiosity – it's an indication you're hooked. A project has captured your interest, and the pull request process feels like a puzzle you're eager to solve. Shift to a weekly routine and dedicate 90 days to one project.
You went through the sessions but felt lukewarm. This often suggests the project was not the best fit, not the hobby itself. Try with a codebase tied to something you use every day before dismissing it altogether.
Each session felt like a battle, and you stuck with it out of a sense of duty. This isn't about lacking productivity. If reading documentation feels like torture and feedback waits make you anxious instead of curious, this feedback loop may not be for you. It's okay to accept that.
You're reading release notes and can't shake the thought, I wonder how they built that. That's more than a passing thought – it's a persistent curiosity. This curiosity is what keeps contributors going despite ignored issues and nitpicky reviews. Without it, the work may feel like an unpaid homework assignment.
Unpredictable schedules and tiny focus windows make this hobby tough. Substantial contributions need at least 60–90 uninterrupted minutes to maintain context. If written, slow communication frustrates you, reconsider this path. Also, if you crave instant results for motivation, look elsewhere – PRs can linger, maintainers may go silent, and recognition often comes sparingly.
For quicker fixes, see our roundup of things to do when you're bored.
No — open source projects welcome contributors of all skill levels. Many projects have beginner-friendly issues labeled 'good first issue' or 'help wanted.' You'll learn by doing, and experienced maintainers are usually happy to guide newcomers through the process.
Start with platforms like GitHub, GitLab, or SourceForge where projects are hosted and searchable by language, topic, and difficulty level. Look for projects you already use, care about, or that align with your interests — this makes contributing more enjoyable and meaningful.
Open source projects need documentation, bug reports, design, translations, and community support — not just code. If you're not ready to code, you can help by writing guides, testing features, or answering questions in forums to build experience and value.
It depends on the project and contribution scope. A small bug fix might take an hour or two, while a significant feature could take days or weeks. Most projects let you work at your own pace, so you can start with small tasks to get comfortable.
Yes — contributing itself is free. You don't pay to work on open source projects or use them. Your only 'cost' is your time, though you gain skills, portfolio material, and community connections that benefit your career.
Most projects use version control (like Git) and require you to fork the repository, make changes, and submit a pull request for review. Each project has contribution guidelines — read the CONTRIBUTING.md file first to understand their specific process and standards.