Meme Motes - Harry Chesley's Weblog

Ethical Experimentation on Artificial Cognitive Entities

If you experiment in computer-based cognitive science, as I do, sooner or later you have to ask yourself about the ethics involved. At what point does experimentation cross the line from acceptable to unethical. This essay is an attempt to survey the question and draw some concrete conclusions.

Let's start by giving some examples from human experimentation. On the one end, an experiment such as asking subjects a pair of questions and drawing conclusions about concept priming from their answers is clearly ethical. At the other extreme, locking someone in a dark room for three days without food or water and periodically applying electric shocks to them to see how their math skills degenerate under those conditions is clearly unethical -- even if there are no long lasting physical consequences.

Yet, cognition researchers do -- or may do -- the equivalent of each of these to their artificial subjects. And this is perfectly reasonable so long as the artificial subjects cannot feel pain or fear. Unfortunately, we don't know whether they do or not.

Consciousness, pain, and fear are undefined in a scientific sense. We know them when we see them, but we cannot, so far, give objective, testable definitions of them. All three appear to be the results of evolution, given that pain and fear are clearly tuned to the goal of survival and consciousness is apparently inextricably linked to those two. (Note, however, that it is possible that consciousness is somehow an external phenomenon that has been employed in the service of pain and fear, much as, say, potassium is used in ways that have evolved yet potassium itself is not the result of evolution.)

I have every confidence that some day these concepts will be fully understood scientifically, but I don't want to wait for that day to start doing experiments in cognition. The best approach available today is to map out some of the possible explanations for these concepts, and consider the probability and ethical consequences of each.

The first possibility is that consciousness, pain and fear (CPF) do not really exist, that they are cognitive illusions. This would mean that any experiment is acceptable, since there is no real harm done. But it also means that any experiment on humans is also acceptable. Call me chicken, or perhaps trapped by my human psychological makeup, but I'm not willing to make that assumption without further proof. It may be true, but the consequences of being wrong are sufficiently large that, from an ethical point of view, we're best off ignoring this option. (And, for that matter, if that's true, it's also likely that ethics is an illusion as well, so this whole discussion is moot.)

The second view, at the other extreme, is that everything, animate or inanimate, is conscious and capable of feeling pain and fear. Which means that every rock you step on may be silently screaming in pain. But given this assumption, we don't need to wait for a cognitive experiment to worry about ethics; we all do it every day just by living. The only way to avoid it is suicide. So without making any judgment about the truth of this idea, we can say that it is irrelevant to the question at hand -- it's a problem that everyone has to face, not just cognitive scientists.

The third theory is that CPF are undirected emergent phenomena; that at some level of cognitive complexity, they simply arise without external planning or influence. If this is true, and until we have a better understanding of when and how they emerge, it is impossible to know when a given experiment in cognition will develop CFP and to what degree. Worse, there is no clear way to tell when the emergence has occurred. This makes ethical experimentation difficult or impossible, since the consequences are both unpredictable and possibly unobservable as well.

The last theory is that CPF are emergent, but do not emerge randomly -- they require some amount of structure, which arises either from natural processes such as evolution or from experimental design. According to this theory, CPF will not "just happen," but the experimenter may introduce them either intentionally or unintentionally as a consequence of other aspects of the experiment. As naturally occurring CPF is clearly highly directed as a consequence of evolutionary pressures, this theory seems the best fit to what little we know about the subject.

How, then, can the experimenter make sure not to introduce CPF? Or to introduce them in a controlled and ethical fashion? As the whole point of cognitive experimentation is to understand cognitive processes better, and the central problem of ethics is understanding the cognitive processes involved in CPF, the answer is perhaps more one of staying alert to the possibilities than of having a specific test for ethical experimentation available beforehand. That is, as experimentation tells us more about cognition, it should eventually lead to an understanding of CPF. What is important ethically is to recognize this new understanding before the experiments lead to unethical treatment of the artificial experimental subjects. And it is also important to publish any results that provide a better empirical understanding of CPF, in order to allow other researchers to understand the possible consequences of their own experiments as early as possible.

This is a poor answer. Perhaps the only truely ethical approach is to do no experiments until we fully understand the basis of consciousness, pain and fear. But that is a very slow route to the creation of aritficial cognition and to understanding congition in general. As there is reason to believe that experimentation will lead to understanding before it leads to abuse, so long as the experimenters are sensitive to the questions of ethics, this is the approach that I am taking personally.

