Abstract

The paper begins with the story of EMACS (short for Editing MACroS), an editor programme originally written for TECO (Text Editor and Corrector) language and PDP-10 machines in the MIT AI Lab by Richard Stallman, from which various more sophisticated versions have been developed. I analyse how the innovation of EMACS took place over time as a socio-technical process. The EMACS story serves to illustrate how the innovation process in the FLOSS (Free/Libre Open Source Software) community occurred, but one that is then adopted and deployed in other social contexts, including the commercial sector. The analysis of EMACS is especially useful since it spans the period that saw the origins of the free software movement and the subsequent development of a broader FLOSS social world. I will talk about how a variety of EMACSen (the plural form of EMACS) (e.g. GNU Emacs, XEmacs, MulticsEmacs etc.) are created, developed and employed/deployed in mundane programming within an actor-centred network. Actors from different backgrounds contribute multiple ways of knowing, understanding and resolving problems that arise in the innovation process. A socio-technical perspective is employed to analyse how EMACSen are shaped by diverse actors, and at the same time also shape these actors and their practices.

To widen the scope of the paper in terms of its implication in a wider societal dimension, anchored in sociology of intellectual/knowledge, this paper also contributes to our understanding of the formation of knowledge in the Internet era, where information and knowledge flow fluidly and rapidly. The EMACS case denotes various key factors of forming cosmopolitan knowledge: how actors network together (e.g. shared interests), how they interact with one another (e.g. problem-solving process), and how local epistemologies and tacit knowledge being translated into cosmopolitan expertise in an in/tangible form (e.g. materiality of hardware or software). I believe this empirical enquiry will provide us with a means of retaining the holistic and meaningful characteristics of real-life events. Methodologically speaking, the contextual thickness makes a case study appropriate for "how" and "why" research questions because answering these questions deals with operational links needing to be traced over time. The detailed investigation of FLOSS phenomenon with attention to its context by using multiple sources of evidence and various methods of data collection will help to examine the innovation process by which new FLOSS technologies are created, arguing that this is ongoing and involves diverse groups who give the technology different meanings. This perspective also reflects an ongoing thinking in science and technology studies (STS) that technologies, no matter their designs, uses or applications, are not independent from social factors. Given the history of EMACS, one can see how the hacker ethics are emerged, developed, and followed in the innovation process. Based on the hacker ethics, EMACS, or a wide range of FLOSS, are not only a technological revolution, but also a social movement that operates largely in terms of symbol and meaning, both at the level of everyday life and at that of institutional operation.

Acknowledgement: My heartfelt thanks go to Professor Andrew Webster for his insightful comments on and assiduous proof-reading of the first version of this paper. Much appreciation also goes to the friends in the Debian community and the audience at the Oekonux 3.0 conference for their constructive suggestions and encouragements.

Introduction

EMACS (Background Information)

In 1976 Richard Stallman, an employee at MIT AI Lab, and his colleagues, wrote the editor EMACS to upgrade the previous editor TECO on an ITS (Incompatible Time-Sharing System), which was the software running on the AI Lab’s Digital PDP-10 mini-computer. In the text-based pre-graphical world that existed before the Apple Macintosh and Microsoft Windows, the editor was a programme crucially important for creating and manipulating text (Moody 2001: 16). Instead of typing commands when editing texts, the TECO editor enabled users to employ macros, command strings for a cluster of TECO programmes, which provided a more immediate onscreen feedback for users. TECO had already had the 'WYSIWYG' (What You See Is What You Get) feature named Control-R, written by Carl Mikkelson, which allowed users to enter macros (command strings) and discarded them after entering them. Borrowing the idea from another WYSIWYG editor named E, Stallman then brought additional functionality to TECO to make it possible to save macro shortcuts on file and call them up at will. It is said that this improvement was subtle but significant in that this raised TECO to the level of a user-programmable WYSIWYG editor, which later on enabled innovation at another meta level that became the progenitor of FLOSS (Williams 2002: 82). The amended macro function in TECO permitted users to redefine their own screen-editor commands, pass them around and improve them, make them more powerful and more general, and then the collections of user-redefinitions gradually became system programmes in their own right (ibid.). In so doing, users extended the original TECO system by adding or replacing functions based on their self-defined definitions of 'the problem’. Users were not, then, limited by the decisions made or problem-solving approaches taken by the original innovators (Stallman 1998: 2). The extensibility made TECO more flexible for use and in turn attracted a larger number of users to incorporate the macro function into their TECO programmes.

