Outline

I. Preface

II. What is collaborative software development?

III. The motivations behind the open source movement

IV. Qualities of successful collaborative software development projects

V The future of open source software development

VI. Recommendations

VII. Additional Considerations

I. Preface

During my second semester at Hampshire College, I began a computer interface design project. I created an application designed to assist people with the process of creating custom physics models for the computer game Marathon. My project was called The Help Program. I initially concentrated only on designing an intuitive interface, but over time the functionality of the program became more and more important to me. When it became clear that the purpose of my program was too narrow to make it of interest to many people, the program evolved into an application capable of providing tutorials not only for the Marathon physics model editor, but for every other program as well. Needless to say, this called for the creation of a huge amount of help content. It had previously been possible for me to create all of the help content myself, since my program had been targeted towards one specific application. But it was impossible to create step-by-step tutorials for every application under the sun. In order to create enough help content, I had to find a way to solicit the help of others. My solution was to encourage users to create and distribute their own content, via a tutorial editor within The Help Program. Users of The Help Program are able to create their own content using a simple graphical interface. Completed content can be easily uploaded to a central server, where it can then be accessed by all. Thus the content-creation process became integral to the use of The Help Program itself.

I realized that this communal creation of tutorial content had some similarities to the open source approach to the development of software; both demand collaboration and rely upon the Internet for communication and distribution. This voluntary, decentralized approach to software development has forged tight online communities and has proven to motivate people to develop cutting-edge software, despite the fact that nobody is being paid to do so.

II. What is collaborative software development?

Mozilla. Linux. Apache. Darwin. Gimp. Aleph One. Gore 2000. These oddly-named computer projects are all being worked on collaboratively. When several people combine their skills and talents, the result is often far superior to what any one person could achieve on their own. The Internet has made it possible to take collaboration across great distances. Now people who do not know each other in real life can comfortably develop software together. The significance of this is that the Internet offers a huge pool of talented programmers- several of which are likely to have enough interest in a given project to devote their free time and effort to it, without asking for any financial compensation. Without the Internet, a programmer looking for free help has nobody to turn to except those in his or her immediate vicinity. Those with the necessary skill and motivation are invariably found in more distant corners of the world. Here is a brief explanation of each of the collaborative projects listed above:

Mozilla is a multi-platform Web browser being developed by AOL-Time/Warner’s Netscape subsidiary. As if the company does not already have enough employees, it is finding even more help by reaching out to the public. Mozilla is an open source project: its source code can be viewed and modified by anyone who has the programming skill to contribute. This design model is unprecedented; most software companies keep the source code to their products a secret, for the same reason that Coca Cola keeps the recipe for its soda under wraps. The Mozilla browser boasts a fast page display engine, and it complies with the World Wide Web Consortium's guidelines for the display of Web content. These achievements were made partially by volunteers who, after examining the Mozilla source code, saw ways in which it could be improved and implemented changes as they saw fit.

Linux is a kernel that follows the same open source model as Mozilla. A kernel is the essential core component of an operating system. Combined with other open source components, it forms a complete free operating system. The official Web site of the GNU project explains how Linux came to symbolize the free software trend. (GNU, oddly enough, stands for GNU’s Not Unix.)

The Linux operating system has progressed more quickly than its competition, thanks to the large number of volunteer programmers who have worked to make it fast and stable. It is arguably the most sophisticated operating system available, with advanced "under the hood" features. It has not yet caught on in most business and home environments however, due to the fact that it is more difficult to use than Windows or the Mac OS, and it carries a smaller library of software.

Apache is the name of the most popular Web server software. It too is open source. Like Linux, it is continually being improved, and it is extending its lead over the closed-source alternatives. The description of the server provided on apache.org is indicative of the spirit of open source projects:

Darwin is an open source operating system core provided by Apple. Apple may take advantage of the enhancements being made to Darwin by rolling them into its upcoming commercial operating system, OS X. According to Apple’s Web site, Darwin "...allows Apple to partner with external developers to create richer, faster and more reliable products for our users through open source development." (Apple Computer, Inc., 2000) The Darwin project has a very appropriate name. Open source projects are Darwinian in nature; ideally, the inferior portions of an open source computer program are replaced by superior alternatives. A programmer’s contribution will only survive until a better chunk of code is written and submitted. Consequently the source code behind open source projects tends to evolve until it becomes stable, fast, and efficient. Unlike Darwinian evolution however, mutations do not happen by accident; they result from careful planning and hard work. This forced evolutionary process can happen only if enough talented, devoted people participate.

The GIMP, which stands for The GNU Image Manipulation Program, is an open source image editing application similar to Photoshop. The GIMP is significant not only because it rivals the power of Adobe Photoshop, but because it is one of the first major Linux applications to appeal to end-users rather than to developers and system administrators. According to the Linux Journal:

Aleph One is an effort to improve the Macintosh computer game Marathon Infinity. The source code for the game was released by its creator, Bungie Software, on January 17, 2000. The project’s bizarre name describes the scope of the project well; the term aleph one is actually an advanced mathematical reference to a number greater than infinity. Appropriately, the goal of this open source Marathon project is to create an edition of Marathon that improves upon Marathon Infinity. Recently people have begun to refer to the project as The Marathon Open Source Project. Its Web site is located at http://source.bungie.org. Open source projects like Marathon, Linux, and Apache adhere to the principle of "copyleft", as opposed to copyright. This means that participants are encouraged to modify and redistribute source code, and they are required to keep the software free. Richard Stallman, who first conceived the idea of copyleft, explains the concept in depth, and examines its benefits:

The incentive that Stallman refers to is that by adhering to the principles of copyleft, one becomes able to make use of existing free code in their own projects. Furthermore, it is not permissible to include open source code in proprietary software. To sum up this concept: "The central idea of copyleft is that we give everyone permission to run the program, copy the program, modify the program, and distribute modified versions--but not permission to add restrictions of their own." (Stallman, 1998.) Such forbidden restrictions include charging money for the software, preventing the software from being further modified, and preventing others from redistributing it. Copyleft is designed to perpetuate itself by ensuring that once software is free, it can never return to a "closed" state.

But what about the Gore 2000 project? Al Gore’s official Web site, located at http://www.algore2000.com, is another project that is being developed collaboratively. The vice president seems to be very interested in the open source movement, and he is even trying to extend the concept to the creation and maintenance of the his presidential campaign site:

Viewing the site’s "source code" reveals a hidden message sandwiched between several lines of HTML:

Other collaborative computer projects are less far-reaching. Advanced 3D modeling and animation systems such as SoftImage let several artists work together to create 3D environments. Each participant uses a different computer, and each computer is hooked up to a server that houses the 3D scene data. Several participants can work on the same scene simultaneously. When one artist makes an addition or a change to a 3D environment, that change is reflected on the other artists’ computers. In the past, different elements of a complex scene had to be modeled individually, and brought together only after they had all been completed. Now all parts of a scene can be constructed in the proper context. This allows artists to see how different objects affect each other visually.

Unfortunately, not every collaborative project succeeds. So far The Help Program’s tutorial editor has not fostered the development of many step-by-step tutorials. The Marathon Open Source project can not be considered a complete success either; after two months, it had attracted much interest, but only three serious programmers. Even the Mozilla project has had problems. During its early stages, it struggled to attract enough volunteer programmers, and throughout it’s drawn-out development cycle Microsoft continued to update its own Web browser, which by now has won the "browser war." Al Gore’s Web site is flawed too; the crew that controls what site design suggestions to implement clearly has its own agenda. Undoubtedly, only a small fraction of the feedback and suggestions that have been sent have been acted upon.

This paper will address the causes behind the failings of such open source projects. It will also explain what it takes to have a successful open source project, focusing specifically on the vehicles needed to properly facilitate such a project. Finally, it will speculate on the future of the open source movement, and offer recommendations advising how its future might become brighter. But first it will explain the advantages and disadvantages of using the open source development model in the first place.

III. The motivations behind the open source movement

The advantages and disadvantages faced by a producer of open source software are not the same as those faced by the user of that software. Furthermore, the advantages and disadvantages faced by a commercial developer of open source software differ from those faced by a volunteer developer. First we will examine the user’s incentives to choose open source software instead of commercial software.

The User

The end-user has two very important reasons to use open source software. Most importantly, the software is free. Secondly, the software is continually enhanced with new features and bug fixes. It sounds like a deal too good to be true. In fact, it is. The consumer of open source software faces several disadvantages. First of all, since open source programs are in constant state of flux, it becomes hard to keep up with the latest changes. New features can make a program more difficult and confusing to use. Secondly, open source software comes with spotty documentation that is quickly outdated. Since the documentation is usually written by the programmers themselves, it usually uses an advanced vocabulary that is understood by only the most experienced users- those who are well-versed in technical jargon. This sort of documentation is unreadable by novice users, who quickly grow confused and frustrated trying to use open source software. But where users encounter confusion and frustration, commercial ventures discover money-making opportunities. Companies such as Red Hat, Caldera, and TurboLinux sell the Linux operating system, bundled with superior documentation and phone support. (Linux Online, 2000.) Of course, neither Red Hat nor anyone else is allowed to sell Linux; what they are really selling is the documentation and the promise to provide help when you need it. Since Red Hat provides solid documentation and phone support, customers are willing to pay $30.00 or so for an otherwise free software package. (Red Hat, Inc., 2000.)

Another problem faced by users is that open source programs sport user interfaces that are often too difficult for inexperienced computer users to navigate. Developers who focus on the inner workings of a program often neglect the user interface. (Kuniavsky, 2000.) Hence, Linux is considered to be not only one of the most powerful operating systems, but also one of the most difficult to use. Open source software can be hard to use as a result of poor user interface design, and because of haphazard product development. The lack of a top-down organizational approach can also make software harder to use due to inconsistent interfaces.

Finally, commercial alternatives to open source programs are often just plain superior. For example, the open source community has yet to create a word processor as sophisticated and capable as Microsoft Word. This is subject to change, as the open source model has already resulted in the creation of an operating system, a Web browser, and a Web server that are arguably superior to their closed-source alternatives. But until volunteer programmers seriously delve into mundane tasks such as word processor creation, the most practical computer software will continue to cost money.

Clearly there are a lot of good reasons to use the software that the open source community has provided. However, the fact that only expert users have latched onto the open source movement indicates an important fact: only high-end users can enjoy the advantages of open source software. Novice and intermediate users do not benefit from hard-to-use software that does not serve their modest needs.

The Volunteer Developer

The reasons to create open source software are entirely different from the motivations to use that software. Volunteer software developers- those who collaboratively create software without expecting to be compensated financially- do so for several reasons. The collaborative process is a reward in itself. Dissuasion, debate, and cooperation between programmers lead to the creation of a community full of people with similar interests. It is educational for everybody who is involved, and it is something a volunteer can take pride in. Finally, it is possibly the fastest and least expensive way for a programmer to obtain the kind of software that he or she needs.??

However, volunteer developers also face several disadvantages. First and foremost, volunteers are inherently unpaid. The incentive of being paid can be considered one of the primary motivations behind sitting at a computer and writing code in the first place. Without pay, many people simply refuse to work. However, those who remain involved in a project despite not being paid are undoubtedly the most interested and excited of all the potential contributors. Therefore they are valuable assets; even if a volunteer is not particularly well-suited to the task at hand, his interest and enthusiasm motivates him to learn to become a better programmer- one who can make valuable contributions to a project. Put simply, the problem of not getting paid is not a particularly bad problem; although it weeds out some of the most talented and most skillful programmers, it also weeds out some of the least interested and least motivated programmers.

Volunteer programmers face another problem: a single volunteer, no matter how devoted or well-informed, can not control the overall direction of a project’s development. A person only has direct control over his or her own contributions. Discouragement may result from being powerless to control the direction of the project. With that said, it is probably best that the group a whole decides the direction a project takes, instead of having a single individual make all the decisions. However, there is an even more troubling problem: it is up to the development community at large to determine whether one’s contribution is even added to the project at all. It can be very distressing for a programmer to be told that his work will not be included in the project. It can lead to a breakdown of the positive relationships that are established when people work together cooperatively. The following e-mail dialog between two contributors to the Marathon open source project illustrates this point:

Clearly, programmer 2 examined and evaluated all of the work that programmer 1 had contributed, and decided that it was inferior. His decision not to accept it was a troubling quality-control measure. Fortunately programmer 1 did return to work on the project, but his relationship with programmer 2 remained somewhat strained until enough time had passed for a constructive partnership to be reestablished.

A more frequent problem is not that so many enhancements are made to a program that some must be rejected, but rather that not enough enhancements are being made. If the community built around a project does not include enough programmers, them the other members are likely to spend their time doing nothing but demanding certain features from the programmers, and complaining when their wishes go unfulfilled. It is true that too many chefs spoil the bacon, but having too many patrons is an even worse problem. In cases where too many people are merely making requests and not putting in the effort to bring their ideas to fruition, the power is put into the hands of the programmers. Those who can program ultimately determine whether a specific feature is added or not. In this situation, the community is less discriminating, and new features are more likely to be added to a program, regardless of their value. An equally troubling result of this situation is that animosity develops between programmers and those who demand certain features but are too lazy or ignorant to implement those features themselves. For example, the Marathon Open-Source mailing list has recently been inundated by messages requesting that the space marine character should be able to jump. Every time someone demanded the jump feature, a similar response would come. Something along the lines of:

Of course, the people who were requesting that feature are powerless to add it themselves, because they do not know how to program. For better or for worse, the programmers remain in control of the development process.

Developers participating in some small-scale open source projects face another motivation-draining threat: the fear that their partners may abandon the project, leaving them alone with all the responsibility and no community to turn to for support. The open source system has the potential to be fickle. Programmers may lose interest and quit without having to face any consequences. A key point in the argument against open source software development is identified in Eric S. Raymond’s seminal open source manifesto, The Cathedral and the Bazaar,

However, Raymond refutes this argument, claiming that sustained development is entirely possible within the open source community.

Perhaps any open source program that flounders due to a lack of interested, devoted volunteers does so because nobody needs it; if the software were really needed, people would be willing to contribute to the project. On the other hand, perhaps such projects fail not because nobody would want to use the software, but because those who are capable of writing the software have no use for it. Later we will explore the qualities of successful open source projects, and it will be shown that such projects are usually developed to serve needs that have not been met.

The Commercial Developer

The motivations that a commercial software developer may have in starting an open source project are similar to those faced by a volunteer developer. First, releasing an application as open source brings new features and bug fixes to the software. Volunteer developers serve as willing participants and enthusiastic underlings to the company in charge of an open source project. Second, the commercial developer is exposed to a community of independent programmers, some of whom may be especially knowledgeable. A constructive dialog may be established between the commercial developer and the volunteer community, potentially allowing everyone to learn from each other. Finally, in releasing the source code to one of its programs, a company can put a positive spin on its image. A company that jumps on the the open source bandwagon instantly becomes hip with the times; it becomes one of those companies that "gets it." This positive image may result in the accumulation of venture capitol, or in the increased sales of the company’s commercial software products. By not participating in the open source movement, a company becomes old-fashioned and out of touch, at least among industry insiders.

There is another reason to release the source for a commercial application. If a company has stopped profiting from an old program that is no longer competitive within the software market, it is often worthwhile to release the program’s source code, in order to foster interest in the company and its product line. This tactic has been used by game developers such as Bungie and Id, who have released the source code for games like Marathon, Quake, Doom, and Wolfenstien 3D. The newest of these games, Quake, debuted in late 1996 and was released as open source three years later. Although any three-year-old game is considered out of date and unexciting, amateur programmers are often interested in getting a peek at any game’s source code, just to see what programming techniques were used. Skilled volunteers have added exciting features to old open source games. For example, Quake has recently been upgraded with 24-bit texture maps. Marathon is currently being given OpenGL support, so that anybody with a 3D graphics accelerator card will see the game’s environments rendered with much greater realism. Understandably, game companies are unwilling to release the source code to new games, and risk losing sales revenue to those who would be willing distribute the same product for free.

Perhaps the most powerful motivation that a company could ever have to release the source code for its products is the one that caused Netscape, after much debate, to release the Mozilla source code: desperation. Netscape’s share of the browser market had descended into a free fall after Microsoft created Internet Explorer and positioned it as the default browser on PCs. Undercutting Microsoft’s price was obviously not an option. Netscape’s choice was to gather an army of willing, unpaid engineers to write a superior browser that would outperform Internet Explorer in every way.

The above justifications for releasing a program’s source code are unfortunately negated by the overwhelming reasons that commercial software developers have not to release the source code to their applications. The first of these is the simple fact that a developer can not easily profit from the work of the open source community- at least not without making the volunteer developers feel exploited. The General Public License that most open source projects adhere to demands that nobody profit from the work of the volunteer programmers. (Free Software Foundation, 2000.) It will be interesting to see how the situation at Apple unfolds in the next few years, if Apple attempts to add the improvements made to the open source Darwin operating system into their commercial operating system, OS X. Similarly, Netscape may be profiting from the volunteer labor that is being used to improve it’s browser. Although the browser will be able to be downloaded from the Web for free, it will likely cost money to obtain the shrink-wrapped version, as this has been the case with Netscape’s previous browsers. If this commercial release proves to be profitable for Netscape, the company may be resented by the volunteers who worked on the project with the expectation that Netscape would not profit financially from their labor. It can be argued that a store-bought, shrink-wrapped edition of an otherwise free program exploits volunteer labor. However this is currently the only sensible way to provide documentation and support to novice computer users. Netscape, Red Hat, and others claim to profit from the support they provide rather than from the shrink-wrapped software they sell, leaving the volunteer developers unaffected. Furthermore, consumers value the tangibility of store-bought software products. It is hard for novice computer users to come to grips with the fact that a program existing only in cyberspace could have any value at all.

Another obvious motivation not to release a program’s source code lies in the possibility that an independent developer may maliciously use an application’s code to create a competing product that undercuts the price of the original product, driving its creator out of the market. This fear has not yet materialized however. In the case of Mozilla for example, it is true that releasing the browser’s source code leaves the door open for someone to create a competing product based on the source. However this could not possibly result in any financial loss on the part of Netscape, because the product that it released as open source had previously been free. Competing against a free product is neither a way to make money, nor a way to hurt the company providing that free product. In giving away its browser, Netscape essentially gives users a vehicle by which users can view the revenue-producing banner advertisements found on the company’s portal site. It is possible that a company could use the Mozilla source code to create a shrink-wrapped, store-bought program that touts superior documentation, yet costs less than Netscape’s offering. However, it is very difficult to gain access to the necessary publishing and distribution channels without Netscape’s resources. Even if those problems could be solved, profit margins would be paper-thin for a competing publisher. The companies that are competing to provide store-bought implementations of Linux are experiencing this dilemma. (Red Hat, Inc., 2000.)

?Microsoft, on the other hand, has a lot to lose by releasing the source code to its products. Opening the Windows source code would result in a slew of Windows derivatives, most of which would probably be free. Microsoft would be in no position to charge money for a product equivalent to that which somebody else is willing to give away. Each competing open source version of the Windows operating system would cut into Microsoft’s market share. Computer hardware manufacturers would no longer have a reason to purchase expensive licenses to include Windows preinstalled on their PCs. Likewise, if Microsoft released the source code for the Office software package, a similar progression of events would occur. The only way Microsoft could participate in the open source movement without losing money would be to follow the Netscape model more closely, releasing the source code for one of the programs that it already gives away, such as Outlook Express, Internet Explorer, or Windows Media Player. On the other hand, Microsoft has no reason to release the code behind those products; each carries the Microsoft logo, they have helped the corporation establish its brand identity, which makes consumers feel comfortable spending money on profitable products such as Windows and Office. And unlike Netscape, Microsoft was not forced to take drastic measures to restore a plummeting market share.

