My earliest open source contributions date back to the mid-1980s when our organization first connected to UseNet where we discovered the contributed code and the opportunities to share in its development and support.
Today there are endless contribution opportunities, from contributing code to making how-to videos.
I'm going to step right over the whole issue of contributing code, other than pointing out that many of us who write code but don't consider ourselves developers can still contribute code. Instead, I'd like to remind everyone that there are lots of non-code ways to contribute to open source and talk about three alternatives.
Filing bug reports
One important and concrete kind of contribution could best be described as "not being afraid to file a decent bug report" and all the consequences related to that. Sometimes it's quite challenging to file a decent bug report. For example:
- A bug may be difficult to record or describe. A long and complicated message with all sorts of unrecognizable codes may flash by as the computer is booting, or there may just be some "odd behavior" on the screen with no error messages produced.
- A bug may be difficult to reproduce. It may occur only on certain hardware/software configurations, or it may be rarely triggered, or the precise problem area may not be apparent.
- A bug may be linked to a very specific development environment configuration that is too big, messy, and complicated to share, requiring laborious creation of a stripped-down example.
- When reporting a bug to a distro, the maintainers may suggest filing the bug upstream instead, which can sometimes lead to a lot of work when the version supported by the distro is not the primary version of interest to the upstream community. (This can happen when the version provided in the distro lags the officially supported release and development version.)
Nevertheless, I exhort would-be bug reporters (including me) to press on and try to get bugs fully recorded and acknowledged.
One way to get started is to use your favorite search tool to look for similar bug reports, see how they are described, where they are filed, and so on. Another important thing to know is the formal mechanism defined for bug reporting by your distro (for example, Fedora's is here; openSUSE's is here; Ubuntu's is here) or software package (LibreOffice's is here; Mozilla's seems to be here).
Answering user's questions
I lurk and occasionally participate in various mailing lists and forums, such as the Ubuntu quality control team and forums, LinuxQuestions.org, and the ALSA users' mailing list. Here, the contributions may relate less to bugs and more to documenting complex use cases. It's a great feeling for everyone to see someone jumping in to help a person sort out their trouble with a particular issue.
Writing about open source
Finally, another area where I really enjoy contributing is writing about using open source software; whether it's a how-to guide, a comparative evaluation of different solutions to a particular problem, or just generally exploring an area of interest (in my case, using open source music-playing software to enjoy music). A similar option is making an instructional video; it's easy to record the desktop while demonstrating some fiendishly difficult desktop maneuver, such as creating a splashy logo with GIMP. And those of you who are bi- or multi-lingual can also consider translating existing how-to articles or videos to another language.