Social Augmentation

As software engineers, we tend to overfocus on the tools we create rather than the problems that we solve. Today, a major area of interest is social computing. But when people say social computing, they tend to mean email and bulletin boards and IM and blogs and Wikis -- a set of tools for moving glyphs from one computer to another. A better way to look at it, IMHO, is as using the computer to augment human social interaction. Thinking solely about publishing and transport extends our ability to speak, it's true, but there's so much more to social interaction than that.

One book that got me thinking about this was The Tipping Point, by Malcolm Gladwell. He divides people into connectors, mavens, and salesmen. Each of these three types of people -- or these three aspects of each of us -- has very different requirements when it comes to social interaction. Augmenting the type of behavior typified by each category can amplify even further those who are already good in that area, and enable the rest of us to be better than our innate talents alone would allow.

Connectors are people who seem to know everyone, who love to talk and to listen, who form the primary, or at least the most far- and fast-reaching elements of the worldwide social network. Personally, I'm not a connector, but I've known several and I've watched them at work. For example, for each person they know, they remember their names, their relationship, their personal details (how many kids, which ones are in college, if they're divorced), and their past communication; and they reconnect from time to time just to stay in touch, or when there's an excuse like a birthday. Yet none of the address books that I've ever used has a space for "number of kids", or reminds me to send a "happy birthday" email (or just sends it automatically, for that matter), or lets me keep a record of other contacts with the person, like phone calls and meetings.

A maven is someone who knows a lot about a particular area, and is always willing to tell you about what they know. Mavens often get asked about the same area over and over. Yet mail systems provide little support for boiler-plate answers to frequent questions. Mavens usually know just where to go for information, whether it's a web site, a book, or a person. But our current systems don't support this sort of indexing and retrieval of personal knowledge, in a format that's easily converted to communication or publication.

Strangely, current systems may do more to support salesmen than the other types of user. They correct your spelling, let you use slick fonts, and let you include pictures. But they only do most of this if you know that they're good ways to raise the level of excitement in your communication. Much like Microsoft's PowerPoint makes it easy to put together slick presentations, a more salesman-friendly email or blog system might make the choices more automatic.

This is just a surface-level scratch of the possibilities if we stop thinking of existing systems as a way to move glyphs, and start thinking of them as a tool for augmenting social interaction. So long as we think of the next social computer tool as a new version of the existing ones, we'll be stuck in those preset molds. It's only when we think in terms of the problem area -- social interaction -- that we have a hope of creating something really new.

Agricultural Google

Twenty years ago, if I wanted to know about, say, aardvarks, I'd go to a library, check out a book, and read it. Today, I go a web browser, search via Google, and read ten bits and pieces from a range of sources. There are two important differences (and a hundred less important ones): first, I don't have to go anywhere (assuming, of course, that I have a web browser near by); second, I don't get one monolithic source, but a plethora of smaller pieces, selected for me from the immense infosphere by Google's search technology. Of course, I won't currently get that original book I would have started and ended with twenty years ago, but that will no doubt change.

This is all true because information has become mobile, and the conduits through which we access it have become, if not quite ubiquitous, at least widespread. A similar change is bound to happen to physical things as computer-based intelligence is pushed out into the physical world and becomes widespread. This will happen as the computers already in most devices become more sophisticated, as nanotechnology makes those devices smaller and more distributed, and perhaps also as biotechnology matures (and eventually merges with nanotechnology).

Currently, we maintain a separation between nature and civilization. And where we employ nature toward civilization's ends, we order and structure it as much as we can in the name of efficiency. Thus, we grow our food away from where we live, and we grow it in unnatural neatly organized rows. This is all done for the sake of efficiency. But local intelligence makes it unnecessary. Local intelligence allows each plant to be dealt with individually, rather than as part of a row of plants.

So imagine instead, a world where separation and order are not required. And while you're at it, a world where clustering in cities is not important either. Rather than fenced off rows of agriculture out away from where you live, there would be a world-wide garden. And it would be a garden in the true sense: not nature left to grow however it likes, but guided into aesthetically pleasing lines and colors and vistas, with robot-maintained pathways. The divisions between human space, agricultural space, and nature would disappear.