A third factor that discourages companies from releasing source code is that they can not control the direction that the program moves in. If a company releases source code hoping that the independent developers add feature x, and they instead add feature y, the company is at a loss. However, the threat of not having one’s efforts added to the official project is often enough to keep volunteers in line. A well-planned development road map is a good way to prevent volunteers from getting sidetracked. This has clearly helped the Mozilla project, which has been successfully focused on the creation and perfection of a core set of features. Mozilla has not become a sprawling, bloated program with a boatload of unnecessary features.

With these advantages and disadvantages in mind it is possible to understand why a company or an informal group would decide for or against releasing a program’s source code.

IV. Qualities of successful collaborative projects:

Several conditions are necessary for an open source program to succeed. The following passage from The Cathedral and the Bazaar suggests one very important condition that was necessary for the success of Linux:

Besides having to exist within a properly networked environment, an open source project needs several other merits in order to achieve success. Raymond goes on to suggest that Linux might not have succeeded, even in this ideal Internet environment, if it were not for one of its other qualities:

The following paragraphs will explore this leadership factor, plus the many other characteristics of successful open source software. Several projects, including Mozilla, Linux, and the Marathon Open Source project will be analyzed to determine if they meet the necessary criteria.

A strong purpose

In order to capture the interest of volunteer programmers and users, a collaborative software design project needs, among other things, to have a strong purpose. That purpose should entail accomplishing something that has never exactly been accomplished before. This does not have to mean an entirely new kind of program; it could simply be the first open source application in a certain genre, for example financial management software. Another valid purpose is to enhance a previously closed application that has recently been released as open source. The Marathon Open Source project is taking this route. Although the Marathon game engine is technologically inferior to that of newer 3D games, some find the game to be more enjoyable than the latest offerings in the genre. There is a large gaming community that would enjoy enhancements such as multiplayer gaming across the Internet and OpenGL hardware acceleration, and members of that community are attempting to add these features to Marathon. The project’s purpose is strong enough to warrant the attention of a critical number of developers, and a large group of end-users. A project with a weak purpose is one that does not win the hearts and minds of developers. A project with an even weaker purpose would be one that does not attract the interest of end-users.

A sense of direction

Another requirement for a project’s success is a sense of direction. This could mean establishing a clear development path at the outset, so that the programmers do not go off on foolish tangents, adding unnecessary features. However, the development schedule should not be so strict that it limits the decision-making ability of the volunteers who contribute their efforts to the project. That would cause the programmers to lose their sense of direct involvement. This is one area where the Mozilla project is flawed; from the outset it had a strict development road map. Undoubtedly many programmers were deterred from participating in Mozilla upon finding out that any features that deviated from the original plan would not be incorporated into the official build of the program. The rationale of a programmer in this situation: "Well, if they’re only including the features they’ve already thought of themselves, then the program’s fate is sealed. Why should I bother to add those features? Someone else is could do the same work just as easily."

It is important to have a flexible agenda, and that means taking others’ ideas into serious consideration. Such a policy increases interest in the project, and trust in the project’s leaders.

It is therefore important that the direction of a project should be flexible. But what should control how flexible the project’s direction becomes? The Marathon Open Source project’s Web site has a page full of Marathon enhancement initiatives; these are the ideas sent in by developers and others, speculating on how Marathon could be improved. Every idea submitted to the site’s maintainer is listed on a page called "The Plans." It is up to the programmers to pick which plans to execute. Of course the programmers are free to follow their own sense of what should be added to the program, but most of their work originated with pie-in-the-sky ideas sent in to the Plans section by non-programmers. Some of the suggested features have proven to be easy to implement; some are hard but worthwhile. Still others are just plain ludicrous-- too hard to implement, and of questionable value. But every idea is given an equal chance to be heard. Two advantages come from this; everybody has the satisfaction that comes from having a voice, and the programmers work on implementing only the ideas that they deem to be the best. So while the entire idea-producing community enjoys a sense of participation, the programmers rightfully retain the ability to control which features are added to the program. Both the game and the community built around the game flourish.

Advertising

An open source project needs to advertise itself to attract developers and the interest of potential users. Since most open source projects have no financial backing, Web sites and word of mouth are often the only ways to spread interest. Submissions to Internet news sites like Slashdot are often very effective ways of generating interest in an open source project. After the Marathon Open source project was announced in Inside Mac Games magazine, the number of visits to the project’s Web site increased by an order of ten. (Marathon Open Source, 2000.) This kind of advertising is best accomplished by a project administrator, whose main jobs are to organize the efforts of others and to disseminate information.

A diverse group of skilled participants

Another important requirement of an open source project is that it has a group of participants with diverse skills. These skills could range from programming to graphic design to administration. The Marathon project has four core participants, plus a number of less directly involved members. One person has been doing most of the administrative work, which includes maintaining the project’s Web site, making the latest source code and compiled builds available for downloading, facilitating the developer mailing list, promoting the project, and recruiting participants. Another person has taken up the task of adding features that improve the appearance and playability of the game’s existing levels. A third person has been focusing on enhancing the core engine, which has resulted in increased frame rates. A fourth person has been focusing on adding features that future level designers will be able to take advantage of. These engine enhancements will allow more sophisticated levels to be developed in the future, but existing levels remain unaffected. Several other people have made minor changes to the program, such as improving the mouse driver and creating new icons for the program.

People with varying skills are not only desirable, but sometimes mandatory for the widespread acceptance of the project. For example, in order for an open source project to be user-friendly enough to appeal to a large audience, programmers may need to seek outside help from interface design experts. This means involving artists for design work, and novice computer users, from which feedback can be solicited. Although the inner workings of an open source program may be well-designed, their user interfaces are frequently shoddy. Linux’s difficult interface makes it too hard to use to be assessable to a mass market. In an article entitled "It’s the User, Stupid.", Mike Kuniavsky explains the user interface failings of open source software.

This feedback loop is missing because open source software is tested by the same people who create that software. These people are advanced users who may be sensitive to inconsistencies in underlying program code, but are not bothered by poor interfaces. Programmer-users frequently gloss over poor interface design because they are capable of quickly adapting to bad interfaces. In fact, these "advanced users" are best described as people who have adjusted to the difficult interfaces associated with complicated computer software. Because of the fact that advanced users lack a methodology for identifying interface design problems, novice computer users should be brought in to help. Observing a struggling user may help developers identify interface flaws. They can then decide, with the help of artists who understand interface design, how a flawed interface could be remedied.

Apparently there is only one way to make programmers create usable interfaces; they must be paid. That is why Red Hat, in an attempt to spread the appeal of Linux to all computer users, maintains a staff of twelve programmers who are working to improve Linux’s graphical front-end, which is called Gnome (GNU Network Object Model Environment.) (Gnome Project, 2000.)

Communication and coordination between participants

These two requirements go hand in hand. Once a group of people with suitably diverse skills has been assembled, a dialog must be established between the participants. Communication can exist in the form of a news broadcast, and in the form of a dialog. Each format should be used to disseminate different kinds of information. The Marathon Open Source Web site utilizes the news broadcast format to relay objective, uncontroversial facts about the project. This is an effective means to disseminate information that every participant ought to know, such as what new features have just been added to the Marathon program, and what each programmer is currently working on. The Marathon project also supports a dialog between programmers. This dialog takes the form of a mailing list, which anyone may subscribe to. With factual information from the project’s Web site in mind, the participants in this dialog debate matters of opinion. It is here that ideas are thought up, plans are made, and technical details are shared. In order to understand the complicated topics being discussed in this dialog, it may be necessary to refer to the Web site for background information. Because of this, the Web site must remain a comprehensive source of unbiased, objective information, devoted to putting all participants on a level playing field. With the same base of knowledge, developers can intelligently discuss in-depth topics and arrive at the best decisions.

Giving everyone access to the same base of knowledge is important not only because it allows everyone to intelligently discuss complicated topics, but also because it ensures that no effort is being wasted. One of the primary concerns of any open source project should be that no two programmers are tackling the same problem and unknowingly duplicating each other’s work. Communication can prevent this waste of effort. Unfortunately, a significant amount of effort has already been wasted on the Marathon project; a newcomer arrived on the Marathon project’s mailing list with the announcement that he had added a specific set of features to the program. If he had joined the mailing list several weeks earlier he would have learned that others were in the process of doing the exact same thing. By the time he arrived, others had eclipsed his work. Here is the first e-mail he sent to the Marathon Open Source mailing list:

Indeed his experience was extensive; in fact, he was a programmer at Connectix who had a huge amount of experience with graphics programming. With him involved in the project, anything seemed possible. However, some time after making the discovery that an organized group of people had already surpassed his initial efforts, he lost interest. He faded away before making a significant contribution.

If this programmer had known about the others who had been working on the project all along, much more work would had been accomplished through cooperation. Additionally, the programmers would have learned something from each other. It has been proven that two people working together to solve the same programming problem are more effective then a single person. Working together, people get more enjoyment out of the programming process. A 1998 study titled The Case for Collaborative Programming concluded that high-quality software can be developed 40% more quickly when programmers work in pairs. (Nosek, 2000.) The additional cost of hiring two programmers to cooperatively compete a given task is offset by the benefit of getting the product completed more quickly. Since cost is not an issue in the open source world, these benefits do not seem particularly advantageous. However, the report goes on to say that besides outperforming individual programmers, teams of programmers enjoyed the process more, and had greater confidence in their work.

Establishing effective communication may have to be the work of the project’s facilitator, because a constructive dialog does not always spring up naturally. In the case of the Marathon open source project, a dialog did come about naturally, because the alt.games.marathon forum already existed. If such a forum had not existed, it would have been doubly important to establish a mailing list or some other means to disseminate information and share ideas.

Besides mailing lists, open source projects may foster communication through a variety of other devices. Newsgroups are still very popular. Some Marathon developers prefer to use the alt.games.marathon newsgroup instead of the project’s official mailing list. Each format has advantages and disadvantages. Mailing lists seem preferable because you don’t have to remember to check for project-related messages; they arrive whenever you check your regular e-mail. In addition, you can send attachments with mailing lists; newsgroups usually do not let you send attachments. Also, a news reader program is yet another application to learn how to use. Finally, e-mail allows you to easily organize and archive project-related messages. Newsgroups have advantages over mailing lists, however. First, you do not have to leave your browser to access newsgroups. Also, you do not have to manually delete unwanted messages from a newsgroup.

Real-time chat programs are also used to discuss open source projects. But most do not provide an easy way maintain a record of your conversation. Messenger programs such as AOL Instant Messenger, however, have recently become more robust, and are quite capable of serving as a means by which to discuss collaborative projects. Another potential solution is called Hotline. It is a decentralized system that allows users to chat in real time or on message boards, set up personal servers, and share files with one another. The Hotline Client and Server programs are both free, and can be downloaded from http://www.bigredh.com.

However, communication requires more than a mailing list, a newsgroup, or a messenger program. Long before a discussion may occur, a large enough number of people must be made aware of the existence of the project in the first place. That can only be accomplished through advertising, which was described above. This advertising may take the form of banner ads, news stories, or word of mouth. Advertising invariably directs people to a project’s Web site. Once people have arrived at the Web site, they are finally made aware of the opportunity to communicate with others. Only then does a dialog have a chance to occur. By missing one of these steps the Connectix programmer described above missed out on a dialog that would have saved a lot of time and prevented a lot of wasted effort. A project’s Web site is not merely one of the necessary steps along the way to a meaningful dialog. It has many other important purposes, as described below.

A Web presence

A Web site is the closest thing an open source project has to a physical "home base." A project needs to associate itself with a metaphorical location, because without one, it offers nothing tangible that people can latch on to. For the same reason a corporation would want to occupy a large, well-furnished, attractive office building to do business in, an open source-project should want a slick-looking, comprehensive Web site. It makes the project seem more significant and worthwhile.

A project’s Web site has several functions. First, it provides necessary background information. For example, the Mozilla.org home page includes links to several pages of general information, explaining the purpose of the project, who is running the project, and how to get involved in the project. The Marathon Open Source site does the same. Its site administrator gathers much of this background information by listening in on the developer mailing list discussion. A project’s Web site also lays out a plan for the development of the software. The Mozilla project provides a very clear plan, indicating that the program’s feature set was already decided on before the project began. The Marathon Open Source project’s "Plans" section contains is more vague; it contains a collection of ideas, some of which will be implemented, and many that will probably never be implemented. In addition an open source project’s Web site lets you view and download the source code and the latest compiled builds of the program. The Marathon project’s site administrator determines which source code submissions to include on the site; if a programmer submits work that the site administrator deems to be a clear improvement over the existing version, it goes up on the site, and is tagged with an incrementally higher version number. The administrator does not have absolute power when it comes to deciding what is released, however. Any programmer can write to the mailing list, announcing that he has created a new version of the software. If he provides a place to download that software, it becomes just as accessible as any "official" release. The Mozilla project’s Web site makes a new version of the software available every single day. An automated system compiles the code at the end of every day, regardless of whether that code is capable of producing working program.

There are several other things that the Web site should have. It needs to provide a solid base of technical information on subjects such as compiling the source code and removing bugs. It also should provides information explaining how to communicate with other developers. Additionally, there should be legal information, such as the GPL, explaining what can and can’t be done with the source code. Finally, the site should let you give feedback to the site operator.

Except for a few technical differences, the Marathon site and the Mozilla site have much in common- despite the immense difference in the two projects’ sizes. Mozilla is a huge project run by a well-financed group within a large corporation (the Netscape subsidiary of AOL-TimeWarner.) The programming work is being handled by both paid employees and unpaid volunteers from around the globe. The Marathon Open Source project on the other hand is nothing more than an attempt to improve a simple computer game. While Mozilla has several hundred contributors, Marathon Open Source involves fewer than five serious programmers. It is therefore easier to organize the efforts of Marathon’s developers. The developers communicate via a single mailing list, which receives fewer than fifty messages per day. Mozilla’s 51 mailing lists and newsgroups on the other hand, are each geared toward a specific facet of the Mozilla project. The subject of the discussions that take place in these newsgroups range from the program’s user-interface to the format of its preferences file. Mozilla also offers its developers real-time chat, bugs-tracking software, and even a custom program that tracks the most important of the messages posted on Mozilla’s newsgroups. A fair amount of software development has been done to simply create the tools that are being used to develop Mozilla.

A lot of thought has been put into the Marathon Open source project in order to ensure that the project’s developers are kept abreast of current happenings. The news section is updated daily with information on the game’s progress- particularly who has done what, and who is working on what. A huge amount of administrative work is done just to keep up with the half dozen people who are working to enhance Marathon. The amount of administrative work that must be done on a colossal project like Mozilla is staggering.

The Marathon Open Source site does not have sophisticated server-side software used for tracking bugs. It also lacks a Concurrent Version System (CVS) for dealing with the collection of text files that comprise the "source tree." But it uses inexpensive alternatives to accomplish the same thing. The project uses a Hotline server to hold each of the source code files. The server allows real-time chat between developers. It also provides a place to download executable files, test levels, and general information that is helpful to developers. (Hotline Communications, 2000.) Hotline’s biggest advantage is that it can be used to serve files very easily. Any registered developer can add their contributions to the server by simply dragging files into the server window. The Hotline server effectively acts as a CVS system, because it contains a folder full of the 173 different text files that comprise the Marathon source code. Anybody can download any one of these files. Any registered developer can upload modified versions of these files back to the server. The collection of source code files is continually being updated, one file at a time. At any given time, the collection can be downloaded in its entirety and compiled into a functional game. In order to ensure that important files are not overwritten with inferior material, the server’s moderator only allows trusted developers to upload source code files.

Support from non-programmers

Capturing the interest of non-programmers can boost morale within the ranks of the programmers. When someone senses others paying attention to their work, it affirms the importance of their efforts. In order to make the outsiders themselves feel a similar sense of importance, they should be able to contribute to the project in any way they can. Increasing someone’s sense of involvement provides a morale boost. Splash screens, icons, documentation, and ReadMe files can all be created by non-programmers. In creating a program’s icons, an artist is capable of feeling the same sense of involvement felt by a programmer; as long as someone is providing the most their talents allow them to provide, their work seems worthwhile.

The Marathon Open Source site makes an attempt to increase morale and involvement by letting non-programmers contribute. The site has a section full of artwork related to Marathon. This artwork includes entries of a contest to see who could design the best splash screen for the game. Also included were several icon submissions. The feeling of involvement that someone has in contributing an important program element like a splash screen is similar to that of someone who contributes to the source code itself.

The Mozilla project is clearly working to increase morale as well:

This party was clearly meant to inspire developers to work harder as the Mozilla project nears completion. Since it is free to the public, it is also meant to gain support from potential users. Another example that created a stir of outside interest: when the development of the Macintosh version of Quake II was nearing completion, a contest was held to see who could create the best set of Quake icons. Still another way to gain the interest of outsiders is to allow them to test beta versions of software before it is made available to the public. These methods are often used to attract attention not only to open source projects, but to all kinds of software development projects limited by tight budgets.

While emphasizing the importance of non-programmers, I do not want to gloss over the importance of programmers- particularly those who are skilled enough to contribute meaningfully, but not charismatic enough to lead the project. These programmers should not allow the project’s leader to dictate what they can and cannot do. Derek Moeller writes:

Ambition

Eric S. Raymond stresses that open source projects be not too easy and not too hard for the programmers involved. A delicate balance is absolutely necessary:

Overly ambitious projects result in stress, frustration, discouragement and ultimately, failure. Of course ambitious is a relative term. What is ambitious for one group of people is easy that it is boring for another group. Almost everyone would consider Mozilla and Linux to be two extremely ambitious projects. Marathon development on the other hand is a modest project. Some would scoff at the idea of wasting time trying to fix a simple, outdated computer game. All of the people involved in these three projects have chosen one that suits their skills and level of ambition. It is important to choose a project that is sophisticated enough to be interesting while simple enough to be doable. Fortunately, people seem to naturally latch onto projects that challenge them. Sometimes overly ambitious projects are chosen, and the participants burn out and give up. Unfortunately, some people are only interested in projects that are impossibly complicated. One way for an open source project to be both ambitious and doable is to start with a solid base of code. Mozilla lacked this, and as a result, it has taken a very long time to create from scratch. Marathon had it somewhat better; the project started with the release of a collection of semi-functional code. Within a week developers got the game up and running. Soon afterward, new features began appearing in the program. The limitations of the programmers’ skill would have made it impossible to create such a project from scratch. But working off an established base of code is giving comparatively mediocre programmers the chance to create a game with cutting-edge graphics. Eric S. Raymond positively demands that all open source projects run upon introduction to the volunteer community.

With this logic in mind, Simon Brownlee is creating a new level-editing program for Marathon as a closed-source application. When the program becomes mature enough to benefit from the efforts of volunteer programmers, it will be released under the open source model.

Another factor that allows for relatively ambitious yet doable projects is the use of code libraries that handle common tasks like connecting to the Internet and displaying text on the screen. When the time came to improve Marathon’s graphics, extensive use was made of OpenGL shared libraries, which automatically handle texture smoothing, mip mapping, and anti-alaising. OpenGL and other application programming interfaces provide a graphical base upon which nearly every 3-D computer game is built.

V. The future of open source software development

Creating software is something that some people are willing to do during their free time. But until recently, it has been impossible for a hobbyist to create software that is as good as commercially developed software. The Internet has made it possible for hobbyist programmers to collaborate and produce extremely good free software. Such software can compete with commercial software and sometimes it can win out, as Apache has done.

