It looks like not many people realize they can help their favourite projects while not being programmers. If you've been meaning to do that, but didn't know how, read on!

“2.5 people? that's a shame... so many creative developers out there. I assumed there were at least 100 people working on this... no wonder it [GIMP] is lightyears behind Photoshop, with only 3 people working on it.... ” The Quentin Tarantino Archives

The recent GIMP 2.8 story reminded us how fragile some things are. It's true: many people believe that all big free software projects have dozens, if not hundreds of contributors. Which is really as far from reality as one could get. Things are even worse: people tend to think that even a sorry state of affairs is normal for a project unless you state loudly that it really isn't so and make sure that the news gets around.

It's especially critical in the world of libre graphics tools, because lack of contribution to many projects is obscured by considerable success of Blender as a community project. A simple dissection reveals that behind success of Blender indeed there is really a rather well designed work with community (albeit there is more work still to do).

The key word is communication. There are all kinds of reasons why many free software projects fail, but lack of communication between developers and the user base has a very special place.

Why is it critical to maintain close relationships with community? In free software projects active comminity members resemble employees in commercial companies. Even if you work on free software, you still need different people doing programming, testing, design, marketing, tech support and so on. A developer cannot be Jack of all trades and keep going that way forever. Sooner or later (s)he either fails or learns to delegate duties to someone who is better at them.

There have been some attempts at helping developers to reach a wider audience of potential contributors, such as SourceForge's People section. It doesn't work, because it cannot work: very few people browse lists of tasks for arbitrary projects in their leisure time. With what little time on hands contributors have, they usually focus on projects they care about most.

So this is all about commitment and dedication. And while there probably is no such thing as dedication workshops, there is a fair bit of eye-openers ahead, because in reality many people do not realize they have skills that their favorite free software projects could make a good use of.

Despite a popular belief helping a free software project doesn't necessarily involve programming. This, of course, brings up a question, whether non-programming involvement changes anything. It actually does. Contribution is another way to tell a developer his/her work is appreciated, be it money, code, tutorials or anything else. And appreciation is one of the best motivation boosters.

There are different ways to contribute, these ways are specific for each and every project. Let's go through most popular ones.

Localization and documentation of all kinds

You are probably going to read "it depends" many times in the next 5-20 minutes. For localization it really depends. Creating user interface translation for a smaller project can be a matter of a couple of spare evenings with occasional subsequent updates once a month. Or it can be a serious commitment.

Localization, however, always needs maintenance. Depending on technology in use a simple change can make an already translated message appear in English just because developer added forgotten comma or fixed a typo in the original message.

Writing documentation is considered fun by a very small part of any user base. But tutorials, as well as screencasts, are a whole different thing. With a bit of planning you can suddenly make a big splash. It's what happened to MyPaint project in August 2009.

This great painting tool wasn't very well known, and it took David Revoy just one timelapse video featuring Al.Chemy, GIMP and MyPaint to suddenly make MyPaint team face a user base several times as large as before, but also get several very important new contributors.

Talking of screencasts, one thing that needs to be mentioned here is that really good training material can be put on commercial rails. Check out BlenderCookie to get an idea. Speaking of textual tutorials, you might like writing for e.g. tutplus.com, who also since recently have a marketplace for tutorials.

Scientific work

It probably is a little unexpected, but many free software projects could benefit from scientific researches, especially those in multimedia field. There's still a lot of work to do in the graphics department — just read a list of papers that get submitted every year to SIGGRAPH and EuroGraphics.

There even is a chance to be sponsored. Few weeks ago Google announced its 7th Google Summer of Code program that provides financial support to students who wish to work on free software. The work within GSoC could be part of a bigger scientific research, or a standalone work you can later write a paper on.

This is e.g. what Adam Turcotte did in 2009: his senior thesis was partly based on his GSoC 2008 project to implement image enlargement resamplers for GEGL — the new GIMP's image processing core.

For list of ideas please contact the team behind an application you care about. Krita team, for instance, has a document that lists potential scientific researches to benefit the project.

Improving design

Whenever you start evaluating various big free software projects, you can easily see that many of them lack visual polish. If you look at e.g. MusE you'll see that the MIDI sequencer that's been around since 1999 looks like it's still 1999, whereas its younger brother called MuseScore (anno 2002) looks more or less modern.

Why is that so? For some reason the existing community of designers doesn't get in touch with the community of developers, and thus we are in a unique and rather silly situation, when even tools for artists lack artistic touch. The two communities are simply disconnected. In a world of people who talk things people who do things don't talk to each other.

Don't get me wrong: there's a lot of activity in the desktop environments department: design teams in mainstream Linux vendors continuously improve the look and feel of GNOME, KDE, Unity and so on. And yet many tools we have these environments for are simply far away from state of the art.

If you are designer and you happen to use Linux or just some open source tools on Windows or Mac, simply look around: maybe you could help a free software project you rely on and get some publicity in return.

At some point it would be nice to centralize requests for missing art. So far even http://live.gnome.org/GnomeArt/ArtRequests doesn't seem to work as expected.

An important thing to remember here is that most open source applications for content production are based on either Qt/KDE or GTK+ and thus UI graphics should at least take design style references into consideration. For KDE it is Oxygen, for GTK+/GNOME it is Tango (though symbolic style is currently gaining momentum).

Improving usability

Usability is often neglected or understood utterly wrong. Contrary to another popular belief, usability is about listening to various opinions, figuring out the big picture and working from it on increasingly finer details.

Let me just quote Paul Davis, principal developer of Ardour, a free digital audio workstation for Linux and Mac:

In the 10 years I’ve worked on Ardour, it has been my experience that listening too carefully to any one person’s experience with a given piece of technology always tends to be misleading. We have heard from people who tried Ardour and found it mostly unusable. We have others who have had years of experience with Logic or PT who find Ardour much more functional for them.

Both these points of view are right, and it's taken me a long time to realize that once a tool becomes even remotely complex (possibly at the point where there is any user choice at all), there’s no way to make that tool be the choice of all possible users.

If you have experience in doing usability researches and designing interfaces, and you see a project you like that would benefit from UI and UX improvements (you hardly have to aim), don't hesitate to approach the team. There is, of course, a usual issue of already knowing most pitfalls and not having developers to fix them, but YMMV: it never hurts to suggest your help.

Work on website

I'm talking about both web design and maintining existing/new website.

Website design is another thing that developers are usually not very good at. Ever since SourceForge introduced Wordpress and Mediawiki, projects started actively using them, in some cases simply because even default design was better than what they had.

What we discovered with Inkscape project is that people are actually willing to work on a cool design in their spare time, because they love the software and are willing to give back, especially if they get an attribution.

Why? Because being part of what/who you love is a very human thing. I happen to know a web developer who is ready to slice web designs to templates for various open source projects and do some basic web programming (and she's great at doing that) just because she feels grateful to the community. Needless to say, feel free to ask me for contacts.

Maintaining the website is a very important task. People judge on project's activity by how often it publishes news and reports on changes in any possible way. All one has to do is stay tuned to development and write updates periodically.

Other ways of contributing while not writing code are more project specific. Please approach teams to find it out what those are.

Single contributions

Speaking of dedication, not everybody is ready to take a new commitment, so is it bad to do single contributions? There is no universal answer to this question, as it heavily depends of the kind of task to take, as well as half a dozen of other criteria.

Programming-wise, all source code in a project needs a maintainer — a person who is responsible for it, so that bugs get fixed and the code gets updated over time to match new paradigms. At the same time core teams often have tasks they simply lack time to do, and they'd be gladly supporting someone else's code if that code was written. So really this is the old "please contact the team to find out" all over again.

One thing worth noting here is the recent trend for social coding that we owe to distributed version control systems such as Git and Mercurial. Source code hosters like Github, Bitbucket and Launchpad make it easy to do point contributions by forking an existing code, improving parts you care about and sending a merge request. They also make it easy to see how exactly people put your work to a good use — this is something existing development teams are probably more interested in.

Where to start

Contact the teams. Seriously. Free software is about communication.

More on this topic: