An Open Source Primer

Brian Still. Global Information Technologies: Concepts, Methodologies, Tools, and Applications. Editor: Felix B Tan. Volume 1. Information Science Reference, 2008.

Introduction

Eric Raymond, in his book The Cathedral and the Bazaar (1999), likens the key difference between proprietary and Open Source Software (OSS) development as similar to the relationship between building a cathedral and a bazaar. According to Raymond, OSS is not the product of a few “wizards or small bands of mages working in splendid isolation, with no beta to be released before its time” (p. 29). Instead, OSS development is like a “great babbling bazaar of differing agendas and approaches” (p. 30).

Facilitated by the Internet, hundreds if not thousands of developers working on OSS projects combine their talents to create software that addresses practical needs or solves problems. OSS projects are constantly reshaping themselves. A version of the software is produced and distributed, tested, debugged, and then improved upon and re-released. All of this process takes place in the open. Errors are not kept secret, nor are improvements. The software is made available to the developers and to anyone else who wants to access it. Moreover, the software is open for others to improve upon it. Depending on the OSS license, others can even release their improvements back to the public or sell them for a profit without needing the permission or authorization of the original programmer.

OSS development has literally exploded in popularity among consumers and software developers. For example, today the most popular Web server on the Internet is Apache, an Open Source, not proprietary, product. Additionally, Linux, perhaps the software referred to most often as the perfect example of OSS, is challenging Microsoft Window’s once unquestioned dominance of the operating system market. Still, OSS is not without its detractors. Just as there are those who would argue for it because of its little or no cost and flexibility, there are others that would argue that it is difficult to implement and its core developers are undependable hobbyists.

Despite these misgivings, businesses and even nations (Liu, 2003) in already lean economic times are increasingly relying on OSS as a cost-effective legitimate alternative to proprietary software. In some cases, larger companies have saved millions of dollars just by switching from Windows to Linux operating systems (Koch, 2003). As long as OSS proves more affordable and as (if not more) effective than proprietary software, organizations will continue to integrate OSS into their business infrastructure, using it to power their Internet services, operating systems, and other key software applications.

As a result, technical communicators in the workplace will—to some degree—become involved (if they are not already involved) with OSS or Open Source ideas. They may write end user documentation for Open Source software that their organization has acquired and then modified for its own purposes. They may manage or participate on project teams tasked with evaluating and adopting new software for a business. They may have to explain OSS and the intricacies of its licensing and development practices to decision makers who lack technical expertise. Because of these scenarios and others, technical communicators can benefit from a solid understanding of OSS and the role it plays in business.

The purpose of this chapter is to provide that solid, introductory overview of OSS. To accomplish this, the chapter presents the following information:

A definition of OSS and a brief look at how it is used;
An explanation of how OSS works in comparison to proprietary software;
A history of OSS development;
OSS licensing types;
OSS applications in business;
OSS strengths and weaknesses;
An evaluation of the practical potential of OSS in the workplace;
Emerging and future trends in OSS; and
Online resources available to conduct further research on OSS.

Defining Open Source and Tracing Its Origins

OSS is currently used in a number of different roles. Linux, as already mentioned, powers computer operating systems for businesses offering services ranging from aerospace to telecommunications. OpenOffice (www.openoffice.org), although not nearly as popular as Linux, is an OSS alternative to Microsoft Office. OpenOffice offers word processing, spreadsheet, presentation management, and drawing tools. Other OSSs run certain key services, such as email and the Internet, that have become necessary staples many businesses consider critical to their core services. Sendmail, for example, is a free software program that handles a majority of all email. INN manages the collection and distribution of Usenet articles. Majordomo powers electronic mailing lists. BIND is also an OSS that enables the Internet’s Domain Name System (DNS) to map connections between numeric and human-readable addresses. In other words, BIND makes it possible for users wanting to visit a website to type in an easy-to-use-and-remember address, like www.opensource.org, rather than a long string of numbers. Obviously, OSS is an integral part of today’s business infrastructure.