However, a new problem emerged along with this new feature. While the new full-screen capabilities were embraced vigorously, various customised visions of TECO also led to over-complexity. The most obvious example was that one had to spend more time than before figuring out what macro commands did what in terms of an individual’s self-definition of 'the problem’ when improving each other’s work. Guy Steele, a colleague of Stallman’s at the AI Lab, recognised this problem and sought to address it. He firstly gathered together four different macro packages and began assembling a chart that he believed identified and organised the most useful macro commands (Williams 2002: 83). In the course of implementing the design specified by the chart, Steele’s work attracted Stallman’s attention and led to the latter’s participation in this renovation project. Together with David Moon and Dan Weinreib, the four tried on the one hand, to develop a standard system of macro commands, and on the other hand, to still keep the command set open-ended to enable ongoing programmability/extensibility by others. The programme was named EMACS.

The distribution of EMACS marked another milestone in the software history. In response to the prevalence and technical opacity associated with the practice of entirely self-defined commands, and to endorse the hacker tenet of sharing information, Stallman set the terms of on which EMACS could be used in the statement linked to the source code when distributing the editor. EMACS, as noted in Stallman’s biography, served as a social contract that rendered communal sharing the basis of its distribution. Users, on the one hand, were able to modify and redistribute the code; on the other hand, they were asked to report back the extensions they might have made to Stallman so that he could incorporate and distribute those again. In so doing, Stallman strengthened the functionality of EMACS, making programming with macros more standardised through creating a reciprocal understanding of the written codes through sharing problem solutions, as well keeping the extensibility that macros afforded. Consequently, a library was created for users to load new or redefined functions and to publish and share their extensions. By this route, many people can contribute to the development of the system, for the most part without interfering with each other. This has led the EMACS system to become more powerful than any previous editor. (Stallman 1998: 2). Since then, an archetype of EMACS had been established.

Affordance and EMACS: Extensibility and Customisation

The earlier generation of EMACS had been successful because it provided flexible use with an embedded programming language, TECO. Because of this feature, editing commands could be written in that programming language and users could load new commands into her/his editor while s/he was editing. EMACS resembled a system that was useful for things other than programming, and yet one could program it while s/he was using it. It was claimed to be the first editor that could operate in this way (Stallman 2002: 1). Consequently, the socio-technical networks of EMACSen have been expanded. GNU Emacs for example, is now available for Unix, VMS, GNU/Linux, FreeBSD, NetBSD, OpenBSD, MS Windows, MS-DOS, and other systems. GNU Emacs has been re-configured more than 30 times as part of other systems. Other variants include GOSMACS, CCA Emacs, UniPress Emacs, Montgomery Emacs, and XEmacs. Jove, Epsilon, and MicroEmacs are limited look-alikes. These systems on the other hand also have requirements, needs, and visions that differ from the original GNU Emacs. This phenomenon widens the range of what we might see as 'digital epistemologies’ (ways of ordering and knowing software) and their expression through software artefacts in the FLOSS social world.

Problems and solutions: the sine qua non of innovation

In light of the EMACS account above, problems play a crucial role in the innovation process. Triggering a problem or perceiving a problem and dealing with it are important tasks for scientists and engineers, and through their resolution help generate innovation. A problem thus can be seen as the inauguration of an innovation. The confronting of a problem provides an opportunity of coming up with something new or different. A problem de facto denotes one’s perception of the situation, one’s knowledge, and skills. Accordingly a problem signifies one’s identity as an expert or a novice, for example.

