Chapter 3

OPEN SOURCE SOFTWARE AS AN

ANALOGUE

The relationship between Brecht’s learning plays and computer software is not as contrived as it first appears. As shown in the two previous chapters, Brecht’s plays provided a renaissance in the field of German theater. He did away with many of the existing conventions of his time, while assimilating new theories into practice. He made theater less expensive so the common man could attend, he also used a sparse staging method with few props and he used his plays to teach both the audience and the actors. These theories included his use of V-Effekte[1] in theatrical productions along with new technologies that changed the face of stage productions throughout Germany.[2] Brecht, along with Erwin Piscator, utilized emerging technology and wove new elements into the context of his stories and plays.

The current open source movement of our day also makes use of the latest technological advances as well as the coding efforts of its developers. Like Brecht’s own theatrical efforts to revise the status quo of stage production in his day, open source software is working to revise the industry’s view of closed source software. The open source model dispels many long-held theories regarding the commercialization of software thanks largely to the growth of the Internet and the inter-connecting of computers worldwide. New business practices have taken shape along with the collaborative effort of computer programmers and mainstream developers.[3] However, as open source increases in popularity it runs the risk of becoming more popular with major businesses while also adopting many of the same practices opens source initially sought to dispel. As it tries to shake off the monopolistic practices of other software giants, a few open source businesses are homogenizing the available diverse open software and reducing the amount of available choices. The emergence of this new way of developing software in some ways resembles Brecht’s efforts in writing. Both argue against the mainstream practices of their business counterparts, while encouraging a revision of thought and freedom of expression previously unknown in their respective disciplines. This chapter examines how open source software has pioneered some novel techniques in thought and writing. Some of these similarities correspond directly to Brecht’s works.

Open Source’s Origins

Open source software promotes the free exchange of data among developers. Information is not held in proprietary escrow, but can be improved upon and distributed by all. The resulting effort can be viewed more as a coding achievement than as a business model due to the fact that all software code is a collection of written text that incorporates the nuances of each author’s code or writing style into a functioning application. It is not uncommon among coders to borrow and share excerpts of code with each other. As more original code is added to the wealth of open source programs, the selection of applications from which anyone can choose is also enriched.

Open source software’s emergence as a forerunner of computer development is a relatively recent event. Less than a quarter of a century old, it has emerged from a minor footnote in programming to become a major contributor to enterprise operations. Open source software whose code is freely accessible and distributable by all, can be found in nearly all aspects of computing: from servers that provide the hardware for large networks to the average user’s home desktop computer. Many companies that were formerly staunch proprietary advocates have adopted the philosophy that computer source code should be available to all. This extends down from larger corporations that embed Linux into their standard appliances to the publishing companies that produce hundreds of new technical manuals on open source applications every year. They support developers’ efforts to create a universally shared platform of code and to compensate their programmer’s innovations. Rather than jealously hoarding new advances they encourage the free distribution of code to their competitors. This breaks with the current analogy of Brecht’s works as they correspond to open source since Brecht jealously guarded his own works. Though he openly acknowledged early on in his career the contributions made by others and the works from which he borrowed text,[4] he considered the final version of his plays solely his own. This is unlike open source’s dilemma; namely can code that is freely available to all generate any financial return to the original investors without it also benefiting competitors?

Up until the last decade most software code produced by large corporations, whether it was financial software or the drivers controlling computer hardware, were kept under lock and key and never shared with outside interests. This included the computer code or the written set of instructions that ran the software or that made a specific company’s games or applications operate. The idea of sharing the source code with others was unthinkable. Things began to change in 1991.

It was during the early 1990s that a rift developed between hardware and software creation. Microsoft-DOS ran most personal computers. Purchased by Bill Gates from Tim Paterson of Seattle Computer Products for $50,000,[5] the former bare-bones operating system known as QDOS (or the “Quick and Dirty Operating System”) transformed into MS-DOS and enmeshed itself in every corner of the world. At the time most PC users had no other choice in operating systems.

The other dedicated camp of computing was the UNIX world, but UNIX software itself was far more expensive than even that of Apple Corporation’s software. In pursuit of high returns on investment, the UNIX vendors priced their software high enough to ensure that home and small office PC users stayed away from the over-inflated cost of UNIX software. The source code of UNIX was cautiously guarded and not published on the open market. Only the larger corporations were financially solvent enough to purchase the UNIX solution. Worse yet, those users with access to UNIX software found the cost too high to run the software on UNIX systems. Because these machines were so bulky and expensive operating time had to be scheduled in advance. Depending on seniority and the importance of the task, time slots could fall at any hour of the day. There was also a distinct lack of proper documentation for the available programs, many of which were arcane and poorly explained. Programmers familiar with the nuances of each program became prized commodities and were widely sought after. The entire computer industry was a behemoth of inefficiency.