Some of us, no doubt, would even choose to return to an idealized nomadic lifestyle, made up of days wandering through lush vegetation (via convenient pathways), stopping occasionally to grab and eat low lying fruit (made with biotech and nanotech that has long since eliminated pesticides and pests that would make the fruit dangerous to eat right off the vine), working all the while via cell phone or portable web browser with others. Each evening, the family would rendezvous at an inn for dinner and a place to sleep, or their robotic servants would set up a picnic dinner and tents in the forest, filled with their favorite possessions and toys.

A better approach to DRM

Perhaps the biggest stumbling block to wide-spread digital publishing is digital rights management. The current major players (Apple, Microsoft, et al) have one model of how that should work. Their model has significant problems (IMHO). But it's not the only possible model. Read on for an alternative.

Traditional ownerships of things like books and music involve a one-time transaction. Once you've bought it, your relationship with the author, publisher, and bookstore ends. There's no on-going contractual relationship. There is copyright law that limits what you can do with the item you've purchased, but that is a society-wide law, not a contact between you and the publisher.

Current digital rights management (DRM) schemes from companies like Apple and Microsoft work differently. They imply a permanent relationship with the publisher. Without it, you can't move the material to a new computer, or to a new version of the player application. Because usability depends on this long term relationship, if the company ever disappears or drops support for the technology, your ownership suddenly evaporates. This issue is at the heart of why I don't buy DRM'd works. The future of my ownership is simply too foggy.

But digital rights are important. So long as our society uses capitalism to allocate resources and motivate its members, ownership is virtually inescapable. Ownership of digital works, without some sort of DRM to back it up, is tenuous at best. So what to do?

I believe the answer is to change the model. Don't sell digital works, lend them. Rather than the model of a bookstore, let's try the model of a private lending library. Rather than thinking Amazon, think Netflix.

Using the library model entirely changes your expectations of digital rights management. For example: It's now OK if the work is only usable on the device it was downloaded to, because you can always check it out a second time on another device. It's now OK if the work is only usable for a limited period of time, because that's how borrowing from a library works, and you can always renew the check-out. It's not great if the library goes out of business, but if it does, you don't lose something you'd paid for and thought you owned permanently.

And it enables other aspects digital works that were not a feature of the traditional publishing world. In the old days, once something was printed, it was finished. But today, works can continue to grow, interlink, and be annotated indefinitely. For example, I find the MySQL manual somewhat opaque, but the online version has annotations from users that almost always answer the question I had clearly and with explicit examples. With the lending library approach to DRM, if I check out the same title at different times, it's just natural to get the most up-to-date version each time, not one that was frozen at some arbitrary point in time by the publisher.

A lending library works best for books, but it can also work for music, video, and other forms. The higher the bandwidth between the library and the user, the better it works for these other media, since they tend to require more frequent borrowings of larger sizes. Luckily, bandwidth is constantly growing.

So now that I've figured out "the answer," how do we proceed? Implementation is not hard. What's hard is convincing someone in a position to bring on-board the existing publishers. The point to this essay is to get the idea out where someone in that category may find it. Please let me know if you do. I'd love to be in the beta, or even help develop the system.

Frank and Ollie

Sarah Allen's blog entry "time as a design element" reminded me of a book that every user interface/interaction designer should have, though few are even aware of it: Disney Animation: The Illusion of Life, by Frank Thomas and Ollie Johnston.

The Illusion of Life is a beautiful book, full of incredible, full-color bits of Disney cartoons. But more importantly, it captures a big portion of the principles that the Disney team used to create those cartoons. And almost all of those principles are relevant to computer user interface design.

Frank and Ollie were two of the key people in the original animation group at Disney. I had the pleasure of hearing them give a talk some years ago at Microsoft Research (where Linda Stone used to bring in all manner of fascinating people to give lectures). They were sharp, funny, great story tellers, obviously life-long friends, and willing to share the insights that made their work so great. This book has all the same characteristics.

Perhaps the heart of the book, at least from the UI perspective, is chapter three, The Principles of Animation, which lists twelve basic principles. Although obviously intended for animators, it's not hard to repurpose them to UI design. Here they are (with some selected quotes):

1. Squash and stretch. In real life, things are almost never static or of fixed size and shape. They change to reflect the forced acting on them.

