Casual Open Source Contributions
I am not a regular open source contributor. I have contributed to many projects and I maintain a couple of them, but it's never been a consistent activity for me.
Sometimes I spend several weeknights or entire weekends contributing to open source. And sometimes months go by and I don't contribute to any project. It all depends on my availability, interest, and energy. And it's all okay.
You don't have to give all your free time away to be a useful part of an open source community. You don't even need a regular contribution schedule. In fact, it's common to see developers who have only made a couple contributions in a project's lifetime, and their contributions are still valuable!
If you've been thinking about contributing to open source, but you are not sure if you want to do it regularly, this post is for you. This is a simple guide on how to contribute to open source when you don't have much free time on your hands or simply don't want a long term commitment.
Finding Projects & Problems to Solve
Finding a project to contribute to can be time-consuming and exhausting. If you don't have a specific system, you'll end up asking yourself questions ranging from, "Am I in a position to contribute to this project?" to "Is this a meaningful project?", and it can become complicated!
What project should you contribute to? And even after you find the perfect project: which problem should you solve?
I've found three approaches to finding the right problem in the right project.
The Active Approach
The simplest way to start is to take a look at open source software you are already using and actively look for things you can help with. It can be an app you use daily, a dependency for one of your hobby projects or a build tool you use regularly.
Think about your favorite open source project, open the project's page (GitHub, GitLab, BitBucket, etc.), and try to find out what's the best contribution you can make! Keep in mind that it doesn't have to be a code-related contribution, there are many ways to contribute!
The Passive Approach
Wait for the problem to come to you. I believe that most casual open source developers prefer this method. Report problems, fix issues or propose features that affect you directly.
- Is your build step failing because of one bug in an open source project you depend on?
- Is there something missing in a project's documentation?
- Is there a feature you would like to see in your favorite open source app?
As long as the problem is not too big, these are good reasons to contribute.
The best part of this approach is that you have a personal incentive towards solving a particular problem, making it a highly-rewarding activity.
The only downside is that this type of contributions are spontaneous by nature and don't happen very often, which is troubling if your responsibilities don't allow you to find the perfect time to solve the problem.
The Vigilante Approach
The final one is a variant of the Active approach. It consists of using apps, dashboards or feeds to stalk watch your favorite organizations, developers, and projects. See what problems they are facing, and when the opportunity arises, contribute!
In my case, I use DevHub (basically TweetDeck for GitHub). DevHub provides a horizontal dashboard with feeds from my favorite OSS organizations, developers, and/or projects. I usually watch out for issues that I can reproduce, bugs I can fix or docs I can write.
This is my favorite way of finding open source projects to contribute to and problems to solve, because it's on-demand, rewarding, and easy to squeeze into my schedule from time to time.
Whenever I feel like dedicating some time to open source (i.e. an uneventful Sunday evening), I check my dashboard and see if there's any small problem I can help with. It's not guaranteed to work, but it frequently does.
How to Contribute
There are multiple ways to contribute to an open source project, but generally speaking you should focus on discrete problems rather than recurrent tasks such as maintenance or content moderation. Those tasks are much better suited for regular contributors and maintainers.
Code Contributions
- Bug Reports – open new issues, file bug reports, reproduce issues
- Feature Requests – request new features, propose solutions, draft proposals or RFCs
- Bug Fixes – fix known issues, patch minor bugs, solve performance issues
- Security – search for vulnerabilities, patch them, update dependencies
- Features – add requested features, enhance existing features
- Automated Testing – write tests, integrate with CI/CD, refactor tests
- Accessibility – fix accessibility issues, provide accessibility feedback, point to useful resources
Non-Code Contributions
- Manual Testing / QA – test usability, solve non-trivial testing issues, develop automation strategies
- Documentation – document features, write how-to guides/tutorials, write examples, write translations
- Mentoring & Support – help in community forums or chat channels occasionally, provide learning resources, participate in community discussions
- Design – make logos/graphical assets, propose branding strategies, provide constructive design feedback
- Outreach – promote a project, write instuctional articles, showcase a projects' usage
Financial Contributions
- Project Donations – donate thorugh open source funding programs such as Open Collective
- Developer Funding – sponsor individual developers through subscription-based platforms such as Patreon
Learn more on how to contribute to open source here.
Choosing Tasks & Problems to Solve
Contributions for any open source project can be split into two main categories: general contributions and specific contributions. As a casual open source contributor, the type of problems you tackle and the tasks you complete for a project should be determined by your knowledge, skills, availability, and interests.
General Contributions
This type of contribution focuses on tasks that are general in nature (i.e. they apply to many projects of the same kind) and require little to no domain-specific knowledge.
General contributions are suitable for you if you are familiarized with the project, but only at the surface level. This type of contribution is usually non-critical which means that your contribution will probably only enhance the project.
This is my favorite way of contributing to a project because contributions of this type are generally easy to solve, don't require a big time investment, and aren't domain-specific.
I also like that this type of contribution is usually non-controversial. It's likely that your contribution will be welcome without much push-back or debate, which saves you some precious time.
Examples for general contributions include but are not limited to:
- Fixing simple code errors
- Writing reference or usage documentation
- Translating content/docs to other languages
- Authoring usage guides ("How to do [...]")
- Updating dependencies that bring no breaking changes
- Adding surface-level features
- Comprehensive bug reports
- Reproducing and documenting simple issues
- Fixing typos and errors in documentation
- Adding supporting resources
- Translations, formatting tools, etc.
Project-Specific Contributions
Project-specific contributions are focused on the core functionality of the project. This type of contribution is suitable for you if you have domain-specific knowledge that could be leveraged for solving project-specific problems.
This one is the trickiest, but in my opinion it's also the most rewarding type of task you could find. The biggest downside is that it requires more skill and time. If you are familiar with a project's inner-workings and structure, you might be able to do this from time to time.
It's also important to note that this type of contribution also means that complex debates and brainstorming sessions might be necessary. It could take weeks or sometimes even months for your contribution to be accepted. If you are limited on time or are not willing to commit temporarily to solving a specific problem, this might not be the best type of contribution you could make.
Examples for specific contributions include but are not limited to:
- Fixing a critical bug that affects a specific group of users
- Writing feature requests
- Drafting proposals or RFCs
- Refactoring a major part of the project
- Updating core dependencies that bring breaking changes
- Adding support for a particular platform/integration
- Reproducing and documenting complex issues
Conclusion
I've been a casual open source contributor for ~6 years and as time passes, I dedicate more time to it. I do it with confidence because I know that if at any point in my life I need to take a break, I can do it without letting anyone down.
You don't have to be a 10x developer or a full-time contributor to be a useful part of an open source community. There are ways to contribute to open source without dedicating your life to it or being exceptionally good at it.
If you know anyone who is thinking about contributing to open source share this article with them! If you have any other tips or hints on how to make casual open source contributions let me know (@KristianMuniz on Twitter) and I'll add them here!
Supporting Resources
Although this post is mainly subjective, the following resources served me as a source of inspiration and references for its development: