For those new to GNU/Linux and Free/Libre Open Source Software (OSS or FLOSS) and the associated communities, some explanations may be in order. How to be part of this community, how to find your way and how to make things work for you.

This article starts with several aspects of the OSS community and OSS development, indicating what makes OSS developers tick. Then it explains how to deal with problems. The novice Linux user is invited to exchange the more common troubleshooting reflex (retry, reboot, reinstall) with a more OSS minded method (check, communicate, correct). The last section provides some more concrete starting points for those who want to learn more about their Linux system.

For those who want to skip the background explanation and directly go to that last part, just click here. However, knowing a bit more about the background may help you to understand why supporting the Free Software / Open Source Community will benefit yourself.

A well respected professional programmer, who had written a driver for an ethernet card, was asked why he would devote his spare time to write this driver and then give away the code under the GNU General Public License (GPL). The point the inquiring person tried to make was that this programmer must be crazy, doing a professional job and giving away the code. His answer (well, paraphrased anyway): "I put in a few evenings of work, and in return I get an 80MB Operating System for free, including the source code, and you're telling me I'm the one who's crazy??"

Basically, to develop code as OSS means that developers can work together to create software that is much more powerful and capable than they could have created alone, and the GPL ensures that they will always have access to any further improvements of their code. So if you want to fill a need, the GPL is a great way to get others to contribute to your code; they too will forever be able to profit from their own work.
This explains why it is (was) commonly said: "OSS developers write code to scratch an itch," other developers are welcome to join in. On the other hand, if they like their program and a mere user doesn't like it, tough luck. There's not always enough incentive to improve or modify once the developers of the program feel that it suits their needs.
There have been some changes of late, in many projects the developers have shifted their aim to develop the best possible solution/implementation. The Linux kernel development is a good example of this, but also high profile projects such as as KDE and GNOME.
Also, more and more OSS developers are actually getting paid to work on their projects professionally, although they are still a minority. Note that payed developers on one and the same project may well be payed by different companies, for instance 2 (competing) Linux distributors. They still work together to make their project the best it can be.

The FLOSS development shows strong contrast with closed source or proprietary software development, that in most cases is just a means to an end: namely to generate the highest possible income and to ensure the ability to do just that in the future. One company very good at that is Microsoft.
For those companies, it would almost be the end of them if they would create and market the perfect product (if such a thing could exist). Imagine an Operating System that never crashes and fulfills all tasks perfectly, and the management talking with the designers: "so, what can we design and sell next"? Of course, this is too naive a situation sketch, but still. All the proprietary software makers have to do, is make software that is merely 'good enough', which in some cases is quite abysmal. With a bit (or a big load) of lock-in, they have found that their customers (often large companies) are willing to put up with a lot of things.

But this article is not about proprietary solutions, so I'll save that criticism for some other time.

The point I would like to get across is the following: OSS developers are giving the fruits of their efforts away for free, for all to use. Most of them do not get paid for their efforts, or at least, not by you. They often do aim to make their program the best it can be. So your complaints may not always be welcome, but your bugreports (especially of reproduceable bugs) very often are.
In many (most?) cases, extra developers are welcome to join a project. You can contribute in other ways too, if you're not a (good) programmer, you could help out with the translation or the documentation. Check the project homepage for these kinds of things. Sometimes, financial or other donations are possible.
OSS is free of charge, but money makes the world go round. If you like some program/project, please think about contributing to it. If you like your distribution, buy a copy or, in the case you use and like Mandrake Linux, become a clubmember. If you don't have the money to spare, contribute in any other way: by promoting the use of OSS, by writing code, writing and / or translating documentation, helping (supporting) people in real life or on mailinglists, forums, etc.

Many of the difficulties and problems that people encounter when starting out with Linux are due to being unfamiliar with the system. In other words, the problem is not with the system, but with the user. This is sometimes referred to as 'operator error'.

If things don't behave as you, as a novice Linux user, expect or would wish, that doesn't mean they are wrong - even if it means that you may take a bit longer to get used to things. The standard system behaviour is well thought out, and the complexity and flexibility of the whole implies by definition that there is much to learn.

One example: logging in graphically as root is not a good thing. You are free to educate yourself as to the how and why. The Mandrake developers have made it more difficult (but not impossible) in Mandrake 9.1 to log on graphically as root. Kudos to Mandrake for trying to get people on the right path, this is a Great Thing (tm). You can still log on graphically as root (it is Linux, remember) - but don't complain if it's not so straightforward to do, and definitely don't complain if, due to this, at some point you end up with a broken system.