2. Anticipation. "People in the audience watching an animated scene will not be able to understand the events on the screen unless there is a planned sequence of actions that leads them clearly from one activity to the next."

3. Staging. "...the presentation of any idea so that it is completely and unmistakably clear."

4. Straight ahead action and pose to pose. "Straight ahead" is when the animator simply takes off animating, with no plan or destination. "Pose to pose" is preplanned. Pose to pose "is always easy to follow and works well because the relationships have been carefully considered before the animator gets too far into the drawing." But "both methods are still in use because they each offer certain advantages for different types of action."

5. Follow through and overlapping action. This principle includes several techniques to keep the action from coming to a complete stop and then restarting when going from one scene to the next.

6. Slow in and slow out. Slowing down the action around the important poses, so the audience sees these, and isn't bored by the in between pieces.

7. Arcs. "Very few living organisms are capable of moves that have a mechanical in and out or up and down precision... most movements will describe an arc of some kind."

8. Secondary action. "Often, the one idea being put over in a scene can be fortified by subsidiary actions within the body."

9. Timing. "Neither acting nor attitude could be portrayed without paying very close attention to timing."

10. Exaggeration. I think that one's obvious...

11. Solid drawing. "Drawing is giving a performance; an artist is an actor who is not limited by his body, only by his ability and, perhaps, experience."

12. Appeal. "...a quality of charm, pleasing design, simplicity, communication, and magnetism."

For some of these principles, the application within UI design is obvious and established (2, 3, 4, 9, 11, 12). The others may seem to apply only to animation, but I suspect the real truth is that we just haven't gotten there yet.

A group of programmers walk into a bar...

A group of programmers walk into a bar. The bar tender asks, "What'll it be?"

The C programmer says, "You see that bottle?" pointing to a large green bottle marked only with a "*". "Give me whatever's in it."

The Lisp programmer says, "Give me (on the bar in front of me) a glass (a small glass (or plastic cup)) of (imported (German)) beer. (If that's not available, then wine (red (California (Cabernet))).)

The assembly language programmer says, "Take a glass from position two in the glass rack and place it on the bar in position zero (in front of you). Take a bottle from position seven in the bottle rack and pour the contents into position zero on the bar. Stop after three seconds. Put the bottle in position seven of the bottle rack. Take the glass from position zero on the bar and place it in position four on the bar (in front of me)."

The Smalltalk programmer says, "Bartender get vodka bottle. Vodka bottle pour into glass. Hand lift glass. Mouth drink."

The Visual Basic programmer says, "You see those two guys sitting over there?" pointing at a big bald guy and a smaller one wearing glasses. "I'll take whatever they're willing to let me have."

The SQL programmer says, "Take all the bottles containing beer, call them 'beers'. Take all the bottles that come from companies with output of less than one million units per year, call them 'micros'. Take the intersection of 'beers' and 'micros', and pour me the first one."

The Forth programmer says, "White wine, give me."

The Prolog programmer says, "I'll have coke if I want caffeine. I'll have vodka if I want to get drunk. I'll have water if I'm thirsty. I want caffeine if I need to stay awake. I'm thirsty if it's a hot day. I need to stay awake if I still have work to do today. It's a hot day if it's greater than 80 degrees Fahrenheit. I still have work to do today."

The UI designer says, "I'd like a small glass with a thin edge so it's easy to drink from. It should be large enough to grasp easily, but not so large that it's too heavy. It should have a picture on it of a person drinking (thus showing how to use the glass)." "But what do you want in it?" asks the bar tender. "I don't care," says the UI designer.

The manager says, "Oh, just give me a drink!"

Comparing Operating Systems

I recently added Linux to my set of in-house operating systems, together with the already existing Windows XP Pro and Macintosh OS X. This has led me into thinking about comparative operating systems, and thus to this summary of my thoughts on the subject.

But first, a quick historical sketch: I've been using OSes for a long time, starting before any of these existed. Sticking to the direct predecessors of these OSes, in roughly chronological order, I've used various flavors of Unix; CP/M (arguably the predecessor to MSDOS); MSDOS; all of the releases of the Macintosh OS; Windows 3.0, 95, 98, NT, 2000, XP; Linux Fedora Core 3. That doesn't make me an expert, but I'm not a neophyte either.

