How to contribute to Open Source without coding

How to contribute to Open Source without coding

Actually, there are plenty of ways to contribute without coding:

  • Submit bug reports
  • Suggest new features and options
  • Make other comments on how to improve the the quality of the program
  • Help write good documentation
  • Translate the documentation (and program text) into another language
  • Read existing documentation, follow the examples, and make corrections
  • Correct spelling and grammar mistakes in documentation
  • Develop spelling and grammar style conventions for documentors
  • Build a glossary of technical terms
  • Convert documentation into more useful formats (i.e. DocBook)
  • Create templates to write documentation in a WYSIWYG word processor (AbiWord, KWord) and XSLT to transform it into DocBook
  • Create diagrams, screen-shots, and graphics for documentation
  • Submit graphics (icons, backgrounds) to use in the program
  • Help other people learn how to use the program (answer questions on mailing lists or IRC channels)
  • Write an email expressing your appreciation for the programs you use
  • Send the programmers post cards
  • Send the programmers a virtual beer
  • Write your legislators about the concerns that Open Source programmers have with recent and upcoming legislation
  • Write book reviews and critiques
  • Write a book
  • Maintain a FAQ or HOWTO document
  • Help organize LUG events, including InstallFests, BugFests, and DocFests
  • Help write articles for the LUG newsletter
  • Help update the LUG web site
  • Help maintain a web site for an Open Source project
  • Design a better user interface for your favorite program (GLADE and Qt Designer are great for mocking up a new UI)
  • Run usability studies
  • Create validation or regression test cases
  • See how a program handles streams of random data
  • Package the application for a particular Linux distro (or other OS)
  • Get the program to compile on a new platform
  • Create a Linux advocacy web site (probably not so easy to do right)
  • Provide training to new Linux users
  • Read relevant standards and make sure the program follows them
  • Convince people to chose Open Source products when possible
  • Write up case studies of successful Open Source implementations
  • Send the programmers some money

Here are some suggestions if you want to start coding for an Open Source project:

  • Read a lot of code, and learn from that (I’ve never seen a book that stressed this enough, but it is critical, and you’ll read much more than you write, especially with Open Source)
  • When reading code, consult include files for info on library functions (Learn how to grep for the function or structure you are looking for)
  • Start small, with one-line changes to existing programs (You don’t have to understand too much to do this in many cases)
  • Write your own small programs just to learn the language and libraries
  • Start off commenting existing code where it needs it
  • Write some documentation on the architecture of the program
  • Learn how to use all the tools (CVS, diff, patch, libtool, automake…)
  • Experiment by making changes to your local copy of the code
  • Test your code thoroughly before you submit it
  • Adhere to the maintainer’s coding and formatting standards
  • Don’t get discouraged when your patches are rejected (they will be!)

This list was contributed by Craig Buchek to the St. Louis Unix Users Group listserv on 6 February 2020.

whoami
Stefan Pejcic
Join the discussion

I enjoy constructive responses and professional comments to my posts, and invite anyone to comment or link to my site.