Linus Torvalds created the Linux operating system and is still in charge of Linux development. After graduating in computer sciences from the University of Helsinki in February 1997, he went to work for a California-based company called Transmeta. At the same time, Linux was becoming a relatively mature operating system, and was beginning to get attention from the press. When Linus moved to the United States it gave the American media far greater access to him, and thus the shy nerd was suddenly transformed into poster boy for the entire Open Source movement.

One of the most frequently asked questions at the time was, "When will the next version of Linux be released?' Linus had a stock answer, which was always, "When it's done.'

Long before Linus joined up, one of the mainstays of Open Source program development was that a program is released when it is ready. There are no deadlines, and the developers won't give even a rough estimate of any release date.

In his legendary essay "The Cathedral and the Bazaar', Eric Raymond discusses this principle.1 He comes to the conclusion that in a programming project, as in any project, there are typically three expectations: the finished product must have certain features; it must meet certain demands of quality; and it must be completed by a fixed deadline.

These three demands - features, quality, and deadline - would build a certain tension into any project. If, for instance, the schedule is too tight, there may not be enough time to include all the features you want. But if a project manager leans on his team, demanding that all the features are included and the deadline be met, then they are compelled to do a rushed job and, inevitably, quality suffers. Raymond concludes that by consciously abandoning just one of the demands, you can usually achieve good results on the other two.

In the light of that, the Open Source community's no-deadlines principle makes excellent sense, and is probably one of the reasons Open Source programs are so successful. This no-deadlines attitude is, of course, at odds with the project culture prevalent in the rest of the business world, where it is usual for there to be not just one final deadline but also several intermediate deadlines to be met at different stages along the way. Sometimes, to be such a project manager is to find yourself having to give greater priority to working out, following up, and constantly re-evaluating schedules, than to doing the actual work, thus the work itself becomes of secondary importance.

I experienced this firsthand not so long ago, when I was involved in a project for a large Finnish IT company.2 At the first meeting, the client didn't even know in detail what the project was to be about. Making a precise list - defining the number of features - was to be part of the project. But the one thing that was clear right from the start was the schedule. Before we'd even defined what we were to do, we were given a deadline. And the "well-justified' reason for it was that the project had to be realized within two months because its funding had to come from the budget for the current quarter. I don't know if this is an indication of the usual priorities within that company, but I certainly found it amusing.

However, my amusement lessened as the project deadline approached, and we made the finishing touches to the work late on a Sunday night. But the final project meeting was held within the specified time period, the invoice was sent on the last day of the quarter, and everybody was happy. Of course, this did require some self-deception, because we agreed to hold another meeting a few months later to sort out whatever had not been properly resolved by the time of the final meeting, and that turned out to be quite a lot. But that's fine - better to be a bit dishonest among yourselves than to compromise on quality. So, the project was pronounced a success and said to have been completed on time.

Quality and quantity of features are factors of the corporate world and of production. Perhaps some project manager will employ Eric Raymond's way of thinking in their next project. But more important is to understand the influence of deadlines on our own lives. To many people a deadline can seem like a matter of actual life or death, and they feel impelled to work like crazy late into the night to meet it. And very often this life-or-death deadline is totally arbitrary or - as in my own case - is fixed to comply with some utterly unproductive bureaucratic detail. And for that we allow ourselves to become so stressed?

Linus has tried to sort out his own approach to work in a principle he dubbed Linus's Law. It answers the question: why do people do things? The first reason is survival. The second reason is to have social life. And the third reason is that people do things for fun. In that order.

Linus's Law can be applied to work. Primarily, people work to earn enough money to buy food and pay to keep a roof over their heads. But if these were their only motivations, people could work a lot less than they do today. Somebody once said if it were only a question of getting the sustenance for survival, people in the Western world wouldn't need to work more than a few hours a week. By Monday afternoon, we'd have earned the essential part of our income. And in a welfare state like Finland, odds are one could survive one's entire lifetime without working at all.3 But people still want to work. Why?

Work provides people with a social life. School and the workplace are where most of us get to know our best friends. So, that's the social-life motivation. And most people strive to get a job they think they will enjoy doing. So, they work for fun.

Since we work to have fun, to enjoy it, then why do we drive ourselves into the ground trying to meet artificial deadlines? Why work like drudges, as if it really is a question of life and death? Linus feels there's no sensible reason for it. You ought to enjoy work, because that's why you do it. Once again, it's clear that deadlines are bad for both the worker and the work itself.
Linux 2.2 was finally released on 25 January 1999. And almost immediately speculation was rife about when the next version, Linux 2.4, would be released.4 By the time version 2.6 was released the press had learned to be patient, and nobody had bothered to ask Linus for a release date. The media had learned something. You, too, could try learning something from Linux. Take it easy and enjoy what you do.

• 1https://catb.org/~esr/writings/cathedral-bazaar/
• 2Unfortunately, I can't tell you the name of the company or about the project because, of course, the contract included a non-disclosure clause.
• 3Naturally, everyone survives their entire life. :-) What I mean is that it's possible to live to become a pensioner without ever working a single day. Most people, however, don't want that sort of a life.
• 4Linux versions are always denoted by even numbers. Odd numbers are development versions for programmers.

Another question Linus and other Open Source developers get asked a lot is, "Why does your program not have this or that feature?' Those who ask such questions are not so often journalists as people who use a particular program, the clients so to speak. Naturally, the stock answer is, "Because nobody's written it yet.'

That answer may seem a trifle brusque, particularly if it is then pointed out that, "The program source code is freely available on the Internet. If you need a certain feature you are free to create it yourself.' Since it's quite likely the person who asked the question doesn't know the first thing about programming, that answer really can seem rather brusque.

However, there's a fair amount of healthy self-preservation in giving such an answer. Most Open Source programs are written by volunteers. Linus Torvalds, for instance, began working on Linux while he was studying the programming of operating systems. It was his hobby, nothing more. When Linux became a version that worked to some extent, Linus kept developing it only for his own use, incorporating features which he found interesting. But whether Linus wanted it or not, Linux became popular. Others wanted to use his operating system. Getting a positive response to the work he had put in must have been flattering, but along with it came various requests, such as, "There's this thing that doesn't work on my computer, could you fix it?' or "It'd be really cool if Linux allowed you to ...' The inclination to please others is natural to human beings, especially when it relates to our life's work, we really want people to like what we're doing. But to be suddenly faced with thousands of requests can be overwhelming, and it's better to be a bit brusque than to drown.