I'm going to rank Windows XP Pro, Mac OS 10.3, and Linux Fedora Core 3/Gnome along several axes: available applications, user interface, reliability, speed, quality, and hackability.

Available applications: Windows, Mac, Linux. (Note that I'm talking desktop, not server here.) While most people don't care about how many applications are available, only whether the ones they want are, the total number is a good predictor whether the one you need is present. Windows' huge market share pushes most developers to target it first, even when they would privately prefer one of the other OSes.

User interface: Mac, Windows, Linux. No big surprise here. Mac is still the best. But Windows is not terribly far behind. Linux/Gnome reminds me of early Windows releases. They're trying, but there are still huge areas of the OS that are uncovered by a GUI, and thus much harder to figure out and use effectively. Mac is the only OS that started as a GUI system from day one.

Reliability: tie. In my experience, they all just keep on running. This was not true of Windows before 2000, nor of Mac before OS X, but is today. My systems never crash, and most stories I hear of other's crashing involve questionable drivers, always a weakness of any OS. If pressed on the subject, I'd say Linux has a slight edge, mainly because it's come out of heavy server usage, where reliability is very highly prized, but it's a thin edge.

Speed: Linux, Windows, Mac. But Windows and Mac are really tied. And I'll bet Linux slows down as the GUI gets more complex and extensive.

Quality: Uh. This is a very tricky area. In a pure OS sense, Mac wins. It's clear they take more time hand-crafting the system. But here Linux is very interesting: Linux itself and most Linux applications are built by people who really care about what they're doing, are often more technically sophisticated than people who build apps based purely on market share analyses, and often have no corporation backing them up. This means that when those developers are less skilled than they think they are, there's no corporate quality control to censor them, and the result is junk. On the other hand, when they are good, they're *really* good. (I have to add one pet peeve here: originality. Why do Linux developers seem to feel they have to slavishly copy the look-and-feel of Windows? How about pushing the envelope a bit more, huh?)

Hackability: Linux. By hackability, I mean your ability to dig into the system and change or extend it, not the ability of others to do that against your wishes (in that area, it's Windows, Mac, Linux, but mostly because malicious hackers primarily target the most wide-spread OS). In hackability, Linux obviously has no competition from either of the other two. You can literally see and change every line of code and every byte of Linux and any open source application you run on it. Wonderful.

Everyone has to make their own decisions about which of these criteria are important to them. I always advise naive users to start with the applications they want to use and pick the OS that has the best of them. By this criterion, Windows usually wins. On the other hand, users who aren't doing anything complicated or unique are probably best off with Macintosh, the simplest and most user friendly of the three. Non-experts should still stay away from Linux, which has a ways to go yet in usability (try explaining to a non-techie what "chmod 755 foo" means). But for people like me who like to hack the system sometimes (albeit less so than when I was younger), Linux can be very, very attractive.

My own solution is to keep all three around. But that probably doesn't work for most people.

I Had To Write This, But I Did It Because I Wanted To

Every once in a while, I run into a discussion of free will versus determinism, and it always strikes me as a completely meaningless dichotomy. It's one of those things where you can say it in English, but that doesn't mean there's actually anything there.

First, let's look at how a decision gets made. What leads to deciding between two courses of action, A or B? What are the ways to determine what you "want?"

One possibility is logical, rational, thought, based on known facts and prior knowledge (either your own or that acquired from others). Thinking requires structure and mechanism. You need some way to process facts, learned relationships and procedures, and come out with a choice. Whatever the mechanism (brain cells in humans, transistors in computers), given a body of knowledge, the result is perfectly determined.

A second possibility is emotional choices. But what drives emotions except those same brain cells? In fact, you can make a strong argument that we evolved our emotions for very rational reasons; that they're a species-level rational decision making mechanism, as opposed to an individual-level one. I know of no evidence that emotions are any less determined than rational thought is. And the fact that I can alter my emotions by taking certain drugs certainly supports that.

A third possibility is random chance. Flipping a coin. While this isn't strictly deterministic (well, it depends on your random number generation algorithm), it's also not very interesting when you talk about free will versus determination. "I don't believe in fate! It's all random!"

What else is there? I can't come up with any other mechanism for making decisions. In other words, "free will" in the sense of something independent of rational or random processes is really a meaningless concept.

People tend to separate themselves and their bodies. That makes it easy for them to believe there's some process going on that "outside" their physical bodies. I don't think this makes sense. I think everything we are is tied up in our bodies and the cells it's composed of. That somewhat simplifies the argument that we're deterministic or random because we're the result of biochemical activities that are so. But even if there is some other, even transcendental mechanism somehow tied in there, doesn't it also have to either be rational or random?

But does that mean we don't have free will? No!

First, decisions are still made within us; within the collection of cells that makes us individuals. It's the end product of a series of deterministic events, but those events end within us. Now, it's also true that the decision to turn on the heat in my house is made in my thermostat, and so that thermostat has free will in the same sense. Of course, it's not self-aware, and not very interesting, but it's still making decisions.

Second, the deterministic bits are so far down in an immensely complex hierarchy of functionality, that even though it may be deterministic (if it's not partly random), it's not predictable. In a sense, the decisions might as well be made by an outside "me," because that "me" is a gestalt aspect of the person that is not really understandable from the component parts (at least not with today's level of analytical tools).

So do we have free will or are we deterministic automatons? Yes, both. It's all deterministic, but we're the part of the larger deterministic system where the important stuff happens. I decided to write this blog entry, but it was deterministically determined that I would make that decision. I can live with that.

Choosing a Career

There's been a lot of talk lately in our house about career choices. This has, in turn, led to my thinking through the objective goals in a career choice. The following is my best shot at listing and prioritizing the things to consider when picking a career area. Much of it is personal and subjective, of course.

First and foremost, you should have a passion for it. If you don't, it will be a long boring life. If you do, you'll be willing to spend the hours required to be really good at it. Of course, it's not always easy to find the thing you're really, long-term passionate about. Which argues for checking out a number of areas early on. I think most people know it when they see it. Myself, I found programming during high school, and have since spent probably an average of seventy hours a week (3,640 hours a year) doing it and loving doing it. Having started 35 years ago, that makes for 127,400 hours, give or take.

Second, it should be a positive sum game. Game theorists divide games into zero sum games, where the number of points is fixed, so if someone wins, someone else must lose; positive sum games, where more than one person can win; and negative sum games, where everyone loses points. Some career areas, like marketing and politics, are zero sum games. (Politics, when it focuses on finding solution regardless of sides, can be positive sum, but it's very seldom played that way.) If you love competing and winning, that can be a great choice, but it's not for me. Careers that involve creating something new (knowledge, products, etc.) are generally positive sum. Of course, there's often competition between groups or companies, so it's not always the case that everyone wins. But even when my group loses, I still get to use the product of the winning group (whether it's new science or a commercial software application).

Third, it should be an area that's active and expanding. It's much more fun to work with computers, whose power (and thus the set of potential applications) doubles every couple years, than it is to work on refrigerator design, which hasn't changed much for decades. Areas where new discoveries happen regularly provide more opportunities and more material to build your own work on top of. Today, that probably means computers, biotechnology, or nanotechnology; but there are dozens of other possibilities as well.

Fourth, for me at least, something on the border between science and engineering is ideal, where you can surf back and forth between the two. Science is great because you discover things that no one has ever known before, and because the potential impact on civilization is huge. But there's about a ten year minimum delay between a major discovery and its use in everyday products. Engineering is great because people actually use what you create directly, and it happens while you watch. Sitting between the two gives you the best of both, and lets you help reduce that delay from discovery to use.

Did I think all this through when I made my own career choice? No way. I took a course in programming, thought it was the coolest, most fun thing I'd ever seen, and never looked back. The thinking above is all after-the-fact, justify-the-decision-after-it's-made stuff.

Rumor Monger

[The following was originally written for the Apple Computer History Weblog. It has been amended slightly.]

Around 1990 I was working in the Apple's Advanced Technology Group. ATG was an incredible place to work, especially when Larry Tesler was running it. It's probably the best place I've ever worked. Shortly after I joined the group, they did a survey and discovered that there were more projects than people. While this bothered some people (mostly managers), I thought it was perfect, reflecting the huge quantity of great ideas that people were exploring.

While in ATG, I read a paper from some people at Xerox PARC: Alan Demers, Mark Gealy, Dan Greene, Carl Hauser, Wes Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Dan Swinehart, Doug Terry, Don Woods, Epidemic Algorithms for Replicated Database Maintenance, Xerox PARC Technical Report CSL-89-1, January 1989. (The link above requires an ACM Portal account; you can also find the paper here.)

They were using a class of data distribution algorithms known as epidemic algorithms, modeled after how diseases spread in a population. This is also how rumors spread, and the paper makes reference to rumors and rumor mongering. Their work had concentrated on how to distribute email directory information. But as soon as I read the paper I knew what I had to do: write a rumor mongering program that used the rumor mongering (epidemic) algorithm, called, of course, Rumor Monger.

The algorithm is quite simple: When a node gets a new piece of data, it marks it as "hot." Periodically, it talks to another node (either at random or as communications capabilities and efficiencies provide opportunities). It takes its "hot" items and, for each, tells the other node "have you heard this one?" If the other node has not, the item remains "hot." If it has, the item is marked slightly "cooler." The chance of an item being told to another node is proportional to its temperature. Eventually, items get cool enough that the node hardly ever tries to share them. In addition to being an efficient way to distribute information, the algorithm is entirely decentralized, requiring no server or central coordination.

Rumor Monger was conceived as an experiment in distributed, light-weight communication, what today we would call peer-to-peer instant messaging with broadcast. The program sat in the background, continually exchanging messages with other machines. The user could, at any time, bring it to the front and enter a new message, which would then be distributed to every other instance of the program within the company-wide local area network. As an afterthought, I added the option to send messages anonymously. This was done sort of on principle, more than because I thought anyone would actually use it. The test population was Apple Computer employees.

To my surprise, Rumor Monger rapidly became very popular within the company. And even more to my surprise, 99% of all messages sent were sent anonymously. This changed it from an experiment in technology into an experiment in sociology.

More than any other communications system I'm aware of, Rumor Monger had a virtually zero barrier between thinking something and sharing it with everyone else. It was always there, so you just had to click and type to spawn a new message, making the physical barrier minimal. And the messages you sent were anonymous, making the social barrier minimal as well. In a sense, Rumor Monger became a window into the minds of the community that used it: messages were posted that would never have been said out loud. The results were simultaneously fascinating, hilarious, ugly, mundane, profound, and contentious. The messages included company rumors, bad jokes, personal insults, new product ideas, and an inexplicably long discussion of haggis.

I was ecstatic with the results. It went far beyond what I'd hoped to achieve. Remember that this was before the days of community web servers and instant messaging. It seemed to open up whole new worlds of possibilities for connecting communities of people via the computer.

Apple management was less ecstatic, especially the then head of ATG (we'll leave names out of it). It seems some rumors were being posted that could be interpreted as being libelous, and management felt Apple might be held responsible. A meeting was called to determine how to deal with the problem. I explained that Rumor Monger was entirely decentralized, and therefore could not be "turned off." (I actually didn't come completely clean about that, since I did know one way to do it: flooding the system with bogus messages, so the real messages would be lost in the flood.) I was told that it had been irresponsible of me to release dangerous technology like this with no way to control it.

In the end, no one got sued over Rumor Monger (though there are rumors of one marriage ending because of it). Management posted a bulletin on AppleLink (the primary corporate online communications system) telling people to be responsible in their use of it (it was actually hilarious to read: because they didn't want to encourage even more people to use Rumor Monger, the program they were telling people to be responsible about was not actually mentioned in the bulletin). And some zealous managers forbade their groups from running the program.

Rumor Monger continued on for years afterward, with no further help from me. It was not as popular as it once was, but always had an active user base. It seemed to become more popular every time there were layoff rumors around the company.

I wrote an article on Rumor Monger for develop magazine. Management insisted on two changes before they'd let us publish it: First, it should not be called Rumor Monger, so we changed it to Light-weight Asynchronous Conferencing System (LACS, pun intended). And second, that the anonymous feature of the program should be removed. I took out the "Anonymous" checkbox, but left all the code in. It was possible to re-enable it quite easily using ResEdit, though as far as I know no one ever did.

I still don't understand the management response to Rumor Monger. Yes, the liability issues needed to be dealt with. But the very fact that the program was as popular as it was suggested there were ideas worth pursuing. (The next version would probably have explored using it as a group brain-storming tool.) We've seen how wide-spread instant messaging has become since then. Perhaps I should have pushed on despite the discouragement from management -- they never did explicitly say "stop."