[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."