Home | About Me | Writing | Photos | Research | Scratchpad | Projects

Teaching newbies GNU/Linux

In a recent ask Slashdot thread, chrisd asked Slashdot readers how they thought he should present Free Software (FS) on TV, i.e. how one should present FS to "newbies". As is typical of a Slashdot commentators' debate, there was little agreement on the approach that should be taken, with lots of interesting arguments, counter-arguments, and comments coming in from entirely different angles (indeed that is the real value of a Slashdot debate). Some thought one should sit a newbie down in front of the command line and teach them to use grep and compile a kernel, whilst others thought one should show them exciting multimedia applications and try to hide the command line entirely with GUI tools supplied by the latest newbie distribution. What was most interesting was that almost all of the commentators described exactly what they found interesting, and how they would want to have a system showed off to them.

This focus on oneself seems to underly a big problem in the FS community in terms of its approach to newbies. When teaching somebody (which is what we are doing, even in pure advocacy, without telling them how to use a system), it is easy to assume the person holds a certain set of ideas and values which you do, which are critical to an understanding of the subject. It is also easy to assume that people think in the same way as you, or that because you can do something intuitively, others will too. It is not that people are deliberately elitist and rude, though there is unfortunately an awful lot of that around, but that people simply don't take a moment to think about how they approach others that are not like them.

The FS community is really very closed; it is predominantly a male hacker community, and so its culture and politics can seem very alien to many newbies, especially when one considers that many haven't the slightest idea that "hacker" and "cracker" aren't the same thing, let alone that being called a "good hacker" is a high honour. People always bring their culture and politics into what they say and write, whether deliberately or inadvertently, and this is leading to a lot of rudeness and a lot of very confused newbies. For example, if I were to ask a question, and get told "RTFM" (Read The Fucking Manual), I would a) know the person meant, b) realise they weren't being rude, but that I was being stupid, and c) know how to make that statement useful, by finding the appropriate manual and being able to use the information. A newbie may lack all of these skills, so a statement that is quite acceptable to a hacker becomes unhelpful rudeness when used on a newbie. A newbie is also likely to lack a concrete knowledge of what FS even is, let alone the implications of the GPL and the reasons to dislike the DMCA/EUCD. I know many seem to think these subjects are separate from each other, but they are not. One cannot have FS without a binding license to protect it, and one cannot have FS if there are laws that actively discriminate against it. As much as people would like to be apolitical, one has to be a political animal, especially in the FS world. And many people are, as reflected in FS community hangouts like Slashdot and Kuro5hin. So to ease the newbie into the FS world, it is important to explain the culture and politics: explain what FS is, explain what a hacker is (and what it means to be a hacker), explain how the GPL works - do all this, and you will not only be more likely to convert them to the FS/hacker ethic, but you will also help them enter the community and ask for technical help.

This focus by hackers on hackers was also found to be the cause of many a useability problem in a recent study entitled "Usability and Open Source Software". In this, its authors David Nichols and Michael Twidale found that very few FS projects ever think about how others will approach their work; all too often, a program will be designed for its author - a result of the "scratching an itch" motivation that drives a lot of FS development. Even if they do consider useability, the default settings are rarely given sufficient consideration. The result is that programs are unapproachable. This problem is compounded when newbies ask people for help, and the people they ask cannot see the problem because they understand the program perfectly. If somebody asks you how to save a document, it is easy to say "look for the save option in the file menu". But to somebody who doesn't know what a "file menu" is, this makes no sense, something I learnt the hard way when working as an IT trainer.

This example hints at another problem we face: every computer user is an individual, with different types and amounts of knowledge, different goals (in terms of what they want to do with their computer), and different attitudes towards learning. If you try to teach a group of people from a book without ever adjusting yourself to your students, you'll fail miserably, and make them miserable in the process. This is because they all want different things, a principle you would have thought the FS community, with its wonderful obsession with customisation, would implicitly understand and therefore act on. But somehow, when approaching other people, we seem to forget that they, like us, have distinctice tastes and goals. We also seem to forget that they all know different things, so while the statement "look in the file menu" will make sense to some, to others it will be a foreign language.

So how can we approach newbies, if they are all so different? We cannot be relatavists here, because practical constraints demand an objective idea of how to approach them all as a mass (unless one is willing to make a web site that customises itself according to the answers in a questionnaire, which would probably only confuse newbies even more). This takes us back to the Slashdot debate - what is the best approach to all "newbies", if we may bunch such a disparate group of people together under one term. It must be objective, but it must cater for the differences among people. To me, this means that one should tailor the approach in two ways:

1) One should never assume an unreasonable amount of knowledge. If it is a Web Site or book, start from the absolute basics, like "what is a partition" and "what is a filesystem", because the newbie who knows such things can always skip through. Once one understands the underlying concepts, approaching a topic is far easier and far more rewarding.

2) One should provide opportunities for the newbie to participate in his/her education. There's nothing more boring than having somebody teach you - you want to learn, and learning is a verb, it is something you do, not something that happens to you. So one should aim to teach a newbie, but only to equip them with the tools to then teach themselves wherever possible. For example, don't teach a newbie how to use every command line tool - teach them how to use the command line, and then a few programs with which they can learn the rest (ls & cd for the basics, man, apropos and which to let them find their own tools). Then provide them with optional material which they can learn from if they so wish (so a list of really cool tools, like grep and pipes).

The result is an approach to learning which emphasises the newbie, not the knowledge. In other words, the important thing is not that the newbie takes on a whole lot of knowledge about FS and GNU/Linux, but that the newbie finds it interesting and learns how to learn more. So an argument like "command line vs. gui tools" is invalid, because it fails to address the individuals concerned. Some might like the command line, some might like the GUI, and some might love/hate both. Give them the mental tools and the material to learn both, help them learn both, and let them make up their own minds. Remember that they are not you, and that they are in fact lots of Is; remember that they all know, like and want different things, and remember that they want to participate in their education just as you have. If we can all remember this, then newbies should start finding FS and the FS community far more approachable.


This article is copyrighted by Tom Chance, 2002, under the GNU Free Documentation License. As such, the article may be reproduced free of charge so long as this notice is preserved and the author, Tom Chance, is notified.

The article was published on Newsforge.