Considering that almost all Open Source programs are available on the Internet to be downloaded free, a surprising number of companies have built their business on selling the Linux OS and associated programs. These companies are called Linux distributions. Best-known among them are probably Red Hat Linux, SuSE Linux, Mandrake Linux, and in Finland the Finnish-language version called SOT Linux. Only a few years ago all these companies generated most of their revenue by selling Linux CDs packed in colourful cardboard boxes, in the same way as established software companies.

This business model can be explained by analogy to water, which is free, yet selling it can be good business. And I don't just mean selling water to people living in deserts. We all buy water daily when we turn on the tap. Even though tap water isn't very expensive, paying our water bills certainly pays for staffing at a water purifying plant, and for a few plumbers too. In addition to tap water, most of us also buy bottles of Evian or some other expensive spring water. So selling water can be a profitable business in more ways than one.

Although there are many Open Source programs available for free on the Internet, it's a lot more practical for users to buy a bunch of CDs and get all the most important programs at once instead of having to spend hours on their slow Internet connection, gathering them for free off the Web. In this, the analogy of selling water is interesting, because on the CD market, too, there are two kinds of compilations. Some companies have specialized in making CDs with as many different programs as possible on them and selling them cheap. This is the tap water of Linux distribution. On the other hand, we have companies like Red Hat that sell CDs under the protection of their own trademark and with their own logos - and the funny thing is, people are happy to pay a little more for a genuine Red Hat Linux rather than buy a no-brand CD with more or less identical content.

In many ways, this selling-water business model is a lot like that used by established software companies. In both cases, the business is based on selling software on CDs. However, the similarity is usually only skin-deep. When you buy software from Microsoft, for instance, you don't necessarily buy the CD because you need the CD itself, but because the law says you have to buy it if you want the right to use a particular program. If you have a second computer at home and you want to run the same Microsoft Office software on it, you should buy a second copy of the software on another CD. You don't actually need that second CD, because you already have one with exactly the same content, but you have to buy it anyway.

However, Linux distributions that use the selling-water business model don't make anybody buy anything. If the CD is useful, you can buy it, but if you don't need it (because you can download the software from the Internet) you don't have to buy it and you certainly don't need to buy multiple copies of it. You can use the program anyway, whether or not you have bought the CD. Companies selling such CDs are OK with that and everybody is happy. The mean-spirited business model used by established software companies seems very artificial and a lot of ordinary computer users - laymen, if you will - find it hard to understand why they have to buy multiple copies of an expensive software CD they don't actually need, and really resent it. So, at least selling Linux distribution CDs as CDs seems rather more natural than the various artificial and mean-spirited sanctions imposed by established software companies.

The idea of giving software away for free and selling services for a fee was current by the mid-nineties. In a sense, the selling-water business model is one way of realizing this principle.

The main theory behind selling services is very simple. Free software isn't enough for most people, because your average computer user doesn't know how to install the programs, and needs help to get started. In addition to help with installation, many people would also benefit from a few tips on how to use the program. The simplest form of selling services is to provide an easy-to-use and helpful guide along with the software CD. That is, you don't necessarily buy the software CD to get the CD itself, but to get the User's Guide that comes with it.

Put that way, it's easy to see how easily a profitable business can be built around a free program. The above example is just the beginning. The really big business is in selling services to large corporations or communities with extensive computer systems. Installing Free Software on the 14,000 computers belonging to the City of Munich is a big job. Then, all the people who use the programs need to be trained. The transfer to a new system must be planned carefully and implemented as smoothly as possible, so as to cause as little disturbance as possible to the actual work being done. Some programs may need to be adapted - or tailored as it's known in the trade - to work smoothly with whatever internal information system is already in use. The users will need customer support and the computers will need servicing and updating. Antivirus and other protective software must be kept up to date at all times. And so on ...

The City of Munich is in the process of moving its entire IT infrastructure onto Linux-based systems. At the time of bidding, the contract to provide this service to the city was estimated at some EUR 35 million. So it's not really for free!

The services business model isn't really so exotic. Increasingly, all the big IT corporations that used to focus on selling computer hardware and/or software are becoming service consultancies.

Selling services is particularly interesting when it's built around Open Source software, because there is the same threat of monopolization inherent in support services for closed software or closed hardware that there is in the closed programs themselves. If, for instance, you buy an IBM supercomputer and the IBM AIX OS that goes with it, you're very likely indeed to require a bit of help in getting started.1 Realistically, you have to go to IBM to get that help, because not many other people understand these machines very well - at least not as well as those at IBM. And when it comes to tailoring and updates, you definitely have no other options than IBM, because the source code for these programs is not open. Only IBM employees have access to it and can make changes in it.

If you've bought an open system, however, you can get your service wherever you want. If you end up using a computer running Red Hat Linux, for instance, it's likely that you also want to buy the support services from Red Hat, because they are obviously the experts on their own product. But if you don't like their service or you think it's too expensive, you can get the service from any other company you like. There are plenty to choose from - anybody who has studied computer science in the past five years is likely to be able to help you. Tailor-made solutions and updates pose no problems either, because everybody has access to the Linux code.

Such competition is, of course, advantageous to the customer. At the same time, it also seems sensible and somehow natural. It makes sense for you to buy the services you need from wherever you get the best attention. The competition also keeps the companies that sell such services on their toes. The customer or client isn't bound forever to the same service provider just because they once chose to use their system. If the quality of service slackens off, you can always change your provider, which means they have to earn the loyalty of their customers by continuing to provide good service.

Another aspect of selling services also seems sensible and natural. When clients buy a service, they are buying work. That's opposed to buying a Microsoft CD, which you don't even need, and which doesn't cause Microsoft to work any harder. It's simply free money that just flows into Microsoft without them really having to work for it. At least services can be billed in some relation to how much work a commission requires. A closed computer program, on the other hand, can be priced arbitrarily and that's usually a losing game for customers and clients.

But selling services is also good for the business providing them. If sales of services are compared to sales of software on CDs - and this holds true whether it's a closed or open program being sold according to the selling-water principle - the selling of services generates far more long-lasting clients and therefore more lasting cash flow. A computer program is bought just once, whereas the need for support is usually permanent. Service contracts can even be made on the basis of a monthly fee, which gives a steady cash flow into the company providing the service. In return, the company must do a good job to keep the customer or client happy.

Any company whose business is based on one-off sales is always in a strange relationship to its customers or clients, because they should always try to get them the best possible product, but not so good that they won't be interested in buying a new and improved version of it the following year. This conflict occurs in many fields: for example, in maintaining a balance of fragility and strength in pantyhose for women. However, this has not yet posed a problem for Linux businesses. The Linux world has developed so rapidly in the past few years that Red Hat, for instance, has published two new versions of its Linux distribution in the busiest years. The world of Windows, on the other hand, is so much more mature that the updates published by Microsoft - particularly in the Office family - have seemed to be more like artificial ways of making more money. You should get the latest version, but nobody knows why. Realizing the problem, in the past few years Microsoft have tried to move increasingly into being a service-based industry and charging annual fees.

If you compare the business models of selling water and selling services, the latter of which is favoured by Linux companies, it is interesting to note that since the nineties all the major Linux companies have been trying to become service companies, yet, until recent years, most of their revenue was coming from sales of CDs packed in colourful boxes. In 2003, there was a clear change. Big jobs like the City of Munich are seriously opening the doors of the services market. Also, old Unix computers in many a company basement are busily being upgraded to Linux. At the same time, increasing numbers of Internet users are getting fast Internet access and have a CD-ROM burning capability, which makes getting Linux off the Internet and making CDs at home increasingly widespread, and thereby minimizing the importance of CD sales.

Of the big Linux companies, Red Hat suddenly decided in the summer of 2003 to stop making its cheap basic Linux. Since then the company has focused entirely on servicing the needs of its well-paying corporate clients, and based on its good accounts, there are enough of those. Red Hat is now selling its Enterprise Linux products wholly on the basis of an annual fee, that is, they've stopped selling cardboard boxes. In January 2004, SuSE was bought by Novell, an old and experienced software business, which means it now has a considerably wider and more experienced services network to offer its clients than does Red Hat. SuSE has made several successful deals with cities in Germany. Mandrake Linux, popular with many home users, has encouraged its customers not to buy CDs but rather to download their Linux from the Internet, provided they spend a corresponding sum on the Mandrake Club service.

• 1And why wouldn't you? The cheapest IBM supercomputer comes at a reasonable $21,645, though you are more likely to want one of the proper machines that cost around half a million. The deal includes an operating system and a year's worth of updates, so there's also a bit of service thrown in to sweeten the deal.

Experience has shown that working with a completely open business model has proved tricky for many Linux companies. As previously explained, the clients of a Linux company are free to demand the best and cheapest service, and to switch to other providers who may offer a better service. This puts Linux companies on the spot and many of them have tried to make things easier for themselves by including some sort of catch in their service agreements, something that will keep customers loyal despite the openness. We'll now take a look at two examples of this.

Red Hat is the best-known company selling the Linux OS and services, so in many ways it is fitting for this review of Linux companies to start with them. As a company Red Hat has always been strongly behind the Free Software ideology, and from the start they published all their own products under the same open GPL (General Public Licence) under which Linux is published. Despite this, there are some catches to be found in the company history.

Until the year 2003, Red Hat's best-known and most important product was the Linux operating system itself. Most users copied it freely from the Internet, but there were also a lot of other people who bought Red Hat Linux CDs from the stores. Even so, for a long time now Red Hat has worked to increase its revenue by providing services. And because the company employs some of the most talented programmers, or hackers, of the Linux world, the company's consultancy services have a certain credibility. The well-known Internet store Amazon, for one, trusted Red Hat consultants when porting its Web servers to a Linux platform.

Despite their hard work to improve their income from selling services, Red Hat's biggest revenue-generator in its first years of business was from selling Linux on CDs. But because it was also possible to download the same content directly from the Internet for free, many users acquired their Linux OS that way.

Inherent in the logistics of CD production is a certain difficulty in the selling of CDs, which was financially unfavourable to Red Hat. Once the contents of a CD have been compiled - i.e. Linux and other compatible programs - they can be published in digital form on the Internet the very next day. However, for the physical CD-ROM the journey to the retail outlets would only then be getting started. The time-consuming business of manufacturing the CDs, printing the covers, and transporting the finished product to the shops meant that by the time the CDs were available for sale they were often a month or even two months behind the identical software already spreading via the Internet. With such a long delay even those Red Hat users who would have preferred to buy a CD ended up downloading Red Hat Linux from the Internet for free because they didn't want to wait.

At one point, Red Hat tried to bypass this problem by delaying the Internet release of its latest versions. The new versions were distributed only after the physical CDs had been in retail stores for a couple of weeks. Although we can appreciate the logic behind this artificial delay, it did provoke some criticism. After all, it could be considered mean-spirited. Also, it may well have been an unprofitable tactic for Red Hat itself. Since Linux was then developing at an amazing pace, a delay of up to two months was quite a long time. Holding back the new version meant that their product was already out of date by the time it was published. The tactic also gave an edge to other Linux distributors, who released their own versions on the Internet without delay. After a while, even Red Hat seemed unable to believe in its own plan, and so gave it up.

In the Internet era, the most important task of any operating system provider has become the quick finding and fixing of bugs in their system. Flaws in programs can be used to break into computers, which is why it is important to fix them quickly and efficiently. In the past few years, almost all the viruses that have spread in the Windows world have made use of bugs either in Windows itself or in the e-mail application Outlook. Linux has proved more reliable than Windows in this, and has therefore not had the same kind of viral epidemics, but in theory all operating systems are similarly at risk. That makes the fixing of faults as soon as they're found one of the mainstays of computer security. In practice, this responsibility falls on the supplier of the OS, whether the company in question is Red Hat, Microsoft, or anyone else.

The flawlessness of the Red Hat system is based on the use of the up2date program and subscribing to the corresponding Red Hat Network service. For a client who has joined the Red Hat Network all the available updates are just a click or two away.

Red Hat's business is now wholly based on the sale of annual subscription fees for joining the Red Hat Network. The operating system sold by Red Hat is no longer even itemized as a separate product; getting the OS and a year's worth of updates is always a package deal. Pricing is also based on an annual fee, not on the one-off purchase of a CD. Today, Red Hat focuses entirely on its Enterprise products, which are seriously pricey. The annual fee per computer varies from the cheapest versions at $179 to $349 dollars to big computer server versions at $1,499 to $18,000. In addition to consultancy deals with big clients, the most important source of revenue for Red Hat is the up2date program and the Red Hat Network subscription fees.

The up2date program is closely tied to the Red Hat Network and its annual fees. Many other Linux distributions and the correspondingly simple update programs allow installation and updates through a third party. This benefits consumers, because it allows them easy installation and upkeep of the more exotic software which doesn't come with the Linux distribution itself. And that really is what Open Source is all about: for the consumer to have the freedom to build their computer from whatever programs best suit their needs. But this would mean that Red Hat's customers could update their entire operating system from some third party, and thereby do away with the need for the expensive Red Hat Network contract. Of course you can update Red Hat Linux without the up2date program, but all the alternatives require some amount of computer skill. The only way officially sanctioned by Red Hat is to use their Red Hat Network.

By forcing users of its up2date program to pay expensive annual fees Red Hat has, surprisingly enough, elected to get its revenue from a rather aggressive and very much un-open catch. Although the source code for the up2date program itself is open and follows the principles of Open Source, its use is surprisingly closed, considering the history and principles of Red Hat. It's not just about money - any business needs to make a profit - it's more about the mean-spirited limiting of choices. In order to make a profit, Red Hat has tied the up2date program to its own servers and thereby excluded the rest of the Internet and all the potential on offer there. Which means a Red Hat user is forced to make a choice that is disadvantageous to them. If you use Red Hat, you must get all your software through Red Hat. If you need programs that Red Hat doesn't offer, you have to make do without them. Naturally, it's possible to install programs from other sources than Red Hat Network, but because the up2date software doesn't support them, the installation and upkeep will cause unnecessary hassle.1

For the sake of comparison, we'll give all the companies presented in this part of the book a brief evaluation. Or perhaps verdict would be a better word. So what's the verdict for Red Hat? Among Linux companies, Red Hat is one of the strongest proponents of the Free Software ideology. All Red Hat's own software is also published under the GPL licence. Red Hat Network's closed nature is somewhat in conflict with hacker ethics, but is acceptable - barely.
Switching to a service-oriented business model and corporate products has been a financially viable strategy. In the fall of 2003, Red Hat published its first ever profit result and has stayed clearly in the black ever since. In the autumn of 2004, the company generated a profit of $12 million, which is a lot considering the turnover is only $46 million. After a strong growth, Red Hat has made a hit with its Red Hat Network, and has taken its place in the world of grown-up companies, where you don't get along on fancy technology alone, you also have to run a profitable business.

Verdict: Financially successful company whose actions can stand a hacker-ethical inspection, but there's still room to improve.

SuSE LINUX is a Linux company with strong German roots. Its history is as long and venerable as that of Red Hat, and it is generally considered to be number two in the competition between Linux distributions. At the beginning of the millennium, SuSE equalled Red Hat in turnover and number of employees, but then had some financial problems and almost halved its staff. The company stayed afloat, thanks to support from IBM.

Today, SuSE is seen as IBM's foremost Linux partner, and IBM's database and mainframe architectures are usually first to be supported by SuSE products. SuSE Linux is also supported by all the other big software companies, such as database manufacturer Oracle and super computer manufacturers Cray and SGI. With this in mind, it's easy to believe that SuSE, like Red Hat, employs some of the best Linux programmers in the world.

It made quite a splash in the Linux world when, in the autumn of 2003, the old IT giant Novell announced they had bought SuSE for $210 million. Novell is known for its NetWare operating system, which in the early nineties was the most popular OS for company intranet file and print servers. Although the company still has a large and loyal customer base, it has lost market share to Microsoft since the late nineties when many people saw Novell as something of an historic remnant in the IT business. However, in 2003 Novell decided to go with Linux and bought in top knowledge by first acquiring Ximian (more of which later) then a couple of months later the number two Linux distribution SuSE. IBM stayed in the equation, because part of the SuSE deal was that the company made a $50 million investment in Novell. Overnight, SuSE LINUX had become the product of an established, venerable and, importantly, a financially stable IT company, and once again Novell became a hot name in supplying netowrk servers.

The story of SuSE's survival teaches a lesson that has wider application. If you're a talented professional, you'll always land on your feet. In this instance, SuSE had become such an important expert partner for IBM, that Big Blue simply couldn't afford to let the company sink. IBM needed SuSE to realize its own Linux strategy and with IBM's support, the company survived its other less than profitable experiments.

The Novell deal was basically about the same thing. Because Linux is an operating system that is both open and free, there's no reason to pay hundreds of millions of dollars just to have your own Linux version. That wasn't what it was about: it was about Novell paying for and getting top-notch knowledge of Linux - and, if you want to know my opinion, they got it cheap.
As with Red Hat, the two most important sources of revenue for SuSE have been consultancy and the sale of CDs. Unlike Red Hat, SuSE continued to sell the packages suitable for the ordinary consumer.

The strategy SuSE originally chose for its CD sales has been severely criticized. In addition to the freely distributable open Linux programs, SuSE Linux comes with an installation and administration program created by SuSE and known as YAST, the licensing terms of which don't fall under the definition of Open Source. The installation program, and therefore the entire CD, can be copied freely, but you mustn't sell it. That is how SuSE prevents cheap clones being made of its Linux, something that always eats up some of the profits in other Linux companies. Furthermore, and unusually for a Linux distribution, SuSE CDs cannot be copied from the Internet, which means more users of SuSE have been forced to buy CDs to get what they want than have those using other Linux distributions.

Though SuSE has the full and legal right to define the licensing terms of its own programs as strictly as it pleases, I think it is reasonable to ask how they can justify putting in such restrictions when the rest of the contents on their CDs is Open Source and therefore freely available and free for the company to use. Where is reciprocity? And should we understand the SuSE strategy to mean that the second-largest Linux distributor doesn't think Open Source programs can really be used for profitable business?

Despite the well-earned criticism, SuSE has got off rather lightly and has always been a respected member of the Open Source community. Caldera, for instance, met with far harder resistance when they tried a similar strategy, and that company has since disowned its Linux enterprises entirely, having already burnt all the bridges behind it. The reason the SuSE strategy was received so much more kindly is that SuSE is actively involved in the development of the Linux kernel, the KDE windowing environment, and several other important Open Source projects. These weigh more on the good side of the scales than stepping away from the Open Source principle in one instance.

After Novell bought SuSE, the company published the above-mentioned YAST program under the same GPL licence as Linux, which means the SuSE catch is now history and we can forget all about the little flaw that once existed in an otherwise excellent Linux distribution. In this review, we've been looking at the old SuSE, with the catch still in place, and the verdict is therefore based on that. Novell's solutions are the SuSE of the future and will have to be evaluated by others.

Verdict: After surviving its financial troubles SuSE is building its business as a consultancy with excellent know-how, particularly in exotic mainframe environments. As a company SuSE shows how a skilled professional will always have work. The company's Linux distribution is popular, but the realization of the whole package (prior to the Novell buy-out) unfortunately failed our ethical criteria. Whereas the Red Hat catch barely scraped through, the SuSE catch, just as barely, fails it.

• 1To clarify, in the free Fedora Core Linux which Red Hat has published since 2003 mostly for hobby and test use, the up2date program has been changed so that users can freely add other websites from which software can be installed and updated. At the time of writing, all actual Red Hat products aimed at businesses are still tied to the Red Hat Network service.

What would you pay somebody to do if not work? The twists and turns of the market economy are wonderful, but even amidst all the brilliant business ideas of the techno boom at the turn of the millennium, there are still people out there who actually support themselves by honest work! This notion, which is so self-evident it could sound sarcastic, is an example of the selling-services business model. Established software companies initiate and make a computer program which they then sell packaged in colourful boxes, whereas in the pay-for-work model software is specifically commissioned. It works something like this: brilliant Open Source programs are available on the Internet free for anyone to use. If, however, what you need is not yet out there, programmers can write it for you - provided you pay, of course.

One example of the successful implementation of this model was the Kroupware project commissioned by the Federal Republic of Germany. In the summer of 2002, Germany commissioned a groupware solution running on Linux and the corresponding client or desktop software for use on both Linux and Windows from three companies closely associated with the KDE project (German Efrakon and Intevation, and the Swedish Klarälvdalens datakonsult).

A groupware solution is the kind of e-mail program that contains not just e-mail but other functions that are useful in an office, such as a calendar, contacts and, in some cases, chat groups. The best known groupware solutions used by companies are Microsoft's Exchange and IBM's Lotus Notes. Although there are a number of e-mail server programs available for Linux, nobody had yet made this type of multi-tasking tool. But the German authorities wanted to take their groupware needs into the world of Open Source.

The three companies with the winning tender named the project Kroupware.1 They decided to build the software around well-known Open Source programs, such as Apache's web server, the e-mail server Postfix, the OpenLDAP directory server and the IMP Webmail. The desktop software was created from existing and well-functioning KDE project modules, the e-mail program, calendar and contacts, which with a little work could be made into an entity resembling Microsoft Outlook. Naturally, some functions had to be created from scratch, but a lot of the work had already been done and could be put to direct use, which meant the Kroupware project was completed in record time in the summer of 2003. The resulting software was finally called Kolab.

Finishing such a complex software project within one year is somewhat unheard of in the IT world. Even more incredible is that the work was done by three relatively small and unknown consultancies. The fast pace of the work was only possible because the project could build so much on top-quality Open Source work that had already been done.2

The Kroupware project breaks with familiar market-economy mechanisms in an interesting way. The Federal Republic of Germany got the groupware application it wanted, but because the Kolab software is Open Source anyone who subsequently needs a good groupware solution for a Linux platform can copy it for free from the Internet! Is it fair that a software solution paid for by the German taxpayers could then be used by others free of charge?

Offhand, that may seem unfair, but in the world of Open Source such an outcome is standard practice. Since the beginning of hacking, Open Source hackers have always made programs to suit their own needs. With little interest in who else may or may not benefit from their work, their primary interest has essentially been to solve their own problems. As a client, the Federal Republic of Germany accepted this logic, and they aren't likely to have any reason to complain. Not only did they get what they wanted, they got a high-quality solution, they got it cheap, and they got it fast. What could be unfair about that?

Actually, Germany didn't have to pay for all of Kolab. After all, most of the Kolab software was made up of existing Open Source programs, the creation of which required many thousands of man-hours worth of blood, sweat and tears - or rather, loads of excited hacker spirit. For all this work - worth millions, if not billions - Germany didn't have to pay a single pfenning, nor for that matter even a single cent.

It is important to keep that in mind if we are to understand how Open Source works at its best. If we spend all our time jealously guarding how others might end up with more than we do, life can grind to a halt while all available time is diverted into sorting out disputes and backing out of dead ends. If instead we all focus on solving our own problems, everybody can be a winner.

Verdict: The pay-for-work business model that has proved to work very well is completely consistent with hacker ethics and utilises the strengths of Open Source. It's also worth mentioning that all the other models we've looked at have their financial roots in something other than programming. That is, their main business is consultancy, and programming is more or less a hobby done on the side. In the Kroupware project, however, programmers were actually paid to write code, which seems a very healthy thought! The pay-for-work principle appeals to everybody's common sense, particularly when we've seen the number of millionaires, on paper, created by the technology explosion.

However, the Kroupware project does leave some questions unanswered. The Federal Republic of Germany is a big enough client to be able to finance such a commission single-handed. But what about smaller clients? Must smaller companies and consumers wait for crumbs to fall from the tables of the big corporations and nation states, or could the same model work on a smaller scale? Such questions are what we'll look at next.

• 1There is a tradition in the KDE project to give all programs names beginning with the letter K, hence from groupware you get Kroupware. What was originally a fun idea has paled over the years.
• 2Hackers like to quote Isaac Newton, who wrote, "If I see further, it is because I stand on the shoulders of giants.'

One way many Open Source hackers use to support themselves somewhat resembles the relationship between a Renaissance artist and his rich patron. Perhaps the modern version is sponsorship, but the analogy of patron and artist is a better description. The best example of this patron-and-artist model is the long relationship between Larry Wall, creator of the popular programming language Perl, and his former employer, the publishing house O'Reilly & Associates. One would be justified in wondering what the creator and developer of an Open Source programming language was doing as a full-time employee in a publishing house.

O'Reilly has become known as the publisher of top-notch computer guides. The company's trademark is to print an exotic animal on its book covers. For example, Programming Perl, the guide to Perl, has a camel on its front cover, which is why this Perl programmers' bible has been dubbed the camel book.

In the early nineties, the camel book had become compulsory reading for every Perl programmer. Tim O'Reilly, the CEO of the publishing house, realized that the more Perl programmers there were, the more camel books O'Reilly & Associates would sell - so whatever was good for Perl would be good for O'Reilly. Putting his thoughts into action, Tim gave Larry Wall a full-time job to develop Perl while, of course, writing a new edition of the camel book on the side. In addition to this mutually beneficial symbiotic relationship, it was also good PR for the publishers to hire a well-known leader of the Open Source community. O'Reilly has subsequently become the book purveyor not only to Perl programmers but also to the whole Open Source community, supplying programming guides and other kinds of computer literature.

A somewhat similar relationship existed between Linus Torvalds and his former employer Transmeta, which is neither a Linux nor an Open Source company but a manufacturer of low-energy computer processors. When Linus got his degree from the University of Helsinki in 1997, Transmeta hired the undisputed leader of the Linux world and gave him free reign to use his working hours to develop Linux.

Although Transmeta itself had no use for Linux, hiring the world's best-known programmer was a smart move. No amount of money could have bought them such an effective marketing campaign. Media interest was only heightened by the fact that Transmeta had yet to publish a single product and was keeping all plans for its future a secret. It was even uncertain whether or not the company actually made processors or were up to something entirely different. By the time their first processors were made, everybody was bursting with curiosity, so much so that when the company held a press conference it was front-page news in the entire IT press, which meant there was no need for an advertising campaign.

But putting Linus on the payroll was not just charity, nor even a simple marketing gimmick for Transmeta. In principle, Transmeta's new processors were compatible with the processors used in Intel's x86 architecture. And since Linus Torvalds' Linux system had been made for those particular Intel processors, he was naturally one of the world's best authorities on the x86 architecture. Which means he was probably irreplaceable for Transmeta in solving various technical problems, although by his own admission he spent more than half his working day tinkering with his hobby, Linux.

It may not be hard to find patrons eager to support the best programmer in the world. But how about your average unknown hackers? Will somebody want to employ them? Even though the patron-and-artist model probably works best with the hacker stars, there are rank-and-file members of the Open Source community who have managed to make a living in a similar way.

Quanta Plus is an HTML editor that's part of the KDE windowing environment - or, more simply, it's a program you use to make web pages. The two main developers of the program are Eric Laffoon of the US and Andras Mantia of Hungary. Eric's day job is to grow and sell catnip, which apparently cats like so much it's possible to make a living out of growing it. In addition to supporting his own family, Eric sends some of his catnip revenue to Andras, who in turn works full-time on Quanta Plus and other KDE programs. The two men have calculated that this arrangement is more efficient than if both of them tried to develop Quanta Plus in addition to having day jobs. Of course, the difference in the standard of living between Eastern Europe and the US is what makes this particular collaboration possible. But irrespective of world economy, Eric is a true patron who puts money into the KDE project rather than contributing his free time.

KDE has also had a lot of positive publicity through a program called Adopt-a-Geek, a project initiated by KDE activist Scott Wheeler. The whole thing started with the observation that many industrious KDE programmers are students - either from Eastern Europe or from otherwise disadvantaged backgrounds - who do their valuable volunteer work on slow old computers simply because they're the best they can afford. The Adopt-a-Geek program strives to support these poorest of KDE programmers by supplying them with more efficient hardware to enable them to work more efficiently. Although the Adopt-a-Geek project only supplies computers and parts, not money, it is one example of how users of KDE software can help satisfy the material needs of the people who make the programs.1

Verdict: The patron-and-artist model, or sponsorship, has proved itself a workable way of putting food on the table for an Open Source hacker, but is probably best suited to the famous hacker stars than for your average code merchant. Ethically the model naturally scores an A+. It doesn't just pass ethical review, it practically oozes hacker ethics and the joy of sharing.

• 1https://devel-home.kde.org/~wheeler/adopt-a-geek/

In 2000, the well-known horror writer Stephen King conducted some interesting experiments in Internet publishing. Although they weren't Open Source projects, King clearly understood the dynamics between immaterial work and the Internet so well that there is much we can learn from him.

King made history in the spring of 2000 by publishing his novel Riding the Bullet in digital form only. It was the first time a well-known author had written a book not intended for printed publication. The vendors of various eBook solutions and programs made the most of this opportunity, and old news clippings remind us of all "the death of printed books' stories.1

The cost of publishing a book in digital form is of course far less than having it printed. This, and marketing reasons, allowed King's book to be sold for as little as $2.50. In the first 24 hours, an amazing 40,000 copies of the book were sold. I don't know what sales figures King is used to, but the press at least saw this as a huge success and the makers of eBook products pointed to it as proof of - what else? - "the death of printed books'.

However, it seems King wasn't altogether pleased with the experiment. Despite the fact that the eBook files had been protected with some childishly simple copy protection mechanisms, crackers quickly broke through them, and pirated versions of the book quickly spread on the Internet. Even though the webstores Amazon.com and Barnes&Noble.com were, by this time, distributing the book free on their websites for advertising purposes, the existence of pirated versions seemed to annoy Stephen King enormously.

His readers weren't particularly happy about the various eBook formats, either. Because of the copy protection it was impossible to get a printout of the book from the eBook programs. It could only be read while sitting at a computer, which effectively prevented anyone from curling up on the couch or hiding under the covers at night to read King's latest exciting story. And there was a further irony to his use of copy-prevention techniques. Because there was nothing to prevent anyone from printing out the pirated editions of the story, they were inevitably more user-friendly than the official eBook editions.

The eBook hype has since faded away, and despite all the doomsday prophecies the printed book has not died, because it is still far more enjoyable to read a story printed on paper than it is to read it on a computer screen. Today, however, many people continue to work on creating more functional systems to prevent copying, apparently in the belief that readers will eventually want to buy books they can't read in the comfort of their favourite position.

Despite his disappointment, King had sufficient pioneering spirit to go ahead with a new Internet experiment the following summer. This time he chose to publish his work on his own website, thereby bypassing all established publishers. Coincidentally the story, called The Plant, was all about a murderous vampire plant striking terror into the hearts of the employees of a publishing house. Meanwhile, Stephen King's experiment struck terror into the lives of real publishers, who feared that if it succeeded it could undermine the very existence of the publishing industry.

After his disappointing eBook experiences, King intended to turn things upside-down with this book. He published the first two chapters on the Internet without any complicating attempts to prevent copying - this was a straightforward text on a straightforward website. However, the text wasn't free, as readers were asked to pay one dollar per chapter they read. If a sufficient number of readers paid up, King said he would finish the story, one chapter at a time.

King's idea was somewhat similar to the Kroupware pay-for-work model described earlier. He accepted that many people would read his work for free. That didn't matter to him, provided enough readers also paid. He reasoned that if people were willing to pay, he would do the work.

This foray into self-publishing didn't get as good a reception as the eBook experiment earlier in the year, but in the first week some 152,132 eager fans had visited the site and read the first chapter. Of them some 116,200 had also paid a dollar. This met the terms King had stipulated, so, to his own surprise, he had to write more of this horror story set in the publishing world.
By the time he reached chapter six, however, the excitement had waned. Only some 40,000 people had bothered to read the chapter, and half of them hadn't paid their dollar. So, all of a sudden, King dropped the project that had got off to such a good start.

Of course, the failure of The Plant is somewhat disappointing to those who seek an open Web community. If a popular writer like King couldn't earn enough from Internet publishing, who could?

But at least some of the blame can be laid at King's own door. The project might have done better had King had a greater understanding of the mechanisms of Open Source. As it was, his experiment resembled the practices of the Open Source community only by chance, as he probably didn't know about Linux and hadn't learned from it and the flourishing businesses growing up around it. For example, the Stephen King site used the word thieves to refer to those who read his story without paying. However, when it comes to marketing, abusing your own readers may not be the smartest thing to do. The experiment also gave the impression that although King didn't really mind that the number of paying readers had dwindled, he actively resented that a growing number of people were reading it for free. Also, at some point, for some incomprehensible reason the first chapter was removed from the site, which virtually guaranteed that no new readers would ever start reading the book. So, there was a sense of a certain lack of openness in the project, which may have influenced the readers and made them apprehensive.

One can't help feeling that King was never fully committed to the project. He had actually written the first two chapters, with which he'd started the whole process, some 20 years earlier. Apparently, he found his incomplete and unpublished text in the attic and published it on the Internet as an experiment. Only when he unexpectedly found that readers were willing to pay for what they'd read, did he bother to write another four chapters, but that was it.

Enjoying the view of hindsight a little longer, we can see that the book publishing project may have worked better if it hadn't been chopped about so much. It seems only natural that the number of paying customers would decrease after the first flurry of excitement, particularly after the first part of the book was removed from his website. It would probably have worked better if customers had been asked to pay a slightly larger sum up front, in either two or at the most three instalments.

Whatever the best way to do it may have been, there is at least one thing to be learned from King: if you write horror fiction, don't ever sell your readers half a book. Readers who were disappointed by King's decision not to finish the book were crushing in their criticism. For some reason King didn't seem to have anticipated that the thousands of readers - who by then had paid seven dollars for part of the book - would be angry when they were denied the end of the exciting story. The anger wasn't exactly dissipated by the promise King had made in the summer that if he ended up writing more than the first two chapters he wouldn't leave the book unfinished. So, the experiences of The Plant project may not be very encouraging, but they do serve as a warning: if you cheat your customers, they usually get angry.

Another interesting experiment in Internet publishing was that of The Metamorphosis of Prime Intellect, an eight-chapter novel by Roger Williams. Unlike Stephen King, Williams was an unknown and unpublished author, who despite numerous attempts had failed to get a publisher for his novel. His solution was to publish it on the Internet. Although technically, his publishing venture failed to meet the criteria of the Open Source ideology, Williams' approach to Web publishing was rather more positive and open than King's had been. It was published in its entirety, and could be read and copied freely. Williams offered those who liked the novel the chance to give him a tip through the PayPal service.

Later on, Williams wrote about the experience in the article "The Tip Jar as Revenue Model: A Real-World Experiment'. He not only studied the financial side of the matter, but also stated that for an unknown writer like himself, just having readers was a big thing.2
But how did the novel fare?

According to Williams, some 5,000 to 10,000 people read the novel to the end. That's not bad for a first novel by an unknown writer! And he received $760 in tips. Although Williams was happy with his success, he did conclude that the tip jar didn't really cover his rent or groceries.

At the turn of the millennium, somewhat similar Open Source experiments were being carried out in relation to computer programs. But hey, what experiments weren't being done around that time? More than one company actually tried to bring makers and users of Open Source software together in a sort of virtual job market. Programmers could use such sites to publicise the sort of program they were currently developing, and interested people or potential consumers could use the site to offer financial support for a particular programmer. Any consumers interested in specifically commissioning software could use such sites to offer the sum of money they were willing to pay. After which other buyers interested in the same type of program could commit to the project by paying whatever sum they felt was appropriate. In theory, for a programmer looking for work, all the pledges would provide a nice sum of money once the software in question was finished.

Not one of these projects ever got beyond their initial start-up.3 Perhaps they were ahead of their time, but more likely the model itself was simply bad. For one thing, the job markets didn't seem to be of any interest to the hacker community. Hackers were already busy with all their existing projects. They preferred to do something they found really interesting without remuneration than to take on something they found boring for mere money.

In early 2004, by far the most popular host of Open Source projects, SourceForge, began offering programmers who used their service the chance to receive financial donations through the PayPal service with, of course, a percentage of the tips going to SourceForge itself as their commission.4

SourceForge's tip-model way of financing programmers of Open Source projects differs from the failed job markets in that their first and foremost aim is not to handle transactions of money. SourceForge's real business is to offer programmers the tools they need for their work together with providing a channel for distributing their programs. The chance to support the creator of your favourite software is just an added bonus, not something that lies at the heart of operations.

The success of SourceForge, as compared to the failed job markets, provides us with a good lesson, particularly for future entrepreneurs in the IT business. In the job-market model, the most important thing was money, with programming taking second place. On the other hand, new projects are started every day in SourceForge, and nobody says anything about money. Successful projects get some tips - some more, some less. The same thing is clear across the field of IT: there are those who have fancy business plans, and there are those who work.

What was true for Williams' tip-jar experiments also holds true for the tips at SourceForge: some money comes in, which is nice, but not enough to support oneself, let alone a family. So does pay-for-work really not work on a small scale, especially if one actually needs the amount paid to correspond to a regular salary?

There are some examples of the pay-for-work model being implemented successfully for clients smaller than Germany. Almost immediately after the completion of the Kolab 1 project, some companies started asking questions about it in the hope of realizing features that the Germans hadn't thought to order. The businesses that had originally worked on the Kolab project then pulled together the companies asking these questions, and the interested parties pooled their money to finance the next version of the project, Kolab 2. This may be the first time an Open Source project has been realized as a shared commission for a consortium of several smaller clients.

JBoss, the company that develops the Java application server of the same name, works in a similar way. The Java application server itself is such a big and complicated piece of software that there aren't many companies willing or able to single-handly pay for the whole thing. That's not how it's come to be either. JBoss has been available on the Internet under the Open Source principle for years, and has been developing over time. Clients using JBoss are usually happy with it as it is, but every once in a while somebody needs an added feature of some kind. When that happens, they can commission the JBoss company to write the code for it (or commission some other programming company to do the job, because the source code is open and available), and little by little this further develops the JBoss application server. So, horror fiction may not sell well piecemeal, but that seems to work fine for developing Java application servers.

Although the pay-for-work model doesn't seem to work at the small consumer level, it seems you don't have to be an economic power the size of Germany to make it work for you.

Verdict: The pay-for-work model is a beautiful thought, but so far there's been no evidence to suggest that it works for products aimed at the private citizen or other small consumers. However, it seems that it can work extremely well for medium-sized companies upwards.

• 1Despite all that was said in 2000, three years later Stephen King's story Riding the Bullet was published in the printed collection Everything's Eventual.
• 2https://www.kuro5hin.org/story/2003/4/27/195833/305
• 3Actually, they failed so dismally that nobody even remembers the names these projects had during their brief existence, which is why this is an anonymous anecdote.
• 4https://sourceforge.net/

Possibly the most financially successful strategy for Open Source software has been the so-called dual licensing of it, particularly the way it is employed by companies making "low level' tool-type software.

MySQL Ab is a Swedish company known for its popular database program, which is particularly liked for data storage of web pages that run on a Linux platform. The MySQL database can be downloaded for free from the Internet under the same GPL licensing system as Linux. Another option is to buy it under licence for $500. But why would anybody choose to pay 500 bucks for something they can get for free?

Some people want to pay for it to avoid having to commit themselves to the terms of Open Source. The General Public Licence (GPL) requires programmers who use some GPL licensed code or program in any of their software to also publish their own work under the GPL, source code and all.1 Which is why the programmers who make closed programs can't use the free Open Source version of MySQL, but have to pay $500 for a so-called "commercial licence'. These customers are usually pretty happy with their purchase, because $500 is not a steep price to pay for a good database product.

For MySQL this arrangement has clearly worked brilliantly. The existence of the free GPL version of MySQL helped make it one of the world's most popular databases. Being well-known is obviously important for any product, but for a programmer's tool it's particularly important that programmers learn to use the program. If a software company employee has already used MySQL for free to create the database for the web pages of the local kennel club, he or she is likely to want to use it as part of the company's closed software project rather than have to learn how to use another database program.

The existence of the GPL version has also speeded up the development of the database. In accordance with the principles of Open Source, many programmers outside the MySQL company have improved the database software, making the company's product improve "by itself'. In this way the hacker community pays in free labour and user feedback what the manufacturers of closed software must pay for in money.

Trolltech, who developed the popular Qt user interface library, employed the same business model. A user interface library offers programmers the basic building blocks of computer programs - including such things as push buttons, menus, text fields and scroll bars - with which to build the actual software.

One of the strengths of Qt is that it can be used to program software for both Windows and Linux. That makes it a good choice - out of very few - for programmers who want their program to work on as many operating systems as possible.

The Qt library forms the basis of the KDE desktop environment which is so popular for computers running Linux. With KDE, one can freely use the Qt library version published under the terms of the GPL licence. But, like MySQL, Trolltech also sells a licensed version of Qt for use as building blocks in closed programs. The benefits of this arrangement are the same as those for MySQL. The GPL version of Qt gives it visibility and cachet, while the hackers of the KDE community are an important resource in its development. They give feedback on Qt and often also develop it further, and the improvements they make also benefit the commercial Qt.

Dual licensing raises the interesting ethical question of how these companies would fare in a world that is 100 per cent Open Source. Far from topical, the question is nonetheless relevant for those who believe that the Open Source model is fundamentally better than the mean-spirited restrictions of closed software. If the closed software model is so bad that nobody should use it, then what would happen to those companies that make their money from the makers of closed programs? And is it really kosher to support openness and fight mean-spiritedness, while still recommending this dual licensing business model?

So far, there doesn't seem to be any good answer to the question. The truth is that, for now at least, dual licensing works very well and seems to satisfy all parties. It supports and provides well for companies like MySQL and Trolltech. The makers of closed programs get high-quality tools at a good price. And the Open Source programmers get the same tools on terms they feel fine with. And there's the added bonus that development of Open Source programs is partly financed by funds from the makers of closed programs, i.e. the opposition.

So everybody is happy and, frankly, although the question remains unanswered nobody seems to care.

Verdict: Dual licensing, as used by MySQL and Trolltech, is arguably the most successful business model of the Open Source world. In addition to these two companies, many others like them have used it successfully. However, this model doesn't suit all. In particular, it doesn't seem to work well with software intended for the end user, as all the companies that use this model are selling products - either programming libraries or databases - to other programmers. The model passes the hacker ethical review, although the question of how companies that use dual licensing would do in a wholly Open Source economy remains to be seen.

• 1Not all Open Source software is published under such strict terms. Many Open Source programs or parts of them can also be used in closed software. However, software such as the Linux kernel and MySQL which are published under the GPL licence do not allow this.

Ximian employed a model very similar to dual licensing to license its Evolution e-mail program. For lack of a better description, we'll call this model playing for both teams. A company using this model follows in part the principles of Open Source, and in part the rules of the established software industry.

The history of Ximian is closely associated with GNOME, the other Linux desktop environment. Miguel de Icaza, who founded GNOME, also helped to found Ximian, and most of the other key players in that company are also leaders of the GNOME project. Before Ximian, the Mexican de Icaza revealed his sense of humour by styling himself "peasant farmer' at Linux conferences - a title that hardly does justice to a programming genius on a par with Linus Torvalds.

Most of Ximian's work has been connected to improving, one way or another, the use of Linux on workstations. Ximian's position among the other Linux companies has been curious because in many ways it resembles others, such as Red Hat and SuSE, yet Ximian is not actually a Linux distribution. It's main product Ximian Desktop is designed to be installed on top of somebody else's Linux - a typical combination might be Red Hat Linux with Ximian. In recent years, the company also coordinated and was the most important contributor to the development of Microsoft Mono, which is an Open Source version of the new Microsoft .NET platform. And this is what made Ximian known outside the world of Linux.

In August 2003, Ximian was acquired by Novell, one of the grand old IT companies. As was the case with SuSE, this again shows that an expert is always worth paying for. Because Ximian used to be a private company, no figures were ever made public when it was sold, so any estimates of its profit can only ever be guesswork. Apparently, the largest source of revenue has been the Red Carpet service connected to Ximian Desktop, which its users employ to make installing and updating programs easy (cf. Red Hat Network). However, it is clear that Novell didn't buy Ximian to acquire any single product but rather to get a lot of Linux expertise in one go - just as they did with SuSE. So, another business model that has proven itself in the Open Source world is to demonstrate your skills as a Free Software programmer until somebody hires you or - as with Ximian - buys your company.

But getting back to our test case, one of the Ximian products is the e-mail program Evolution. Ximian took it upon itself to develop an e-mail client because the lack of this was one of the biggest obstacles to the corporate world moving from Windows to Linux.1 When Evolution was ready, it was published according to Open Source principles, which meant for instance that anybody could use it for free.

Alongside Evolution, Ximian also published a product called Connector for Microsoft Exchange, which made it possible to use Evolution with the Microsoft Exchange groupware server that is popular in the corporate world. Although Exchange is an e-mail server, many of its features follow no given standard - instead, they work only with Microsoft's own Outlook groupware program. For Evolution to replace Outlook completely, it had to be able to mimic the non-standard features in Outlook, and Connector was the product Ximian sold to do this. Unlike Evolution, the added features of Connector were not Open Source, but were sold without source code and on licensing terms that allowed only one user per program purchased, as is usual for closed programs.

You'd think their selling a closed program would have caused a protest in the Open Source community, especially as Ximian was one of the best-known proponents of the Free Software ideology. But it never happened. Connector received only positive publicity, presumably because Connector was aimed at existing Microsoft clients and therefore posed no threat to the Linux world. No true supporter of Free Software would ever have owned the Microsoft Exchange server and therefore would have no need for Connector, which made the entire product irrelevant to them. And for any company using Exchange and other Microsoft products it was perfectly normal to pay for a closed Connector - just as they had already paid for Exchange.

Because the sales figures weren't made public, we may never know how well Ximian did out of its Connector product, but according to the company's own statements it did make some money on it. But offhand, it must surely be a fairly marginal product, because any company that wanted to move from Windows to Linux would be more likely to get rid of the Exchange server at the same time. And Connector is useless for anyone using an e-mail server running on Linux, because the free Evolution program is all they'd need. At best, that would have left as potential Connector clients those Linux users who are in a minority at their workplace where most of their colleagues are using Windows and Exchange.

But even so, the Connector episode is an interesting example of the Free Software camp happily accepting, against all their fine principles, the sale of a program, albeit a marginal one, in closed form.

CodeWeavers and Transgaming Technologies are two other companies which could be categorised as playing for both teams. Both have built their products on top of the Open Source Wine library. The Wine project aims to create a Windows-compatible Linux environment, so that programs made for Windows can be used as such on Linux machines. The task has proved surprisingly difficult and after more than ten years the project is still only in its development stage.

However, CodeWeavers and Transgaming have found Wine is already quite useful within an appropriately limited field. So, with a little extra effort, CodeWeavers made Wine into the product CrossOver Office, which makes it possible to use Microsoft Office on a Linux machine.2 And Transgaming have found a niche for their product Cedega among game fanatics who want to play their favourite Windows games on their favourite operating system, Linux.

Having finally harnessed Wine for something useful in their respective fields, these two companies are among today's most important contributors to the Wine project. The work they've done is a significant part of the collaborative effort of the entire Wine process, which makes both companies valued members of the Open Source community.

However, their products CrossOver and Cedega are closed programs and, as with Ximian Connector, their target group is not bothered by that. Clients who need to use Microsoft Office or some game from the Windows world aren't going to start complaining about CrossOver or Cedega being closed programs. It simply wouldn't make sense, as their need for Wine is born out of their wanting to use other closed programs.

The staunchest proponents of the Free Software ideology won't bother with too much bashing of companies that, after all, hand over some of the fruits of their labour for the benefit of other Wine users. They are just as unlikely to buy these closed programs but they're satisfied with a silent boycott. This is noteworthy in a community that is sometimes very loud in its proclamation of the "right opinion'.

Both CrossOver Office and Cedega have proved to be viable solutions and no doubt there are some customers for them. Again, there are no exact figures, but unlike Ximian Connector, CrossOver and Cedega are the main product of each company. Sales must have been at least reasonable, as both companies still exist.

Verdict: Connector cannot have been an important source of income for Ximian, but it is nonetheless a source of revenue. On the other hand, CrossOver and Cedega are each the mainstay of the company that sells them. So, to some extent, playing for both teams does at least work. Significant in these examples is that a Linux company can deviate from the key principle of the Open Source community and sell programs without the source code, i.e. with a closed licence, without there being much protest. Those who do this largely avoid criticism because their products are primarily aimed at clients who use Windows rather than at Linux fanatics who live and breathe the Open Source ideology. On the other hand, the Open Source camp is satisfied because in one way or another such companies are of use to the Open Source movement. This means they are tolerated as companies that are "good on average'.

Even so, the playing-for-both-teams model obviously does not fulfil the criteria of hacker ethics. Also, it feels weird to think that the main source of income for a Linux company would be Windows users, even though it seems there's always plenty of work for bridge-builders in the IT world just as there is in other areas of life.

• 1In fact, several e-mail programs were available for Linux before the advent of Evolution, such as Kmail for the KDE desktop environment, and Netscape which many Windows users knew as well. What the people behind Evolution mean by telling the story this way is that there was no e-mail program for the GNOME environment. Another lack that Evolution actually fixed was that at the time there was no groupware solution similar to Microsoft Outlook available for Linux, so no program combined e-mail with calendar and contacts functions.
• 2It is also possible to use Lotus Notes, Internet Explorer and some other widespread Windows programs.

Now, to turn the tables on the previous examples, we'll look at Corel, a company from the world of Windows that threw out a feeler into the world of Linux. Corel, which is known for its graphics and office programs in Windows, once made a brief foray into the Linux world. Unfortunately, Corel is the warning example here, because it never really managed to fit in with the Linux crowd. It never really became one of us.

In 1999, Corel went out on a limb with its own Linux distribution at the same time as it was launching Linux versions of its popular WordPerfect Office and CorelDraw software. Because the Linux versions available at the time weren't as user-friendly as they are today, Corel also figured that the average WordPerfect user needed a simpler Linux to run it on, so they decided to develop their own Linux version as well.

Because there was no decent word processing program for Linux at the time - at least not one capable of satisfactorily handling documents generated by Word, Microsoft's word processing software - the Linux community was in the main looking forward to the new WordPerfect, but people also thought there was a market for an easy-to-use Linux.

Corel, however, had an ulterior motive for its Linux adventure. The company had been sidelined in the word-processing business, because Microsoft had successfully leveraged the most out of its monopoly. A couple of years earlier, in an attempt to gain independence from Microsoft, Corel had announced it was moving all its programs onto the Java platform. When Java proved wholly unsuitable for the purpose, they piled up their markers on Linux. Corel was ready to go with any technology that could be used to attack the Microsoft hegemony.1 And what was at stake in this game? Becoming the next Microsoft. The company wanted to offer people an alternative operating system and have it equipped not only with an alternative office program but also with drawing and image processing software.

In part, Corel did this rather well. The company making the world's most popular graphics program left an indelible mark on the KDE desktop environment, for instance, as the KDE programmers learned to tell the difference between icons created by artists and those created by engineers. If nothing else, at least Corel gave Linux a snappy look. In addition to KDE, Corel also put a lot of effort into the Wine project, which it used to port WordPerfect and CorelDraw to Linux.

However, when it was released, the Corel Linux OS was no earth-shattering improvement. Finnish users were surprised to find the operating system offered imperfect support for Scandinavian characters, something other Linux distributions had perfected years ago (naturally enough, since Linux was born in Finland). Although the effort to create expressive graphics and a user-friendly interface was commendable, the novelty quickly paled because of the failure to handle the basics, which negated the benefits of the new easy-to-use features.

Corel Linux was based on the popular distribution Debian Linux. But in those days Debian offered a total of six CDs packed with various Linux programs, whereas Corel had included only one CD's worth in its distribution. Simple is beautiful and all that, but sooner or later many Debian users who tried Corel naturally felt disappointed when some program they wanted to use wasn't available with Corel. However, there was a solution: Corel Linux was still compatible with the installation packages of programs made for Debian, which meant Corel Linux users could stock up their Linux from Debian's well-filled larder.

However, this convenient solution didn't save Corel in the long run. Many Corel Linux users ended up using Debian, because that's where all the good programs were anyway. Nor did staid old Debian suffer from the other little problems that beset Corel: for instance, the non-English alphabets worked as they should. Not only Debian, but the other old Linux versions also held their ground against Corel. The basics were running smoothly and by then the other distributions had also improved their user-friendliness. Finally, Corel could no longer compete.

Corel's Linux adventure exemplifies how difficult it is to be the new kid on the block and challenge companies that have been around longer. One year of Linux experience doesn't give even the best minds in a Windows software company the upper hand against gurus who have been in the business for more than five years, often a couple of decades if you include their Unix experience. There wasn't anything seriously wrong with Corel Linux, but neither was there anything amazing about it.

Although the Linux effort of this large and established software company received a lot of publicity, it failed to set off any great migration of Windows users to Linux. When Corel Linux came, Windows users continued using Windows, and Linux users continued using their own brand of Linux. Because of its size, Corel did attract a fair number of people to try its product, but in the history of Linux it is now no more than a note in the margin.

WordPerfect and CorelDraw didn't do well in the world of Linux either. Despite being eagerly awaited - it was the first time any major software familiar from the world of Windows had been released for Linux - in the end both of them stayed firmly on the retailers' shelves. As Windows users, Corel's old customers didn't need the Linux versions; but it probably surprised Corel more that the Linux users weren't interested either. WordPerfect, which supported Word files, met with some success, but otherwise the Corel Linux project was a flop. Typical Linux users considered WordPerfect to be a bad alternative to Microsoft Word. Both were equally closed, so were of no interest to Linux users committed to Open Source. In addition to which, Microsoft Word was - tough but true - many times better than WordPerfect. So, anyone stuck with using closed software in the first place would at least want to use the best there was, and that wasn't WordPerfect.

Within two years, Corel's Linux adventures had come to an end. They were out of money - most of which had been spent earlier on the failed Java experiment. The company desperately tried to fix its deficit by merging with Borland, but at the last minute the owners of Borland realized what was going on and pulled out. With no cash, Corel was hovering on the brink of bankruptcy when Microsoft - in the middle of its monopoly trial - rescued its competitor with a thick wad of notes. Earlier, Microsoft had done the same thing to prevent Apple from going under. Keeping its competitors alive, albeit feeble, allowed Microsoft to prove in court that it was not a monopoly.

As if by chance, all Corel's Linux projects were closed down just weeks after Microsoft had become a partner. Later, the Linux operations were sold to a company called Xandros, which still publishes an easy-to-use Linux distribution. In the past year or so, Xandros has even become quite a respectable player, although it has yet to match the market share of the big Linux distributions.

With the ease of hindsight, Corel's mistakes can be summed up in two main points. First, the company's motives were all wrong. It squandered the last of its money trying to create a weapon against Microsoft, instead of working on ways to keep its own customers happy.

Second, Corel made a miscalculation that resembles Nokia's WAP adventures. Corel seemed to have thought wrapping Linux in a pretty blue box with the Corel logo on it would be enough to get people rushing to the stores to buy it, just because it was there. Obviously, that just doesn't happen, which Nokia and Corel have both now learned to their cost.

Corel was also spurned for not being one of us. The engineers at Corel had downloaded parts of Linux from the Internet, worked on them quite nicely, wrapped it all up, and stuck it on the shelf for people to buy. There was never a true meeting between the Linux community which is used to open development, and Corel which is used to working within the company walls. Had there been more interaction and had it come at an earlier stage, some basic problems - such as the need to incorporate a Scandinavian keyboard - could definitely have been avoided. When Corel later completed the German, French and Dutch versions of its Linux, it marketed the distribution as the first multi-lingual Linux OS. That showed gross arrogance towards the other Linux companies and the Linux community, especially as Corel hadn't even made new translations of its own, but had copied the language versions from other existing Linux distributions, mainly Debian.

Many companies smaller than Corel have tried the same thing. "Hey, let's copy those free Open Source programs from the Internet, put them on CDs, wrap them up, and sell them,' they think. These small companies are rarely even heard of, but Corel was big enough for its adventure to merit some attention. Even so, such an attitude is a sure sign that you're underestimating others. First and foremost, that's not the way to get in with the in crowd. And being alone, Corel was weaker than the rest.

For Corel, the foray into Linux was a sad story, but for the principles of Open Source and for Linux users even this sad story is a victory. If it had been a traditional closed software project, it would have quietly disappeared. The project would have been cancelled and the software would have gone with it. But in the world of Open Source, work that has been done never disappears and a client can rest assured that life will continue, even if a distributor goes bankrupt and stops supporting the product you use.

The work Corel put into the Wine project is still part of today's Wine. And with Wine you can still use CorelDraw and WordPerfect on Linux.2 KDE is not the same as before the Corel visit, either. Gone is the lacklustre engineering style, and instead KDE has become a really artistic desktop environment, which is even being copied by old hands like Apple and Microsoft! Today's KDE is the work of new artists, but Corel's brief participation in the project was revolutionary, and although the company stumbled the work itself was not lost.

Verdict: Corel played its Linux game according to the rules of Open Source and hacker ethics. The company genuinely did a lot of good work on its Linux, but the product flopped. Just making something is no guarantee that customers will flock to buy it. And most of all, it's vital to show some respect for any community you want to join.

A penguin, as in the Linux icon, happens to be a herd animal which makes it an appropriate symbol of hacker ideology. Penguins stay warm by huddling together. Corel tried to survive on its own, and its Corel Linux froze to death.

• 1This is a good contrast to the section on Tolerance in the Part Two of this book, where Linus Torvalds said he wasn't really interested in what Microsoft was doing because he doesn't use Windows. What he did with Linux was to amuse himself. Perhaps Corel ought to have focused more on minding its own business instead of almost bankrupting itself by attacking Microsoft.
• 2But it takes a lot more work now than it did when the same programs were available, ready-to-go, direct from Corel.

One of the lessons learned from Corel's Linux adventure was that the Linux community shunned CorelDraw and WordPerfect because they were closed programs. Linux users had understood and through their own experience seen the benefits of Open Source, and were no longer interested in closed software, whether or not there was a Linux version available. Why go back to the bad old ways when you've just freed yourself of them?

Open Source has posed a new challenge for companies - still the vast majority - that still make and sell closed programs. It is always only a matter of time before a popular closed program will have to compete with an open program. And since closed programs usually can't compete, at least not in price, with any corresponding Open Source software, the advent of an equally good Open Source alternative usually heralds serious discomfort for the makers of the closed program. For instance, the spread of OpenOffice has already set off the beginning of the end for the overly long dominance of Microsoft Office. It's only a matter of time before the computer giants Oracle, IBM and Microsoft will really have to fight to keep their software in corporate server rooms, rather than the evolving MySQL and PostgreSQL - the Open Source databases which already store most of the Internet's web pages. There are also instances where there was never a race to begin with. For example, from day one, the open Apache web server has had more than 50 per cent of the web server market - the closed web servers were never more than a curiosity.

All this begs the question of how long a manufacturer of closed software can expect to be able to sell his product before the creation of a similar Open Source program comes along. Some rules of thumb can be applied to finding the answer.

Obviously, the simpler a program is, the easier it is to create a competitor - either closed or open. In his essay "The Cathedral and the Bazaar' Eric Raymond offers another seemingly self-evident rule: the more popular a program, the more likely it is that there will be an Open Source version of it. And that seems a reasonable principle to go by. The number of users, or clients, traditionally increases competition and brings down prices. This should also hold true when it comes to the creative processes of Open Source software. The more users, the greater the benefit from an Open Source program and the easier it is to find the motivation to write (or have someone else write) the necessary code.

Another interesting rule might be: too much greed quickly turns on itself. For instance, the existence of OpenOffice partly accords with Eric Raymond's rule - after all, there is a vast user base for office programs. But the development of OpenOffice has also been speeded up by the fact that Microsoft, with its virtual monopoly on the market, has hiked the price of its Office package so high that it's becoming unreasonable for private individuals and even small companies to pay so much for basic word processing. This created a crying need for an alternative office program.

Java, the programming language born in the Sun laboratory in the early nineties, has a history which again exemplifies the greed theory. Its strength was considered to be the platform independent "virtual machine model', which allowed the same Java program to run on Windows, on Unix, or on any other operating system that supports Java. This feature came just as it was needed, around 1995, when use of the Internet and the World Wide Web began growing exponentially. Just as html pages could be read by any computer, Java applets (very small applications) could be used on any computer.

Although the use of applets fizzled out after the first flurry of excitement, Java slowly gained ground and is now the most popular programming language in the world.1 Its platform independence must have played a part in that, but it was largely due to the clarity of the language's object programming interface, its simplicity and a certain academic beauty, that Java is used in all universities today.

Naturally, the Java language has also been used to realize a number of Open Source programs. In particular, the Apache Foundation has done well with several applications in the Java world, and they are also used by commercial Java companies. Even so, Java itself - the Java compiler which turns written source code into a computer program and the Java virtual machine that is needed to run the program - does not yet exist in a respectable Open Source version.

In the early days of Java, an Open Source project called Kaffe tried to come up with some competition for Java. Kaffe was always running a little behind Sun's official Java, but often enough was workable. Today, however, Kaffe is lagging far behind the rest of the Java world. In many instances, it's still usable, but it doesn't yet support the Java 2 standard, published five years ago.

Kaffe is just a virtual machine, not a compiler. IBM, on the other hand, has a fairly good Open Source Java compiler called Jikes. Unlike Kaffe, Jikes has kept up with the development of Java quite well. But again, Jikes is only a compiler - it can't run programs. IBM is also working on a Jikes virtual machine but as yet it doesn't quite meet all the requirements, although it can already run some isolated Java 2 applications.

In latter years, the Free Software Foundation has also stuck its spoon in the Java soup, working to create Java support for its venerable GCC (GNU Compiler Collection) compiler, which already supports nearly all other programming languages. This GCJ (GNU Compiler for Java) project is pretty much on the same level as the Jikes virtual machine - nearly, but as yet not quite in working order.

With Java, too, it's only a matter of time before Open Source alternatives replace Sun's official Java. Java may face the same fate as programming languages C- and C++, whereas the Free Software Foundation's GCC has long been the standard to which the closed alternatives of commercial players are compared.

However, Sun has managed to buck this trend for nearly ten years. Considering how popular a language Java is among the Open Source crowd, that's no mean feat. You'd have thought the hackers would have created an alternative that fits their ideology far sooner.

In part, the long time span has been due to the difficulty of the task. Writing a programming language compiler is among the most challenging jobs in the field, comparable for instance with writing the Linux kernel or the GCC (which is in fact a compiler). I read somewhere that a professor at the Helsinki University of Technology said that less than one per cent of all the programmers in the world could even attempt such a task at that level. Another problem with replacing Sun's Java is that the compiler also needs to be a virtual machine, and that's another job that is at least as demanding.

Another factor which is bound to have slowed down the creation of an Open Source alternative is that during all these years, Sun has distributed its own Java for free. Java has never been Open Source, but it has always been available for anybody to use for nothing.
This fact reveals an interesting side to the hacker community. Among the hackers there are idealists like Richard Stallman, people who absolutely refuse to use any closed software, but it seems not all hackers are so wholly idealistic. Most of them seem to feel its OK to use some closed software provided a program is cheap enough - or preferably free.

Sun's Java strategy has been aptly criticized for combining the bad sides of both closed and open software. On the one hand, Java develops slowly and suffers from quality problems due to the closed model of development; on the other hand, spreading Java for free hardly benefits Sun financially. Nonetheless, Sun's strategy has also, by chance, been very successful. If Sun had taken Java down the Microsoft route and milked it for huge profits, almost overnight they would have had competition - both closed and open. Instead, Sun has managed to maintain a reasonable balance between openness and greed, which is why it has enjoyed such a long period of popularity. Even so, it won't be long before Jikes or GCJ catch up with it. By the time you're reading this, it may already have happened.

Artifex Software uses a similar strategy to Sun, but whereas Sun's tactics were probably born out of a series of coincidences, Artifex uses them very consciously in the distribution of its popular software Ghostscript. This program is used to view, create, handle and print out PostScript and PDF files, and is particularly popular in the Unix world and Open Source community. Ghostscript has long been the only strong competition for Adobe's PS and PDF products.2

The two versions of Ghostscript first saw the light of day at the University of Wisconsin: the almost open AFPL Ghostscript and the completely free GPL Ghostscript. AFPL Ghostscript can be downloaded free from the Web, but cannot then be sold on commercially. For commercial purposes, Artifex sells licensed versions of Ghostscript separately and gives the printer and copier maker Xerox as its reference customer. Although AFPL Ghostscript is free, Artifex also distributes a separate GPL version of Ghostscript, which fulfills even the strictest Open Source terms. Each GPL Ghostscript always corresponds to the previous, roughly one-year-old AFPL Ghostscript, which means clients who have paid for the commercial licence always get a bit more than they would get using the older GPL version. By distributing Ghostscript for free and making the older version 100 per cent Open Source, Artifex ensures that not even the toughest Free Software ideologue will be motivated to challenge Ghostscript.

Verdict: In this section we've looked at how various companies selling closed software handle the pressure from Open Source programs. Summing it up, companies clearly operate at various degrees of mean-spiritedness. Most supporters of the Open Source community are willing to accept a fair compromise and will use closed software if it's easily available and cheap - at least, it seems nobody is driven to challenge such software. However, it's evident that too much mean-spirited business practice can be self-defeating. So, don't be too greedy!

• 1Most popular, that is, when a project begins from scratch and the programmer is completely free to choose the language.
• 2Adobe has created both the PostScript and PDF standards. Both technologies can be used for electronic distribution of text documents, etc., although PS is actually a printer control language, whereas PDF has become the standard for distribution of paper files in electronic form - for instance, on the Internet.

Since the rise of Linux, there has been a lot of debate about whether or not the code of closed software ought to be published, in the way that Open Source programs are made freely available. Sometimes their clients will suggest it to a manufacturer of closed software, sometimes the manufacturers themselves become interested in the benefits to be gained from openness. In the late nineties, for instance, at the Microsoft monopoly trial in the US some people argued that the makers of Microsoft Office had an unfair advantage because, unlike their competitors, they had access to the source code for the underlying Windows operating system; and it was therefore demanded that the source code for Windows be made public. The Court, however, did not order this to be done.1 Latterly, however, originally closed programs are being made open, or "freed', with ever greater frequency, and now we'll take a look at some of those stories.

Netscape, familiar to all web surfers, was the first serious software to go from being a closed development model to being an Open Source project. This historic event in January 1998 played a part in the invention of the term "Open Source'.2 It is said that the managers at Netscape had read, among other things, Eric Raymond's "The Cathedral and the Bazaar' and become convinced that the open development model might save Netscape from doom.

Although in many ways 1998 can be seen as the year in which Linux and the open development model really took off and entered the consciousness of the corporate world - which was much thanks to the process Netscape had begun - Netscape's decision wasn't really such a gift to the Open Source community as one might at first think. Microsoft's Internet Explorer had already taken the leading role in the browser wars and was also ahead of Netscape in quality. Also, Netscape seemed to become weaker with each version that was released. It wasn't long before the announcement that Netscape, the very company that had set off and embodied the Internet boom, had reached the point where it would be divided into parts. By the end of 1998, Sun and AOL had split up the remains between them. AOL took over the browser and the Open Source project called Mozilla. The Netscape company lived on as the greatest legend of the "new economy', but in reality it was just a shooting star - all but one of the four years of its business, that had promised so much, were in the red. And perhaps that is actually a good summation of the turn of the millennium's "new economy'.

After all the initial excitement, the Mozilla project proved, at least in part, to be a disappointment. It soon transpired that in the fight to beat Microsoft, Netscape's programmers had been pressed for time and had produced really confusing and low-quality code. In the first couple of years Mozilla was mostly a clean-up project. Finally, the Mozilla coders came to the conclusion that the easiest thing was really to simply rewrite the key part of the browser, the component that shows www pages. Not until this was done was there any sort of backbone to the project. In the end, Mozilla 1.0 was published four and a half years after the start of the project.

One of the leaders of the Mozilla project, Jamie Zawinski correctly observed that Open Source wasn't just "magic pixie dust', and he was right. There is no power in the world that can save a programming project that is all spaghetti code, rambling, and all else that is the consequence of less than top-quality programming. Although by now there are several really good versions of Mozilla available, and in particular the number of bugs has decreased dramatically since the days of Netscape, the slowness and its sprawling code was long a topic to which people kept returning. Possibly, it was in part due to a problem in the project's culture. Perhaps it carried a ballast of casual attitude to quality, inherited with the Netscape code.

The Firefox browser was separated from the Mozilla project, but was based on the same original code. However, a different set of people ran the Firefox project. The first official version, Firefox 1.0, was published in November 2004, and finally put an end to the slowness and other inherited problems. Like a phoenix, Firefox had risen from the ashes of old Netscape. Younger, more colourful and supporting a lot of new technologies, Firefox came to challenge the dinosaur Internet Explorer which latterly hadn't been moving forward.

From 1998 to 2004 was a long time in terms of the changes taking place in the IT business. However, we must remember that the Mozilla project had had other important goals - goals that had been reached a lot earlier. Although in the end Microsoft took more than 90 per cent of the browser market - which, at the time of writing, it still holds - the Mozilla project by its mere existence guaranteed that the Web didn't become Microsoft's exclusive property. The existence of more than one browser ensures that home-page makers - at least those who know what they're doing - stick to common standards, which denies Microsoft both complete monopoly and the opportunity to dictate development.

Also, in the shape of Firefox, the Mozilla project finally achieved its proper goal: it became the best browser in the world, better and faster than its competition. If you believe the statistics, Mozilla and Firefox are still marginal in the browser market - though Firefox is steadily climbing the charts - but for the first time in a long while Internet Explorer is lagging behind its three biggest competitors, technically.3 Although not much is left of the original Netscape browser, there is good reason to be grateful to those who set the Mozilla project in motion. The community that has grown up around Mozilla has proved stronger than the substandard spaghetti code that it inherited. The Mozilla project has given the Open Source community far more than the browser called Mozilla. For instance, the Bugzilla tool, used in almost all Open Source programming projects, is an offshoot of Mozilla, and is also used by many software companies in the production of closed programs.

Finally, it has to be said that an historical wheel has come full circle with Mozilla. The Netscape browser was based on the Mosaic browser originally developed in the academic environment of the National Center for Supercomputing Applications (NCSA).4 When the code for Netscape was released under the Mozilla project, it can be said to have returned to its roots. And actually Mozilla's Web browser is only part of a bigger story: the World Wide Web technology was originally developed in the CERN laboratory, from which is was given to the world, open and free. And before the Web was invented, the entire Internet and all its technologies and standards had evolved in the same way, in the community of Unix hackers, in accordance with the principles of openness. When open Apache became the most common Web server, closed Netscape was actually a tiny freak in an open world - which makes Mozilla the prodigal son returned.

Verdict: The opening of the Netscape code began the popularizing of the Open Source movement, making it a viable alternative for other companies too. Open Source was a kind of defence mechanism for Netscape, for it to make a stand against Microsoft's crushing ascendancy, and in that the strategy worked. Technically, however, the Mozilla project faced enormous challenges. Many years of uncontrolled growth of spaghetti code and the problems that caused didn't magically evaporate under the influence of openness - sorting out the problems took much longer than anyone could have foreseen.

• 1Soon after George W. Bush came to power the trial was brought to a speedy end by the Court expediently finding Microsoft guilty of abusing its monopolistic position, but imposing no sanctions.
• 2Prior to this, the only term used was "Free Software'.
• 3In addition to the Mozilla family (Mozilla and its derivatives Netscape, Firefox, Galeon, etc.), Internet Explorer has two other competitors in the closed Opera and the open Konqueror, which is also the basis for Apple's new browser Safari.
• 4The same is true for the closed Internet Explorer.

Borland became known for its good programming tools in the nineties. In fact, I wrote my very first Java application using Borland's JBuilder which came on a free CD. For reasons nobody as yet seems to understand, this well-known company had some sort of identity crisis at the end of the nineties. In a misguided effort to create a brand name, the company renamed itself Inprise. As it soon became apparent that nobody had ever heard of the company called Inprise and that everybody went on calling Borland Borland, the management then changed the name to Inprise/Borland.com, and soon after that to Borland/Inprise, and finally back to the familiar Borland.1 Of all the crazy IT stories from the turn of the millennium, the Borland-Inprise-Borland one takes the prize for most schizophrenia.

One of Borland's products, which it had purchased in 1991, was the SQL database called InterBase.2 Although not on a level with its bigger cousins Oracle and IBM DB2, InterBase was fairly common for smaller database use.

Just before the end of December 1999, the professional and determined leaders of Borland - actually, Inprise at the time - announced to the developers of InterBase that they were halting the development of the database. Apparently, the management was unhappy with the level of profit InterBase was generating. Even though the product was not in the red, for some reason they'd decided to pull the plug on it.

Borland's customers weren't happy. Big clients like Nokia and Motorola used InterBase widely and in important projects, and if nothing else helped they were even prepared to buy the whole InterBase division from Borland. With big clients like that putting pressure on Borland, the company finally compromised by deciding to release InterBase under an Open Source licence.

And that, one would think, was that. But not a bit of it, the story is just begun.

When the Borland management finally cottoned on to how strong a product they had, they suddenly changed their minds. Of course they ought to go on selling such a good product - what with big clients coming with bags of money and practically begging them to do so. So when the first Open Source version, InterBase 6.0, was released, Borland started pulling out of the project. Suddenly, the company gave the Open Source version no guarantee or support, and on the whole the company went back to the good old way of closed software, charging their clients according to the one license per machine principle.

The result of this confusing and partly amusing story was Firebird, the genuinely open Open Source version of InterBase. The Firebird project amassed a number of programmers who were fed up with the yo-yoing at Borland and were determined to keep working on the open version on their own. Borland's own programmers weren't involved in Firebird, but it was developed by some accomplished programmers from outside Borland who had worked on the first versions of InterBase back in the eighties, together with some other programmers and consultants who had worked with InterBase.

In many ways the first years of Firebird resembled the tale of Mozilla. When the code of a closed program is opened up, all the garbage that has been quietly swept under the carpet over a period of years is suddenly revealed. It is said that one of the first surprises was that compiling the InterBase code into runnable program code produced several thousand warnings of possible flaws in the code. Such "compiler warnings' don't necessarily signify serious problems and don't usually prevent a program from working, but the fact that there were thousands of them says something about the attitude of the programmers working on InterBase.

When a program is developed openly, the situation usually never gets as bad as it was with InterBase and Mozilla. In the development of closed programs, there is always the temptation to take the line of least resistance. Flaws are unimportant: if the program runs and functions and seems superficially OK, it's put on the market right away. The quality of an Open Source program is open for all to see, not to mention the personal reputation of the writers of the code being at stake; so, working in an open environment raises the bar.

The Firebird hackers had to spend the first year or so cleaning up the code. And that long overdue spring cleaning certainly revealed some hairy skeletons in the InterBase cupboard.

In InterBase, as in database products in general, it is possible to define a number of different user IDs and give these users different rights. The person in charge of the database can have the right to do anything, a secretary can have the right to add or delete data, while other users only have the right to read but not change the data. User IDs, passwords, and the level of each user's rights must, of course, be stored in a way that allows the database program to access the information.

In the case of database software, the programmer is lucky in that a database is just the place to store user information. That's how InterBase had done it. The trouble with such an arrangement is that it leads to a chicken-or-egg situation. For a user to access the database, the user ID and password must first be checked, but the user ID and password are stored within the database that can't be accessed until the user ID and password have been checked!

There are probably a number of ways to get around this problem, but in 1992 the Borland programmers chose a solution that must be the most direct. They added a so-called hard-coded extra user ID and password giving access to all databases within InterBase! This user ID had been used internally within the InterBase code to bypass the chicken-or-egg problem, i.e., to check if the user ID and password given were correct. But once the code had been made open and the password that bypassed all further checks was there for all to read, it could also be used to break into anybody's database.3

Another skeleton in the InterBase cupboard was almost as bad. To ease their testing, the Borland quality control unit had demanded that the program contained a command that would allow a database to be scrambled or completely destroyed.4 Inexplicably, they insisted that this command be left in the version of InterBase that was sold to customers. Obviously, the InterBase user manual contained no information about this command, which was only intended for internal use by the quality control department, but leaving a destroy-all-files type of command in a version to be sold to clients does sound a bit like playing Russian roulette with their data. Even more incredible is that this was apparently done at the express request of the quality control department.

So, how have things been with the Firebird project since then?

It's doing fine, thank you very much. It took a little over a year to sort out the worst messes, then it was another six months before Firebird 1.0 was published in March 2002. Though the Firebird hackers got through their spring cleaning sooner than their comrades cleaning up the Mozilla code, this too shows what an enormous job it is to inherit the responsibility of developing an old program.

Firebird has done reasonably well, but it hasn't had the same reception in the Open Source community as Mozilla, because the open MySQL and PostgreSQL already more than adequately satisfy the hacker community's need for databases. Firebird has, instead, found its customers among the old InterBase users, who no longer need to be that worried about Borland's quirks.

Verdict: The InterBase story clearly exemplifies the risks involved in using closed programs. What are customers to do when a manufacturer decides to stop developing a product they really, really need? Building the IT infrastructure of a company on Open Source programs is always a safer option, because it allows the user of a program to make their own decisions about the future. As was the case with Mozilla, the first year of Firebird exposed how much can be hidden or overlooked within a closed program, while revealing how much better the quality of an open program is likely to be. It has been said the security of Open Source programs is better, because openness helps reveal the bugs in a code. In the case of Firebird, this did happen, but it actually took more than six months before a critical gap in the defences was found - despite the fact that it was obvious and easily identifiable in the code.

• 1At this point I'm sure one is allowed a smile. Earlier in this book I've spoken against planning and predetermination, but you have to draw the limit somewhere!
• 2InterBase itself had been created way back in 1984.
• 3You must note that the openness of the code was not the problem, but the laziness and irresponsibility of the original Borland engineer. The code would have been easy to spot even before the Open Source release of InterBase; all you had to do was to look at InterBase's machine code files with an ordinary text editor. It is perfectly possible that some cracker did this - the "back door' had been in existence for nearly ten years.
• 4Most likely the command was used to create artificial error situations to test how the software handles them.

id Software will go down in history as the company that published the first three-dimensional shooting game for PCs. You probably haven't heard of Hovertank 3D - I certainly hadn't - but its successors are legendary: Quake and Doom. Quake, which you could play over the Internet, had a particularly loyal fan base. For them, apparently, nothing was more fun than crawling around a sewerage system using a flame-thrower to shoot at friends dressed up as bogey-men - virtually, that is.

The man behind these games, John Carmack, decided to give all Quake fans a special gift for Christmas 1999. He used an Open Source licence to publish the source code for Quake 1 on the Internet. This was no great sacrifice: the sales of the game had already dwindled to next to nothing, and id Software was selling several new games, fancier than the first, among them Quake 2 and Quake 3, and their code was not made public.

However, soon after the happy surprise, chaos reigned in the world of Quake. The publication of the source code had led to cheating in multiplayer Internet games! Skilful programmers made changes in their own Quake, enabling their characters to automatically dodge all bullets coming their way.1 Or they programmed their character to aim at and shoot all enemies as soon as they appeared - and to do so at lightning speed. Another good scam was to program all walls in the game to be transparent, which allowed the player to see enemies hiding around corners, while the enemies played the game in a version with solid walls.

Although the programming of such X-ray vision and automatic ducking can be an interesting challenge in itself - a challenge programmers could compete in, actually - many Quake players were irritated by the cheating versions of the game. It's not much fun playing against someone who is impossible to hit and who can see through walls.

Eric Raymond, always keen to promote the Open Source idea, hurried to publish an essay on this fascinating problem. He suggested that it was yet another example of how easy it was for closed programs to go for solutions that aren't really safe and which can't take open scrutiny. He argued that if Quake had been created in an open model from the start, such problems would have been dealt with at an early stage and therefore avoided.

In this, however, Eric was wrong! The problems with Quake had nothing to do with its creators sitting in their closed world and choosing shortcuts that compromised security. In fact, you couldn't cheat by giving yourself an unending supply of weapons and ammunition, for instance, because such things had been made impossible at the designing stage of the game. The nature of all the methods of cheating (except the X-ray vision) was that the player had used his own computer as an aid to play better, be it for better aim or something else. This way of cheating could theoretically have been realized earlier, without access to the source code, but publication of the code made it a lot easier and perhaps also more fun.

Actually, the problem highlighted by the cheating in Quake had been realized earlier elsewhere. Playing postal chess had long ago been ruined by chess computer games. The mere suspicion that your opponent might be using the help of a computer was enough to spoil the fun. This is why postal chess is so rare today.

Learning more about the nature of, and reasons for, the cheating also led to the understanding that this was a problem particular to games. In real life we use computers to help us with difficult tasks; that's the whole point of having one. In the military, computers are used to improve aim - just as those who cheated in Quake had done - and nobody thinks that's unfair. Or if we go for a more peaceful example, nobody would accuse me of cheating when I use a computer program to find the cheapest of whatever I want to buy from all that is offered on eBay. That is precisely what computers were invented to do!

But the world of games is different. The idea of a game is that everybody plays it by the same rules, without supplementary technical aids. If I wanted to travel a distance of 26 miles (42 km) as quickly as possible, I'd go by car, or perhaps by helicopter. But if it's a marathon race, it would obviously be cheating to go by car.

Not only would it be cheating, it would be boring. And that's what the Quake players concluded. Cheating is boring. It takes all the excitement out of the game. One player got it right when he said: "I play Quake like I play any other game. Only with friends - who don't cheat.'

Verdict: The story of cheaters in Quake is interesting because the Open Source model creates problems that would never arise with a closed program. However, the problem is limited to Internet gaming, or perhaps rather to "remote game playing', such as postal chess. In the "real world' the Open Source model still seems to lead to better security. Finally, it has to be said that there are a lot of multiplayer Internet games with accessible source code, just as there are probably still those who play postal chess.2

From the above it is clear that opening up the source code of a program that has been developed in closed circumstances isn't as rosy a prospect as might be supposed. The code in many closed programs is often so abysmal it doesn't bear exposure. There are often horrible skeletons in the closet. In the case of Quake, the Open Source model led to totally unexpected problems, a situation nobody foresaw.

These stories throw new light on the demands to open up the source code of Windows, for instance. Who knows what skeletons you might find there? In the monopoly trial, Microsoft defended itself against demands to open up the code by saying that it would constitute a threat to US national security to publicize it. The Open Source people laughed to hear Microsoft say this. "That's what we've been saying all along, that a buggy Windows is a threat to the security of us all!' But having learnt from the stories of Mozilla, Firebird, and Quake, it is right to take the Microsoft claim seriously. In short, security concerns suggest it would be best not to use closed programs, but now that we are using them it's probably better to keep them closed.3 Mozilla, InterBase, and Quake each represent a slightly different philosophy about why it was worth making the code public.

The managers at Netscape decided to open up the source code for Mozilla as a sort of defence. As an Open Source project Mozilla has achieved what Netscape couldn't make happen with a closed program. Even Microsoft couldn't crush the open code. The code was opened at the last minute, however; Mozilla was saved, but for Netscape the company it was too late.

In the case of InterBase, it was the clients using the product who were looking for shelter. The decision to stop developing a closed program is always a threat to its users. Whereas, users of open programs are free of such threats.

With Quake, it wasn't about anyone protecting themselves, but rather more of a cultural achievement. Since Quake, many other games have been "set free'. Their source codes give the fans pleasure, even though the financial heyday of the game was over long ago. Many games can be ported to new platforms, for instance, if the source code is available. Old Windows games are finding new life on Linux machines, or you can play an old Commodore 64 game on Windows. So, Open Source is also about preserving our heritage!

• 1I can't help thinking that the Matrix scriptwriters must have played this version of Quake!
• 2One of the most popular Open Source shooting games is BZFlag which can be played on Windows, Mac and Linux as well as other variations of Unix. https://BZFlag.org/
• 3On February 12, 2004 a large portion of the Windows source code leaked on to the Internet due to security problems at a Microsoft partner (https://slashdot.org/articles/04/02/13/165231.shtml). We are therefore facing the worst possible situation vis-à-vis Windows: it has been developed as a closed program, which means it has more inherent security risks than for instance Linux. The code has leaked into the public domain, which means crackers have an easy time looking for the flaws. At the same time, programmers who might be able to help Microsoft find the problems and fix them cannot do so because it is illegal to be in possession of the code. Microsoft is therefore threatened by all the dangers associated with a sudden publication of closed code without being able to take advantage of the positive aspects of the Open Source process.

The biggest problem for Linux users and would-be Linux users throughout the nineties was the lack of proper office software. Actually, I don't think there was a good alternative for any Unix-type operating system. Scientists at universities would have written their articles "in code' with LaTeX or HTML using, for instance, Emacs, the venerable text editing software created by Richard Stallman. But even most scientists would probably have done what everyone else did: they used Windows together with either Microsoft or Corel office applications. The lack of an office program - and particularly the lack of word-processing software - was often a crucial hindrance to anyone wanting to move from Windows to Linux.

To rectify this, there were naturally some Open Source projects. AbiWord and Kword are popular word processing programs, while Gnumeric and Kspread replace the spreadsheet program Excel and KPresenter replaces PowerPoint. However, to replace the whole of Microsoft Office is not easy, and to be honest even today, in 2004, none of these projects are on a level where they could seriously challenge MS Office.

The problem is not that one couldn't write a text using these programs; it's that they don't do well enough in reading Microsoft Word documents. In an era when a lot of files are sent attached to e-mail, it's imperative that files generated by monopolistic Microsoft can be opened flawlessly. Because these file formats are not public standards, it's not all that easy to write a competitive program - in fact, it requires a lot of guesswork, trial and error.

Closed software was slightly better at overcoming the same problem. Applix was a popular package of office programs and it used to come with a lot of Linuxes. Corel's WordPerfect made its short Linux visit before Corel dropped out of the Linux experiment and left the WordPerfect users on Linux empty-handed.

StarOffice, from the German company StarDivision, was also very popular. This software's popularity was increased by it being free to private users. In addition to which, it could be run on both Linux and Windows. Even so, StarOffice has never been as popular as WordPerfect or Word, but it has nonetheless had a relatively long and distinguished history since its first versions were developed back in the days of DOS.

In August 1999, Sun announced that it had bought StarDivision and with it the StarOffice software. Sun also let it be known that it had plans to publish the StarOffice code under an Open Source licence. Because StarOffice was already a popular office software among Linux users, this news was greeted with jubilation.

Sun handled the Open Source release of StarOffice a lot better than Netscape and Borland did theirs. It took nearly a year before any code was actually published. During that time the code was cleaned up and some of the German documentation was translated into English, so that as many hackers as possible would be able to understand the open code. Some time was also spent on removing code that wasn't Sun's to open, i.e. where the copyright was owned by third parties and therefore couldn't be published under an Open Source licence. In the end, the code was released in July 2000. In October the OpenOffice.org website followed, becoming the home of the hacker community developing the code as well as the name of the Open Source version of the software.1

StarOffice was no dream gift for the hacker community - in quality, it was comparable to InterBase and Netscape. One of the most immediately visible quirks was that in StarOffice all the programs, from word processing and spreadsheets to its e-mail program and browser, were one and the same program. And in order to make the program look the same on all operating systems, whether for use on a Linux or a Windows machine, there was a user interface that replaced the real operating system, from the Start button to file management. The idea must have been to ease the difficulties arising from the differences between the operating systems, but for most people the result was pretty much the opposite. StarOffice seemed equally weird to both Windows and Linux users.

So to begin with, OpenOffice was also mainly a clean-up project. The cleaners chose to get rid of the browser and e-mail program altogether because there were better Open Source alternatives. The single chunk of office software was chopped up into separate programs for word processing, spreadsheets, and so on. Sun's careful preparation and commitment to the project together with the enormous interest in the "missing link' of Open Source applications helped the clean-up crew over the first hurdles. Only a year after the OpenOffice.org project was founded they were able to release the Build 638c version, which was a relatively stable and usable test version of the new open office software. OpenOffice 1.0 was published on May Day 2002. By then, more than six million copies of trial versions like Build 638c had been downloaded from the website.

For a long time now, Linux has been a good choice for a server operating system, but in the nineties it had yet to become a serious contender for desktop computing. OpenOffice has changed all that. Even before the final 1.0 version many cities and nation states started finding out how it might be possible to switch to Linux and OpenOffice in their offices. Many German cities, Munich was the first of them, have made this decision. In the corporate world Novell, for one, has found that as the largest Linux company, it actually has a responsibility to show the way, so it too intends to give up using Microsoft software as soon as possible.

The move away from the Microsoft monopoly to the open world is eased by both Mozilla and OpenOffice being compatible with Windows, which eases the changeover. First, while still running a computer on Windows, one starts using the open software browser, e-mail, word processing and spreadsheets.2 After this it's time to start switching from Windows to Linux, and users hardly notice the difference as they continue to use the same software programs. Novell, for instance, will make the changeover in this way. You too can take the first step towards more open data processing right now. And installing Mozilla and OpenOffice on your computer won't even cost anything!

The advent of OpenOffice was a key step forwards in enabling the use of Linux on desktop computers, but there remains the question: what did Sun get out of all of this? Was the purchase of StarDivision only charity, or was it more about buying a stick to poke at Sun's archenemy, Microsoft?

It wasn't charity, but Sun's relationship to Microsoft may have played a part. Sun's relationship with Linux has been difficult. Linux is strong competition for Solaris, Sun's own operating system, and keeps gobbling up ever larger slices of the Solaris market. Which is why Sun has seen Linux as a threat, and some of the craziest things CEO Scott McNealy has said about Linux can actually hold a flag to Bill Gates' infamous statement about Linux being a Communist and anti-American system.

In desktop software, the opposite is the case, because in that area Linux and Solaris are both underdog competitors to Microsoft. The desktop software for Solaris is mostly copied from Linux GNOME, but it was still short of an office software bundle. Sun donated StarOffice to the Open Source movement, because it was obvious that the open development model was their only chance of challenging Microsoft.

I don't know if Sun's attitude of "your worst enemy is also your best ally' is a sign of schizophrenia or if it's just post-modern, but in any case OpenOffice has been a success - also from Sun's point of view. Sun has sold its own StarOffice version in the millions - although most were sold very cheap, for instance to universities. At the end of 2003 Sun came out with a news bombshell; it had made a deal with the People's Republic of China to sell up to 200 million Linuxes for desktop use at $50 a pop. The existence of OpenOffice, along with Mozilla and many other Linux desktop programs, were a requirement for a deal like this and they are of course included in the package. After the deal with China the company has done a lot more Linux business around the world with, for instance, demand rising for Sun Linux desktops in the UK.

Verdict: OpenOffice is arguably the most successful and definitely most important project in which a closed old program has been released under an Open Source licence. The release of OpenOffice 1.0 removed the last barrier for far-reaching Linux planning in companies and the public services. Furthermore, it seems that the OpenOffice venture will prove to be a financially successful investment for Sun.

• 1Sun still also sells an office program under the name of StarOffice. It is nearly identical to OpenOffice, but also includes some non-open extensions, such as fonts and an Access-type database program.
  The official name of OpenOffice is "OpenOffice.org' (OOo, for short), because plain "OpenOffice' was already a registered trademark. Unofficially, the name used is practically without exception OpenOffice.
• 2Mozilla also has an e-mail program. There are many other e-mail programs for Linux, and Mozilla is not the most popular of them but it is the only one that will run on both Windows and Linux.

On 5 November 2001, IBM sent out a press release announcing a donation of $40 million worth of tools to the Open Source community. The press release made it clear that this was all about some sort of application used for Java programming, but in real life most of the hacker community, or the IT business at large, had never heard of IBM's Eclipse.

A number of reasonably good programming environments already existed for the Java market, and IBM had realized that this made its own Java programming environment - at that point not yet called Eclipse - a less than sensible investment. Not that there was anything particularly wrong with the IBM toolset, but nor was it significantly ahead of its competition either. Which meant it would probably never replace the competition. Indeed, there was a risk that things would go the other way and IBM's offering would be superseded by a competitor's product.

However, IBM didn't want to give up its programming tool, as it was an irreplaceable part of the IBM portfolio - its main products being an expensive Unix and Linux server, the DB2 database and the Websphere Java application server. It would be hard to sell clients an application server if at the same time there wasn't also a tool for programming the application components for the server. Getting the programming tool from a third party - such as Sun or Borland - didn't appeal to IBM. That would mean spending money outside the company; and also, IBM wouldn't want to end up being way too dependent upon the unpredictable quirks of companies like Borland-Inprise-Inprise/Borland-Borland/Inprise-Borland.

In other words, an interesting situation. IBM had to keep developing Eclipse; yet, financially, investing in it was a bad idea. The solution, of course, was Open Source.

IBM had already grasped the idea of Linux and Open Source before they released Eclipse. While many other businesses in the IT sector saw the distribution of programs for free as a dire threat to their own existence, IBM had understood that even when people had switched to Linux there would still be plenty of work for IBM to do. In fact, IBM already had experience of Linux, and that experience had shown them that clients bought as many IBM servers as ever and paid just as much for them, even when they ran on Linux. In fact, now that the IBM servers were running on Linux, even more people were buying them. The only difference to the old Unix servers was that the development of Linux didn't rest solely on IBM. In other words, labour costs went down while revenue went up!

As news of Eclipse, and knowledge of what it really was, spread it gathered more developers and a lot of users. Today, it can be described as the best and most popular Java development environment available. Which means it very quickly became a success story; much faster than, say, OpenOffice or Mozilla. In addition to Java, it now has modules for C- and C++ programming, as well as many other uses, such as programming in Python. Once again, the Open Source development model has shown its strength and wealth and outperformed all competitors.

Where OpenOffice satisfied a need in the Linux world, the situation was different with Eclipse. There was no lack of Java programming tools - in fact, there were too many of them! They were all reasonably good, but none of them came close to the brilliance of today's Eclipse. The existence of so many different tools was a problem for all companies working in the Java market, as the programs did not follow any agreed standard and caused unnecessary training costs, etc. When all parties gathered around one common and open solution, less effort quickly gave better results.

Before Eclipse, most Open Source projects had been collaborations which centred around a single private individual - such as Linus Torvalds - or were administered by non-profit umbrella organizations founded by individuals - like the Apache Software Foundation. Mozilla and OpenOffice were still administered by their old parent companies, but they weren't collaborations between companies, as the participants were mostly individual programmers. IBM, however, had gathered an impressive group of 150 collaborating companies behind Eclipse, and their first press release mentioned in particular Red Hat, Rational and TogetherSoft. Soon more businesses joined, among them Oracle and Borland. It's encouraging to see that businesses can actually be successfully involved in Open Source projects at an organizational level.

Verdict: The incomplete Eclipse was dropped into the lap of the Open Source community like a bolt from the blue and quickly became a very functional and versatile Java programming tool which outperformed its numerous competitors. IBM is the one old IT business that has adopted the rules of the Open Source world better than the rest, which is why Big Blue is doing swimmingly alongside the Linux penguin.

Blender, which makes 3D animations, started in 1995 as an internal programming project in the Dutch animation studio NeoGeo. It replaced the animation program previously used by NeoGeo, which originally had also been developed for internal use.

The average computer user sees Microsoft and other manufacturers of finished programs as the embodiment of software production, but in reality most of the worlds' programmers work on internal programs for specific companies, such as Blender. Programmers work everywhere and anywhere, from banks and insurance companies to film studios, because the programs needed by such businesses aren't always available "off the peg'.

Because Blender was such a brilliant program, its creator Ton Roosendaal decided to externalize the development of it to a separate company called Not a Number. The idea was for NaN to sell licences to Blender for other animation studios to use and get revenue from the consultation services surrounding it. The new Blender software was presented at the Siggraph animation conference, where it immediately awakened a lot of interest. The company was then able to raise a total of €4.5 million from venture capitalists and soon had 50 full-time programmers working on Blender. The first version - known as version 2.0 - was released in the summer of 2000 and by the end of the year Blender had 250,000 registered users.

Unfortunately, something went wrong and the capital was spent before the project was properly up and running. In April, new investors had put their weight behind Blender and the development was continued by a reborn but considerably smaller NaN. Six months later this new NaN company released Blender Publisher, which was designed to do the in thing, i.e., create three-dimensional interactive media on the Web. However, the sales figures for the product were a disappointment and the second lot of investors also decided to pull out. The company quit all operations and development of Blender was discontinued.

Although Blender hadn't conquered the world, it already had a loyal user base. Encouraged by the feedback from these users, Ton Roosendaal tried a third time to save Blender, and this rescue operation did work.

Ton founded the Blender Foundation and made a deal with the investors who owned the rights to Blender. The investors agreed to sell Blender to the Foundation for €100,000 under the GPL licence, thus enabling the Foundation to keep developing the software according to the principles of Open Source.

For venture capitalists who have lost several million, the offer of €100,000 is naturally better than nothing. And the deal didn't involve Ton in any risk either - but how would he raise the €100,000?

To his own surprise and that of all the other people who had been involved in Blender, Ton and the other former employees of NaN managed to raise the money in a mere seven weeks! On Sunday 13 October, 2002, Blender was turned over, under GPL licence, to the caring hands of the Open Source community.

As an Open Source program, Blender once more came to life. There have already been several new versions. The number of users is increasing and a whole community is growing up around the software. Thousands of users chat on Blender's website and on IRC. Images and short films made using Blender can be viewed, and admired, via the many links on the Blender website. The program can also be used to make games and some Open Source games have already been built around the software's games engine.

Financially, the makers of Blender have also moved from the traditional venture capitalist model to Open Source financing. For the Blender Foundation's fundraiser in 2003, some 3,000 copies of the new Blender guide were sold. At the beginning of 2004 the Foundation received research and development grants from the EU to the tune of €140,000. Thanks to this funding, both large and small, together with numerous hackers volunteering for the project, Blender's future looks brighter than ever.

Verdict: Through citing several examples, this section of the book has considered whether or not it is possible to build a viable business on the Open Source development model. Despite the number of examples, you may remain not yet wholly convinced; or perhaps you're thinking that, along with the closed development model, Open Source may be a model that is "OK', a model that "does work'. However, the story of Blender turns the tables on that question. What is wrong with the closed and venture capitalism based "traditional' programming development, which twice failed with Blender and nearly killed off a great product? After all, this product had a brilliant future ahead of it - but not until the right business model was found!

"The end of the road', read the surprising headline on the front page of the Linux Weekly News (LWN) of 24 July, 2002.1 Founded in 1998, it had established itself as the most reliable, expert, and analytical Web publication of the Linux community. Today, Linux Weekly News, like Linux Today and Slashdot, publishes daily links to various Linux news sites, but its mainstay was always a weekly issue consisting of original articles.

As usual, in the last July issue it published articles relating to the world of Open Source, and included stories on: RealNetworks' decision to switch to the Open Source development model; US plans for legislation that would give film studios and record companies the right to harass and possibly break into the computers of Internet users of their choice without any police or court order; security problems at PHP and SSH; the cli() and sti() functions of the Linux kernel, and the publication of Ogg Vorbis 1.0 and Debian GNU/Linux 3.0. Then, out of the blue, at the end of the main page was an article under the heading "The End of the Road'.

Linux Weekly News had come to the conclusion that banner advertising wasn't a viable way of financing a free webzine.2 For some time, LWN accepted donations from its readers through the PayPal system, and even though the income generated was somewhat bigger than the advertising revenue, it still wasn't enough to finance a staff of five. Having considered the option of making LWN a subscription webzine, the people behind LWN finally decided to call it a day. The issue of 1 August, 2002, would be the last. There was nothing else to be done; the decision was final.
The reaction of LWN readers to this announcement surprised everybody, including its editors and the readers themselves.3 Naturally, the demise of the most esteemed journalistic publication focusing on Linux caused great disappointment, even shock, but the response to the announcement being what it was, on a practical level, was historic.

Posted Jul 25, 2002 20:26 UTC (Thu) by other-iain
I've read LWN for about 4 years. My guess is that a reasonable subscription price would have been $30 a year. That's $120. I gave $20 earlier, so that leaves $100 unpaid. I've just put that $100 in through PayPal. Consider this payment for services rendered. I'm sorry to see you go, but I understand why [...]

Good luck in your post-LWN ventures. Let us know who you're writing for next so we can tune in.

Posted Jul 26, 2002 0:46 UTC (Fri) by BogusUser
I did the same, registered to donate, and to say thanks for the great work over the years. If these extra donations do not make enuf of a difference I smile thinking of you having a beer on me.

Posted Jul 26, 2002 14:19 UTC (Fri) by jgm
I hope you find your miracle. I've donated my US$100. I hope it helps keep you going. If not, consider it my late :-( subscription fee for your fine publication.

I've found LWN to be the best site for keeping up with what is happening in the GNU/Linux, Free Software, and Open Source Software world. I'm really going to miss you!! I especially enjoyed the Kernel section. My Thursday's are just not going to be the same without LWN!

In any case, best of luck to you all and thanks for the great work you've done on LWN. I hope you can find a way to continue.

By the time the following week's issue was published, a total of $25,000 had been donated! For a staff of five editors, that would only cover expenses for about six weeks, but it did make the LWN staff rethink their decision to close LWN down. After a week-long break, they decided to turn LWN into a subscription webzine. The daily newslinks and the accompanying user forums would remain open to all, but the weekly publication of original articles would be available to subscribers only, and the price was set at $5 a month. However, LWN's loathing for the closed model proved so strong that the staff decided that all articles over a week old would be made available to non-subscribers.

After this decision, although LWN had to slightly reduce the number of permanent contributors and partly make do with freelance writers, life went on virtually unchanged. In 2003, LWN showed what it was made of when SCO claimed that Linux contained code that was illegally copied from SCO. While other IT publications at first accepted SCO's allegations as the truth, from day one the LWN editors knew what was what. When SCO published two examples of code sections "illegally copied into Linux', Bruce Perens and the readers of LWN were able, in less than a day, to trace the real origins of the relevant source codes and prove that one of them was a product of the seventies and, ironically, the other was written by the Open Source community and illegally copied by SCO.
Investigative journalism had shown that it was worth the price.

Verdict: The Open Source community has been criticized for taking a free ride in the world of IT. There is much talk of freedom, but nobody is willing to pay for anything, opponents claim. If nothing else, the LWN case showed that this is simply not true. Linux users may not be prepared to hand over their cash to monopolies whose prices are 90 per cent air. No way are they ready to give up their basic freedoms, such as the free sharing of source code. But they are willing to pay for something that is of real importance to them. The $25,000 in LWN's account proved that.

• 1https://lwn.net
• 2This may not sound like a very surprising conclusion, but in the golden nineties even banner advertising seemed like a smart idea.
• 3Readers' reactions are still available in the comments to the article at https://lwn.net/Articles/5409/

Because I did my compulsory military service in the non-combatant or civilian service, the story of the birth of Mandrake Linux has always fascinated me. The founder of MandrakeSoft, Gael Duval, has said that the idea of a Linux distribution of his own was born in 1997 when he was doing his civilian service and consequently had a lot of spare time. That sounds familiar, but for some reason I never came up with an idea to fill my hours by founding a company that would change the world.

Of the four major Linux brands, Mandrake is clearly the youngest. Gael released his first Mandrake Linux in the summer of 1998. He was a fan of the KDE desktop environment, which had just seen the release of the 1.0 version. The then market leader Red Hat hadn't made KDE part of its Linux, because there were some political differences about the licensing of Trolltech's Qt library, which KDE used.1 Gael took Red Hat's then 5.1 version, added KDE to it together with some other additions. He put the package he had onto a public Ftp server, called it Linux-Mandrake 5.1, and went off on a two-week summer holiday.

When he returned, his mailbox was full of enthusiastic responses! It was clear that "Red Hat with KDE' had tapped into a need. With Frederic Bastok and Jacques Le Marois, Gael founded a company called MandrakeSoft to continue the work with Mandrake Linux, and by 1999 Mandrake was one of the most popular Linux versions, winning several awards and honorary mentions and finally, in 2000, achieving the same sales figures in the US as the market leader Red Hat.

The third quarter of 1999 generated a profit of €100,000. Not bad for a little company celebrating its first birthday! But that would be the last profit-making quarter in the Mandrake books for a long time to come.

Because this was "new economy' madness at its most heated, Mandrake enjoyed the wheelbarrows of money that venture capitalists brought to the company's door. In interviews, Gael spoke of listing the company on the Nasdaq. With new investors, the company also got a new management, whose job it was to make the money invested in the company work. A lot of new programmers were employed to further the development of the company's popular Linux distribution. Money was also invested in new fields, such as Linux training and eLearning in particular. Education on the Web was one of the big things among the businessmen of the "new economy' in the year 2000.

The "world-class management team' - as Gael was later to describe the leadership in sarcastic tones - worked hard. Mandrake's turnover grew quickly, but unfortunately mostly on the expenditure side. Only a year after the first quarter being in the black, the company had a quarter that made a loss of €3 million, achieving an even worse quarter the next year: €5 million in the red!
When the new management had the bright idea to "cut losses' by dropping the development of the company's own Linux distribution, in order to focus on eLearning, the original owners reached breaking point. The management was told to pack their bags, and Gael once again took control.

From the start, Red Hat had been very loyal to the Free Software ideology and published all its programs under the GPL licence, but Mandrake went even further. Red Hat used to release excerpts of its future Linuxes in a package called Rawhide. However, Mandrake opened up the entire development process to interested independent hackers. Through mailing lists set up for the purpose, anybody could get involved in planning the future of Mandrake Linux. In addition to good ideas, the company also accepts code from volunteers, although their own employees, of course, do most of the work.

Does this sound Utopian? Would you do something for free, hand it over to a company, then buy the product they make from it back from them? It doesn't sound very likely, but already in the first year more than 200 eager hackers were involved in the Cooker project. Whether that's such a good name for the project is another question, considering the old adage about too many cooks spoiling the broth. Nonetheless, it's thanks to this strategy that Mandrake Linux has always been very close to its users and striven to respond to their needs - and after all that's what Open Source is all about.

From the start, part of the Mandrake strategy was to make the latest Mandrake version available on the Internet as soon as it was ready.2 This set it apart - in a good way - from Red Hat, which at the time used to delay the release of its online version until the physical CDs had reached the stores. In a number of interviews Gael said he thought it was good for the company to make the new version available on the Web as soon as possible, rather than artificially (mean-spiritedly) withholding it for months. And that way of doing things was also in line with the principles of openness.

The Mandrake strategy must have played a part in its rapid growth in popularity. But one would expect such a strategy to have had a negative impact on the sale of the physical CDs, which were always late. However, the most loyal users understood the principle of reciprocity, and as soon as the CDs were available they went and bought them just to support the future of their favourite Linux. Besides which they were happy to pay for such a good product. The CDs themselves were obviously of no use to them, since they'd already been using the downloadable version for several months. They just happened to understand that without any revenue their favourite Linux couldn't stay around for long.

This principle of reciprocity gradually grew into the idea for a new business model: the Mandrake Club. CDs are slow to manufacture, and many of the buyers didn't even need them; they only bought them to support Mandrake. So, why bother them with having to buy the CD at all, since the manufacture, packaging, and physical distribution of CDs all costs money. The Mandrake Club is for Mandrake users, who pay what is essentially an annual subscription fee ranging from $60 to $1,200, with most users paying either $60 or $120 a year.

There are some practical benefits to being in the club. Using your Mandrake Club password you can download versions of Java, RealPlayer, Flash, Acrobat and other programs that have been adapted for Mandrake; programs that are free but not freely distributable. Without the club, a Mandrake user would have to surf the Internet to pick up the same programs and install them one at a time. A feature that has proved very popular among club members is RPM Voting - the chance to vote on which Open Source programs should be included in the next version of Mandrake Linux. This allows even those Mandrake users who lack the level of programming skills necessary to participate in Cooker to influence the future of their Linux distribution. But, in addition to this and some other relatively small benefits, there is no actual reason to pay the membership fee.

Briefly, Gael Duval's argument for the Mandrake Club was: "Following the principles of the Free Software ideology we wish to give you Mandrake Linux completely free, without any catches. We also want to give our products the necessary security updates freely and for free, without any catches. In the long run we won't be able to do this, however, unless somebody pays our employees. Therefore we ask that you support the Mandrake Linux, which we have given you for free, by joining the Mandrake Club.'

Once again, that sounds Utopian. Who would pay to belong to a club if there were no benefits to be had? As in the case of Linux Weekly News, the Mandrake Club has shown that Linux users are willing to pay for services they have enjoyed for free if the service or product is worth it. In 2003 the Mandrake Club had some 14,000 active members as well as a couple of corporate members (who pay a higher subscription fee).

That is a small number compared to the several million people who use Mandrake Linux. Even so, if each of those 14,000 users has paid an average membership fee of $120, that's $1.68 million a year, which is quite a lot for a company the size of MandrakeSoft! And the good thing about it is that the income goes directly to paying the salaries of the company's programmers, rather than to paying for the manufacture of superfluous CDs.

Although the company rid itself of the management team that had almost bankrupted it, some of the commitments they'd already made were not so easy to shake off. The eLearning deals, for instance, required payments to be made for years to come and despite MandrakeSoft severely streamlining its operations, the old sins cast long shadows in the form of many accounting quarters in the red. But Gael's long-term commitment to the principle of openness had created a group of loyal Mandrake users and they were the ones who kept the company going through the hard times.

During the worst period Mandrake even had to beg its clients for donations. Mandrake never listed on Nasdaq, but at the end of 2001 the company stock was on sale, on the slightly less well-known French exchange Euronext, to the most loyal supporters of the company, its own customers. In the long run they may prove to be better owners than the "world-class' venture capitalists. When the capital raised through the stock issue was spent and there were still bills to pay and commitments to honour, the company's founders had again to plead with its Mandrake users, who hurried to buy club membership and other company products. Again, in December 2002, the company asked its customers for support, and even this third time the Mandrake users supported them.

First the Mandrake Club, then the fundraising, and through it all Mandrake's customers remained staunchly loyal. In the tough IT business, not many companies would dare hope for so much from their customers, but as the Mandrake experience so clearly demonstrated, one does reap what one sows. From the outset, the company had been open and fair with its customers, and in return the customers helped it to survive.

Despite the help, MandrakeSoft had to apply for debt restructuring in January 2003 to protect itself from the last eLearning liabilities, which were due to be paid within the month. A little over a year after that the debt restructuring was completed and, even better, after a break of some five years the company again started to show a profit. With Red Hat moving away from the home users to focus on expensive corporate server architectures, many previous Red Hat users have become Mandrake customers and after a long break the company seems once again to be a strong Linux contender. Since the restructuring programme, their accounts have been consistently in the black, and in 2004 the company branched out from being the favourite Linux for home users to doing some rather more lucrative corporate business by making big Linux deals with two French government departments.

Verdict: MandrakeSoft has been the most open of the commercial Linux distributions and is strongly committed to the Free Software ideology. The company was born of its time, and survived the years of the Internet bubble which created a lot of froth for Mandrake. Through its Mandrake Club strategy the company built, on purpose, a business model similar to the one Linux Weekly News was later to chance upon. Both LWN and Mandrake are proof that if work is done openly, fairly, decently, and most of all if it's of use, then loyal customers will willingly pay and support it, even when it's in trouble.

• 1Qt was not at the time being distributed under the GPL licence, which is why for several years the entire KDE project incurred the wrath of Richard Stallman's Free Software Foundation.
• 2The company made an exception to this principle in the autumn of 2003, when it released the 9.2 version. At first, Mandrake 9.2 was available only to members of the Mandrake Club and was only released for completely free distribution at the same time as the CDs became available.

Part Three of this book has been looking at how Open Source companies survive financially. Among them we've looked at three of the four best-known brands of Linux: Red Hat, SuSE and Mandrake, but the job isn't done without looking at the fourth one: Debian.

Debian is not a company. Then how can it be considered as if it were a business model? Perhaps it can't. But Debian exists, and that can't be ignored. Not only does it exist, it's one of the oldest and most popular Linux versions and in many statistics it beats the competing Linux distributions hands down.

Have you ever installed a Windows machine or watched anyone else installing Windows? When the installation is complete, you have a computer that works, but no more than that.1 Next, you have to install a word-processing program (OpenOffice, maybe) and an e-mail program (Mozilla, perhaps). But that is just the beginning. What if you need image processing software? And how about your printer - does it work? And are you planning to play games? They all have to be separately installed and you even have to get them from various vendors, since you're using closed software.

However, if you're using Linux and Free Software, all the software can all be conveniently bundled up in the same package. When you've installed Linux, you've also installed hundreds of other useful programs, including OpenOffice and Mozilla. Because the software can be freely distributed, your Linux distributor - whether it be Red Hat, SuSE, Mandrake, Debian or anyone else - has been able to gather everything you need into one package. And your Linux computer will be ready to use in less than an hour.

For anyone who measures their Linux by the number of programs that come with it, Debian includes 8,710 different software programs, which is by far the biggest.2 And all this can be installed for free by downloading it from the Internet or alternatively from CDs that cost around €8 from DataClub. Imagine, 8,710 different programs, all nicely bundled up in an easily installable and working package.

The other Linux versions are usually only available for computers that have Intel's so-called x86 architecture and in some instances some other architectures, such as the PowerPC (Apple computers) or IA-64 (Intel's new 64 bit architecture) or AMD's Opteron. At least Red Hat and SuSE support IBM's mainframe architectures in addition to these. But Debian is in a league of its own. It works on eleven different architectures!3

The Debian project currently involves almost 1,000 active programmers or hackers. The biggest Linux company, Red Hat, has some 600 employees and only some 300 of them are engineers.4

Debian is a non-commercial organization which involves the Debian-making programmers but also the people who run Debian's Web and data servers. In addition to which, there is of course someone who donated the servers themselves as well as their Internet connections, or at least the money needed for them. Then there's legal counsel - they, too, are volunteers - and the people who write manuals and make translations. And of course a large project like this always requires some bureaucracy - even in the world of Open Source - so Debian also has elected leaders.

Debian was founded in 1993 by Ian Murdock.5 At the time, Linus Torvalds and company had got the kernel into such good shape that Linux could be used with other free programs on top of it. However, these separate free programming projects were spread any which way across the Internet and nobody had pulled them all together to make a unified operating source product. But in 1993 the first Linux distributions were born, and Debian was one of them.

Because the Linux kernel, the bash command interpreter, the GCC compiler, the Emacs editor and all the other tools required to make a perfect operating system, most of which had been created under the GNU project, had been developed through the open model, it was only natural for Ian Murdock to make his Linux distribution open too. The commercial Linux companies came into the picture a little later. And just as well - diversity and freedom are our guiding principles, remember?

And so, little by little, the Debian project started to develop, with an ever increasing number of volunteer hackers maintaining a growing collection of Free Software and a free OS. One of the early leaders of the project was Bruce Perens, who today is one of the best-known advocates of Open Source. One of Bruce's legacies is that Debian always offers a comprehensive range of software for radio amateurs.

The first "ready' version of Debian was (exceptionally) given the version number 1.1, and that historic event took place in June 1996. At the time, many commercial companies, among them Red Hat and SuSE as well as the infamous Caldera, had a good head start in their released Linux versions.
Debian has by its mere existence balanced the Linux world, by offering a free alternative to the commercial Linux brands. Where most Linux companies release new versions of their Linuxes as often as twice a year, Debian can let up to two years pass without releasing a new version. Perhaps more than any of the other Linuxes, Debian has kept to the principle of releasing a product only "when it's ready'. By the time Debian finally releases a new version, many of the programs included in it are already relatively old, because Debian observes a very conservative testing and quality control policy. In part, the delay also reflects the Debian principle of releasing for all eleven different architectures at the same time. Most other Linux distributions release the version for each of the architectures as they get them done.

Although many of us computer freaks love to try everything new on our computers, Debian's steady pace actually suits many people very well. In the corporate world - where people actually want to get some work done in between - it's a positive thing not to have to run around updating all the company computers so often. Besides which, Debian computer freaks aren't bothered by the slow pace, because many of them use the so-called "testing' version of Debian. The "testing' version is a continually evolving collection of software which finally becomes the next version of Debian. Although it's not an official version, it is of course publicly available - after all, this is an Open Source project!6

Since it has at times been difficult to guess at what Red Hat and SuSE are planning, and with Mandrake's future being at stake due to financial problems, and many smaller Linux brands have genuinely disappeared, Debian's non-commercial status has actually seemed to give it a competitive edge. Debian hasn't suffered from financial problems, its plans haven't changed every six months and nobody has suddenly offered to buy Debian - not that it would be possible, anyway.

In addition to users who value stability, Debian is naturally of particular interest to programmers and computer freaks. This, among other things, is reflected in the installation of Debian. Whereas other Linux companies make their installation programs as automatic as possible and give them nice colours, Debian's installation program tends to ask fascinating questions, such as: "What kernel driver file is needed by your network adapter?' or "What is the refresh rate of your monitor?' Real nerds know no better fun than answering such questions, but ordinary mortals need a Linux that is as highly automated and colourful as possible.

As a giant project maintained by volunteers, Debian also realizes the Open Source principle of doing it together. For programmers and other real nerds - from Linus Torvalds down - it's always been more fun to make your own operating system rather than buy it encased in a colourful cardboard box.

In this sense, Debian resembles the Finnish talkoo or barn-raising tradition. A Finnish talkoot [sic] is arranged when a Finn wishes to build, say, a summer cottage by a nice lake. What he does not do is to buy a ready-made cabin to be delivered to the site on a trailer. Where's the fun in that? No, the cottage is built using talkoo power. A talkoot is when someone gets all their mates and a few barely-known acquaintances together to build the cottage as a joint effort. The future hostess of the cottage serves the talkoo workers soup, and it's all a bit like barn-raising in the Amish culture. Except that the Finns obviously head to the sauna when the building work is done, and are also likely to down a beer or two at the end of the day.

The Debian project is like an enormous virtual barn-raising. Volunteers often gather on Internet Relay Chat (IRC) channels and work together to write the code for the new programs in Debian. While they're coding away they also chat about this and that, some of it related to Debian, some not. They're doing it together and having fun. Somebody may even have a beer and give the glass a virtual clink to drink to the success of it all. And alongside the fun, they create the best operating system in the world.7

But let's go back for a moment to Debian as a business model. Can we call barn-raising a business model? The unspoken assumption in this part of the book has been that one must be able to build a profitable business on Linux for the idea of Open Source to be viable. Debian (and Eclipse, Blender, Mozilla, and many other examples in this part of the book) prove that assumption wrong. Debian exists and is widely used, but it is not a business that is out to, well, do business.
Those of us who've spent years in an over-commercialized capitalist (mean-spirited) world seem to have forgotten that not everything can be measured in monetary terms. (And I'm not talking here about friendship, love, and the like, but actual material things.) There's a tendency to think that because Microsoft has such a huge turnover, then it must logically follow that Windows is a good operating system. But what is Debian's turnover? It doesn't even have one.

To equate profit with quality is to forget that the actual job of computer programs is not to increase turnover, but rather to produce books, letters, minutes of meetings, images, films, web pages, music, phone books, statements of accounts, payslips, information storage, to enable communication, space travel, and much else besides. And Debian, for instance, makes all that possible, including having been used on a space shuttle! So, Debian is a useful and meaningful thing - but not a business model.

Because many of us get locked into a certain way of thinking we can miss obvious connections and solutions. Twenty years ago, solar architect Steve Baer came up with a good metaphor for our inability to perceive locally available solutions. He called it the clothesline paradox. It goes like this: if I were to buy an electric clothes-drier, that purchase would show up on a statistic somewhere, from which someone would eventually infer that electricity consumption had increased in Finland. And so I will have made it that bit harder for Finland to keep within the limits set by the Kyoto Protocol to tackle climate change.8

If, however, I get rid of my clothes-drier and let my clothes dry on a clothesline, there's no statistic that says Finland is now using more solar energy. But that doesn't mean a clothesline isn't a good way to dry clothes. And there we have the clothesline paradox.

The old Debian activist Bruce Perens understood the lesson of the clothesline paradox. From the point of view of Linux users, it's not relevant how many operating systems they have bought. What matters is that the work which needs doing, can get done. Some business leaders who met Bruce have apparently realized the same thing, because at the request of some, as yet unnamed, clients, Bruce has recently begun working on a new Linux distribution called UserLinux. Its aim is not to sell as many copies of Linux as possible, nor is it the aim of UserLinux users to buy as many Linuxes as possible. What they do want, however, is to get their job done. The aim of UserLinux is to be a Linux distribution which, like Debian, is open to everybody, but also to be a more streamlined Linux version than Debian, to be more automated - for corporate clients.

At the time of writing, UserLinux was still just a "twinkle in Bruce's eye' and it remains to be seen how the project is realized. Red Hat's latest changes in its range and pricing are sure to have been instrumental in getting the debate about UserLinux going, and getting the organizations behind the project to see the benefits of a model such as Debian. "I know of one business that invested millions into developing the IA-64 Linux system, with a marked absence of help from Red Hat. Now, that business is forced to buy their own software back from Red Hat at a high per-unit price, to package with their own products.' 9 The project gets some credibility from the fact that the organizations backing it, according to Bruce, have pledged to finance UserLinux to the tune of one million dollars a year, and that these organizations have a total of some 50,000 computers. So, this is no longer just hackers getting together for some barn-raising and fun, this is big corporations wanting to get the job done.

Verdict: Debian is doubly Open Source. All the programs it contains are created using the Open Source development model. In addition to which Debian itself was born as Open Source. A thousand volunteers worked to develop Debian, which in many ways is the biggest Linux distribution. In the IT market of the early 2000s, Debian has even been the most financially stable alternative for Linux users. From the criteria applied throughout this book, there is simply nothing bad to say about Debian.

• 1Well, of course some people think a computer with Windows installed on it instead of Linux is a computer with serious problems. But let's pretend you have a working computer.
• 2This statistic is from December 2003. The number has been growing rapidly in the past few years, so by the time you're reading this, there's bound to be a lot more.
• 3By the time of going to press, this number too had grown.
• 4You could argue, of course, that today IBM and HP are also Linux companies and they do have rather more employees.
• 5If I tell you Ian's wife is called Debra, you can guess where the project got its name.
• 6The use of Debian's "testing' and "unstable' versions works in the same way as Mandrake's Cooker project. Actually, Debian was the model for Mandrake in this respect.
• 7You can get to know the people working on Debian through the IRC channels on at: https://www.linuks.mine.nu/debian-faq/
• 8American readers of this English edition can rest assured they have nothing to worry about in this regard. Their Texas-born president never signed the Kyoto Protocol, so you can all keep on using electricity regardless of climate change.
• 9Although Bruce Perens does not reveal the identity of the company which invested millions, it was Hewlett-Packard. And, remember that selling one licence per computer is rare in the world of Open Source.

In the case of Mandrake and Linux Weekly News, when clients are prepared to support a company financially in exchange for "nothing', i.e. not in return for certain products, one of the key issues has become how to report back to those clients on the company's financial situation. The message from the clients is clear: "We're happy to support you, but you must tell us how much money you need.' Some have even suggested that the companies make their entire accounts public, so that everyone has free access to check up on anything and to gain a clear picture of the company's financial situation at any given time.

I've yet to hear of any company that has actually done this, and for a listed company it may not be easy to do, as there are strict rules about what information they can and must give, and when. However, the thought itself is intriguing. It may not be completely realistic, and it is not directly connected to Open Source, but let's use the rest of Part Three on this mind game. If a company wanted to be as open as possible, how open could it be and what would it lead to?

Although the question is carried to the extreme, it is not entirely without precedent. Nokia, for instance, was cited earlier in this book as an example of a company that is sadly enamoured with non-disclosure agreements. However, the passion for keeping secrets is not something the company carries into every area. In its relationship with its subcontractors Nokia strives to make the information flow both ways as smoothly and openly as possible.1 If, for instance, a subcontractor could follow the sales figures for mobile phones by directly tapping into Nokia's databases, the subcontractor could prepare for the increased demand in advance, before the actual order comes in from Nokia. This would remove a number of bottlenecks and make the long and complex chain of production run more smoothly.

So, there is a realistic argument to be made for open thinking. But how open could a company be and what would it lead to? Now that IT companies are building their head offices from Plexiglas, it's about time we tried a thought experiment: What would a totally transparent company be like?
Our totally transparent company wouldn't necessarily be in the IT field, but the product would naturally follow the spirit of Open Source whenever appropriate.2 That goes without saying. But what else?

Well, first of all, it would obviously not have a single trade secret. Non-disclosure agreements would be banned. Like Mandrake's Cooker, product development would be open, with company e-mailing lists open to people outside the company.
Budgets and financial accounts would be open to public scrutiny insofar as it's possible and makes sense. Naturally, for reasons of confidentiality, the salaries and sick days of individual workers could not be made public, but otherwise everything would be out in the open.

In addition to product development, the company's board meetings and other negotiations at management level would also be publicly accessible. And I don't mean just the final decisions, but also any vetoed ideas and other suggestions that have been put forward would all be recorded and made accessible - the meetings could, for instance, be video-taped.

If a company were to meet such demands for 100 per cent openness, it would become a totally transparent company. What a contrast to all the "Enrons' of today to whose tune the financial world dances. Office buildings of Plexiglas may look transparent, but actually even the glass walls are less than see-through, as from the outside they reflect the external light rather than what goes on inside. Our fictional company, on the other hand, would be a true, genuinely transparent Glass House.

So, what would happen to this transparent company? If the observations we've made of the Open Source world are reliable, the open processes in the product development of the company and its management would surely open up the company for some surprises in the form of help from the outside. That would accelerate product development and over time make it better than its competition. The company could form totally new kinds of partnerships, or perhaps its clients would come up with suggestions for reorganizing its sales methods, just as outsiders send in suggestions for improvements to the code for Open Source programming projects.

Of course, the Open Source product would also be available to the competition, which would be a challenge for our transparent company. A company which works to the principles of openness cannot hide behind copyright, patents, trade secrets and other traditional models of mean-spiritedness, but must be prepared to face competition openly. That would not only keep the company on its toes at all times but also force it to continually evolve and renew itself. Of course, such declarations are endlessly repeated like some kind of mantra by most companies, but in an open business such aims would become real requirements.

Total transparency would also lead to some surprising and possibly difficult situations, which would require the company to look at the basics of business from a new perspective - a bit like when Open Source was a new concept and the first Linux companies had to reassess their ways of working in the IT field.

An example of the kind of situation that would require new thinking might be when a client invites tenders from several potential business associates and specifies a certain day for receiving bids. First, the tenders are kept secret and not opened until the deadline is reached, at which point the client usually chooses the cheapest alternative. Because of the secrecy surrounding the tendering process, nobody can know for certain what their competitors will bid. Naturally, the point of all this is for the client inviting the tenders to get a product or service supplied as cheaply as possible.

Working to the principles of openness in such a competitive situation, our transparent company would inevitably be worse off than the others. While the closed companies would submit secret tenders, our transparent company would be open to having the minutes of its management meetings examined by their competitors, who would not only discover exactly what sum our company had tendered but perhaps even what detailed calculations had led up to it. Naturally, in such a situation, it would be ridiculously easy for a competitor to put in a lower tender.

This may mean that our open business would lose a lot of tenders. But, it's not quite that simple. The problem with inviting tenders is that there is a sort of gamble built into the law of supply and demand, because no party selling a product or service ever makes tenders purely on the basis of actual costs. Instead, they try to second-guess what the competing parties will tender, then formulate their own on the basis of that. They aim to strike a balance between making the tender as high as possible, yet lower than those of the competition, so that their produce or service is the one that wins the job and them the highest possible profit margin. Which is why many offers aren't necessarily as low as they could be.

Our open and transparent company could therefore protect itself by always and only submitting honest tenders! Honesty here means that our company would base its tenders only on the actual cost of the work involved, then honestly put in a tender that is as low as possible without actually losing money on the deal. If somebody makes an even lower offer, there's no reason to cry over the lost deal, because selling our product or service for less than our tendered amount would not have been good for us anyway. And it might just be that our tender is as low as anyone can go. If so, we've won honestly, without hiding anything at all!

If one looks at the situation from the point of view of the client requiring the service or product, for them to work with a company that always plays an open card would be to work with an ideal partner. Naturally it's not good for the client when tenders are based mostly on the competing companies guessing at how fat a deal they all think they can fool the client company into paying this time. A company that has calculated its tender openly is much easier to trust. If I were to receive an honest tender of €1,000,000 from a company that operated with open principles, and the tender from a closed company came in at €999,500, I'm likely to laugh at the latter and accept the former.

Verdict: The Glass House was an entirely fictitious company invented to exemplify what can follow from openness. Who am I to judge whether or not my ideas are good or bad? The aim of this book is to stimulate different ways of thinking about business, but also to encourage readers to increasingly apply open thinking in their own lives.

• 1Well, if we're honest, we must admit that the culture of secrecy and mean-spiritedness is so strong in all of us that it's not always so easy to create such a culture of open information, but at least in theory Nokia is as open as possible towards its subcontractors.
• 2The next section of the book will deal with the use of the Open Source ideology outside the IT sector.

Part Three of this book has presented a number of case studies of companies and organizations in the Open Source world. Challenging traditional IT businesses through the rules of openness has forced the players in this sector to reassess their ways of doing business, which in turn has given rise to new and successful innovations in business. In the case of Linux Weekly News, for instance, it wasn't so much a question of the Open Source ideology, but the natural openness of the Internet and how to react with that. On the other hand, Debian and the clothesline paradox can help us understand that it may be hard to find the right answer because we've yet to ask all the right questions. I've tried to judge each example according to how successful a company has been financially, together with how well the example follows the principles of the Open Source ideology. I thought it would be useful to sum up the results of this long section in a picture, which as we all know will say more than a thousand words.1 You'll find the financially successful examples from this section of the book towards the top of graphic, and the less successful ones towards the bottom. The examples that follow the principles of Open Source are on the right, and the mean-spirited ones are to the left.
Chart of business models / Summary of Part 3

• 1Of course, this part of the book already has over 30,000 words - my computer can calculate that all on its own, isn't that marvellous - but I hope the graphic is of some use anyway.