How do you contribute to open source without code?

There are endless ways to contribute to open source. An easy one is answering our poll question.
106 readers like this.
Dandelion held out over water
Image by:

Seth Kenlon, CC BY-SA 4.0

191 votes tallied
Filing bug reports
35% (67 votes)
Answering user questions
20% (39 votes)
Writing (Guides, stories, documentation, etc.)
38% (73 votes)
Other (Tell us in the comments.)
6% (12 votes)

How do you contribute?

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.

Chris Hermansen
Chris Hermansen portrait Temuco Chile
Seldom without a computer of some sort since graduating from the University of British Columbia in 1978, I have been a full-time Linux user since 2005, a full-time Solaris and SunOS user from 1986 through 2005, and UNIX System V user before that.
More about me

4 Comments

Avatar
Torin Doyle | April 11, 2019
No readers like this yet.

I spread the word about the benefits of using FOSS over closed-source.

Avatar
Don Watkins | April 11, 2019
No readers like this yet.

Great article. Another way to contribute is to send money to your favorite projects. I always advocate for open source solutions for any organization that I'm a part of.

Avatar
Greg Pittman | April 11, 2019
No readers like this yet.

I've done some of all of the options - including some minor code tweaks. For me, I found that answering user questions on a mail list was the biggest help that I had to learning Scribus in a more comprehensive way. Clarifying someone else's answer helps in all directions. You can learn a lot about filing a bug report by adding information to one that already exists, which can eventually give you the courage to file one of your own.
As far as writing about projects, I would favor writing for the official documentation or some repository like a wiki, if one exists. There are more than enough introductory articles on some aspect of software, and these typically just scratch the surface. What's needed are more in-depth articles that speak to particular use cases.

Avatar
Peter Cheer | April 11, 2019
No readers like this yet.

I have done some translation of user guides and documentation from French and Spanish to English, despite being no linguist. The output of Google translate always needs some attention but if you know the context then figuring out what needs fixing is not too hard.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.