[rox] my written contributions
- From: Yuwei Lin <yl107 york.ac.uk>
- Date: Wed, 02 Jun 2004 21:40:56 +0100
Hallo Stefan,
Please see my conferece paper as below. Cheers.
/yuwei
Title:
Epistemologically Multiple Actor-Centred System: or, EMACS at work!
Author: Yuwei Lin
Version 1.0 (3 February 2004)
Copyright (c) 2004 Yuwei Lin.
Permission is granted to copy and distribute, but modifying this
document is not allowed.
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.
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.
1. Introduction
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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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: 1) He thought selling the product to a
firm might broaden the network. But the transaction symbolised Gosling's
failure to continue the network expansion. 2) 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.
________________________________
http://www.oekonux-konferenz.de/