Free as in Freedom | Page 3

on software data piped in
over a computer network to turn that data into professional-looking documents. Created
by engineers at the world-famous Xerox Palo Alto Research Facility, it was, quite simply,
an early taste of the desktop-printing revolution that would seize the rest of the
computing industry by the end of the decade.
Driven by an instinctual urge to play with the best new equipment, programmers at the AI
Lab promptly integrated the new machine into the lab's sophisticated computing
infrastructure. The results had been immediately pleasing. Unlike the lab's old laser
printer, the new Xerox machine was fast. Pages came flying out at a rate of one per
second, turning a 20-minute print job into a 2-minute print job. The new machine was
also more precise. Circles came out looking like circles, not ovals. Straight lines came out
looking like straight lines, not low-amplitude sine waves.
It was, for all intents and purposes, a gift too good to refuse.
It wasn't until a few weeks after its arrival that the machine's flaws began to surface.
Chief among the drawbacks was the machine's inherent susceptibility to paper jams.
Engineering-minded programmers quickly understood the reason behind the flaw. As a
photocopier, the machine generally required the direct oversight of a human operator.
Figuring that these human operators would always be on hand to fix a paper jam, if it
occurred, Xerox engineers had devoted their time and energies to eliminating other pesky
problems. In engineering terms, user diligence was built into the system.
In modifying the machine for printer use, Xerox engineers had changed the user-machine
relationship in a subtle but profound way. Instead of making the machine subservient to
an individual human operator, they made it subservient to an entire networked population
of human operators. Instead of standing directly over the machine, a human user on one
end of the network sent his print command through an extended bucket-brigade of
machines, expecting the desired content to arrive at the targeted destination and in proper
form. It wasn't until he finally went to check up on the final output that he realized how
little of the desired content had made it through.
Stallman himself had been of the first to identify the problem and the first to suggest a
remedy. Years before, when the lab was still using its old printer, Stallman had solved a
similar problem by opening up the software program that regulated the printer on the
lab's PDP-11 machine. Stallman couldn't eliminate paper jams, but he could insert a
software command that ordered the PDP-11 to check the printer periodically and report
back to the PDP-10, the lab's central computer. To ensure that one user's negligence
didn't bog down an entire line of print jobs, Stallman also inserted a software command
that instructed the PDP-10 to notify every user with a waiting print job that the printer
was jammed. The notice was simple, something along the lines of "The printer is jammed,
please fix it," and because it went out to the people with the most pressing need to fix the

problem, chances were higher that the problem got fixed in due time.
As fixes go, Stallman's was oblique but elegant. It didn't fix the mechanical side of the
problem, but it did the next best thing by closing the information loop between user and
machine. Thanks to a few additional lines of software code, AI Lab employees could
eliminate the 10 or 15 minutes wasted each week in running back and forth to check on
the printer. In programming terms, Stallman's fix took advantage of the amplified
intelligence of the overall network.
"If you got that message, you couldn't assume somebody else would fix it," says Stallman,
recalling the logic. "You had to go to the printer. A minute or two after the printer got in
trouble, the two or three people who got messages arrive to fix the machine. Of those two
or three people, one of them, at least, would usually know how to fix the problem."
Such clever fixes were a trademark of the AI Lab and its indigenous population of
programmers. Indeed, the best programmers at the AI Lab disdained the term
programmer, preferring the more slangy occupational title of hacker instead. The job title
covered a host of activities-everything from creative mirth making to the improvement of
existing software and computer systems. Implicit within the title, however, was the
old-fashioned notion of Yankee ingenuity. To be a hacker, one had to accept the
philosophy that writing a software program was only the beginning. Improving a program
was the true test of a hacker's skills.For more on the term "hacker," see Appendix B.
Such a philosophy was a major reason why companies like Xerox made it a policy to
donate their machines and software