So if the system doesn't behave as you think it should, don't complain, but figure out why it does behave that way.

This being said, it is clear that many pieces of software, OSS or not, have bugs. I will not contradict that you can easily run into some of these bugs, instead I want to explain how to deal with bugs and other problems with Open Source Software.

The 'other system' troubleshooting paradigm mainly consists of the Three R's:

• Retry
• Reboot
• Reinstall

I'd now like to present the OSS troubleshooting paradigm, which I like to sum up with the following Three C's:

• Check
• Communicate
• Correct

Check whether your problem is not just an operator error, which is very often the case: due to unfamiliarity with the system the user falsely expects it to behave differently than how it was designed. These errors were (I do hope my speaking in the past tense is correct in this case; at least it should be) often answered with: RTFM (Read The Friendly Manual) or UTFS (Use The Friendly Search) (note that I prefer to use another f-word than is usually aimed at in these acronyms). Your check should start at the manual page or documentation, and can include any or all of the following: acquaintances who have experience with the program at hand, the project website, google, newsgroups and forums.

Communicate to see if others (possibly including the developers of the software in question) are having or are observing the same problem. If they have, see how they managed to solve it, or at least work around it. It may be that you have come across a bug that cannot be fixed directly. Again, you may use any or all of the following: newsgroups, project mailinglist, forums.
Note that even if you haven't purchased the program, software vendors will still appreciate your feedback and bugreports - if they can fix the problem they will: you are not likely the only person with this problem.

As a last point in this process, you can correct the problem on your own system (either because you've just found out it was an operator error, or fix it as per the feedback you got in the former step) and / or the developers of the software can and should correct the problem by fixing the source code, in which case a next pointrelease (or for the more daring and experienced users: the CVS code, which is the code under development) will include the fix.

With proper application of the Three C's, OSS continuously gets improved, and you get rewarded for your effort: in the next version of that certain program your problem will have been fixed. Also, please realise that if there is a persistant bug that you have trouble with but apparently doesn't get fixed, and you didn't follow the Three C's, you have no-one but yourself to blame. You may consider this one of the costs of OSS.

One of the great things of OSS is that the source code is freely available, so you don't depend on those few developers of one specific software vendor who fix bugs, and if the root cause is found you don't have to wait for the next big release. Agreed, this applies more to expert users. But in any case, and best of all, you don't ever have to pay for that next release in which your problem is solved.

To get started on learning how to use your shiny new Operating System, I'd like to propose the following: whenever you get stuck or feel the need for some more information, read the documentation that came with your system. Yeah, I know it's a real shocker, but few people actually ever pay attention to that.

For instance, in Mandrake you go from the start-button to Documentation, then select the Howtos. Many programs also have their own built in documentation. KDE and Gnome, the two major Desktop Environments, both have excellent online help files. In Gnome, go from 'start' (the footprint) to 'help' which starts 'Yelp'. In KDE, all KDE applications have a help entry on the menu at the top, where you can select '[Application] Handbook'. OpenOffice.org is another group of programs with extensive online documentation.

You may also use Konqueror (KDE's multipurpose filebrowser) to read manual pages (manpages) for commands and programs. If you are using KDE, click the 'home' icon on your taskbar (panel) or desktop. Then, in the location field (where it says: file:/home/[yourusername] -- see image)

To find out more, you can also read books, magazines and websites, search the web, newsgroups and forums.

And most of all, if you get stuck, remember the Three C's.

Note that I use the terms Free Software and Open Source Software to denote the same thing, and I don't want to go into the differences of these terms from a philosophical standpoint. The term 'Free Software' stresses the fact that the code is free in the sense that the user can do with it as he/she pleases, but it's somewhat confusing since it can still be charged for. 'Open Source Software' stresses the fact that the source code is available, but from the term it is not clear that the user can do with it whatever he/she wants. 'FLOSS (Free/Libre Open Source Software)' leaves less doubt but also requires some explanation and is a bit long... Maybe 'Freedom Software' (what 'libre' actually hints at) should be used...
Next to the GPL, there is also the BSD licence, which is less limiting in the sense that closed source software may be based on BSD licenced code, without opening it. Stephen Pinker has explained here why that is less beneficial for the FLOSS community.