Contributing to Free Software using Open Source processes may look like intimidating deep expert work. But it doesn’t have to be that. Most Free Software communities are friendly to newcomers, and welcome all kind of contributions
Reporting bugs
Hitting a bug is an opportunity, not a nasty problem. When you hit a bug, it should be reported, and with a bit of luck, it may even be fixed. Reporting the bug in an open forum also makes other users find the bug, give attention to it, and they may in turn be able to help out working around or fixing it. Reporting bugs is the most basic, but still of the most valuable contributions you may do. Finding bugs are finding real problems. Reporting bugs is helping fixing them, for you, and for other users. You may not complain to your coworker on a bug unless it is reported upstream.
While reporting bugs, remember to collect as much information as possible on the issue, including logs, runtime environment, hardware, operating system version, etc. While collecting this information, make sure you don’t send any traceable private information that may be used by rouge parties, like IP addresses, host-names, passwords, customer details, database names, etc.
Reporting bugs in operating system packages
Bugs in components delivered by a Linux distribution (Ubuntu, Debian, Fedora, Red Hat, SUSE, etc), should be reported through their bug reporting interface. Remember to search for the bug before posting yet another duplicate bug. Perhaps a workaround already exists.
So the next time something strange happens to your ha-proxy, Nginx, varnish, or your Firefox browser crashes or has unexpected behaviour, collect data from your logs, and open a bug report.
- Red Hat / EPEL / Fedora users should report bugs through https://bugzilla.redhat.com/
- Similarly, OpenSuSE users may search for and report bugs at https://bugzilla.opensuse.org
- Ubuntu users may have luck looking at https://help.ubuntu.com/community/ReportingBugs
- As Ubuntu’s upstream is Debian, you may search for bugs, fixes and workarounds using their tools at https://www.debian.org/Bugs/Reporting
These tools have detailed guidelines on the details on how to search, report, and follow up the bugs.
For an example of an end user bug report with an impressive follow up from a dedicated package maintainer, have a look at https://bugzilla.redhat.com/show_bug.cgi?id=1914917
Reporting upstream bugs
Using software directly from the upstream project is growing more usual, specially as container technology has matured, enabling developers to use software components without interfering with the underlying operating system. Reporting and follow up bugs becomes even more important, as such components may not be filtered and quality assured by operating system security teams.
Find your component’s upstream home page or project development page, usually on GitHub, Savannah, GitLab, or similar code repo service. These services have specialised issue trackers made for reporting and following up bugs and other issues. Some projects only has good old mailing lists. They may require you to subscribe to the list before you are allowed to report anything.
Following up the report, you may be asked for test cases and debugging. You will learn a lot in the process. Do not be shy to ask for help, or admitting that you don’t understand or need guidance. Everybody started somewhere. Even you may learn to use the GNU debugger (gdb) in time.
Non code commits
Similarly to reporting bugs, non code commits may be low-hanging fruit to you, but may be crucial to a project’s success. If you can write technical documentation, howtos, or do translations to your native language, such contributions to Free Software are extremely welcome. Even trivial stuff like fixing typos in a translated piece of software should be reported. No fix is too small. I once did a single word commit to GPG: A simple typo fix in their Norwegian translation. Also, write blog posts. Don’t have a blog yet? Get one. Free blog platforms are thirteen to a dozen.
Use source code tools
Admit it: You already use Git in your day job. Using it for documentation or translation should be trivial. If you have not done so already, learn how to clone a project on GitHub (just google it), grep through the source for what you like to fix or add, make a branch with your contribution, and ask for a pull request (again, just google it). If you changes are not merged at once, be patient, ask for the maintainer’s advice, and listen to their guidelines. Be proud of your contribution, but humble in your request.
Feature requests
Usage of a piece of software is not given from the start. Perhaps you have ideas on how a piece of code may be used in some other way, or there is some piece missing that is obvious to you, though not reported in the project’s future road-map. Don’t be shy to ask. Report a feature request. Usually this is done the same way as reporting a bug. The worst you can get is that they are not interested, or a request the missing code. Which somebody, maybe even you, may provide.
Join a project
If your work require it, and/or your interests and free time to spend allows for it, join a Free Software project.
Distribution projects
Upstream distributions like Fedora, Debian, and OpenSuse (not to mention Arch and Gentoo and tons of more specialized distros) are always looking for volunteers, and have sub projects for packagers, documentation, translation, and even marketing. As long time players in the field, they have great documentation for getting started. Remember to be patient, ask for advice, follow guidelines. Be proud of your contributions, but humble in your requests.
Upstream projects
If you want to join a project, show your interest. Join the project’s social and technical forums. Subscribe to their development email lists. Join their IRC channels. Lurk for a while, absorbing the project’s social codes. Some projects are technocracies, and may seem hostile to newbie suggestions without code to back them up. Others are welcoming and supportive. Do some small work showing what you are capable of. Fix things in their wiki documentation. Create pull requests for simple fixes. Join in their discussion. Grow your fame. Stay humble. Listen the long time players.
Release your own
Made a cool script at work? A build recipe for some special case? An Ansible playbook automating for often-visited task? A Puppet module? Ask your manager for permission to release it as Free Software. Put GPLv3 or some other OSS license on it, and put it on GitHub. Make a blog post about it. Tell about it in social media. Congratulations, you are now an open source project maintainer. Also, Google will find it, and so will other users.