Unfortunately, one also has to accept that there are a large number of people whose mission in life is to complain. For Linus, who was all excited about making a working operating system for himself, mixed in with the plaudits came the complaints, "Linux doesn't have so and so,' and "Linux can't do this or that.' Such people are never satisfied. And alongside them come the propeller heads wanting their ideas to be incorporated: "I've been thinking you could add such and such a feature to Linux ...' But even if the feature they'd suggested was added to the program, they'd never use it, because by then they'd already have had ten other new ideas about what "it would be so cool if you were to …' The poor programmer would like to make all these Little Helpers happy, but if he tried, he'd find himself swamped by a never-ending stream of requests. What's worse is that too much popularity of this kind can be the death of a project that had got off to a good start.

With this in mind, a program developer's curt reply should be interpreted as a polite negative, a necessarily shortened version of, "Because I work on this program as a hobby and for my own enjoyment, I unfortunately lack the time to realize the feature you suggest, and for which I myself have no need. However, I do think your idea is good and, if you want, you can realize it yourself because the code is freely available on the Internet. Working together is fun, too.'

In addition to self-preservation, there is another little seed of truth in the short answer. After all, if the person asking really needed the feature they'd mentioned, they could create it for themself or at least hire someone who could do it for them. Of course, many of these people are truly excited about their good ideas, but when put to them like this, they become considerably less excited. In reality, they don't believe enough in their great idea to invest more than a few seconds of their time chatting about it, or to invest a penny of their money.

A good friend of mine is a pastor, a job which I can tell you is far more varied than you might expect. In addition to performing religious services and wedding ceremonies, pastors have to provide all sorts of programs for young and old. Also, a pastor needs a working knowledge of sound systems, to be a computer support person, and to generate and get involved in all sorts of interesting projects. My friend has even delivered a live sermon on the Internet.

We once talked about how he plans his work. After the summer and winter vacations he usually writes a list of projects and whatever else needs to be done. If more good ideas crop up later, they can always be added to the list. He then chooses one or more projects and gets them started, and when each one is finished it is crossed off the list.

After six months, it's time for a new list. Happily, many of the projects on the old list will have been completed, but many of them will have remained undone. Like programmers, pastors seem to have more ideas than they have time. Undone projects are transferred to the new list.
Sometimes, a great idea can move from list to list for years, always stuck among the work that remains undone. In the end, such projects are struck from the list, and no more thought is given to them.

Unknowingly, my friend follows the same principle of prioritizing his work as do Linus and his colleagues. Like him, they list the features they'd like to realize in their programs - some they've come up with themselves, others have been requested by users. Then, everybody does what they feel like doing.

With everybody doing whatever they feel like, some things often stay undone for a long time, simply because they're things nobody feels like doing. This gives Linus no cause for concern. If some feature remains unrealized for years, it can't be all that important, as people have been getting along without it! What Linus teaches us here is that the important stuff will automatically get selected and done, so it need not be worried about.

Today, Linux is a billion-dollar business, with companies such as IBM and HP involved. If some feature is really needed, they can get it done themselves - and they do, because the code is freely available on the Internet.

Even if you don't happen to have a billion dollars, you can still apply this principle of the Open Source community in your own life. Next time your boss offers you a really important new project that must be done immediately, you can think: If this project is really so important to the company, I'm sure they can hire somebody to do it who won't have to do it as overtime.

The birth of Linux dates from the message that Linus posted to the Usenet system discussion group, comp.os.minix, on August 25, 1991. Of course there weren't any Linux discussion groups at the time.

From: Linus Benedict Torvalds (torvalds [at] klaava.Helsinki.FI)
Subject: What would you like to see most in minix?
Newsgroups: comp.os.minix
Date: 1991-08-25 23:12:08 PST

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)

Linus (torvalds [at] kruuna.helsinki.fi)

PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.1

There is a certain grandness in that quote, and you can practically hear the making of history. Looking back at this thirteen-year-old post, it is also rather endearing in its naivety. Today, Linux is big, and the work to develop it is done professionally. On top of which, it is probably the most portable operating system in history. At the time of writing, Linux supports the architecture of at least 16 different processors, from the IBM s390 mainframes to tiny processors used in consumer electronics. In fact, the Linux code is said to be exemplarily modular and therefore easy to port.

A further irony is that the GNU project mentioned by Linus still hasn't managed to finish its own "big and professional' Hurd kernel. All credit to them for not having given up, though. I've been following the development of Linux closely for half a decade, and all that time Hurd has been almost complete. Somehow, it is amusing to see that their situation was much the same thirteen years ago, when Linux was born.

We often use the so-called great men of history as examples when trying to make some sense of our own lives. There is even a colourful set of professionals - psychologists, philosophers, dancers, hockey coaches, and who knows what else2 - who make their living by talking about success at various business functions, and they too draw inspiration from many sources including history. Such people often talk about great visions, determination, and hard work.

Linus - undeniably a great man in the field of computer programming - is someone who doesn't fit the mould of these spirit-lifting talks. It seems that the guiding principles at work in the development of Linux have been the lack of vision and determination, or something we might prefer to call openness. Openness to other people's ideas. Openness to changes in plans.

I find it amusing to imagine what would have happened if Linus had been, say, "determined'. When someone, in accordance with the principles of Open Source, first sent him the code to make Linux compatible with SCSI type hard disks, he might have answered, "Thanks, but no thanks. After all, this is just my little unprofessional hobby and, as I wrote, I don't have SCSI disks, so I won't be needing this code. And, anyway, I'm a bit busy right now, because I'm working really hard at the moment.'

Even if that is a ridiculous scenario, I'm sure there are stories just like it out there - stories of people who say "thanks, but no thanks' to the chance of a lifetime. And possibly do so because someone giving a talk once advised them to be focused, determined and to work hard. But we don't often get to hear those stories, because those people rarely become the great men or women of history.

So, what is the secret of Linus Torvald's greatness? I think we can find in his story at least the following key principles:

• Linus does something he finds exciting.
• In addition to Linus being interested in operating system (OS) programming in its own right, Linux was from the beginning also a response to a tangible need: in 1991, the OSs for PCs were either lousy (dos) or expensive (unix) and that is why Linus decided to make an OS that corresponded better to his own needs.
• It could also be said that Linus was in the right place at the right time. He has said it himself: if he hadn't created Linux, somebody else would have.
• However, at the time Linus was the person who was open to the possibility when he encountered it, even though it wasn't what he had planned.
• Also, Linus didn't stay in his cubbyhole hiding his work, but shared it openly with his friends.
• One final important factor was that Linus didn't work alone. He was open to the ideas put forward by others, and open to collaboration. Furthermore, he based his work on that previously done by others (minix) and took advantage of tools created by others (bash, and gcc).

Of course, more bullet points could be added to the list, the kind of qualities inspiration consultants love. It is obvious that Linus Torvalds is among the most talented in his field. He has also worked hard with Linux, but it would be wrong to describe his input as "hard work'. What he did was excited work, which is altogether different. So, it is not good to advise people to work hard, they need to do what excites them.

The lesson to be learned from this one of history's greats is: Don't plan anything, because you can't know what life will bring.

It would be unfair to end this section without a small tribute to the GNU project. Richard Stallman began the GNU project in 1984, and he is the person who first devoted his life to developing software in an open process. Even though the Hurd kernel was trumped by Linux, nearly all the basic tools used in the Linux OS came from the GNU project, including bash and gcc, which Linus mentioned in the post that marks the birth of Linux. So, even if we laugh a bit at the Hurd kernel (which Linus mentions only indirectly), it is only fair to say that a lot of the work behind what we now know as the Open Source movement was done by the GNU movement. Perhaps it is appropriate to end this section with the words of Richard Stallman. Here is his response to the argument that most of the Open Source software was born [only] to scratch a developer's personal itch: "Maybe that happens sometimes, but many essential pieces of GNU software were developed in order to have a complete free operating system. They come from a vision and a plan, not from impulse.'3

• 1The post can be read on the Internet at: https://groups.google.com/groups?selm=1991Aug25.205708.9541%40klaava.He…
• 2These are the actual backgrounds of some popular Finnish lecturers.
• 3https://www.gnu.org/gnu/thegnuproject.html

Now that we've got off to such a good start with that inspiring analysis of Linux we've practically dealt with the subject matter of this section in the previous one. But that's fine, there's nothing wrong with being on the go.

An integral part of the ideology of the Open Source movement, which Pekka Himanen, for instance, has called the hacker ethic, is the rule: Do whatever you like.

So far, much of the Open Source programs has been written by volunteers. It works a bit like barn-raising or, to use the Finnish term, a talkoot. Despite the changing situation - with more and more companies and therefore paid employees getting involved - the volunteer tradition is still strong. It is usually as a direct consequence of using volunteers that the people involved are so, well, involved. Nobody is obliged to take part. Indeed, who would volunteer to do it if they were not interested? Their enthusiasm generates an atmosphere of huge excitement and inspiration. The high quality of Open Source programs is often attributed to this genuinely committed atmosphere. When you do something because you have to, from nine to five every day, the result is very different to how it is when a person does something they're truly excited by and really enjoy doing, and perhaps even feel is their life's work.

But the do-whatever-you-like principle is about more than the consequence of a barn-raising or volunteer attitude. At least, Linus Torvalds himself has gone deeper than that and found a way to express it. In addition to the growing media interest in Linux in the late nineties, there was also a growing interest among programmers. Along with working hackers, many computer science students wanted to get to know Linux and to get involved in its development. For some, this offered an interesting challenge, while others probably only got involved because it was considered cool.

One consequence of this fashion fad was that people started contacting Linus because they wanted to get involved in developing Linux. When they sought his advice about what they should start doing, he came up with another curt answer: Figure out what you're interested in, then join in by doing that.

Linus knew why he gave such non-specific answers. If he arbitrarily suggested that people get involved with this or that project, possibly something currently fascinating to himself, his advice was bound to prove inappropriate for the other person. For one thing, the person seeking advice would probably not be interested in the same things as Linus, and would have a different range of abilities. So, anyone who was given specific advice would probably soon get frustrated with the whole project and end up being angry with both Linus and Linux. Also, no project can benefit greatly from a volunteer who isn't really keen on their part of the work.

Once again, such an attitude presents a real challenge for the corporate world. It's a challenge for Linux, too, now that the corporate world itself is getting involved in the development of the operating system (OS). How many employees can choose to do exactly what they want to do at work? And how many employees must do what the boss tells them to do? Is it even possible to implement such a do-whatever-you-like principle in the corporate world?

If we accept that the do-whatever-you-like principle is a cornerstone of the Open Source community, it follows that we might expect that the same principle applied in the corporate world would generate the kind of success it has for Linux.

Usually, the vision and business strategies which guide a company are created in the upper echelons of management, after which it's up to the employees to do whatever the boss requires of them. How strictly this tradition is imposed varies from company to company but most employees accept that it is the way things are and, indeed, the way they should be. But the principle of do whatever you like would suggest that management - in accordance with the principle of don't plan anything - should quit producing the whole vision and business strategies, and focus instead on making it possible for employees to realize their own vision as best they can. For many managers such a concept would seem totally alien.

Those of us who are not corporate big-shots are always faced with the question, "Am I doing what I really want right now?' When you chose your present place of work, did you go for the job offering the highest salary or the one you were most interested in? This question is not only relevant for the sake of your own mental health, but should also be of interest to your employer. When enthusiasm for the work is so much better in the Linux universe, why should the corporate world settle for employees who merely put in their hours from nine to five?

So, do Linus Torvalds and the other hackers follow their own advice? Yes, they do. Today, all the foremost Linux programmers work for companies where their main job is Linux programming. Their hobby and their life's work has become their day job as well. Could you imagine a better existence? Never settle for less!

You may be surprised to hear that the first and foremost virtue of a programmer is laziness. In the Linux community laziness is acknowledged and valued above even eagerness and interest. Well, if you happen to be married to a hacker, you may already know they're a lazy bunch; there's never any help with the washing-up, not a chance of a hand with the laundry - in fact, often, a hacker even forgets to eat. However, others may find it hard to understand how Linus, for instance, can be said to be lazy; he is, after all, the kid who more or less locked himself in his room for a year, sitting up at all hours writing the code for the first Linux version.

The logic of the claim goes like this: the lazier the programmer, the more code he writes. When a programmer hits a boring, time-consuming and high-on-routines task, he gets lazy. There is nothing worse for a lazy hacker than boring routine tasks. That's why he decides to write a program that will do the routine tasks for him. This is the program he sits up all night to perfect, seemingly diligently at work. Typing is too arduous for him, so he writes the code for a word processing program. And because it's too much effort to print out a letter and take it to the postbox, not to mention licking a stamp, he writes the code for e-mail. Now you'll understand how truly lazy programmers are.

So, laziness is a programmer's prime virtue. It's good to remember this contradictory and somewhat amusing claim, because it's all too easy to forget why computers and computer programs - along with all other technology - were originally invented.

A new nuclear power plant is currently being built in Finland. Before the decision was made to build it, there was lively debate for and against nuclear power. One Member of Parliament who debated the question suggested that more nuclear power would be bad for Finland because the other ways of producing energy employed more people. Now, I must emphasize that I think there are many good reasons not to build more nuclear power plants in the world, but this was the most ridiculous argument I've ever heard, and I retain the right to laugh in the face of such an absurd argument.1

Naturally, you could actually produce electricity by having all the unemployed people in Finland pedal exercise bikes hooked up to dynamos, which in turn would be hooked into the power grid. That would probably give enough energy to light a fair-sized village, not to mention the added benefit of guaranteeing employment for everybody. But you'd be crazy to do it that way.