What was needed was something with the stability and growth capability of UNIX, but with the functionality of MINIX.[6] MINIX was a rudimentary operating system that was rooted in UNIX, its proprietary counter-part. Linus Torvalds in 1991 combined available code with his own and dubbed it Linux, fashioned after his own name and that of UNIX and/or MINIX. He set into motion a new operating system[7] based on an existing concept. His early designs were functional, but they required more work than he could dedicate to its development, and so he did what seemed almost heretical in the minds of most programmers at the time; he gave away his work. He posted his rudimentary operating system on the Internet and allowed others to contribute to its future growth.

MINIX, the precursor to Linux, was based on the computer language C, as well as machine assembly language, an even more abstract programming code. A Dutch professor by the name of Andrew S. Tanenbaum, who wanted to teach his students the inner workings of an operating system, wrote MINIX from scratch using only 12,000 lines of code, a fraction of text compared to the behemoth UNIX operating system. Professor Tanenbaum dubbed his program MINIX in reference to the well-known operating system UNIX and the word mini.[8] The small processing footprint allowed it to be run on most any machine, including personal computers, without purchasing expensive software or cumbersome hardware. Professor Tanenbaum distributed the code freely in his classes, publishing the entire text in print and making it available on electronic bulletin boards. With the proper permission and licensing from Professor Tanenbaum anyone could do with it as he or she saw fit.

For the first time an aspiring programmer or hacker could read the operating system’s source code, which software vendors had previously guarded vigorously. Tanenbaum captivated the brightest minds of computer science with a lively discussion of the art of creating a working operating system. Students of computer science worldwide reviewed his work, examining the code to better comprehend the operating system they could then run on personal computers. This helped to further the cause of open source software.[9]

In 1991 Linus Benedict Torvalds, was a second-year student of computer science at the University of Helsinki and a self-taught hacker, a term Eric S. Raymond defines as “a person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary”.[10] The 21-year-old Finn enjoyed tinkering with computers and testing the limits to which a given computer system could be pushed. All that was lacking was an operating system that could meet the demands of the professionals. He considered MINIX a viable alternative for basic purposes, but it remained an educational operating system, designed for students and not for enterprise-level needs. MINIX was intended as a teaching tool rather than an industry-strength operating system.[11] Torvalds recognized the stability of UNIX and wanted to bring that same computing power to the desktop. He was frustrated by the limited commercial applications available for the PC and their instability. They crashed frequently and did not have the features touted by UNIX systems.

For lack of anything better, he borrowed what information he could from the original MINIX source code without overstepping copyright restrictions, which was still available for student use and instruction. On August 25, 1991 Linus Torvalds sent this historic post to the MINIX news group.

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)

Newsgroups: comp.os.minix

Subject: What would you like to see most in minix?

Summary: small poll for my new operating system

Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>

Date: 25 Aug 91 20:57:08 GMT

Organization: University of Helsinki

Hello everybody out there using minix

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). I've currently ported bash(1.08) and gcc(1.40),and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)

Linus (torvalds@kruuna.helsinki.fi)

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

Linus stayed away from the original MINIX code and wrote instead his own version of a UNIX-like operating system. He was mildly successful at first in compiling basic programs or converting them from plain text into a computer-readable format which then ran on his machine.

Soon the code went worldwide via ftp sites in Finland and elsewhere. To ensure that his work would not be commandeered by some commercial entity, Linux took the precaution of licensing his work under the GPL or General Public License.[12] This feature alone is partly responsible for the rise of Linux in popularity and use. Developers and programmers could re-use code published under the GPL and incorporate new code into the existing Linux kernel; optimizing patches for their applications. In all, this contributed to the stability and functionality that have become trademark signatures of Linux applications.

The Advent of GNU

Another decisive factor behind the success of Linux and open source software is credited to the GNU Project.[13] This organization is the principle force behind the promulgation of the GPL and advocates the dispersion of open source applications. Thanks to the GNU Project, a wide variety of free and open programs were available for use on the Linux operating system at the time of its conception. Supported mainly by the Free Software Foundation (FSF), the GNU Project was launched in 1984 to develop a complete UNIX-like operating system, composed of free software, better known as the GNU system.[14] Variants of the GNU operating system, such as the Linux kernel, are now widely used. Though these systems are often referred to as “Linux”, they are more accurately called “GNU/Linux” operating systems. Only code that is freely available to all can be licensed under these terms.

The purpose of the GNU Project is to encourage the free and open exchange of software code among developers and users. Their license or the GPL is not restrictive. Anyone can package GPL’ed source code and sell it to others. Individual applications or bundled GPL programs can be bought and sold without restriction. In fact, the GNU Project supports many of its developers and is funded partly by proceeds made off the sale of its software. This does not compromise its integrity or license. Users of such code still have a moral and legal obligation to make any and all changes available to the community. Having simply purchased the source code does not entitle them to restricted or proprietary re-distribution. This fact alone is what makes Linux so elusive in the minds of general software vendors. How can one compete with software that can be freely distributed and whose source is open to all, including any modification or improvements added to it by subsequent programmers? This practice undermines the entire “for-profit” software industry.

In the early 1990s programmers worldwide were inspired by the GNU Project as envisioned by founder Richard M. Stallman. Stallman was then and still is revered as a cult hero in the realm of computing. He started his career at the Artificial Intelligence Laboratory at MIT and during the mid and late seventies created the emacs editor, a versatile text editor now widely used throughout the world. Emacs is considered the standard of all open source GPL programs. In the early eighties, commercial software companies lured away many of the programmers of the MIT AI Laboratory. They were then locked into stringent nondisclosure agreements (NDAs) to protect the programming secrets of their respective employers.

Stallman, however, had a different vision. His idea was that unlike other products software should be free from restrictions against copying or modification. This would guarantee better and more efficient computer programs over time. With his famous 1983 manifesto that declared the beginnings of the GNU project[15], he initiated a movement to create and distribute software that conveyed this philosophy. To achieve this dream of ultimately creating a free and stable operating system all could use, he needed to create the tools or building blocks of an operating system first.

In 1984 Stallman started writing the GNU C Compiler (GCC), an open source tool that encodes plain text into binary code or into a format that is read, understood and executed by a computer. At the time, this was considered an amazing feat for an individual programmer. He outclassed entire groups of programmers from commercial software vendors in creating the GCC, still considered one of the most efficient compilers ever created. The GNU C Compiler is in use today and is perhaps the best benchmark by which programs are judged acceptable and in compliance with the GPL.

By 1991 the GNU project had created many of the tools that would subsequently be incorporated into the corpus of Linux. Before Linux emerged, there was still no operating system comparable to the GNU C Compiler. Even MINIX had to be licensed for use in any environment outside of the academic community. Work was proceeding on the GNU kernel HURD[16], but actual software was still slow in forthcoming, as was and still is typical of open source projects not under time schedules or constraints.

Current Developments

New advocates for Linux have sprung up all over the Internet. One of the most vocal of all Linux promoters is Eric S. Raymond, who has also contributed greatly to the establishment of Linux as a credible institution. He is also a frequent contributor to the body of open source software with his own applications. Raymond shares many of the same views as Stallman; however, his views are entrenched more in profitability and practicality. Although he, too, supports the idea that the code to all software should be available and easily modifiable, he still supports the idea of software generating some form of revenue. According to Raymond, rather than charging for the software itself, revenue is generated by selling technical support. Raymond put forth many of these ideas in his treatise, “The Cathedral and the Bazaar”, perhaps the most often cited and referred to work regarding open source software.

Raymond tested the theories of open source by developing a free and open software application called fetchmail. Fetchmail is a remote-mail retrieval and forwarding system. Raymond saw a need that required filling or as he later explained, “Every good work of software starts by scratching a developer's personal itch”.[17] He required a utility that would automatically download his email from any location in the world and then forward it to another location or store it for later perusal. This was no easy task, but one thing he had learned from using open source software was that it was not always necessary to reinvent the wheel; someone had most likely written something similar. Raymond theorized that an application already existed that accomplished that which he was attempting to do, and naturally there was.