The driving force behind OSS is the Open Source movement, which can best be understood by what it opposes (proprietary software) and what it also supports (open software development). OSS advocates believe in an open exchange of ideas, an open coordination if not merging of different software, and, at the most crucial and basic level, an open access to the source code of software. Bruce Perens, creator of the Open Source definition, calls it a “bill of rights for the computer user” (1999, p.171). Perens helped found the Open Source Initiative (OSI) in 1999. OSI maintains the Open Source definition and its registered trademark, and it campaigns actively for the Open Source movement and strict adherence to its definition. Only those software licenses that adhere to the guidelines of the OSI Open Source definition can use the trademark.

The entire OSI Open Source definition can be viewed online at http://www.opensource.org/docs/definition.php. Its key tenets, however, can be summarized here: For a software license to be considered Open Source, users must have the right to make and even give away copies of the software for free. Additionally, and perhaps most importantly, users must have the right to view and, if they want, repair or modify the source code of the software (Perens, 1999).

Source Code

To better understand the significance of allowing users to view the software source code, we should take a brief look at what source code is. Source code is the wiring that makes software work the way it does. Put simply, programmers use a computer language to create source code or to script (write) commands that tell the software how to perform. In order to create new software, to fix or debug faulty software, or to modify existing software to meet a particular need, the programmer must have access to the source code. OSS allows for “open” access to this code. That is, individuals are free to modify/change software code at their desire and without needing approval from the original programmer who created the code.

An illustration of how source code works to instruct a computer to carry out a specific task is illustrated in the following example of a C++ computer programming language script (Figure 1).

In Figure 1 the script prints a particular message depending on a set of conditions presented in the if/else commands written by the programmer. If the age entered is under 16, for example, the message returned is: “I’m sorry but you’re too young to get a driver’s license.” The if/else conditions and “printf” commands of this program are the source code.

This source code, although useful to a programmer, cannot be read by the computer. It must be translated or compiled into object code or the binary 1s and 0s that computers can read and execute. This binary or object code is often referred to as “machine language” because it is written in numbers that can be easily understood by computers, or machines. Of course, what makes it easy to understand for computers makes it impractical for people to understand. Most proprietary software licensed for use comes in object code form only, which means that the computer running the software gets the numbers or machine language it needs to know what to do. However, users, such as programmers, do not get access to the source code or language needed to understand and if necessary modify the program. In other words, the source code is not open.

Assuming there are no problems with the object code or that no changes need to be made to the information the software is providing to the computer, access to the source code will not be needed for the proprietary software to run as it should on the computer. But what if changes are required? What if, for example, the legal age to get a driver’s license in the state changes to 17? How would the software be changed to allow for this new wrinkle? If only the object code is available through the software, the programmer cannot make changes. Only access to the source code enables the if/else command to be modified so that it reflects the new legal driving age.

Proprietary software companies close access to the source code of their applications because they consider it intellectual property critical to their business infrastructure. If any user could change the source code of the software, there could be eventually many different versions of it not easily supported by computers. And if the user who purchased the software could change the source code, the user would not need to pay the software company to make the change. With unrestricted access to the source code, a user could even develop another version of the software and then distribute it at a lower cost or for free (Nadan, 2002).

