Table of Contents
The goal of this section is to present a version of the history and politics of software that is released under a license allowing the user the liberty to copy, modify and redistribute the code.
Many companies using propriety software favour the FUD tactics  to stop people from using Open Source software, therefore it is important to know the history of Open Source software and become familiar with the role players in the Open Source community, and in this way be able to make informed decisions regarding which Operating System and software to use.
When you start to get familiar with the Open Source environment, you will notice that two terms are used: Open Source and Free Software.
Free Software is a term used to describe software that is freely available, which allows users and developers to copy, modify and redistribute the source code.
Open Source software allows the user the exact same privileges.
“So what is the difference? And which is the correct term to use?” These are questions only you can answer for yourself, once you have read the following chapter:
Much of the internal debates that range in the Open Source/Free Software communities, range about the licenses used to distribute software and Operating Systems. There are two main factions when it comes to Linux;
As you will see from the section below the main difference between these two organisations is their motivation for developing the software that is released under a license that allows freedom to modify, copy and redistribute the code.
GNU (GNU's Not Unix) was formed by Richard M. Stallman (RMS) in 1984, when he became disillusioned by changes in his working environment.
Stallman worked in MIT's Artificial Intelligence labs in an atmosphere where developers freely shared source code with each other, with the understanding that this is how software was improved. This changed in the early 1980's when the MIT lab started using new hardware, which used proprietary hardware. To use the hardware the developers had to sign non-disclosure agreements.
RMS: The rule made by the owners of proprietary software was, “If you share with your neighbour, you are a pirate. If you want any changes, beg us to make them.” 
Stallman left MIT and started the GNU project. He believed that if he wanted to continue developing software he needed to be able to do so in an environment that would allow him to share his work with others, even if that meant creating a new Operating System and new utilities for that Operating System, as well as creating a license to release these products under.
It is important to understand the meaning of the word 'free' in the context of Free Software (or Open Source Software), the Free Software Foundation and Open Content. 'Free' does not refer to the cost of the product but rather that the user is allowed the Freedom to access the Source Code for the product (be that a software application, an Operating System or documentation for an application.) A popular way of expressing this idea is: "Free Software" is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech", not as in "free beer." 
The Free Software Foundations' definition of Free Software: 
Freedom to use an application, for any purpose.
The Freedom to modify the application, to suit your needs.
The Freedom to redistribute copies of the application, so as to "help your neighbor".
Freedom to modify the application and then distribute this modified version to whoever wants to use it.
The Free Software Foundation has commented on several licenses that claim to be Free Software licenses. To view this list visit this page
The Open Source Initiative (OSI)  promotes the development of Open Source software.
The OSI was formed in 1998 after Netscape released the source code for Navigator5.0. Netscape decided to do this after they had read "The Cathedral and the Bazaar". (see our summary of the "Cathedral and the Bazaar" the section called “The Cathedral and the Bazaar”later in this section.)
Eric Raymond, John "maddog" Hall, Larry Augustin and Bruce Perens are some of the people involved with the OSI from the start. This was a group of people who felt that the term "Free Software" as used by the Free Software Foundation is misleading and that it was not correctly understood despite being in existence since 1984. They also planned to work closer with commercial companies than the Free Software Foundation does.
The Open Source Initiative's definition of Open Source software:
“When the application is released under Open Source Licenses it allows the user many more freedoms than just access to the Source Code. These are:”
The application can be redistributed, either on its own or as a part of a bundle of other applications. No royalty or other fees are required to do this.
Explanation as I see it: The idea of this is to not lose the long-term benefits (discussed later) of Open Content Software just to earn some money in the short term.
The Source Code for the project must be easily available, if it is not downloaded with the compiled code (human readable code compiled into code the machine can read) clear instructions must be given as to where and how the source code can be obtained.
One of the main ideas of Open Source and Free Software is to make the evolution of software as easy as possible.
The license must allow applications to be modified and distributed again with the same license as the original application.
Explanation as I see it: By allowing people to modify and redistribute work, the evolution of applications are improved.
Integrity of the Author's Source Code
If the author wishes to keep their Source Code as is, they may stipulate that modified Source Code cannot be distributed, only if they then allow files (patches) to be distributed with the application that will modify it at runtime.
The author must allow the distribution of applications built (Compiled) from modified Source Code.
This allows the author to specify that the original Source Code may not be modified (so that the author can be better recognised for the work done on the original Source Code), but forces the author to still allow modifications to the application by way of patch files that will modify the application, but not the original Source Code.
No Discrimination against Persons or Groups
The author may not discriminate against any person or group; the product must be made available to all people who want to use it.
This is to ensure as wide a range of users as possible, to improve the evolution of the software.
No Discrimination against fields of Endeavour
“The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.”
This is to ensure that the software can be used for commercial purposes.
Distribution of License
The same license applies to all the people who the application is redistributed to.
This is to make sure that some people who the application is distributed do not have to accept an additional license, (e.g. A Non Disclosure Agreement), to use the software.
License must not be specific to a Product
If an application is taken from a bundle of applications that was released as Open Content, then that application has the same license as the original bundle of applications.
This is to ensure that applications can be freely distributed in whatever form that it may be in. (i.e. part of a bundle or on its own)
License must not restrict other Software
The License the application is released under cannot specify that it can only be distributed or used in conjunction with Open Source software.
This allows distributors of software to decide what software to use and redistribute, further enhancing the evolution of software.
License must be Technology Neutral
For example: the license cannot specify that to use the software you must download it from a web page, or from a CD-ROM. The license must allow modification of the application so that it can be used in all environments.
This is so that, if the original application only ran in a GUI environment it can be altered to so that it can run in a command line environment. Also so that the License agreement cannot be made in one specific way, i.e. "Click Wrap" to allow the user to download the file from the web.
Bruce Perens, a leading advocate and developer of Free Software developed the Open Source Definition. The latest version of the Open Source Definition can be found on this page
The Free Software Foundation believes that their cause is a social one, to allow people to freely and openly use software for the betterment of mankind.
The Open Source Initiative believes that allowing people access to source code and allowing them to modify these to improve the software is a practical need, not a social right.
Though these two organisations differ on the reasons, they are not against each other; both believe that proprietary software inhibits the development of useful software.
“Throughout the rest of this document, I will use the term "Open Source Software" when referring to either Open Source or Free Software Foundation issues or products. It was difficult to choose between the two terms. The common misconception that "free" means free-of-charge and the fact that many people relate this to a anti-business mindset made me choose to use the term, "Open Source Software". I do, however, understand what the GNU means with "free software" and admire them for what they have done for this movement. ”
Open Content was an organization that promoted the sharing of materials, specifically those used to educate people.
To do this it developed licenses that people could use to license their works be this software or manuals.
The organisation was founded by David Wiley in 1998.
During 2003 Wiley closed the Open Content organization because he felt that the Creative Commons organisation was doing a better job at creating "licenses for content" that would be recognised in court legally.
For more information about Open Content, visit this page.
More information about the Creative Commons Organisation can be found on this page
Linux typically includes many utilities that were developed by the GNU organisation.
The following section will briefly explain the history of the how the development of Free Software has led to the development of Linux, as we know it today.
Using Linux to describe an Operating System is incorrect, Linux is the kernel not the complete Operating System. The kernel is responsible for the allocation of resources in an Operating System, it allows processes to utilise the hardware of a computer.
The correct way of describing Linux as an Operating System is GNU/Linux. Since the Operating System consists of Linux as the kernel, and many other utilities (most of which were created with the assistance of the GNU project). In the rest of this document we will use "Linux" to describe the Operating System, since that is how most people refer to it today.
Richard M Stallman started the Free Software Federation in 1984, yet that is not where our story starts.
When Stallman started work in the MIT's Artificial Intelligence Laboratory in 1971, he found a community of developers who shared software that they had written with each other, other learning institutes and companies. As Stallman indicates on the FSF website, the sharing of software was not new or unique to the MIT AI Laboratory community, it is as old as computers. Just as cooking recipes are shared, so were software applications.
In the early 80's the MIT hacker community started to disintegrate, a new computer system (a PDP-10) with a proprietary Operating System that hastened the collapse of the AI Lab community. To work with the software on the new system, Stallman had to sign a Non-disclosure agreement with the company who created the PDP-10. Bear in mind that this was to use the executable files for the software, these are not human readable, one needs the Source Code of the application to truly understand what it does, how it does this, without this it is nearly impossible to modify an application to better suit your needs.
Stallman was not willing to accept an agreement that would mean that he would not be able to help his fellow developers, he saw it as actively hindering other people from being able to do their work. Stallman tells of an incident that occurred to him while he was working in the AI Lab in MIT, where the software that they used to control their printer in the lab, lacked a few key features. Stallman was refused access to the source code for the printer's program because the company who created the printer and its software did not want to allow anybody to see how it worked. They did this by having their developers sign a non-disclosure agreement.
Stallman had to make a decision to either become one of the developers who were forced not to help each other or to stop developing or to devise a way where he would be able to recreate a community where people helped each other to develop better applications. He realised that he would first need a free Operating System, as without an Operating System computers cannot function. This was a very brave step, designing a new Operating System is no small effort.
Stallman had made the decision to develop a free Operating System on 27 September 1983. He decided to design it so that it would be compatible with Unix, then the most stable and widely used Operating System, so that Unix users could easily use it, and so that applications could be easily transferred to the new Operating System (a process referred to as 'porting').
Following a Hacker tradition which uses recursive acronyms, the term GNU (pronounced "guh-noo") was born. This stands for GNU is Not Unix.
Stallman started by developing a compiler, compilers are used to change the human-readable Source Code into Machine code. The Operating System needs this machine code to be able to run applications. This proved difficult to do and in reality it took him a few years to complete the compiler.
Stallman decided to work on a text editor, which he called GNU Emacs. Many people started to take an interest in Emacs and wanted to use it. He released GNU Emacs on a FTP server, but not everybody had access to the Internet, this was 1985 remember. To get his Emacs to the people who wanted to use it Stallman started a software distribution company that would mail people copies of the software for a small fee. This was a precursor to the many businesses that exist today that make a profit by redistributing Linux.
People started to join Richard Stallman in creating the GNU system in 1985, to fund their work they founded the Free Software Foundation, a tax-exempt charity that would create funds by distributing the software that the GNU had created.
By the time Linus Torvalds started working on his Operating System Kernel in 1991, the Free Software Federation had already written or helped to write a wide range of software distributed as Free Software.
Linus Torvalds was a student of the University of Helsinki when he announced on the 25th of August 1991 that he was busy developing a free Operating System.
At the time the only Operating System that made its source code available was MINIX. An Operating System developed by Professor Andrew S. Tanenbaum to teach his students the inner workings of an OS. MINIX was very limited and could only work on hardware based on the Intel 8086 framework. MINIX was also not Open Source, it had to be licensed, though the Source Code was available to licensed users. When Linus Torvalds started working on the kernel that would become Linux it was the start of the Internet boom, and Linus quickly got help from developers around the world, debugging the code and offering solutions to issues they found.
The Linux kernel was released under the GNU GPL License. Which allowed anybody to download the source files, modify them and use them in their own projects.
The Internet boom allowed many people to continue work on the project; new versions of the kernel were released often (sometimes even weekly). This had a number of benefits, perhaps the most notable is the fact that the kernel improved significantly in a very short period of time, another is that with this many releases it appealed to a wide range of users; those that wanted to be on the leading edge and worked on the development used the latest version of the kernel, whilst those want more stability used older versions. The Linux Kernel grew in popularity quickly.
The GNU has been working on its own kernel for some time now. It is called the GNU HURD.
The official definition for HURD is:
'Hurd' stands for 'Hird of Unix-Replacing Daemons'. And, then, 'Hird' stands for 'Hurd of Interfaces Representing Depth'. We have here, to my knowledge, the first software to be named by a pair of mutually recursive acronyms.
Its is believed that it will be released very soon (since it is Free Software you can already download and use it but it is not yet ready to be used in a production environment)
When one examines the developmental history of the Linux kernel the point that stands out is the extraordinary improvements made to the Linux kernel in such a short time.
This success is attributed to the knowledge of the developers who contribute to the project, and the development model used by Linus Torvalds.
Proprietary software is usually developed by small teams working closely together and products are only released once the developers believe that they have found all the problems in the code, this results in long development times and, as we all know, code that still contains many problems.
The model used by the Open Source community is more open than that, it uses many developers, often people who have never met each other physically, and releases code often. This is done because Open Source developers depend on their users to help them improve the code.
The Cathedral and the Bazaar(CatB) is paper written by Eric S Raymond (ESR), which examines the differences between the development models used by the Open Source community (the Bazaar) and the one used by Proprietary software companies (the Cathedral). Raymond first presented The Cathedral and the Bazaar (CatB) on 21 May 1997 at the official "Linux Kongress" (sic). The latest revision was released on the 11th of September 2000.
In The Cathedral and the Bazaar, Eric Raymond examines the Linux kernel development model and comes to the conclusion that not only does it work, but that it is perhaps the only economical way of developing large systems that satisfy most of the people. He also considers and responds to the arguments raised by people who prefer the traditional Cathedral style of development.
|--ESR; Cathedral and the Bazaar|
This is Raymond's abstract of the work:
I anatomize a successful open-source project, fetchmail, that was run as a deliberate test of the surprising theories about software engineering suggested by the history of Linux. I discuss these theories in terms of two fundamentally different development styles, the "cathedral" model of most of the commercial world versus the "bazaar" model of the Linux world. I show that these models derive from opposing assumptions about the nature of the software-debugging task. I then make a sustained argument from the Linux experience for the proposition that "Given enough eyeballs, all bugs are shallow", suggest productive analogies with other self-correcting systems of selfish agents, and conclude with some exploration of the implications of this insight for the future of software.
|--ESR; Cathedral and the Bazaar|
Eric S. Raymond is the president of the Open Source Initiative (OSI)
Raymond was involved in Unix and Open Source development for the GNU before Linus Torvalds released the Linux kernel, which made him used to the Cathedral style of development, small teams working closely together on a project and only releasing the application once it was close to perfection.
Torvald's methodology of development (releasing early and often, delegating as much of the work as possible and being open to almost all suggestions) seemed strange to Raymond.
No quiet, reverent cathedral-building here rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who'd take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.
|--ESR; Cathedral and the Bazaar|
Raymond wanted to learn why the model used in the development of Linux worked so well, and he worked hard to learn more about it. In 1996 he had the chance to apply Linus's methods in a project he had just started. He needed an email client that would allow him to automatically download email from the community Internet Service Provider he had helped to start. Raymond had tried a few of the existing client applications, but none did exactly what he wanted it to do, so he did what all good hackers do, he decided to develop a new POP client. This was the perfect opportunity for him to also test the bazaar style of development. The application that was developed is called fetchmail and is still used extensively today.
In CatB Raymond lists 19 reasons why he believes the Bazaar development model works well.
“I will discuss these, as I understand them.”
Every good work of software starts by scratching a developer's personal itch.
Raymond needed a POP email client that would allow him to automatically fetch mail from his ISP (Internet Service Provider), the clients that were available did not have the necessary capabilities Raymond needed. In the Open Source world this is very true. If there were a need for something a developer would have all the resources needed to develop a better application. A developer is also sure to have the support of many other people who have felt the same need for a better application. Applications are developed for the love of the art, not for any other reasons.
Good programmers know what to write. Great ones know what to rewrite (and reuse).
Because you are dealing with Open Source software the source code is always available. It would be senseless to re-design the wheel every time you need a mode of transportation, so why do it when you are developing an application? Raymond looked at 9 POP mail clients and chose 'fetchpop' by Seung-Hong Oh, who included some of the changes that Raymond had written, in version 1.9 of fetchpop.
"Plan to throw one away; you will, anyhow." (Fred Brooks, The Mythical Man-Month, Chapter 11)
Raymond wrote the code that allowed fetchpop to do what he wanted it to do, but was not satisfied with the total product. While searching for mailclients he could modify he had come across Carl Harris's popclient. Though fetchpop did what he wanted it to do Raymond had two reasons for switching to popclient, popclient supported multiple protocols including IMAP (Internet Mail Access Protocol), which is more powerful than POP3. He also had another more theoretical reason to change, and that was to throw the first code that he had written away. This was one of the ideas that were often used by the people developing the Linux kernel.
If you have the right attitude, interesting problems will find you.
Carl Harris, the author of popclient, had lost interest in the project and he and Raymond decided that Raymond should take responsibility of popclient.
Raymond suddenly was no longer writing a few modifications for an existing mail client, now he was maintaining a mail client and he was full of ideas that would lead him to make many changes to popclient.
When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
It is important for developers to realise when it has become time for someone else to take responsibility for his or her project. Once Raymond had proved to Harris that he was the correct person for the job he graciously handed the reins over to Raymond. This attitude assures the continued development and growth of a project.
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging
When Raymond took over the popclient application, he did not only inherit the management of the code but also the users of popclient. In the Linux development model, users have the ability to be co-developers (if used correctly). This is one of the main reasons why the Linux kernel has been as successful as it has.
Release early. Release often. And listen to your customers.
Previously most developers felt that this was a bad policy for bigger projects. They felt that releasing buggy software would cause the users of the software to give up on the product.
Yet this was not the case with the Linux kernel. Linus Torvalds often released a new version of the Linux kernel more than once a day! This was what kept his users satisfied and stimulated. 'Stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work. ' ESR; CatB
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Raymond had dubbed this the 'Linus Law'. Raymond believes that this is the core difference between the cathedral and bazaar development models.
In the cathedral model it often takes months for the developers to be satisfied that they had eliminated most of the problems in the program.
In the Bazaar model, you have so many people looking and using the code that most bugs are found quickly. Even if this happens at the expense of having a major problem in a few of the released versions, the benefits of rapid development are still enough to justify this.
For the users who did not want to use the latest version of the Linux kernel, Torvalds also made available the older versions in which most known problems were dealt with. This meant that a wide range of people would use the kernel, not just the few people that wanted to be on the bleeding edge of the technology.
Smart data structures and dumb code works a lot better than the other way around.
Raymond started maintaining popclient by first rewriting it, he did this for two reasons;
To understand how the application works;
And also to change the way it was coded so that the data structures were more robust.
In other words he redesigned the way that the different protocols were expressed in terms that the kernel and thus the hardware could understand.
If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
Raymond had decided to develop his new mail client using the Linux kernel development model. He did this by doing the following:
I released early and often (almost never less often than every ten days; during periods of intense development, once a day). I grew my beta list by adding to it everyone who contacted me about fetchmail. I sent chatty announcements to the beta list whenever I released, encouraging people to participate. And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.
Raymond was amazed at the response he got from the users of the application.
I got bug reports of a quality most developers would kill for, often with good fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature suggestions.
The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
One of the users of popclient sent Raymond some code that would allow it not just to be a local mail delivery agent (just fetch mail and make it available on a workstation), but also enable it to be a Mail Transport Agent (MTA). By using SMTP (Simple Mail Transfer Protocol) it would do the job better and giver it more capabilities. Thus one user's ideas allowed the project to grow fundamentally.
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. By using SMP and changing popclient to act as a Mail Transfer Agent rather than a Mail Delivery Agent Raymond could remove some of the most redundant features of popclient and make it easier to use and more stable.
...the benefits proved huge. The [clumsiest] parts of the driver code vanished.
"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." (Antoine de Saint-Exup?)
Raymond states that when your code evolves to be better and simpler, then you know it is better.
There is a more general lesson in this story about how SMTP delivery came to fetchmail. It is not only debugging that is parallelizable (sic); development and (to a perhaps surprising extent) exploration of design space is, too. When your development mode is rapidly iterative, development and enhancement may become special cases of debugging-fixing 'bugs of omission' in the original capabilities or concept of the software.
Popclient has changed to such an extent that Raymond believed it was time to change its name, fetchmail was born.
Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
Raymond started to see that fetchmail could become what is termed a 'category killer', software that causes all others in that field to be forgotten. To achieve this, fetchmail would have to be able to do things he never set planned for it to do.
I'd have to write not just for my own needs, but also include and support features necessary to others but outside my orbit.
Whilst at the same time making sure the program stayed simple and robust.
When writing gateway software of any kind, take pains to disturb the data stream as little as possible - and never throw away information unless the recipient forces you to!
By following this rule Raymond was able to satisfy another demand from his users (8-bit MIME support). In the ASCII character set the eighth bit is not used, and another developer might have been tempted to use this bit to transport data internally in the program, Raymond was not, and thus was able to support 8-bit MIME without having to rewrite major parts of the code.
When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
A security system is only as secure as its secret. Beware of pseudo-secrets.
Some of the users asked Raymond to encrypt the password in the control file of the application, so that people who were looking at the control file would not be able to see the password in plain text. Raymond points out that anybody who has the permissions to read the control file would be able to find out, from the code, which decoder to use to read the password. So security was not really enhanced, the user would just have been lulled into a false sense of security.
To solve an interesting problem, start by finding a problem that is interesting to you.
It is also obvious that if you have developed something that is interesting to you and solves problems for you, that it would play the same role for other people.
Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
In The Mythical Man - Month, Fred Brooks observed that programmer time is not [interchangeable] ; adding developers to a late software project makes it later.
This has become known as Brook's Law, but if it was true, how could the Linux kernel have been such a success?
Gerald Weinberg's classic The Psychology of Computer Programming supplied what, in hindsight, we can see as a vital correction to Brooks. In his discussion of "ego less programming", Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere"
Clearly the Bazaar method needs to use this ego less method of development if it is to succeed. Something in which Linus Torvalds exceeds;
We may view Linus's method as a way to create an efficient market in egoboo - to connect the selfishness of individual hackers as firmly as possible to difficult ends that can only be achieved by sustained cooperation.
Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed - source world cannot win an evolutionary arms race with open - source communities that can put orders of magnitude more skilled time into a problem.
The book has been released under the Open Publication License v2.0 and can be read online on this page
Why has Free Software in general, and Linux specifically, not been as widely used in the enterprise environment as the proponents of it expected? Developers of proprietary software would have you believe that Linux is not suited to the corporate environment. But this is not true, the next section attempts to highlight why it is that Linux has not yet taken over from Microsoft, as the Operating System of choice for home and corporate users.
Linux and Free Software must be a marketer's nightmare, Linux is perceived to be an Operating System used only by highly technical people, who hardly ever leave their homes or offices. Worse, the people who develop Linux call themselves hackers, so how do you sell a product to companies when people think that only 'uber'-geeks can use it, and that they use it to break into bank accounts via the Internet?The truth of the matter is that home users and more importantly CEO's (Chief Executive Officer) and CTO's (Chief Technology Officers) have the perception that Linux is difficult to use and that would not be possible to use it in their environment.
When you examine how Microsoft has marketed their products and compare that to the way Linux as been marketed to the world, one begins to understand why Windows is the Operating System of choice, instead of Linux.
Traditionally Linux has been marketed to the business world, from the bottom up. Since it was only the technical people who knew about Linux, and how to use it, they were the people telling their bosses about how stable and cost-effective it is compared to the products offered by Sun, IBM or Microsoft. Unfortunately few technically minded people are also good businessmen, or know how to communicate their ideas to people who have the power to make decisions that will affect the company.
Microsoft, arguably the most successful software company around today, has marketed their products to the Chief Executive Officers, Chief Technology Officers and Chief Financial Officers. Not to the people who would use it, but rather the people who may not necessarily have the knowledge required to make a sound technical decision, but the people who are able to make financial decisions.
When deciding whether or not to use Linux in a business environment, one needs to make a distinction between an Operating System for a server, and an Operating System for a desktop. Whilst all Linux proponents would agree that it is very well suited to the server environment, some would say that when it comes to desktop systems, meant to be used as workstations, Linux may not yet be polished enough to replace Microsoft's products. Though, recent versions from SUSE and Red Hat are very close to being perfect for the desktop.
For Linux to gain more acceptance in the Business world, it will need to be marketed in the correct way.
CEO's would need to be made aware of why Linux is a viable option to use in the business environment, which is what the next section attempts to highlight. I will not be able to turn you into a marketer , or a business person, but I will attempt to list the reasons why Linux should be used.
Surely this is one of the main draw cards that Linux has over its competitors. During the IT industry boom in the late 1990', Information Technology seemed to promise unbelievable growth in profits and productivity. After the .com bust in 2000 many companies have slashed their IT budgets drastically. IT just did not deliver what it promised.
Today, businesses want even more out of the IT infrastructure, but they are more cautious when it comes to spending. Unlike the products from companies like IBM and SUN, Linux can run on almost any hardware architecture, you can use Linux to run your file server using the normal Pentium/AMD architecture. Of course it can run on other more obscure architectures, you can even run it on a Xbox gaming system. (Though that is not so strange once you know that the Xbox is just an IBM PC that is meant to be used for gaming exclusively. visit this page for more information on how to install Linux on a XBox) What is impressive is that people are creating clustered computer systems from these 'hacked' Xboxes. They are using the Xbox, because it uses good-quality hardware, is relatively inexpensive and is very quiet.
There are Linux distributions like Red Hat Fedora, Debian, and Gentoo that you can use completely free of charge, and there are distributions that require the user to purchase a license, for example Red Hat Enterprise 3 and SUSE Linux Enterprise 8. The advantage of buying a license is that you get support from the company who has created the Linux Distribution, including regular security updates and bug fixes. With the distributions that are free of charge, you depend on the community of users of that distribution for the security updates and bug fixes. Admittedly, this is a very enthusiastic community and these fixes are made available before most people know that they exist, but this is not a risk that many companies are willing to take. They would rather pay somebody for guaranteed service than depend on no-cost services.
Free Software is renowned for its stability, which translates to better uptime (the time between rebooting the system). Many commercial web-hosting companies use Free Software to run their servers, and to deliver the pages to Internet users.
Security is another reason why businesses would benefit from switching to Linux. Every year millions of dollars are lost worldwide by damage caused by Trojans, worms and viruses that affect Microsoft products. These programs exploit features in Microsoft that (it seems) Microsoft is unwilling to fix, since it would mean that Microsoft loses some of its ease of use. In Linux a much stricter security policy is implemented than on Microsoft Windows. In Linux the root user needs to allow any and all programs that want to run on the system. This can only be done by the root user (the administrator of a Linux machine).
In Microsoft systems, programs are allowed to run without any input from the user. In other words a malicious program can install itself on a Microsoft system, and run itself without the user of that system even knowing about it.
A classic joke: "Heard about the Linux virus? It works on the honor system. First it asks you to please e-mail it to all your friends, then it asks you to please log back in as root so it can tell you how to trash your system."
As discussed earlier, Linux is based on the Unix system, which has been used by enterprises since the early 1980's. With the release of version 2.6 of the Linux Kernel early in 2004 Linux has evolved even further.
(Joseph Pranevich has written an exhaustive analysis of what capabilities the latest Linux kernel bring to the Linux Operating System, read it at: http://www.kniggit.net/wwol26.html It is also included in the appendix Appendix B)
Now that IBM and Novell have thrown their weight behind Linux, one can no longer say that there isn't a major company who will make support available for Linux servers and workstations. Many businesses would rather pay a license fee and be sure that support for their IT infrastructure is just a phone call away.
On the 13th of January 2004 Novell finalised its acquisition of SUSE Linux ,Press Release and this means that there is now a multi-billion dollar company offering support for Linux on an Enterprise level, from servers to workstations.
 Fear, Uncertainty, Doubt
 www.gnu.org The Homepage of the GNU and the Free Software Federation
 www.opensource.orgThe Home page of the Open Source Initiative
 Richard Stallman www.gnu.org
 The GNU's explanation on the meaning of "Free Software"www.gnu.org
 From the GNU's philosophy page, visit the following link for the exact wording:www.gnu.org
 'Egoboo' is a word that ESR uses in Cathedral and the Bazaar. I believe he means that open source development is successful partly because the individuals who are working on the project enjoy having their ego stroked. And because anybody can see their code, everybody will know how good they are
 The understanding of the man on the street of the term "hacker' is incorrect. Developers have been calling each other Hackers since the 1960's. In this context a Hacker refers to a developer who is able to improve a program in an intelligent and elegant manner. When using to people who gain unlawful entry into computer networks you should use the term "Cracker'.