Surely, the point of having electricity is to free people from having to work so hard. We've come up with machines that run on electricity and do the job for us while we lie on the sofa watching television, which also runs on electricity. Lots of politicians seem to forget this, particularly when they talk about unemployment.

Don't misunderstand me. Losing a job can be one of the greatest misfortunes to befall us in life. Many people would rather be both ill and divorced, as long as they could keep their job. And some unemployment almost always follows technological advances. When the tractor was invented, farmhands lost their jobs and people moved to the cities. Luckily, they found manufacturing factories there, and got themselves jobs working on conveyor-belt production lines. But today, when a factory updates its production lines, one result of installing more advanced production machinery is that it inevitably requires less people to run it. And, once again, working people are made redundant.

But don't blame the engineers. Thanks to engineers, we no longer have to ruin our backs ploughing the soil. Thanks to engineers, machines now do the heavy work in factories with people overseeing it. Thanks to engineers, most of us have more free time to use in any way we choose, which is what we wanted when they were still inventing the tractor. The point of inventing and developing machines, computer software, and suchlike is that we won't need to work - or at least not work so much.

It's an unfortunate conundrum of modern society that the work that is available is unequally divided so that some people work as hard as ever in the factories, while others are left entirely without work. Perhaps here, too, we should learn from the Open Source way of thinking and employ the principles of openness and sharing. Perhaps the engineer who invented that first tractor actually meant for everybody to have some work to do - enough, but not too much - and for us all to enjoy our fair share of idle moments too.

• 1Tee hee hee. Woah woah woah.

We'll leave the values of Linus and his friends for a while and turn to learning something from the organization and hierarchies of the Open Source community. How do you control a programming project that involves tens - or, in the case of Linux, hundreds - of programmers working in different parts of the globe, particularly when the workers are volunteers who have no official status as employees on the project?

Linus is the benevolent dictator of the Linux project. He didn't coin the expression himself; it comes from Eric Raymond's essay "The Cathedral and the Bazaar', in which the author studies the various organizational forms of Open Source projects. Although the dictatorship model is not the only way Open Source projects are run, it is by far the most common and the least formal. Guido van Rossum, the creator of the programming language Python, is known publicly in Python circles as BDFL - Benevolent Dictator for Life. Apparently Python programmers have no intention of ever letting poor Guido enjoy a well-earned retirement.

A benevolent dictator is the leader of a project and the person who alone has all the power to make decisions.1 Often this authority is a natural consequence of the leader being the instigator of the project, as Linus is in the case of Linux.

For those of us living in Western democracies, talk of dictatorship could sound suspicious. Although the directness of a dictatorship is sure to be cost-effective and helps to create a light organizational structure, history has taught us something about the problems inherent in such a system. Alas, few monarchs or dictators have ever been known for their benevolence. So, despite the cost, inefficiency and frustration caused by the negotiations, compromises and voting in a democracy, we have learnt the lessons of history and chosen to live under a democratic system of government. Linus Torvalds may score well above average for benevolence, but can we really trust that his successor - when that day comes - isn't a total disaster?

The answer is yes, because it isn't as if Linus is the leader of Linux by chance and it's just a lucky fluke that he is benevolent. Actually, it's quite the other way around: he's the leader only - and I repeat - only because he's as smart as he is.

The principles of Open Source generate a curious dynamic, which directly influences the hierarchy of the project organization and the relationships of its members. What would happen if for some reason Linus decided to screw things up and out of spite started making stupid decisions for Linux? Within twenty-four hours the other Linux developers would leave him to fool around on his own, make a copy of the Linux source code somewhere Linus couldn't get his hands on it and keep working without him. It's also extremely likely that the hackers involved would quickly elect - more or less consciously and more or less democratically - a new benevolent dictator.

All that is possible because the code itself is open and freely available for anyone to use. As dictator, Linus has all the authority while at the same time having no power whatsoever. The others see him as their leader only because he is so talented - or benevolent. There is a fascinating equilibrium of power and freedom. The dictator has the power and the others have the freedom to vote with their feet.

But in some other environments the dictator model doesn't work so well. If your boss isn't up to his job, it's a bad thing, but what can you do about it? The army must blindly obey its commander-in-chief, but if he proves to be a sick tyrant what choice do the soldiers have about what they do? Such situations lack the openness that is inseparable from the Open Source process. Without openness there can't be complete trust in other members of the organization; instead, we are stuck with having to use the unwieldy processes of democracy to protect ourselves against power struggles and a variety of other forms of mean-spiritedness. Openness is so integral to the system of an Open Source project that such precautionary measures aren't necessary.

As a dictator Linus Torvalds is living evidence of the benefits of the openness principle. Openness leads directly to Open Source projects being free of the usual excess of inhibiting project organization, and to them getting along in a way that is surprisingly lightweight, nimble and cost-effective. Could that mean the dictatorship model might work in a more traditional organization? There is at least one example of it being so.

The World Wide Web Consortium (W3C) is a standardizing organ that has created nearly all the technologies that constitute the World Wide Web. Standards published by the W3C are, among others, HTML, CSS Style Sheets, XML, DOM (part of JavaScript), the PNG and SVG image formats and lots of other technologies of which we make daily use by surfing the Web. Some 450 IT businesses and organizations are members of the W3C, beginning with Microsoft and IBM.

Interestingly, the decision-making process of the W3C as it prepares standards resembles that of the Open Source dictatorship model. Preparation of a standard is done in a working group specialized in the field, and it works very openly. Trial versions of the standards are released so that anybody can comment on them. When the working group is ready, the proposal is brought to a vote. All member organizations are eligible to vote and each of them has one vote.

After the vote the W3C leader alone either approves or discards the proposal, no matter what the result of the vote. In practice, the W3C strives to get everybody in agreement, but the decision-making system itself clearly resembles the benevolent dictator model.
Since the W3C was founded, Tim Berners-Lee has been its leader. He is the same guy who developed HTML and other Web technologies while working at CERN in the early nineties. He is the Linus Torvalds of the Web - creator and dictator.

As at the W3C, decisions regarding the development of Linux are usually made after thorough discussion. Linus in particular takes the advice of his closest and longer-term colleagues, who within the community are known as his lieutenants. These lieutenants are like mini-dictators, and each one has their own area of responsibility within the project. Just as for Linus, their authority is based on talent proven over a period of years and the trust that it has generated. The dictatorship is therefore a meritocracy.

There have also been instances where, despite Linus being against a particular solution, he has grudgingly had to accept what is wanted by the majority. If he didn't, one day he might not be the dictator anymore. The open system works lightly, but is nonetheless democratic.

• 1At this point, I'm sure, all the project managers reading this woke up and started to pay serious attention!

Having acquainted ourselves with some of the interesting features so characteristic of the Open Source community we will now consider other aspects of it. It must be said that tolerance is not a characteristic of this fascinating community, nor a prerogative of it. If you look at various discussion groups and mailing lists, it's easy enough to find numerous examples of Open Source community members who are anything but tolerant. Despite this, there are plenty of inspirational tales of tolerance that can be told about this community.

Once again, let's go back to Linus Torvalds and the years when the IT press discovered the fascinating and fresh operating system called Linux. This was at a time when Microsoft had managed to create a monopoly in both operating systems and office programs and was putting all its weight behind finally crushing Netscape, its rival in the browser market. This was a time when users had good reason to groan about the lack of alternatives, and were annoyed by the Microsoft monopoly and the abuses it entailed, and also by the flaws and surprising quirks of Microsoft programs, including the animations of squirming paper clips. In computer circles, people were actually beginning to see Microsoft as the root of all evil, hence the term the Evil Empire. Naturally, being the new kid on the block, Linux was of great interest to IT journalists, particularly considering whether David had come to slay Goliath? Would Linux dethrone Microsoft?

Once more, Linus Torvalds had a surprising but wise answer. He stated that Microsoft and its programs were of no particular interest to him, since he didn't use Windows himself. He had worked on Linux for his own amusement, not because he had an axe to grind with Microsoft or anybody else.
Although many of Microsoft's competitors, then and even more so today, see Linux precisely as the OS to challenge the Microsoft hegemony, it is important to understand that for Linux developers that is not a primary consideration. For the most part, they really don't have an opinion about the whole world of Windows, because they use Linux.

Having used Microsoft software myself, I completely understand the journalists' view, but it is nonetheless hard to imagine that Linux would have been such a success if its main raison d'être had been merely to replace Windows. Programmers involved in such a mean-spirited project are unlikely to have been as innovative as those working on Linux, who put in their hours out of love for OS programming. From the outset, such a project would have been doomed to become no more than a Microsoft-aping dog with more bark than bite. Sure, perhaps it could challenge Microsoft products in some areas, but in others it would be just as lame and unimaginative as that which it was intended to outdo.

More than anything, however, Linus Torvalds' tolerant attitude makes sense for the sake of his own mental health. It's not healthy for one's central motivation to be hatred and fear. And, what if one day Linux did manage to bring down Microsoft? Would life then lose its meaning? In order to energize themselves, would the programmers then have to find some new and fearful threat to compete against?

People whose actions stem from this idea of having to outdo some perceived threat usually end up in just such a vicious circle. Take the US Army, for instance. You'd have thought that the fall of the Soviet Union would have been a happy day for American soldiers and CIA spies. It was no such thing. Far from it! All it meant to them was looming unemployment. They therefore needed to conjure up a new threat somewhere and find it fast. First they tried painting dark clouds in the shape of international drug dealing. For some reason that didn't quite have the cachet of an enemy nuclear state, so they had to look elsewhere. Now they've finally got their ideal enemy. Terrorists. They are apparently everywhere, but can't be found. That means there's plenty of work to be done in defending the nation, the money keeps coming in, and motivation is high. Again, the United States of America is a force to be reckoned with.

Although it's even more fun to pick on US foreign policy than on French farmers, we need to remember that more than anything we are now talking about ourselves and what motivates us. Lots of people build their lives on just such threat-based thinking and manage to create great drama out of this or that. It is the source of their vitality. Yet, if they chose to, they could be living happy and satisfying lives working on their own Linux, without wasting their energy on the artificial drama with which they surround everything.

To me, Linus Torvalds' example of tolerance shows great insight. As a talented programmer he cannot accept programs with bugs on his own computer, but their existence as such does not bother him. He can do a better job of writing code himself and is happy with the work he does. At the same time, it wouldn't bother him at all if everybody else wanted to use Windows instead of Linux. After all, that's not his problem. In a world of power struggles and perceived threats, Linus's tolerant attitude is breath of fresh air and an open source of peace of mind for everyone.

In the summer of 2003, someone wrote to the Open Source website Advogato to say he thought the market of Open Source software was too splintered and confusing. Counting only the text editors, it included over 100. Being someone who had just switched to Linux, this made him feel lost. It would have been easier, if people could have agreed on which editor to use, developed it to its peak, and taught everyone how to use it.

This suggestion wasn't particularly well received. Most responses to it just said that the writer must not yet be very well acquainted with Open Source. The 100 editors are a sign of the wealth in the Open Source world. Naturally, it is true that most of them may be somehow deficient and were born as an assignment for some computer science student. But why is that a problem? It's great that he too published his work for open use, even though I don't happen to use that particular editor.

And also, as simple a thing as editing clean text files may actually require very different tools. For instance, the vi editor was created in the seventies and must be one of the simplest and most clumsy tools ever seen in the computing world. Despite this, or actually precisely because of it, it is part of the Unix standard and will be found in all the Unix machines in the world, including all Linux computers. So, if you learn to use vi, you can rely on getting the job done. It works on all platforms, regardless of whether you use it over a remote connection on a "terminal' or in the graphical user interface (GUI) of a standard desktop PC. But in the latter case, you may want to use a more versatile editing tool, designed for a GUI environment. So you choose one of those. In fact, many of us choose the software we use based on personal likes and dislikes - such as colour. So, although it is an appealing idea to get rid of overlapping work by developing only one text editor, or a couple of editors at most, the problem would soon arise of how to choose which one should have the honour. Who gets to judge what taste other users should have?

This kind of splintering is also evident in another area. That is, the Linux universe currently has two windowing environments: KDE and GNOME.1 This occasionally gives rise to concern among Linux users. Even though the programs made for GNOME work in KDE and vice versa, they may look different and follow slightly different principles. In all fairness, this can seem very confusing for a novice. One could also ask whether it makes efficient use of the available resources. Could there be a better way of employing programmers than by spreading their effort over two competing projects?

However, despite all the problems I've mentioned, the Open Source community is unanimous in feeling that the diversity available in Linux - even though it is sometimes inefficient - is valuable. We must always return to the guiding principles of Open Source, as discussed earlier in this book. Programmers do whatever they like to do - what excites them. If someone wants to make GNOME software, who's to stop them? And who loses if someone makes GNOME programs, even when everyone else wants to use KDE programs? These principles inevitably lead to diversity, because the Open Source community is not Soviet Russia, where everybody must follow whatever five-year plan is currently in force.

There are also benefits to be gained when different projects compete with one another. The making of graphical user interfaces is a relatively young science, and nobody really knows which is the one and only right way of getting things done.2 Competing projects may come up with different solutions to the same problem, and not until later does it become clear which of them provided the wiser and smoother solution. Thus, the existence of two separate projects lessens the risk of the GUI world of Linux ending up in a technological cul-de-sac.

Competing projects are also genuinely useful to each other. Even though from the outset KDE has been more technically advanced, GNOME was originally considered a very artistic environment. By using different themes users could make their own environment look very different to that of their neighbours, in effect customizing the look of their computer to suit their own individual taste. Surprisingly, many people particularly like to have this feature in their computer. What wallpaper you use and the colour of your program can sometimes seem a lot more important than what is actually done on the computer. So, the KDE programmers have put a lot of effort into developing these features in their own project and today KDE is at least as colourful and artistic as GNOME. Similarly, in order to catch up with KDE, the GNOME developers have worked hard to improve the stability and technical qualities of their environment.

So, competition obviously benefits both parties. Luckily, the developers of KDE and GNOME understand this. Even though there's a lot of debate on the Internet about the various merits of KDE versus GNOME - and sometimes, in the spirit of the Advogato writer, someone suggests that one of the projects ought to be shut down in the name of simplicity - the people who engage in such debates are never the programmers involved in developing either KDE or GNOME. Firstly, they don't have the time to engage in futile Web debates, because they have better things to do. But more essentially, they don't see each other as rivals. Instead, they recognize competition as a form of collaboration, despite the rest of the world not always seeing it that way.

This leads us to a final question. How does the rest of the world view it?

Even though by definition the Western market economy requires free competition, in reality companies don't always see it as a good thing because competition tends to mean less money in their particular till. Therefore, it seems the smart thing to do is to get rid of the competition, by whatever means. Microsoft is a prime example of how financially rewarding this strategy can be - when it works, it is very lucrative. This leads to Western companies - who one would expect to believe in a free market economy, and who probably genuinely think they believe in that - in practice, doing all they can to prevent competition. If one believes in the validity of the Open Source way of working, then companies that try to crush competition are actually digging their own graves.

• 1A windowing environment is the part of a computer program that creates a so-called graphical user interface on the screen. Other programs are used within this environment, and are activated by pointing at them with one's mouse, etc. Its opposite is a terminal or command line interface, usually operated via a keyboard, where the letters on the screen are a light colour against a dark background, and only one program at a time is used.
• 2Even though Apple and Microsoft have made graphical user interfaces for more than a decade, this is a relatively short time and theirs are only two views on how to do it. Even the Windows user interface has developed and keeps developing - XP has recently moved to a new look and Microsoft has announced that it works with a project called Longhorn, which again will lead to new technologies and practices. In addition, the X windowing architecture used in a Unix-type OS that is different to that of Windows or Apple, so the Unix world cannot take everything from Windows, but in any case the developers of KDE and GNOME have to do a lot of genuine pioneering work.

The installation guide to the popular Linux distribution Debian Linux includes a slightly scary term borrowed from electrical engineering to refer to the first time you start the computer after installing the operating system. It calls this first test run a smoke test. Originally, electrical engineers used the term smoke test in their building projects. For instance, after soldering components to a circuit board, they must then hook it up to the current. If the work has been done correctly, the circuit board operates as intended. If, on the other hand, there's a short circuit somewhere, the typical response would be for the soldered components to pop off the board and produce a wisp of smoke - a sure sign that the circuit board wasn't working.

Being immaterial, a computer program can't produce smoke, of course, but just the same the first time you start a computer with a newly installed operating system is always a moment of truth. It either works or it doesn't. The only way to find out is to try it.

Much like engineers, Linux programmers are driven by a burning sense of curiosity. For instance, they really want to know what new and fancy features Linus Torvalds' latest version of the Linux kernel will have, even before the kernel is complete. These unfinished Linux versions are called development versions, because they haven't yet reached the release stage. Although it's not recommended that you use them, they are just as available on the Internet as the officially released versions, and many a curious Linux user does come to use them before the final release.

Acting on this curiosity takes a kind of foolhardy courage, as there's always a risk in using an unstable development version of a new computer program. It may not work. And, particularly when the newly installed program is an entire operating system, there's always the risk that a malfunctioning program will tie your computer up in knots - such serious knots that you may lose all the data you had on your computer. Nonetheless, curiosity often wins out, and the eager user will disregard all risk and dull cautionary measures and give in to the irresistible temptation to try it out.

I was once given a laptop to work on but its battery was failing. I wanted to know if the battery was completely dead, or whether it was of the common sort that can keep a computer up and running for about five minutes before it finally conks out. Naturally, there are many ways to establish this, including, for example, sending the battery away to be serviced or borrowing a multimeter from an electrical engineer … or use another method which is by far the quickest and therefore the best way for me to satisfy my curiosity.

So, I pulled the plug on my laptop. It died instantly. Which was unfortunate because I'd forgotten to save the text I'd been writing. However, despite this setback, my curiosity had won and the test had told me immediately what I'd wanted to know: the battery was 100 per cent out of order.

It may seem odd to describe Linux developers as courageous. The stereotypical image we have of an average computer programmer is of someone who is very likely to be shy, cautious and quiet, a person of perpetual bad-hair days, wearing unfashionable glasses - a nerd. I'm not suggesting all programmers fit the stereotype, but Linux programmers are often as close as you can get to a real-life version of it. That's why it's so surprising that such a bunch of nerds could be considered brave, but the anecdote above does indicate that nerds, despite their tendency to be shy and cautious, are courageous when it comes to computers. Their curiosity about computers overcomes all caution and can transform the shyest nerd into a courageous pioneer.

So far, this book has portrayed the Linux community as an admirable model for us readers, but this section on courage might be where the shy nerds at the heart of that community have the most to learn from themselves.

Let's imagine, for instance, what would happen if a shy and cautious nerd is sitting alone at a table in the lunchroom at his college or place of work, when a beautiful woman he doesn't know sits down opposite him. The most likely scenario is that absolutely nothing would happen! The nerd would stare at his food, eat it in silence, and leave. If the beauty on the other side of the table also happens to be a timid and quiet nerd, she is likely to do the same. Nothing can happen even by accident, despite the fact that these two people could find one another of interest.

What is the train of thought going through the nerd's head that leads to nothing happening? He'd certainly be interested in establishing contact with the beauty opposite, so surely he ought to speak to her. But nothing sensible comes to mind, and therefore no contact is made. Obviously, he should say something, anything, but then the nerd fears the beauty might think him stupid. And besides, such a beautiful woman would surely have been snapped up already, and even if she hadn't it's highly unlikely she'd be interested in him. The nerd daren't risk being turned down. He fears if he said something the answer, or rejection, might be chillingly polite. The nerd really doesn't want to risk that. So in the end the nerd says nothing, and that's what happens.

If the beauty were a computer, the nerd would behave differently - courageously. With the beauty sitting opposite there would come a moment of truth - time for a smoke test! The nerd would say something, despite the high likelihood of getting a chilling puff of smoke in the face. It's not as if this nerd hasn't had his share of failed smoke tests with computer programs, and they have never slowed him down. Actually, the nerd doesn't even see such failures as failures. They are just different experiments and just as much fun and educational as the successful tests. And it's only through failed smoke tests that you finally get to the ones that don't fail.

Had the nerd applied this same logic to approaching the woman, he'd have spoken to her right from the start. Her reaction would either have been positive or negative. But as far as the nerd is concerned, both reactions are useful and productive, because they immediately satisfy his curiosity and desire to try new things. Not even a rebuff means failure for the nerd; it's just a smoke test and whatever the result you are then free to go on and try something else.

Interestingly, the Open Source community which swears by openness and sharing does hold on to one thing, its names. And they do so to such an extent that this community, which has turned ownership and copyright practices upside-down, sees trademarks - which equals legal protection of a name - as a relatively positive thing. Linux, for instance is a trademark registered to Linus Torvalds, which means you can't call just any old operating system or some other software Linux. Linus allows only operating systems built on the Linux kernel released by him, and later modifications thereof, to be called Linux.

Respect for the name of a person or project is also one of the defence mechanisms of openness. The term Open Source itself is protected, and you can only use the term "OSI certified Open Source' about programs that meet certain criteria of openness.

In the Open Source community, everybody is openly what they are - themselves. In releasing new versions of Linux, Linus Torvalds uses his own name. You can trust that a program called Linux is actually a program by Linus, and not something else. The name Linux guarantees the quality. The person who has worked to create a certain product personally guarantees its quality. And at the same time the work gives him or her credit. The programmer usually becomes famous as a result of their program. Even though people are happy to share the fruits of their labour, the kudos is not shared. And how could you, that wouldn't even be honest. Honour where honour is due: the person who did the job should get the credit. In a community, where everything is open and shared, this is something to hold on to. You've got to be able to trust some things.

But the Open Source community's relationship with names is a lot stronger than mere questions of trademarks or branding. Some words are closely connected to the identity of the community, and these people are willing to fight for them, even when the rest of the world may not quite understand what the fuss is about.

One of these identity-charged words is hacker. Most readers of this book will probably understand hacker as synonymous with computer criminal. To them, a hacker is a person who breaks into somebody else's computer system through the Internet, reads confidential files and perhaps also wreaks havoc in the invaded computer system. Even IT journalists erroneously use the word in this sense.

In the Open Source community, however, the word hacker has a very different meaning. In the early days of computers, in the nineteen-sixties and seventies, programmers at MIT and other American universities called themselves hackers. As the Unix OS (operating system) evolved, the word spread to the community surrounding it. Unix programmers were known as hackers or Unix hackers and they were still mostly university people. The word had no criminal connotation, rather it purveyed the notion of a very talented programmer, a guru and member of the Unix community, of someone who was passionate about programming and technology.

The ideology of the early hacker culture was very similar to the present-day Open Source culture. Not that there was such a concept as Open Source; it was more that all computer programs were open. For a culture that had been born in university circles, this was perfectly natural. The transition to the closed software culture we came to accept as normal didn't come about until the eighties, and it also caused the hacker culture to get a bit side-tracked. The mean-spiritedness that led to the manufacture and sales of closed software was in no way part of hacker culture.

At some point the press started reporting on information break-ins and for some reason began to call the perpetrators hackers. To begin with, it may not have been such a bad name to use because, unlike now, in those days anyone able to break into a computer system had to possess a lot of skill and talent, so in that sense they may well have been a genuine hacker. But from then on, the word hacker came to denote a computer criminal.

I've often wondered why the members of the Open Source community are so stubborn about still calling themselves hackers? The original meaning of the word has been so completely overshadowed by the new definition that it seems downright odd for any law-abiding citizen to still want to be referred to by that name. Even people working in the computer business are often confused, because the original meaning of the word hacker is not well-known outside genuine hacker circles. One ill-informed journalist even managed to write a long article about the notorious computer criminals who had created a new operating system called Linux! Apparently, nobody had ever told him that the meaning of the word hacker had become corrupted. Reading his article, I didn't know whether to laugh or cry.

But I do understand the hackers. How could anyone give up the name that defines their identity? The name that carries such a long and honourable history, harking back to the first computers and artificial intelligence laboratories.1 The name that epitomizes the ideological foundations of the whole community, the foundations that Richard Stallman says so much about and that the philosopher Himanen so loftily proclaims in his book The Hacker Ethic. Despite all the confusion, hackers are proud to be hackers. And I have to admit I understand that with all my heart. It's not as if we Finns would change the name of our country just because the word finni or finne means a zit in a number of other languages!2

There is another story to do with words which engages hackers as strongly as does the word hacker. But this time it's about words that don't unite hackers but rather cause strife among them.

When commercial closed software took over more and more from the hacker culture within universities, one man decided to make it his life's work to fight the mean-spiritedness of the corporate approach. In 1984 Richard Stallman announced that he had founded the GNU project. The aim of the project was to produce free software - or rather, Free Software - and one day release a completely free operating system.3 Richard Stallman was not your average propeller-head. He really was 100 per cent committed to his project. He resigned from his job as a university researcher to ensure that the university could have no claim of ownership on the programs he made, which they could do if he had developed them while employed by them. Stallman's boss at MIT was himself something of a visionary. When he realized why Stallman was resigning, he ordered that Stallman's former office and other university services - particularly the computers - would remain available for him to use. Without such insight the project would probably not have amounted to much. In dire straits financially, Stallman even lived for a while at his MIT office.

And so began the history of Free Software. The project was obviously a success, because as early as 1991, when Linus Torvalds started working on his own project, nearly all the tool programs were ready and even the missing Hurd kernel was almost complete. When Linux came along at the right time to fill this gap, Stallman's dream was finally coming true.

Most of the nineties was spent on an Internet high, but people didn't know much about any free operating system. However, under the surface spread of the Internet also fomented the development and distribution of Free Software, because through the Internet more and more hackers could get involved in the worldwide effort of jointly barn-raising Open Source. And, although there was not much being written about Linux in the press at the time, in reality most of the Internet servers in Finland, for instance, were already running on Linux. By the end of the decade, both the press and the corporate world were seriously interested both in Linux and the open development models that had given rise to it.

At this point, a group of leading hackers got together to discuss the situation (not computer criminals, that is, but the leaders of the Free Software community). They realized that their time had finally come. The hacker culture that had almost passed into history was back and it was challenging commercial software companies. The corporate world was genuinely interested in Free Software. But how could they make the most of the situation? How could they get companies to invest in Linux systems? How could they get the software companies to switch to an open development model? And how should they prepare for the inevitable counter assault from Microsoft?
What the hacker fathers decided was that Free Software needed a new brand, a brand which would take a lot of PR work to establish. That's how in early 1998 the term, or brand, Open Source was coined.