The OSS model works differently, primarily because the profitability of the software in and of itself is not important. This is not to say that some OSS companies do not make money. Many do profit by providing service or support to users. RedHat (http://www.redhat.com) makes a decent profit packaging and distributing Linux to users. While any user can download and install Linux for free, RedHat has managed successfully to convince users that by paying a little extra to RedHat, they will get a guaranteed, ready-to-go version of Linux that comes with experienced support, such as training, manuals, or customer service (Young, 1999).

OSS source code is not the intellectual property of one company. Rather it is more like community property that belongs to every user. With barriers removed to who can access it and who cannot, the thinking behind this key Open Source tenet is, the more individuals who look at the source code, the better it will become. More bugs will be caught, more enhancements will be added, and the product will improve more quickly as the experience and talents of a large community of developers is put to work making it better (Raymond, 1999).

Such an approach to software development and distribution has successfully threatened proprietary software’s hold over the market in recent years. Although it seems revolutionary, it is actually the way things are done, according to Alan Cox, “in almost all serious grown-up industry” (Cox, 2003, paragraph 11). In every field consumers can go elsewhere if vendors are not supportive. Cox uses the auto industry as an example: People can pick the car they want from the dealer they want, they can look for the best deal, and if they want save money fixing the car themselves. Because of OSS, software consumers now have that same sort of power. Instead of just one choice, one kind of license, and one price, consumers now have a choice of brand names, a chance to test multiple products for the right fit and buy, and ultimately the right to tinker with the software’s source code on their own to make it work for their needs (Cox, 2003).

MIT, Hackers, and the Origins of OSS

If we trace the origins of OSS, we see that what now seems like such a novel business and philosophical approach to allow access to a software’s source code is actually the way things were done long before consideration was given to turning a profit by selling software. In his book, Hackers: Heroes of the Computer Revolution (1994), Steven Levy examines the beginnings of computer programming that would lead to the development of, among other things, the personal computer and the Internet. Starting in the 1950s with groups such as the Tech Model Railroad Club at MIT and carrying through to the Homebrew Computer Club in the 1970s (Levy, 1994), the work of these early programmers was very much akin to scientific research and discovery. Since the only way computer scientists could then (and even now) learn from the work of others was to view that work, the source code of any hack or program was always available (DiBona, Ockman, & Stone, 1999). The idea was that another programmer might be able to improve upon the program, and once that improvement was made available to the group of programmers, improvements could be made on it (Levy, 1994).

The beliefs of these programmers parallel those of OSS developers now, and that is no coincidence. The same “hacker ethics” that drove programmers at MIT and elsewhere are clearly principles that have been passed down to today:

Information, such as source code, should be freely accessible;
Nothing, not a person, a law, a government, or a business should stand in the way of programming;
Hackers or programmers should be judged by their skill;
Computers can always be improved and computers can improve life as we know it (Levy, 1994).

For early programmers, the potential profitability of a program was not the key element that motivated them to program. This is true as well for OSS developers. They want access to the source code because they want to tweak it and perhaps make it better. They are, according to the results of the Boston Consulting Group (BCG) 2002 Hacker Survey, primarily motivated by the challenge of programming. After that they want to improve their own skill and be recognized for that skill among their fellow programmers. Money, at least according to the BCG survey, is rarely a motivation for OSS developers.

Some critics look at such statistics and suggest that although that may be true now, OSS development does not have the steam to continue, precisely because OSS developers are primarily just hobbyists who are “hacking” for free. Developers, Robert Glass argues, like to be paid too much to continue doing anything free forever (2000). In truth, however, developers were hacking for fun and for the challenge long before they were doing it for money. And the same forces that drove many of the early programmers still drive OSS developers today: They want recognition for being good, and they want to make the software better so that they and others can do more positive things with it.

The Free Software Movement (FSF)

One of the recognized champions of this view is Richard Stallman, the founder of the Free Software Movement (FSF) and the creator of GNU, a free version of the Unix operating system. Disillusioned by the trend toward commercialization in software programming, Stallman founded FSF in 1984 on the belief that “source code is fundamental to the furthering of computer science, and freely available source code is truly necessary for innovation to continue” (DiBona et al., 1999, p. 2).

The FSF has been committed since its beginning to allowing users this freedom, serving as an alternative to the proprietary model. The “Free” in the Free Software Foundation does not refer to price, although many assume that it does. Actually, distributors of free software can charge for the copies they give out and the software will still be considered free. That is because the idea of “free” that Stallman is interested in refers to the “freedom to run the [software] program, for any purpose,” and “freedom to modify the program” (1999, p. 56).

After creating the GNU operating system, Stallman drafted the General Public License (GPL), which was meant to govern the distribution and use of the GNU. Any software that wanted to be “free” according to Stallman and the FSF had to abide by the dictates of the GPL. One application that did was Linus Torvalds’ Linux kernel, which when matched with GNU made it the robust, freely modifiable operating system commonly known as Linux today (Torvalds, 1999).

As successful as Linux has been as a free software application, other applications and other software companies have balked at the religious zeal of Stallman’s FSF, and also the rigidity of its GPL. The GPL requires that any modifications made to software licensed under the GPL must be made public and freely accessible. Stallman calls this requirement copyleft. If a user, for example, downloads a piece of free software with a GPL license, and then that user makes modifications to the software, the user cannot take ownership over those changes, declare them to be intellectual property, and then sell them for profit. Any code derivative of any GPL software must abide by the same terms of the GPL to which the original software adheres. This prevents any programmer profiting from the use of free software source code. The notion of copyright, therefore, is turned upside down. No one owns the code; the GPL insures that it belongs to everyone. Copyleft means that it is free for everyone to use as long as they give back what they create by using it (Stallman, 1999).

Obviously, the GPL as well as FSF’s overall intransigent position turns off many in the software industry. As much as they wish to contribute to the well-being of the community, they are most interested, as they have to be, in their bottom line. More than a few also regard the FSF as a political entity with an ideology that is very anti-business. Doug Palmer writes that because FSF is a political movement, “the aim is not to allow people to do as they will, but to force people to do as the movement decrees” (2003, Free as in Speech, paragraph 5).

Going Mainstream: The Beginnings of the Open Source Movement

Aware of these negative perceptions of free software, and sensing that some sort of positive effort had to be made at putting a more palatable face on the movement, a number of free software programmers, absent Stallman, met in 1997 to consider ways of re-branding free software. Their concern was that Stallman’s all-or-nothing approach to free software was killing the growth of Linux in the business world. The use of the word “free” was also, they thought, too confusing, simply because the reaction of many, especially those in business, was that free meant no charge (Perens, 1999).

From this meeting and others, the Open Source movement was born (DiBona et al., 1999). The Open Source movement established the Open Source Initiative (OSI) to act as a clearinghouse and public relations vehicle for approving OSI-compliant software and forwarding the OSI definition. Based on the Debian Free Software Guidelines that Bruce Perens had written (Perens, 1999), the Open Source definition is more flexible and friendly to business than the GPL. It “allows greater liberties with licensing than the GPL does. In particular, the Open Source definition allows greater promiscuity when mixing proprietary and open-source software” (DiBona et al., 1999, p. 3). For example, one license that meets the Open Source definition’s guidelines is the Berkeley System Distribution (BSD) license. Like the GPL, it lets developers view the source code of the original software and make a derivative version of it; unlike the GPL, however, the BSD allows the developers to make their changes private. In other words, the developers can make modifications and then distribute those modifications in object code form only, retaining intellectual property or ownership over the source code of their modifications.

OSS Licensing

As of January 2004, the OSI has approved more than 20 licenses, including the GPL and others, such as the BSD, MIT and X licenses, that offer developers more leeway than the GPL in controlling the derivative source code they create. In the past, the options for proprietary software licensing have been somewhat clear if only because they have been so limited. No access to source code means no ability to modify the software to do anything that might possibly violate a license agreement, aside perhaps from duplicating it and then distributing free copies to unlicensed users. However, the availability of open access to source code changes everything. What can be accessed? Can the software be modified? Must those modifications be made available publicly, or can the user who made them keep them private? Depending on the OSS license, the answer may vary. Here is a summary of the most commonly used OSS licenses:

General Public License (GPL). The GPL is as much a manifesto as a license. If the developer wants the source code and any modifications to that source code by other developers to remain public, the GPL is the license to use (Perens, 1999).
Lesser GPL or LGPL. This license, born from the GPL, allows OSS source code to be mixed with proprietary software. Specifically, software libraries, such as the C language library provided with Linux, can be used to build proprietary programs (Perens, 1999). Proprietary programs can also be used to “extend” the source code of the software under this license.
Berkeley Software Distribution or BSD. The BSD allows the software licensed under it to be used for about anything (Perens, 1999). The X and Apache licenses are similar to the BSD. The BSD does require, however, that any advertising of the software licensed under the BSD must reference the University of California. For this reason, Bruce Perens encourages developers and organizations considering the BSD “to use the X license instead” (1999, p. 183).
Mozilla Public License or MPL. Like the BSD and X licenses, the MPL allows OSS to be mixed with proprietary software and modifications made to source code to be privatized. But any derivative work of the original source code, although private, cannot claim patent rights (Wu & Lin, 2001). The MPL is an offshoot of the NPL or Netscape Public License, which was created specifically for Netscape when it made its source code publicly available.
MIT License. This is perhaps the least restrictive Open Source license. Users of the source code licensed under the MIT can copy, modify, and redistribute without restriction the source code or derivatives of it. The only requirement is that the original copyright and terms of the license are retained.

For most users, the intricacies of OSS licensing are not that important. Software companies and technical communicators working for them should be aware, however, of the ins and outs of licensing. Of all the OSS licenses, the GPL presents the greatest worry, especially for small or startup software companies that “have not mastered the terms and conditions of the GPL” (Nadan, 2001, paragraph 9). According to Nadan, the infectious nature of the GPL is a danger, and if companies are not aware, the proprietary software they create could “become GPL if it merely shares data with the GPL code, even if the only such sharing occurs while the program is actually running” (Nadan, 2001, paragraph 9).

Ultimately, software companies have to make a choice. If they want anyone who uses their software to pay, then they should not use Open Source. If they want at least somebody to pay, perhaps for a commercially licensed, derivative work, then they can apply a license, like the MIT or X, that allows for that (Perens, 1999). Perens notes, however: “Most of the Open Source authors consider their programs to be contributions to the public good, and don’t care if they are paid at all” (1999, p. 185).

Selling OSS to Business

Just as Open Source wants to contribute to the public good—a goal it shares with the FSF—it also wants to put a flexible, more practical face on free software. Faced with losing the war for the hearts and minds of software users, the Open Source movement sacrifices the religious zeal of copyleft for a software certifying system that enables more software companies to license their work as Open Source—i.e., leaving the source code of their applications available and modifiable. In other words, OSI does not see itself in an antagonistic relationship with the software industry as FSF does. Rather, “commercial software … [is] an ally to help spread the use of Open Source licensing” (Nadan, 2002, paragraph 5).

To facilitate this relationship, OSI argues that business has much to gain from OSS. Business can, for example, outsource work to OSS developers, and thus save money on in-house development. Additionally, a small business, even one with little capital, can quickly become the next Linux by interesting OSS developers in a project it has begun (Nadan, 2002). Almost overnight, scores of developers around the world, connected via the Internet, could be working for free to make the project a reality.

Open Source, therefore, is about the “true believers” in free software trying to convince individuals in the naturally cautious and skeptical business world to be believers too. Why do they want business to buy into OSS? Because innovation, research and development of software, once found primarily at big universities, is now carried out primarily in business. If business adopts OSS, its popularity will not only increase, but its quality will improve as more dollars and developers will be dedicated to improving it.

The OSI website goes out of its way to sell business on OSS by providing case studies, the full text of approved OSI licenses, and even example business models that employ OSS solutions. At the heart of this effective enterprise are the same ideals early hackers created with their work and Stallman continues to forward. Even though Stallman would probably argue that these original hacker ideals have been diluted if not abandoned, in actuality they have been re-cast. Some of the zeal has been replaced with pragmatism, but only so that OSS can remain a viable force in a software industry where the necessity of putting profits before community has been a fact for some time.

Comparing OSS to Proprietary Software

Despite the inroads OSS has made in operating systems and Web servers, many individuals in business are still standoffish toward it. Others, having heard positive and negative stories about OSS, are curious about what it can really do in comparison to proprietary software. By first taking a look at the strengths and weaknesses of OSS compared to proprietary software, we can establish the knowledge base needed to determine those specific situations where implementing OSS is the right decision.

OSS Strengths

Free Access to Source Code. Organizations, especially those with skilled developers, can take advantage of free access to source code. OSS code is always available for modification, enabling developers to tinker with it to make it better for all users or just to meet their own needs or those of their organizations.

Costs. A number of countries struggling economically, such as Taiwan and Brazil, have adopted OSS to save money (Liu, 2003). Many businesses faced with decreasing IT operating budgets but increasing software maintenance and licensing fees have also made the move toward OSS. Although there are indirect costs incurred using OSS, such as staff salary and training, proprietary software has these same costs. The fact that OSS starts free is a big plus in its favor.

Rapid Release Rate. In the proprietary software model, software is never released until it is ready. If there are changes that need to be made after that, these are not made and deployed as soon as possible, but instead are held back until it can be sure that all the bugs are fixed. But OSS works differently. As Raymond points out, updates to OSS are “released early and often,” taking advantage of the large developer community working on the OSS to test, debug, and develop enhancements (1999, p. 39). All of this is done at the same time, and releases are sometimes done daily, not every six months, so the work is efficient and the improvement to the software is rapid.

Flexibility. Open access to the source code gives users flexibility because they can modify the software to meet their needs. The existence of OSS also gives users flexibility simply because they have a choice that might not have existed before. They do not have to use proprietary software if there is an OSS that works just as well. OSS provides further flexibility for those users that need to move to a new system. Rather than being stuck with “nonportable code and … forced to deal with whatever bugs” that come along with the software, they can use OSS that is “openly specified … [and] interchangeable” (Brase, 2003, paragraph 1).

Reliability. Because OSS is peer-reviewed and modifications are released quickly, any problems with the software are caught and corrected at a rate countless times faster than that offered by proprietary software. It is not an industry secret that Linux, for example, is much more reliable than Windows. Exposed to the prying eyes of literally thousands of developers, Linux and other OSSs are constantly being tested and tweaked to be made more crash proof. This tweaking also extends the life of the software, something which cannot be done with proprietary software unless users are willing to pay for upgrades. Many organizations have found themselves sitting on dated software and facing an expensive re-licensing fee to get the new version. OSS can be refitted by the organization if it is not already tweaked by the community of developers working on it. The software could be abandoned, and this has occurred before with OSS. But it has happened as well with proprietary software.

Developer Community. In the end, the developer community is the greatest strength of OSS and one that proprietary software companies cannot match. Not all developers working on any given OSS project actually write code. But literally thousands upon thousands working on larger projects test, debug, and provide constant feedback to maintain the quality of the OSS. They are not forced to do it. But they contribute because they are stimulated by the challenge and empowered by the opportunity to help build and improve software that provides users, including themselves, with a high-quality alternative to proprietary software.

OSS Weaknesses

Critics of OSS point out a number of deficiencies that make OSS too risky of a proposition to use in any sort of serious enterprise:

Loosely organized community of hobbyists. It is a very real possibility that an OSS project could lose its support base of developers, should they get bored, moving on to another project. Although many that work on OSS are paid programmers and IT professionals, they tend to work on OSS outside of normal business hours. Many in business feel that professional developers working for companies that care about the bottom line in a competitive software market will always produce better software. They will stick around to support it. And the company will put its name on the line and stand behind it.

In truth, the numbers of developers getting paid to work on OSS is increasing. Nearly one-third, in fact, are actually paid for their work. In 2001, IBM—now a strong supporter of OSS—had around 1,500 of its developers working on just one OSS application, Linux (Goth, 2001).

Forking Source Code. Source code is said to “fork” when another group of developers create a derivative version of the source code that is separate if not incompatible with the current road the source code’s development is following. The result is source code that takes a different “fork in the road.” Because anyone can access and modify OSS source code, forking has always been a danger that has been realized on occasions. The wide variety of operating systems that now exist based on the BSD operating system, such as FreeBSD, OpenBSD, and NetBSD, serves as one example (DiBona et al., 1999).

Raymond (1999) argues that it is a taboo of the Open Source culture to fork projects, and in only special circumstances does it happen. Linux has not really forked despite so many developers working on it. Carolyn Kenwood (2001) attributes this to its “accepted leadership structure, open membership, and long-term contribution potential” (p. xiv). The GPL license, which Linux uses, is also a major deterrent to forking because there is no financial incentive to break off since the forked code would have to be freely available under the terms of the license. Overall, however, forking is a legitimate potential weakness for OSS.

Lack of Technical Support. In CIO magazine’s 2002 survey of IT executives, “52 percent said a lack of vendor support was Open Source’s primary weakness” (Koch, 2003, p. 55). Very rarely is software ever installed without some kind of hitch. In smaller organizations the staff’s depth of knowledge may not go deep enough to insure that support for the software can be taken care of internally. And because so many of the systems and applications organizations run these days operate in hybrid environments where different tools run together on different platforms, technical support is crucial. Proprietary companies argue that Open Source cannot provide the technical support business expects and needs. There is no central help desk, no 1-800 number, no gold or silver levels of support that organizations can rely on for assistance.

Recognizing that OSS must mirror at least the traditional technical support structure of proprietary models to address this perceived weakness, a number of “major vendors such as Dell, HP, IBM, Oracle, and Sun” are beginning to support OSS (Koch, 2003, p. 55).

Lack of Suitable Business Applications. Literally hundreds if not thousands of OSS applications can be downloaded for free off the Internet from sites like the Open Source Directory (http://www. osdir.com) or SourceForge (http://www.source-forge.net). But a fair knock against OSS in the business world is that aside from Linux and a few others, most OSS lacks the quality, maturity, or popularity to make business want to switch from the proprietary products it currently uses. Some think this is because building a word processor just is not “sexy” enough for OSS developers (Moody, 1998).

Although it may be changing, the nature of OSS is that those projects developers choose to participate in are the ones that interest them, not necessarily those that others want done. If more companies begin to pay their developers to work on OSS, this may change. For now, however, OSS lacks the “killer app” for the desktop that matches Linux’s impact on operating systems or Apache’s on Web servers. OpenOffice, mentioned earlier, is an OSS alternative to Windows Office, but its user interface lacks the sophistication and ease-of-use of Office and so business has been slow to warm to it. Until it or another OSS desktop application comes along that can seriously challenge Windows’ lock on the desktop, those in decision-making positions will still not see OSS “as a legitimate alternative to proprietary software” (Goth, 2001, p. 105).

Evaluating the Practical Potential of Using OSS

In what situations is OSS a legitimate alternative? How should OSS be evaluated to determine whether it is the right fit for an organization? Carolyn Kenwood (2001) proposes that a taxonomy be applied to costs, benefits, and other intangible factors to determine whether OSS or proprietary software is the best option. Each taxonomy has a list of attributes. For example, a taxonomy of benefits looks at, among other things, the availability, scalability, flexibility, performance, quality of support, and security of OSS compared to proprietary software. Using a scale from very weak to very strong, the organization can rank the attributes by comparing each one’s “relative strength or weakness for OSS versus traditional COTS products” (Kenwood, 2001, p. xvii).

The specific organization affected by Kenwood’s study is the United States Army (2001). But in practice any organization could use Kenwood’s taxonomies to assist it in carrying out a more thorough and quantifiable analysis of the software options available for selection.

Huaiquing Wang and Chen Wang (2001) also outline a number of key technical and managerial requirements that should be considered when evaluating OSS:

Availability of technical support. According to Wang and Wang, “commercial grade technical support” must be available and reasonably affordable (p. 91).
Upgrades. The software should allow for upgrading so that it has an extended shelf-life and can be used by the organization long-term.
Customizable. The OSS “must be flexible enough to be customized or integrated in widely different technical environments” (p. 91).
Reliability. The best way to insure reliability is to use OSS that has been around for a few years and has a proven track record.
Budget. OSS developers tend to cost more than other developers. This cost and others, such as ongoing technical support and maintenance, whether done internally or contracted, need to be considered.
In-house expertise. If the organization does not have the staff to support the OSS, it needs to hire them. If it cannot do that, it should look at other software.
The long haul. The organization should choose OSS that fits into its long-term plans and that has a status that indicates it will continue to be around and supported by Open Source developers (Wang & Wang, 2001).

Beyond these technical requirements are other equally important elements that must be looked at carefully. Just because an OSS application seems better than a proprietary choice does not mean it should be implemented. For example, organizational culture is a tremendously important factor. Small but brutal internal wars have devastated the morale of organizations that made top-down decisions to switch personnel to a different word processor. Staff tend to be loyal even to their Internet browser and resist changing it (let alone upgrading it). Ultimately, the bottom-line need for new technology rarely affects people in understandable ways unless it reaches into their paycheck.

Managers also tend to be leery of pronounced change outside of their areas of control because they have been burned so many times before by new initiatives. At the highest executive levels, anything associated with IT that sounds too good to be true is often just that. CEOs have become shell-shocked after sitting in too many meetings where IT people speak gibberish they do not understand and then ask for six-figure or higher budgets to implement new technology.

It can never be assumed that technology at any level is easy to understand, even for those that work in the field. The widespread opinions on OSS, many based on rumor more than fact, offer proof of this. For an organization to consider the practical implementation of OSS, therefore, it must understand OSS. This is where the technical communicator comes in.

The technical communicator can play a key role in educating the organization at all levels. Explaining the benefits, the cost reductions, the overall positive impact of adopting OSS is a key effort that must be made before it is ever actually adopted and put into use. Organizations should consider informational sessions, phased roll-outs of the software, and even beta testing groups made up of staff that start working with the software, eventually passing back to their colleagues their opinion on the performance and quality of the OSS. IT staff would be well-served before ever reaching this stage to convince reluctant decision makers by setting up OSS on an offline computer for demonstration purposes.

Even with these efforts, the push to adopt OSS, although gaining ground in large organizations, is still a hard sell to small organizations and home users. Brent Thompson is a Microsoft Certified Systems Engineer (MCSE) with a decade of experience in IT. He has investigated OSS for the mid-size organization (roughly 100 employees) he administers systems for right now. He is not happy with Microsoft’s new licensing requirements, and he likes the robust performance of Linux. Still, he does not feel his organization is ready to go away from Microsoft.

The organization provides services, and it relies on Microsoft Word, PowerPoint, Excel, and Access to create, format, store, and present information to its clients. These same applications cannot run on Linux, and even though there may be alternative OSS applications that can, the organization’s staff is too accustomed at this point with the Microsoft products to move away from them. “I personally would like to see,” Thompson says, “another five years of software developed for Linux, so the same applications that we use today have also been written for Linux. I don’t feel the Open Source way is correct for us right now, but I do believe that it might be something to consider in the next 5 or 10 years” (personal communication, May 20, 2003).

Emerging and Future Technology Trends

OSS continues to grow in popularity around the world, increasingly offering a legitimate alternative to proprietary software. And the impact of the OSS movement is being felt even outside of the software community. According to Graham Lawton (2002), Open Source is “a political stand—one that values freedom of expression, mistrusts corporate power, and is uncomfortable with private ownership of knowledge” (p. 36). In other areas, therefore, the desire for the same openness that the Open Source movement has brought to software source code has been extended to other creative materials, such as publications and audio.

The Creative Commons (http://creativecommons.org) sponsors a number of licenses that allow authors and artists to share their work in a public forum while still retaining copyright of it. At present Creative Commons offers 11 licenses. Those organizations or individuals owning non-software, creative material can choose a license that prohibits or allows for their work to be modified or commercialized. Some licenses also allow the licensee to require that they receive some form of attribution should their work be used again or if a derivative version of it is created.

A number of organizations have used Creative Commons licenses to make their work openly accessible. The most prominent perhaps is MIT, which has made all of its course materials available through the Creative Commons Open Courseware License (http://ocw.mit.edu). Advocates are pushing that other educational institutions, especially those publicly funded, follow MIT’s lead and make their coursework free and open to everyone (Newmarch, 2001). But the enthusiasm motivating such advocacy for more open access to information is matched equally by advocacy calling for the increasing protection of what many consider private, intellectual property.

The one trend, then, that can be safely predicted about Open Source is that the battle it has helped begin in the software industry and that has now carried over to other fields is only beginning. Regardless of laws or PR campaigns created to counter it, Open Source is, Raymond writes, “future proof” (1999, p. 171). This is all the more reason for technical communicators to make themselves aware of Open Source.