Efficiency was an important parameter in the process of defining software problems. A problem would not exist if users did not recognise the existing practice (e.g. composing code with printing terminal editors in the 70s) as inefficient. As efficiency is regarded as key within the field of engineering; engineers were and are still taught to design efficient technologies. Efficiency is not however, self-evident: Stallman reports that he did not have a strong sense of the need for a real-time display editor until he encountered the 'E’ programme when he visited the Stanford Artificial Intelligence Lab in 1976. He was inspired by the function E afforded and sought to expand TECO’s functionality in the same way and helped form the group that was to work on a real-time display system. Meanwhile, there were other parallel groups providing solutions for real-time display systems, and their work could become complementary to the work that Stallman’s group were undertaking. Stallman’s macros improvement to TECO enhanced Mikkelson’s earlier WYSIWYG feature for TECO. As a result, with this greater affordance and functionality, TECO became more popular. The TECO socio-technical network expanded when more people accepted the macro innovations and incorporated them into their own versions of the TECO programme.

It is worth noting that Stallman did not sit down and write the editor system programme immediately after his encounter with E. Instead, he looked up the database and found that Mikkelson had made a WYSIWYG feature for TECO. He then integrated his idea into that. If Mikkelson’s work had not existed, we may have seen a different technical option taken, as the 'problem’ may have been defined differently. This points to the contingency of the innovation process. This process is reflected in many FLOSS developers’ own reflections on their systems as seen in Stallman’s and Torvald’s biographies (e.g. Torvald said he probably would not have started the Linux kernel project if the GNU Hurd had already existed; Stallman said he would not have started to write the GCC compiler if Tanenbaum had agreed to share his work). Hence, looking for existing material and tools is another common practice in solving problems in software innovation. Software engineering, as in other fields, is built on existing technologies. Programmers typically explore existing databases and see whether any tool is available; if not, they are likely to try to create one to solve the problem.

Access to problems is another issue that needs to be discussed in light of the data from my fieldwork. The accessibility of problems measures the relative ease with which problems can be understood. If one problem entails an opportunity for innovation, an active innovation field should welcome more problems. In a less open innovation system, problems are less accessible, and the boundary is relatively impermeable to new entrants and new ways through which the system can be enhanced. In such an innovation system, problems are less likely to be seen to appear, innovation options likely to be more pre-defined, and innovators sharing a consensus on 'what needs to be done’. On the contrary, I want to argue that in a heterogeneous field where diverse actors are found, more problems arise or are triggered. If the boundary of the social group centring on the problem is soft, more diverse actors will be included in the circle. There is a positive correlation between the elasticity of the boundary of an innovation field and the momentum behind the pace of innovation because the more accessible the problem is, the higher the level of multivocality existing in the innovation system.

The elasticity of the boundary can be manipulated through a range of educational, legal, political, economic, social and technical means. In the 1970s, software problems were more accessible in the sense that fewer regulations were applied to restrict programmers to access key materials (codes peculiarly). There was a so-called 'collaborative hacker’ approach, sharing knowledge and improving each other’s work, that encouraged programmers to continually to redefine the boundaries of the problem (e.g. conducting reverse engineering to deconstruct a software to understand how a code was written). As a result, a wide range of software programming tools (languages, editors, compilers etc.) was created in the 1970s (Ceruzzi, 2003).