How did they come to settle on the name Open Source? Richard Stallman's term, Free Software, had been taking some heat for being ambiguous. The word free, which used to refer to freedom, could be taken to mean free of charge. Talking about programs for free didn't sound like a good idea, considering these guys wanted to get the software companies involved. And merely having to discuss the semantics of a word is confusing in itself, as it is bound to lead discussion away from the thing that really needed to be talked about. A brand should be short and succinct, not confusing.

Of course, Richard Stallman had to sort out the same semantic problem a lot earlier, and he'd come up with the catchy mnemonic, free as in speech, not free as in beer. Free beer is great, but free speech is rather more important. And this was the freedom Stallman liked to speak about - and that was part of the problem. People might have been able to live with the ambiguity of the word free, but when it relates to computer programs and somebody starts spouting about freedom of speech, it starts to eat away at their credibility. And that wasn't all. Stallman was also happy to expound his opinion that the closed software model was actually unethical!

All this talk was the real reason the term Open Source was coined. The other hacker elders had decided to distance themselves from the ideological rhetoric of the otherwise honourable GNU project. That didn't really sit well in interviews with newspapers like the Wall Street Journal. A new identity was needed, one that would work both on Wall Street and in software companies. Tangle-haired Richard Stallman was out, and instead they offered the smiling poster boy Linus Torvalds.

But to create this new identity, they needed a new name. Open Source stated clearly what it was all about: the source code was open and available. Openness lead to quality, as Eric Raymond had explained in his essay, "The Cathedral and the Bazaar'. Open Source equals quality. If you want the best software, give up Windows and use Linux! If you want the cheapest alternative, use Linux! We know nothing of ethics, but we do know what works best when it comes to programming computers: Open Source!

The Open Source brand was a phenomenal success. Linus Torvalds was smiling and smiling and smiling on magazine cover after magazine cover. On its first day of trading, the Linux company Red Hat's stock quadrupled. Little by little, companies started using Linux more and more. Netscape become the first closed software to open up its code, becoming the Open-Source-based project called Mozilla. Others have followed, including an OpenOffice word processing program previously known as StarOffice, which is the one I used to write this book. But first and foremost, the press and the public got to know of the concept of Open Source.

But not everybody was happy. Richard Stallman didn't approve of the use of the term Open Source. He felt it was important to understand the ideology behind Free Software, not just settle for "using what works best'. And although the Open Source camp made its biggest advances outside the hacker community, many within it stayed true to Stallman and the original ideology of Free Software.
The bitterest fights between the supporters of Free Software and those who espouse the term Open Source are happily in the past, but you can still tell which party they belong to by listening for which term they use when speaking of Linux. It's not just any choice of words. It's all about identity and the ideology behind it. And the hackers hold on to those.

• 1That's another funny name. Even though computers have developed amazingly since those days, true artificial intelligence has yet to be invented. To us today, computers of the sixties were nothing but electricity-hogging heat resistors whose calculating power couldn't compete with that of the simplest pocket calculator. Even so, the term artificial intelligence was bandied about at the time.
• 2Next time you talk about computer criminals, it would please the hackers if you used the term they use: crackers. I, at least, would like to reserve the word hacker for those people of high principles about whom this book is written.
• 3Which, ten years down the line, Linux became. To a large extent, it's the GNU project we have to thank for that.

Surprisingly, the struggle between the two camps of Free Software and Open Source leads us to a fascinating question: What is ethics?

The archetype representing the Open Source camp is, of course, Linus Torvalds whose attitude can be described as pragmatic, practical and engineery. In addition to this approach being natural to Linus, he also believes his position as leader of the Linux project commits him to being as neutral as possible. That's why he doesn't want to get involved in political issues. His maxim is more or less, we do what works best, and in programming Open Source is what works best.

Richard Stallman, father of the Free Software side, considers it very dangerous to limit oneself to such simple thinking. He thinks there is a significant difference between open and closed software development, and this difference influences things as important as equality and the transparency of State administration, but also important technical issues such as data protection and trust. All this leads directly to the conclusion that, more than anything else, the question of the best model for developing software is an ethical one.

So what is ethics?

Mad cow disease - or bovine spongiform encephalopathy (BSE) - was caused by feeding cows a mixture of meal made from the brains and bones of dead cows and sheep. I don't know what's wrong with European farming, but here we go again! Since good brains were going to waste, somebody thought it would be a good idea to feed them back to the cows and save the money farmers would otherwise spend on real feed. A few years later we had mad cow disease and tens of Europeans dead as a result of eating the beef from these cows.

Although Finland was spared this epidemic, which mostly devastated the British farming industry, the crisis was widely discussed here. On a TV chat show, a farmer from the north said that in the early nineties feed which had included brain matter had been offered to farmers in Finland. However, Finnish farmers considered that having cows grow fat on the offal from other cows was completely unethical and they refused to buy the feed.

So, in northern Finland we had a farmer who spoke of what is ethical. Today, the infamous "meat-and-bone meal' is banned throughout Europe. Yet, ten years earlier, farmers in Finland had refused to use it because they didn't think it was ethical! And since the meat-and-bone meal had not been used here, Finland was spared mad cow disease and the tragic consequences that followed it in other parts of Europe.

In hindsight, it's easy to say it would have made sense to ban the meat-and-bone meal from the outset. It ought to have been clear to anyone that cattle shouldn't be fed such fodder. If no farmers had ever fed their cows the meat-and-bone meal, Europe would have been spared the unnecessary loss of life and livestock caused by the epidemic. But how could anybody have guessed all that would happen?

A good question! And yet there were farmers who chose not to use the meat-and-bone meal - not for any practical or scientific reason but because they found the idea of it unethical. In hindsight, their taking an ethical standpoint saved lives. And in hindsight that's what worked for the best.

In a way, when the adherents of Open Source speak - with political incorrectness - of "only what works', they are right. But could Richard Stallman have used the same argument in 1984, when the business world was moving only in the direction of closed software? Because the field of software as a whole was so young, there were no facts and practical experiences to draw on to defend either model. So Stallman was forced to talk about ethics. And he was right, but that didn't become apparent until much later.

In a sense, the reason Stallman, too, ended up making his Free Software crusade was that he found that closed software didn't work as well as the free kind. In his essay "The GNU Project', he tells of an office printer they had in the lab at MIT. Because it was encumbered with a clumsy driver program, using the printer was extremely frustrating. Being a talented programmer, Stallman knew he could easily fix the problem, but the company that sold the printer refused to hand over the source code of its software! This episode affected Stallman's later conclusions.

So we've come full circle. When Linus Torvalds sticks to his "only what works' line, he is actually talking ethics! Ethical solutions are ethical precisely because they are the right ones. And the right solutions are right because they work.