As is often the case with open source software, there are many hobbyists who have written code to satisfy their particular needs. While Raymond was looking for a client or utility that could perform some of the tasks he wanted, he stumbled across a small mail utility called fetchpop written by Seung-Hong Oh. Raymond initially contributed to the development of this code, which the author was more than happy to accept into his code base. However, Raymond later found a more robust utility called popclient coded by Carl Harris. Though fetchpop was useful, it was still amateurishly coded and could only handle the POP3 protocol. The latter client was more robust and better structured. He decided to switch to the new utility, only to discover the author had lost interest. It was agreed that Raymond would take over future development. This passing of responsibility is an important step for any open source project and constitutes one of the most crucial aspects to any open source code of conduct.

Codes of Conduct

An unwritten agreement exists among developers in the open source community that has been in effect for over 20 years. This arrangement extends back to the pre-FSF (Free Software Foundation) era of open source software.[18] It is customary among Internet users to respect the ownership of other developer’s projects and to not take over someone else’s program and claim it as your own. Hackers have closely followed this and other rules even though they have never been verbally expressed or signed as a code of conduct. Indeed, most have followed them without ever being fully aware that they were doing so. Even more remarkable is that they have followed these norms of the programming community with astonishing consistency. The number of documented violations over the past 20 plus years and the culprits made publicly accountable can be numbered on one hand. There is an etiquette or “netiquette” for programmers to follow when either joining a coding project or starting a new project.

The unexpressed rules that open source community members follow are in keeping with the early Anglo-American common-law theory of land tenure, also known as the “Lockean” theory of land tenure or theory of property.[19] This historical analogy between early American Law and current open coding practices can be drawn in several ways. Basically, during the early settlement phase of the Americas land could be acquired in one of three different ways. First, in an area where there were no residents ownership was acquired by homesteading. This involved working the land, setting up a fence and defending the property from invaders. Second, when settling in an area where land had already been improved and boundaries defined, transfer of title granted ownership to an individual over the land in question. The deed of title was passed from one person to another. This “chain of title” in documented form can usually be traced back to when the land was originally settled. Third, common-law theory recognized that when land is abandoned or when the deed of title is lost and there is no clear proof of ownership (as is the case when an owner dies without heirs or when the records needed to establish chain of title to a piece of land is gone), a piece of land that has become derelict may be claimed by adverse possession – one moves in, improves it and defends it as if homesteading.[20] This is also known as squatting and is still practiced today. This happens in other genres as well. For example, book titles that have fallen out of publication and become part of the public domain are often picked up by another publisher and reintroduced again into the market. A republished work might be advertised as having new editorial comments or prefaces by experts or additional, rediscovered text or footnotes not included by the original author during its first printing.

Analogous practices have carried over into computer software and coding. When Eric Raymond was looking for a software application that would accomplish what he needed to do, he initially sought to homestead or begin a new project. As he understood the labor involved in such a task, he looked instead for existing code to which he could contribute, or an existing project on which he could squat and make his own. Eventually a “transfer of title” resulted in which Carl Harris passed ownership and responsibility for the popclient application over to Raymond. It was only later that Raymond rewrote the code base and became a new “homesteader”. He renamed the application “fetchmail” once the major body of code was his own original work and not something he had inherited. Gradually the project escalated. As feedback from existing and new users began trickling in, the focus changed and the application was shaped by the contributors. Recognizing the input from the users themselves is an important part to creating a successful open source project.

In a software culture that encourages the sharing of code and the free exchange of ideas, Raymond’s project itself evolved. He acted on another mainstay principle that formed the code of ethics for all open source advocates; “If you have the right attitude, interesting problems will find you”.[21] However, the attitude of the original programmer, in this case Carl Harris, was equally important. Another unwritten rule of the community states, “When you lose interest in a program, your last duty to it is to hand it off to a competent successor”.[22] This rite of succession was accomplished without argument. Without discussion, Carl Harris and Eric Raymond agreed that the common goal was more important than personal ego.

Analogues between Play and Code

There is a profound similarity between the development of open source software and Brecht’s plays, specifically, the willingness of software users or readers of the works to provide feedback to the authors. This very tenet provided Brecht as well as numerous programmers of code with assistance in perfecting their products. Software coders or authors of theatrical productions should give heed to the voice of the community and either accept or reject solicited feedback. Brecht recognized the importance of peer input and in many of his productions the contributions he requested from collaborators and those with whom he came in contact went back into the work in question. As was shown in chapter 2, Brecht was willing to change a performance’s outcome. The students of the Karl-Marx-Schule in Berlin-Neuköln opposed the fatalistic ending of Brecht’s Der Jasager. Their input was the basis for Brecht to reformulate the play as Der Neinsager.[23] Brecht stipulated that both plays be performed together so that the audience may also decide for themselves which would be the more appropriate outcome, though this recommendation is seldom followed in actual practice.