However, the generation of too many problems may become counterproductive to innovation. The ability to solve problems is key to innovation. The more a problem is accessible, as noted above, the more diverse actors will be invited to participate in the innovation group centring on the problem. As there is no single perfect solution for a problem, multiple voices and silences should always be welcome (Bowker & Star, 1999: 41). If a problem is presented in an intelligible/perceivable/accessible way, it will encourage more participants to craft solutions (though there may be nothing wrong with asking a 'dumb’ question, as the dumbest question can sometimes produce the best answers). As noted by a number of commentaries, well-defined problems in which the given information, operations, and goal are clearly specified will more likely to have solutions than ill-defined problems (Glass et al., 1979; Borgman, 2003). Furthermore, such sources argue that an expert can articulate the queries more specifically and completely than could someone new to the domain. This ability to articulate problems becomes one of the parameters that defines expertise, which will be discussed later in this paper.

As I noted above, while Stallman’s innovation was celebrated because of its extensibility and flexibility, it did however create new problems. One that many saw was the sense of a growing confusion derived from the plethora of self-defined macro commands, which was seen to eventually work against a more efficient process of programming. In response, another member of the AI group, Steele, tried to provide a solution by charting the macros. Steele’s solution encouraged Stallman, Moon and Weinreib to participate in a solution-crafting innovation group. These four who shared the same interest in this project formed a social network of expertise and began to fashion the digital tools that would be seen to provide the solution they were looking for: in this sense the path they took and tools they developed reflected a shared conceptual frame that was 'not accidental, but constitutive.’ (Clarke, 1998; Bowker & Star, 1999: 36). What made the process more intriguing is the relationships and interactions between the actors themselves and the actants (materials), and the transitions - the boundary crossings - that a problem so identified enabled. Boundary crossings can require both getting in (e.g. gaining access to the problems) and getting out (e.g. forging an alternative solutions different from the original one). These boundaries are interpreted or constructed through the problem-solving process of software design. In the process, actors move across boundaries and shift their identities as outsiders or insiders to the core innovation group.

Shared interests and translation of interests

As seen in the story of EMACS, engaging actors in a network is the key to effective innovation in that the range of expertise in the network will affect a group's abilities to solve problems. Since everyone is an expert with regard to some things and a novice with regard to others, a problem/question in an open environment will be answered sooner or later. It is worth noting, however, actors' involvement in a network is not randomly assembled, but determined by shared interests. As Latour articulates,

The first and easiest way to find people who will immediately believe the statement, invest in the project, or buy the prototype is to tailor the object in such a way that it caters to these people’s explicit interests. As the name 'inter-esse’ indicates, 'interests’ are what lie in between actors and their goals, thus creating a tension that will make actors select only what, in their own eyes, helps them reach these goals amongst many possibilities. (Latour 1987: 108-9).

After Stallman left the MIT AI Lab and planned to write an Unix-like operating system for non-commercial distribution, a range of ICTs facilitated his individual action. Stallman's GNU project, as if many other FLOSS projects, precisely took advantage of ICTs to target peers to join his innovation network. These artefacts enabled him to maintain communication with other programmers and even helped to secure some innovation resources when he worked alone. On 27 September 1983, Stallman posted the message below onto the Usenet newsgroup net.unix-wizards in order to invite people who shared the same interest or parallel knowledge to join the discussion. Stallman posted the following message:

Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for GNU’s Not Unix), and give it away free to everyone who can use it. Contributions of time, money, programs and equipment are greatly needed. (Williams 2002: 89)

In this message, Stallman revealed his defined problem and the proposition for possible solutions - a complete Unix-compatible software system. Because he had lost institutional support (financial and intellectual) from the MIT AI Lab, he was more likely to find peers interested in joining the social network of developing a new operating system and to engage their attention by posting messages onto the Unix newsgroup, where specific users/programmers share the same interest inhabit. Without knowing who was going to get in touch with, the message posted entailed uncertainty and risk in Stallman’s project. While Stallman posted this message, he created a social network of crafting a new operating system. If Stallman was able to invite many programmers to join this project, the network would grow and the project would take off. Here, making decisions of which listserv or newsgroup a message should be posted to in order to attract as many actors as possible is another form of classification shaping the innovation process. Stallman reckoned the Unix group was the one where he would be most likely to find his target peers. This tendency of looking for peers who share the same interests echoes my previous argument that a shared interest among peers is crucial for the continuation of collaboration. The common interests engage actors to work together, share knowledge and exchange information. The teamwork gets more complex with higher peer participations. If the management style stays in a democratic/open way, the boundary of the team will remain soft. This type of innovation is more accessible because open debate within the team is more likely to produce multiple topics to attract actors. Here, the construction of a shared interest or a common topic is resonant with Latour’s notion of inter-essant (1987), through which actors are enrolled to mobilise innovation networks. The working environment at MIT AI Lab in the 70s was similar to this way. Most of the FLOSS projects that rely on virtual collaboration also meet the criteria of Latourian inter-esse/sant. In contrast, a closed or centralised direction of a project would reinforce innovation boundaries and restrict accessibility to the innovation process. In so doing, a project can be kept under control to eliminate risks and uncertainties generated by multivocality. Following this route, a project will approach closure eventually. Proprietary software is mostly managed in this way.

EMACS as a Boundary Object

Hitherto, I have investigated how a software innovation network is created and developed in terms of classifications of problems, identifications of solutions and common interests. Actors and actants are brought together, interact and negotiate with each other to solve problems. Boundaries of networks, which determine access to innovation systems, vary in different contexts. A successful innovation, as discussed, is the one that manages to bring in as many actors and actants as possible by translating their interests to extend and mobilise the network as well as handles the uncertainties and risks emerging during the process.

In reviewing the innovation story of EMACS, a variety of EMACSen have been innovated/renovated by diverse actors for different purposes. The functions of EMACS have been expanded and are still expanding. In other words, the affordance of EMACS is sustained. While diverse innovation repertoires are brought into the social network to tackle a joint problem, they also complicate the situation by defining and redefining EMACS’ innovation concept over and over again. If different definitions of innovation concepts cannot be reconciled, a project diverges, as the development of many versions of EMACS show. The reasons for the divergences vary in social scope (e.g. disagreement on Stallman’s social contract), technical/material scope (e.g. original EMACS did not run on other programming language than TECO, so new version of EMACS was designed for other programming language such as Lisp, such as EINE and ZWEI, developed by Weinreb, a fellow colleague working on the original version of EMACS as well), or other contingent factors (e.g. experimental projects-- just for fun, perhaps). These parallel processes demonstrate the dynamic in the innovation network of EMACS. Facing the challenge of the heterogeneity, authors and maintainers of EMACSen try to enhance their legitimacy and uniqueness in providing greater socio-technical functions.

In this account, EMACS, as an extensible editor that can be used flexibly, has served as a boundary object for diverse users. They interpret the role of EMACS in different ways according to their situated practices. A number of common practices of EMACS can be summarised. Some take EMACS as a pure tool for editing texts, programming, gaming, web browsing. Others contribute to the FLOSS community by reporting bugs of EMACS while using it, and still the others residing in the core of EMACS innovation system take EMACS as an artefact or even art work. Because EMACS denotes so many different meanings, the diverse interpretations and manipulations of EMACS can prevent it becoming a stereotyped editor, even though its material effects (as affordances) do give it a specific technical character. This is in contrast to other proprietary software products. For example, Microsoft Office Word software has enrolled a huge number of users for processing their Word documents. When mentioning 'Word' people take Microsoft Office Word for granted. Accordingly, Microsoft Office Word is used not more than for typing and word processing. But for EMACS, its high affordance enables many roles to be played in mundane computing practices. Once EMACS is mentioned, people would like to know which version of EMACS is indicated (e.g. GNU Emacs, XEmacs - each indicates different usage habits, particular interests in programming languages, or even political views), and for what purpose it is used. The potentiality of EMACS for different functions is resilient. Unlike Microsoft Office Word, the open trait of EMACS gives users more space to and customise their own versions which meets individual requirements.

Since EMACSen are used in many different ways and denotes various socio-cultural meanings, diverse projects have symbolised users’ habits and preferences (socially and technically). In adopting specific tools and participating in specific projects, users are attached to the artefacts. These artefacts grow to be norms to demarcate boundaries. For example, the users of GNU Emacs see themselves different from those of XEmacs, while the broad range of users of Emacs distinguish themselves from other users of other editor programmes, such as vi. Holy wars happen often because these users want to fortify their boundaries against each other to show their identities. Accordingly, software programmes containing symbolic contents should be seen not merely as algorithm codes but also as social codes. It would be interesting to see how these projects are symbolised as norms, how they are interpreted and used. That is, in the course of explaining the heterogeneous FLOSS social world, one can study the socio-technical meanings given to various projects to understand 'FLOSS'. This actor-centred view may provide a distinctive research result from the prevailing structure-centred or essentialist approaches in the FLOSS studies.

Life in EMACS will continue to change, but the crucial presumption will be whether the boundary of the innovation network can be maintained to sustain the innovation. For instance, Gosling did not continue to share his codes, rather, he sold his EMACS version to a commercial company. His version of EMACS therefore did not continue to grow. This is not to say that selling software to a commercial company will kill the product. There are other reasons for the elimination of a software product and sometimes the involvement of commercial companies does provide other sources for sustaining or developing a product. But in the case of Gosling Emacs:

He thought selling the product to a firm might broaden the network. But the transaction symbolised Gosling's failure to continue the network expansion.
The commercial product was not successful. The firm failed to engage actors' interest in it.

The commercialised software forms a firmer boundary than FLOSS community projects to exclude outsiders of the developing team from the innovation. In that case, problems will not be triggered that easily. If problems are the initiatives of innovation, a less diverse character in the team will not help the innovation at that point. When GNU Emacs was just invented and still in an unstable stage, it did not put users off, instead, the existing problems invited peers to tackle them. GNU Emacs was able to engage actors in its social network of innovation. The network expanded and a variety of functions were developed. These functions become cornerstones to attract more actors/users as if a snowball effect. Unlike some proprietary software firms try to lock users in by using proprietry document formats (and critics say they do this in order to dominate the market), EMACSen engage users by presenting greater shared interests in socio-cultural or technical aspects. The story of EMACS sheds some light on the FLOSS innovation, albeit the commercial impetus should be taken into account in order to understand the situation completely.

Reference

Borgman, C. L. (2003) 'Designing Digital Libraries for Usability’. In Ann Peterson Bishop, Nancy A. Van House, and Barbara P. Buttenfield. The MIT press.
Bowker G. C. & Star, S. L. (1999) Sorting Things Out: Classification and its Consequences. London: The MIT Press.
Ceruzzi, P. (2003) A History of Modern Computing. 2nd edition. The MIT press.
Debian Documentation Team. (2003) A Brief history of Debian. URL (consulted 27 November 2003): http://www.debian.org/doc/manuals/project-history/project-history.en.txt
Glass, A. L., K. J. Holyoak, and J. L. Santa. (1979) Cognition. Reading, MA: Addison-Wesley.
Latour, B. (1987) Science in action: How to follow scientists and engineers through society. Cambridge, MA: Harvard University Press.
Lave, J. (1988) Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life. Cambridge: Cambridge University Press.
Liff, S. and Steward, F. (2003) Shaping e-access in the cybercafe: networks, boundaries and heterotopian innovation. New Media & Society, vol 5(3): 313-334.
Miller, D. & Slater, D. (2000) The Internet: An Ethnographic Approach. Oxford: Berg.
Miller, D. (1987) Material Culture and Mass Consumption. Oxford: Blackwell.
Moody, G. (2002) Rebel Code: Linux and the Open Source Revolution. London: Penguin Books.
Reitman, W. (1964) Heuristic Decision Procedures, Open Constraints, and the Structure of Ill-Defined Problems. In M. W. Shelley and G. L. Bryan, (eds.), Human Judgment and Optimality. New York: Wiley.
Simon, H. (1973) The Structures of Ill Structured Problems. Artificial Intelligence, 4, 181-201.
Stallman, R. 'The Emacs Full-Screen Editor'. URL (consulted 27 November 2003): http://www.lysator.liu.se/history/garb/txt/87-1-emacs.txt
Stallman, R. (1995) GNUEmacs Manual. 11th Edition, Version 19.29. Boston: Free Software Foundation.
Stallman, R. (1998) 'EMACS: The Extensible, Customizable Display Editor’, 11 February, URL (consulted November 2003): http://www.gnu.org/software/emacs/emacs-paper.html
Stallman, R. (2002) My Lisp Experiences and the Development of GNU Emacs (transcript of Richard Stallman’s Speech, 28 Oct 2002, at the International Lisp Conference). URL (consulted December 2003): http://www.gnu.org/gnu/rms-lisp.html
Star, S. L., Bowker, G. C., Neumann L. J. (2003) 'Transparency beyond the Individual Level of Scale: Convergence between Information Artifacts and Communities of Practice', in the book Digital library use: social practice in design and evaluation, edited by Ann Peterson Bishop, Nancy A. Van House, and Barbara P. Buttenfield. The MIT press.
Williams, S. (2002) Free as in freedom: Richard Stallman’s crusade for free software. Sebastopol, CA: O’Reilly.