If this continues, the jobs of some commercial programmers will no longer be needed. If enough customers opt for free open source software instead of the expensive alternatives, commercial software companies would become unprofitable, and their employees would lose their jobs. Why then have some of Apache’s competitors stayed in business despite the fact that Apache has become far more popular than commercial server software? This can be answered on a case-by-case basis, but there is really only one answer: those companies have diversified. Netscape, whose business model was originally to give away its browser and get rich by selling its expensive server software, remains in business because it was acquired by America Online- a diversified company. (Netscape’s new business model is to give away its browser and expose customers to the banner advertisements on its Web portal.) Microsoft, which attempted to duplicate Netscape’s original business model, proved to be even better than Netscape at giving away free browser software- but its plan didn’t pan out; it too is failing to make much money in the server market. Microsoft is still around, however, because it is a diversified company. Small companies that only offer a single product are much more susceptible to the threat of open source software than large companies.

By all accounts it is senseless to try to compete with free software by selling an expensive alternative. In fact, the only way to successfully compete with a free product is to give away your own product. Because the Netscape browser and e-mail client are free, Microsoft can compete only by giving away its own browser and e-mail program. Microsoft may have won the browser war, but in doing so it paid a huge price.

Competition in the software industry has become absurd: Microsoft charges a huge amount of money for its operating system and its Office software, yet gives away its browser and e-mail program, which require similarly massive amounts of resources to develop. This policy is odd from a business standpoint, but it goes to show that drastic measures must be taken to acquire market share in a market where competition has driven prices down to zero. There should be no doubt that if Netscape did not exist, Microsoft would have charged whatever it could for Internet Explorer and Outlook Express. If Microsoft had never decided to create it’s own browser, Netscape would be free to charge similar prices for its own product. The browser wars represent capitalism at its best.

The browser makers are competing for dominance in a market that they themselves have made unprofitable. All they have left to compete for is attention. Fortunately, the browser wars will not drain enough resources from the browser makers to force them out of business; the two dominant Web browsers are being developed by two of the largest companies on earth: Microsoft and AOL/TimeWarner. Both of these are highly diversified companies that can afford to lose money creating free products that generate a huge amount of positive attention. But it is easy to see that when a small commercial software company is faced with competition in the form of a free product, that company must either change it’s strategy or go out of business. Unlike hardware industries, where the cost of creating and shipping material objects imposes a theoretical limit on how low prices may go, the base cost of software creation is very murky. It is clear that nobody is capable of shipping cargo across the Atlantic for free (as fun as that activity might seem), but software developers are willing to code an operating system for free, because it is both fun and feasible. This should cast serious doubt upon the future profitability of the software industry. As absurd as it sounds, the Microsofts of the world could face trouble in the coming years. Perhaps IBM was right after all when, in the early eighties it said something along the lines of "There’s no money to be made in selling this software stuff. Let’s get Microsoft to make us an operating system; we’ll pay them cheap royalties, and we can get rich off the hardware." (Turner Network Television, 2000.)

Microsoft does not want to admit that Linux is a threat to their profitability. But the company did identify it as a major competitor when trying to disprove the acquisition that it is a monopoly. In beginning of the U.S. government’s antitrust case against the company, Microsoft witness Richard Schmalensee claimed that

"There are applications being written for Linux by major manufacturers. When those applications are completed, I believe it will be viable in a way that it's not now and that's a matter of months, not decades." (Schmalensee, 2000.)

Microsoft should be worrying about the impact that Linux is having upon sales of Windows. Computer hardware manufactures like Dell and Gateway must pay Microsoft close to $80 for every copy of Windows they bundle with their PCs. (Microsoft Corporation, 2000.) Some hardware manufacturers are instead choosing to bundle Linux, which carries no licensing fee. As computers become cheaper, profit margins narrow, and an $80 licensing fee represents an increasingly large portion of the total price of the computer. The comparative cost of Windows, as opposed to that of the rest of a computer, is unnaturally high. Selling a new Windows PC for $800 is less profitable than selling a Linux PC for $750. With the Windows license costing $80, the Linux PC would bring in $30 of additional profit.

But most computer manufacturers continue to include Windows with their PCs. This is because Linux is still too hard to use, and there are not enough programs available for the operating system. If Linux’s fanatical developers want their product to reach the masses, they must reorient their operating system toward consumers instead of developers. They can accomplish this by designing program interfaces that are as solid as the underlying code. The open source community can improve all of their products by reaching out to people with a wider variety of talents. However, open source developers seem content to remain underground; their purpose is not to cater to the masses- instead their efforts are meant to benefit themselves- to create solutions to their own obscure computing problems. The GIMP is a notable exception; a program that is filling the void left by Photoshop. Linux’s community of developers, while more interested in programming than in producing art, is wise to support the GIMP, which is positioned to attract the same group of creative people that have been using the Macintosh for years. But by and large, the Linux development community remains hesitant to "sell out" to the mainstream culture. Understandably, they do not want their platform of choice to be inundated with ignorant, AOL-using newbies.?

Nevertheless, if Linux and other open source programs become as easy to use as commercial software, the commercial software market would have no remaining advantages. Microsoft would become microscopic, and the hardware manufactures would steal the spotlight. Whether this is good or not is debatable. But the fact is, there would no longer be any money to be made in creating software. Undeniably, Linux aficionados want to see Microsoft suffer at least as much as they would like to see their own operating system succeed.

VI. Recommendations

The following recommendations are intended to improve the quality of open source software, to increase the community-building potential of open source development, and to spread the benefits of open source software to as many people as possible. The first set of recommendations should be taken into consideration before a potential open source project has begun. No open source project should be undertaken unless it meets the following criteria:

If a potential open source project has met the above criteria, it is probably worth starting. Once the project is underway, the following conditions should be adhered to:

VII. Additional Considerations

It was stated that the above recommendations were intended to improve the quality of open source software, to increase the community-building potential of open source development, and to spread the benefits of open source software to as many people as possible. It is worth noting that this final goal is not universally lauded. Some people do not recognize that the difficult task of spreading open source software to the masses would be worth the effort. For example, in a recent Slashdot posting, FascDot claims that Linux is so powerful that to give it a more accessible (or as he sees it, a more dumbed-down) interface would do no justice to the operating system:

The problem explained here is that in making Linux easier to use, a certain degree of functionality is sacrificed. Understandably, FascDot believes that maintaining Linux’s power-user features is more important than spreading Linux to grandmothers and other members of the general population. However, the fact that grandmothers do not have to run "pipes and greps and stuff" does not justify switching to a conventional operating system. When faced with Windows or the Macintosh OS, the proverbial grandmother does not care that the pipes and greps are missing. But she does care that her computer is more expensive, crashes more often, and contains bugs that go untreated for longer periods of time.

