[Courses] [Tools] Ways you can contribute to Free Software

[Mary]

This post is the second 'lesson' in the Participating in Free Software
LinuxChix course. You can find previous lessons at
http://www.linuxchix.org/content/courses/tools/ . Questions and
discussion are welcome, please make sure the string "[Tools]" is in the
subject of your mail.

This lesson is an overview of ways you can contribute to Free Software
development. The goal of this lesson is to provide some context for why
you might want to learn about the tools I'm going to describe later in
the course.

I have a much longer, and perpetually unfinished, detailed set of
suggestions at http://users.puzzling.org/users/mary/HOWTO/Free/ [1]. In
this lesson I'm going to ignore the question of other resources (money,
hardware, that kind of thing) and discuss the different ways that you
can help actually build Free Software.

1. Code

Code is the archetypical contribution to Free Software -- it is software
after all. Contributing code to Free Software divides loosely along the
following lines:

 1.1 Contributing features: adding new capabilities to the software.

 1.2 Fixing bugs: repairing broken bits of the software

There are also slightly less well known (to outsiders and newcomers)
code related tasks:

 1.3 Maintainence: being responsible overall for the ongoing code
     direction, which may involve keeping a consistent design and
     feature philosophy, managing dependencies on different bits of
     code, releasing the software and mentoring new contributors.

 1.4 Review: checking existing code and proposed new code for
     consistency, readability, maintainability and correctness.

Coding on a project requires that you know how to or are able to learn
to program in the software's implementation language. Some coding tasks
will require software design skills, user interface design skills and
ability to evaluate proposed features and changes in light of a
project's goals.

2. Documentation

Documentation is usually considered the most neglected part of Free
Software, although this varies a lot by project. There are two major
types of documentation: technical documentation aimed at contributers,
maintainers, packagers and programming users (if you are writing a code
library -- code for other coders to use); and user documentation aimed
at end users. Some documentation tasks are:

 2.1 Writing documentation.

 2.2 Reviewing/editing documentation. Reviewing and editing ranges from
     grammar and spelling feedback to checking that it is readable,
     readily comprehensible, correct and complete.

3. Development feedback

Development feedback is usually provided by users who have a particular
interest in that project, enough interest that they're willing to spend
time reporting problems or ideas to the developers.

 3.1 Bug reporting: telling developers about problems with the project.
     You can usually report bugs in all other aspects of the software:
     not only the program but the documentation, the artwork, the
     translations and so on. Bug reporting systems are usually used to
     report both existing problems and to request additions. Many
     developers also use them as todo lists and file bugs themselves.

 3.2 User testing: in some software development setups, this is a fairly
     formal process in which users are given specific tasks to do
     ("change the clock from 12 hour to 24 hour time", say) and the
     tester notes the ways they attempt to do this, in order to find out
     if the software is easy to use. This is done haphazardly if at all
     by most Free Software projects, but larger desktop projects may
     appreciate a well organised and documented user test.

4. Packaging

Free Software operating system "distributions" typically bundle a great
deal of Free Software into one package and package versions of many Free
Software projects so that they work well together and provide a mostly
coherent user experience. Almost all packaging systems also track
dependenices (software you need to have installed before the current
software will work) and many distributions also have infrastructure
thatallowed semi-automated installation of packages.

The work required to take code from a project (referred to as "upstream"
by packagers) and make it suitable to be part of a distribution is
called packaging. Packaging can be a lot of work: the Debian project
currently has over 1000 volunteer packages taking Free Software and
putting it in Debian.

5. Artwork

Not all software requires artwork but some desktop software does, and
games sorely need it. The most common work is desktop theming of various
kinds, but software artwork can range from icons to 3D game avatars.

6. Internationalisation and localisation

An internationalised piece of software is one that is adaptable to
different languages and cultures. For example, if my software has a set
of error messages coded in that are in English, then it is not
internationalised, because it is not easy to produce a version of my
software with errors in other languages. In a more general case, if my
software displays writing and assumes that it goes left to right, my
software is not internationalised, because it won't display many
writing systems (eg Arabic) correctly.

Once a piece of software has been internationalised, it can be
localised: made usable by a particular culture or (usually) language
group. Localisation work includes:

 6.1 Translations. This can be of text within the program (like menus)
     or of documentation into a different language.

 6.2 Feedback on cultural and political appropriateness. This involves
     surveying the software for potentially offensive terms, gestures
     (icons sometimes use hand gestures that don't 'translate' well),
     images or suggestions that the developers might not be aware of
     because they're from a different culture. To give a real example,
     many projects have had trouble when including Taiwan in a list of
     countries in their software. Taiwan's status is incredibly
     politically sensitive, and implying that it is a country in its own
     right has caused some software projects weeks of internal strife.

7. Accessibility

Large projects have an increasing awareness of the needs of users with
different abilities. For example, pointer driven programs can be hard
for people without good fine motor skills to use, desktops need to be
usable by people with all manner of vision variations from red-green
colour blindness to a need for high contrast to a need for low contrast
[2]. Software can be improved by including hooks for different input and
output, such as software that reads a screen out loud to a blind user.
Accessibility work overlaps with a number of other tasks:

 7.1 Code accessible software or add accessibility to existing software.

 7.2 Test software and provide feedback about accessibility.

8. Community work

Most Free Software projects have a community surrounding them. In many
cases this replaces paid support for users with a community providing
help for free (limited by people's time and inclination). You can
contribute to the community by:

 8.1 Creating or maintaining community resources like mailing lists,
     forums and chat rooms.

 8.2 Participating in help forums and answering questions

 8.3 Using the community to spur future development, such as identifying
     and properly reporting common bugs, or documenting the answers to
     common questions.

I'm not going to cover prerequisite knowledge for many of these things
in this course (although you're welcome to ask). Most of what will be
covered is version control, used for storing and sharing digital work
(usually code and documentation). But in the next lesson we're going to
look at communication tools: bug trackers and mailing lists.

-Mary

[1] People occasionally ask if they can distribute the HOWTO. I intend
to finish it and submit it to the Linux Documentation under a Free
licence sometime soon, but you can pass around links to it.

[2] See
http://developer.gnome.org/projects/gup/hig/draft_hig_new/images/lowcontrast-theme.png
for what a low contrast desktop looks like.