Just as Brecht used his written works as a form of social protest, many open source programmers use their coding as a platform for dissension. Like Brecht, programmers provide written expression or voice their protest in a deliberate manner. One of the more understated methods is through the use of comments in the code itself. Comments are normally notes or explanations about the more obtuse computer code. They are not read by the computer since they are usually ignored when preceded by a hash mark (#) or a semi-colon (;). These comments allow the author to explain why he or she wrote the code the way he or she did, or to make suggestions to later revisionists as to how the code may be improved or altered. But more frequently it is a sounding board for coders to make disparaging remarks about others’ works or to insert snide observations about the application in general. Because their code is often borrowed from existing applications, programmers often insert comments explaining from whence the original code came or who the previous author was. Keeping comments intact is another of the unwritten rules strictly adhered to by open source coders. Comments within programs also function as a warning or as a guide to later developers in terms of what should be avoided or what might prove useful at some later date. These are generally not meant for regular users to see. After source code is compiled all plain text is rendered unintelligible.

Programmers are also notorious for actively protesting what they see as corporate sponsorship or meddling in open source affairs. When the Recording Industry Association of America (RIAA) began encrypting video formats on media such as DVDs and compact disks using what were termed a Content Scrambling System or CSS, many open source advocates protested as their programs were no longer able to view or decrypt these video files. The encrypted disks were only readable through a proprietary decoder licensed to other proprietary operating systems. Open source programs were excluded.

In an effort to un-encode these formats for users of open operating systems, such as Linux and FreeBSD, the open source community fought back with its own DeCSS or CSS Decryption Algorithm. This algorithm was immediately classified as illegal and any copy found on the Internet for download or in a publishable format was forcibly removed. However, a slew of sites and advocates erupted in protest with entrepreneurs publishing the code in its entirety in a variety of formats. Anyone can now download and compile, read, listen to, view as a graphic image or even wear the code on an article of clothing in its entirety.[24] To force a recall of the code in all its new formats is now impossible. The community banded together and staged their own civil disobedience. Just as Brecht used his works to break down prevailing elements of his time, Linux is disbanding common business and formal coding practices. The concept of laying bare computer source code goes against the standard practices of the past half century. However, what has developed so far portends great advances in the future of open source programming.

Tending to the Users

Just as Eric Raymond inherited the source code for the popclient utility, so too did he inherit the popclient user base and became steward to all who used his application. This meant that all users who had accepted popclient onto their systems under Carl Harris now became Raymond’s responsibility. Users looked to him for improvements and entrusted him with their suggestions and patches. When treated responsibly, the user base of any application can be turned into a co-developing body of authors. One of the traits of the UNIX and open source communities is that many of the users are also hackers, or programmers themselves, who engage in some form of coding. When properly encouraged, these users can diagnose bugs or problems in the code, create documentation or instructions on how to install, configure and run the application, suggest corrections and improvements and work to assist the developer’s efforts far quicker than a single person could.

In the open source community the complex code base of an operating system is under constant development by thousands of contributors throughout the world. Though they may be disparate in location, they are united in purpose and objective. This attitude follows another precept of community development; “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging”.[25] Raymond’s motto regarding code revisions is as follows: “Release early. Release often. And listen to your customers”.[26] In other words, all writers and developers should “recognize good design ideas from others”.[27] This is done for a variety of reasons; first, by acknowledging the contributions of others, particularly those collaborators, you appease and increase your base of development. Those same users are more apt to resubmit bug reports, clean up code and offer feedback during beta-testing periods. Also, by incorporating design ideas back into the corpus of code, the project is steered by the users themselves and not by some authoritarian developer whom users soon grow to despise. The open source community actively solicits input from users and contributors. They then interweave the input back into their programs, whether it is code or material for a play. Neither indiscriminately accepts poorly worded suggestions, but each is judicious in his or her selection process.

Another feature of code developers, who solicit feedback from their users, is that they are very self-deprecating in their attitude. Eric Raymond shares another fact important for a successful implementation of open source from the perspective of the software author; “The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.”[28] He stresses that if a software developer is completely and self-deprecatingly truthful about how much he or she owes their success to other people, the world at large treats him or her every bit as well as the invention itself.[29]

This is a key element to Linus Torvald’s success; he is extremely modest about his innate genius. This method of self-deprecation also permits other developers to easily dismiss the author’s mistakes. The open source community normally wants to be acknowledged for the part it plays in a project’s development - for Brecht this community may have consisted of actors and other collaborators who wished to be part of his accomplishments. Brecht realized this fact and though he gained a modest amount of wealth due to the success of his literature, he was known for portraying himself in bohemian fashion in an effort to identify with the common working man.

Brecht’s shabby dress and personal habits gave others the false impression that he was trying to cultivate a “proletarian” look in order to identify with the working class. Dirty fingernails, an unwashed body, an ill-shaven face, teeth that have been described as “little tombstones sticking out of a black mouth,” an ever-present cigar, baggy trousers, and a high-collared flannel or denim jacket...[30]

No worker in Germany dressed that way and Brecht knew it. He used his personal appearance as a way of announcing his anti-middle-class stance and his insistence in appearing as proletarian as possible. Though this may not have been a true self-deprecation as Linux Torvalds and others practice, Brecht had an image he wanted to portray to the community in which he felt he belonged.

Linus Torvalds, unlike his counterpart in the proprietary software industry, namely Microsoft, is no billionaire. He pokes fun at himself and readily acknowledges his foibles when it comes to coding. In fact, after his much-touted 2.2 Linux kernel was released early in 1999, and a very blatant bug was discovered, Linus publicly apologized and coined the new phrase, “the brown-paper-bag bug”, meaning it was so embarrassing that “the author must notionally wear a brown paper bag over his head so he would not be recognized on the Internet”.[31] For a highly visible author or coder, incurring the wrath of one’s developers or adherents would mean more than a fall from grace, it would mean a drying up of the source of feedback, help, development and, most importantly, clientele.

Perhaps a greater similarity between Brecht’s writings and the popularization of open source is its spread throughout the developing world. In the days before Linux, developing countries were much behind in the field of computing. Though hardware costs fell over time, software costs remained a burden to the cash-strapped computer enthusiasts of Third World countries. In desperation, people resorted to pirating software products amounting to billions of dollars. Linux and other related open source products have had a major impact for the better. Since open source applications can be scaled to run in almost any computer with limited hardware resources, they are suitable alternatives for low-budget computer users. Ancient 486/Pentium1 computers that have become a part of history in the developed world are still used in emerging countries. The use of open source software has also proliferated. In the countries of Asia, Africa and Latin America, Linux has appeared as a means of production for local computer enthusiasts.

In much the same way that Linux has appealed to the masses in developing countries, Brechtian theater has also gained enthusiastic supporters around the world. There have been many successful productions of Brecht’s plays in areas such as China and Japan, the Philippines, India, Pakistan, and Africa. The 1989 issue of the Brecht Jahrbuch details the realization and reception of several Brecht plays throughout many developing countries.[32] The portrayal of the struggling worker and his rise above his or her social class is appealing to the average theatergoer of the Brecht plays. In many cases his plays are now better received in the Third World nations than they were when originally performed in Germany. In the countries of Africa where Brecht plays are staged, many have adopted Brecht as one of their own. They easily identify their own toils with the labors shown on stage. Brecht’s plays enjoy popularity unparalleled by many other Western playwrights.

As the insurgence against other Western imports grows in developing countries, including over-priced software, and as the disparity in economic conditions between industrialized societies and developing nations grows, the Third World countries look for answers in alternative solutions. The adoption of an antiquated operating system such as UNIX in the form of Linux has given the people in these countries something with which they can identify and can help them move forward with a common resolve. Chapter six of this dissertation more closely addresses Brecht’s rise in popularity among the developing nations and ties that growth in with the growth of open source in these same regions.

In summary, the open source movement has empowered developers and programmers. Much like literature, these computer applications can be classified as communal works whose purpose it is to assist and enlighten. Some code is meant to be instructional as shown in the early releases of software, such as MINIX, which in turn gave rise to Linux and has now spawned an even greater following of advocates. These students can now use the freely available code base as a platform for learning even more regarding computer programming or in developing original works. Even the compiler, which under other operating systems is prohibitively expensive, is now a commodity under Linux and comes installed by default with every release. In short, open source software as well as Brecht’s plays are seeing a marked increase in popularity worldwide. Both encourage and motivate their audience, whether they are theatergoers or users of computer code, to learn and become more actively involved in their respective fields.