Novice and intermediate computer users would benefit greatly from a system that combined the low cost and stability of Linux with the Mac’s ease of use. However many open source programmers are as self-interested as anyone else; they seem unwilling to produce the needed user-friendly software. They lack the motivation to do so, since such software would not be very useful to the programmers themselves. In failing to pay attention to the public need for a system that is not only cheap and stable, but also easy to use, the pipes-and-greps crowd is leaving the door wide open for a company like Apple to step in and fulfill the requirement with Mac OS X. In saying "think about the power of the tool, THEN decide on a UI.", FascDot does not realize that the real power of this particular tool (Linux) lies not in it’s ability to handle pipes and greps, but in its stability and low cost- two features that mainstream computer users would surely enjoy- but could only enjoy with the proper interface.

It may seem that any given open source programmer is acting nobly by choosing not to sell out, by not catering to the masses, and by producing software that solves his personal needs instead of everybody else’s. Of course it would be ideal if he created software that everyone could use, instead of making esoteric software serving only his own bizarre needs. But since the programmer is not profiting from his work, his rather selfish actions seem entirely excusable.

However given the conditions , this course of action is not as innocent as it seems. In fact, the programmer does profit; only his profits come in the form of software rather than money. A group of open source programmers can be compared to greedy corporate executives, acting only in the service of the company’s bottom line, while ignoring the fact that if it shifted its priorities it could have a more positive social impact. In short, the open source programmer wants powerful free software, and the corporation wants profits. Both work to achieve their goals with little regard for those who are left behind.

The sense that the open source programmer is a noble humanitarian is further eroded by the fact that the material he so willingly shares with others carries no market value and can be replicated for free while keeping the original copy intact. The GNU General Public License that he adheres to ensures that he will benefit by giving away his creation. At the very least, he will break even, and the license ensures that nobody will profit from his work. Clearly an open source programmer must do more if he is to earn respect by positively influencing the software world.

The truly noble thing for an open source programmer to do would be to imitate companies that conduct business responsibly. Consider how such a company gains respect and enhances its reputation: it does so by putting people over profits. (In the case of open source software development, "people" means average computer users, and "profit" equates to esoteric software that only a programmer would want to use.)

It is all too easy for an open source programmer to denounce the act of giving the masses exactly what they want; selling out is inherently uncool, plus it reveals a lack of creative vision. But in the case of open source software development, there is even less motivation to sell out due to the fact that there is no financial reward to be had in catering to the masses. Furthermore, the software that could benefit the masses would be of no use to the programmer himself; such software is far too inefficient, unsophisticated, and mainstream in appearance and function. For this reason, the seemingly noble act of not selling out is merely an excuse to produce software that benefits oneself while forgetting about the positive effects that one might have if their efforts were directed towards producing for others.

The reason that the act of catering to the masses seems so uncool is because that is what the corporate software developers do; they try to please everyone and inadvertently create clumsy bloatware. But open source developers must realize that that in itself is not what makes the corporate software developers bad. The corporations are disagreeable only because they do not promote free software (free as in not costing money, and free as in modifiable and redistributable.) In his free software manifesto, Richard Stallman makes no mention of the dangers of "selling out." His goal is to spread free software to everyone, so that proprietary software could one day become obsolete. After reading his manifesto, the importance of creating free software that can be used by even novices should be self-evident.

It would take an exceptionally selfless group of people to create software that benefits the world more than it benefits themselves. So far only profit-driven programmers have risen to that challenge. That is not exactly what Stallman had in mind. Hopefully when the pipes-and-greps people have finished creating their own obscure software, they will surprise us by announcing that they just finished creating the tools needed to make free software available to everyone.

References

The Apache Software Foundation. (2000, April 14). The Apache Software Foundation. [Online] Available: http://www.apache.org [no date]

Apple Computer, Inc. (2000, April 18). Darwin Open Source SDK. [Online] Available: http://developer.apple.com/products/darwinsdk.html [no date]

"FascDot Killed My Pr." (2000, April 26). Ask Slashdot: What is important in a User Interface? [Online] Available: http://slashdot.org/article.pl?sid=00/04/24/125238&mode=thread [2000, April 26]

The Gimp. (2000, May 3). The GIMP Homepage. [Online] Available: http://www.gimp.org [2000, May 2]

Gnome Project. (2000, May 6). Gnome Project [Online] Available: http://www.gnome.org [2000, May 5]

Gore 2000, inc. (2000, April 26). Welcome to algore2000.com, Al Gore's official Presidential campaign web site. [Online] Available: http://www.algore2000.com [2000, April 26]

Hotline Communications. (2000, May 6). Hotline Communications [Online] Available: http://cgi.bigredh.com/index2.html [no date]

Kevill, Scott. (2000, May 3). Macintosh online multiplayer gaming [Online] Available: http://www.gameranger.com/ [2000, April 28]

Kuniavsky, Mike. (2000, April 12). It’s the User, Stupid. [Online] Available: http://sendmail.net/?feed=interviewkuniavsky [2000, January 20]

Linux Online Inc. (2000, May 6). Linux Online - Linux Retailers. [Online] Available: http://www.linux.org/vendors/retailers.html [2000, May 4]

Marathon Open Source. (2000, May 6). Marathon Evolves [Online] Available: http://source.bungie.org [2000, May 5]

Microsoft Corporation. (2000, April 28). Microsoft OEM Welcome Center [Online] Available: https://oempub.microsoft.com/ [no date]

Mozilla. (2000, April 2). Mozilla dot party three dot oh [Online] Available: http://www.mozilla.org/party/2000/flyer.html [no date]

Nosek, John T. "The Case for Collaborative Programming." Communications of the ACM (March 1998) Vol. 41 No. 3 page 105-108

Raymond, Eric S. (2000, May 6). The Cathedral and the Bazaar. [Online] Available: http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html [2000, April 5]

Red Hat, Inc. (2000, May 6). Red Hat Reports Fourth Quarter Results [Online] Available:http://www.vcall.com/NASApp/VCall/PressRelease?Accept=C&ID=7087 [2000, March 27]

Red Hat, Inc. (2000, May 6). Red Hat Store. [Online] Available: http://www.redhat.com/commerce/redhatlinux.html [no date]

Schmalensee, Richard. (2000, April 28). Microsoft Prepares to Present its Case as Government Rests [Online] Available: http://www.microsoft.com/PressPass/trial/jan99/011399.htm [1999, Jan 13]

Stallman, Richard. (2000, April 8). GNU General Public License [Online] Available: http://www.fsf.org/copyleft/gpl.html [2000, March 6]

Stallman, Richard. (2000, May 6). The GNU Project [Online] Available: http://www.fsf.org/gnu/thegnuproject.html [1998]

Stallman, Richard. (2000, May 7). What is Copyleft? [Online] Available: http://www.fsf.org/copyleft/copyleft.html#WhatIsCopyleft [2000, April 14]

Turner Network Television. (2000, April 4). The Pirates of Silicon Valley [Online] Available: http://tnt.turner.com/movies/tntoriginals/pirates/ [no date]