Keeping stuff: How to preserve course papers despite technological change

Front door ... Previous page ... Next page ... Executive summary


Lessons

From my experiences in keeping stuff, and sometimes failing to keep it, I draw several lessons.

Empowering software and domineering software

One is that the best technology is empowering. Whereas, in 1968, I could write and type ugly documents and, at some expense, copy them, I can now edit them quickly, save them in multiple versions, print them beautifully, store them electronically, search them rapidly, create hyperlinks among them, and publish and distribute them throughout the world. Technology has made me more effective teacher and a better and more influential writer, and these are accomplishments that make me joyful and proud.

On the other hand, in order to secure the advantages of technology, I have had to be fairly skeptical about changing from one technology to another, and even from one version of a software package to another. It's worth while to learn something new when there is something important that you can do with the new technology, and want to do, but cannot do with the old. Changing just to get a bunch of seldom-used new features or a glitzier user interface is a waste of time at best and frequently imperils your efforts to preserve older documents.

This danger is particularly menacing when some application program that you are expected to rely on is domineering and takes away the user's ability to create, adapt, and re-use his documents except by going through the application. The menace is further aggravated when the application is not extensible, so that the operations that the designers explicitly anticipated and chose to allow are the only ones that the user can perform. Instead of conferring new powers on their users, such software attempts to control or channel users' actions and work.

The three really bad technologies that I've discussed -- MASS-11, Microsoft FrontPage, and Microsoft Office -- all have this property. Under the guise of making things simpler and easier for the user and presenting a less intimidating user interface, such programs actually limit what we users can do to what the programs allow us to do. In both cases, the primary interest of the software manufacturer is to make users more dependent on the software (and, in Microsoft's case, on other software from the same manufacturer), even when this is antithetical to such actual interests of users as portability and preservation.

Another danger sign is the inclusion in a software application of a management and control system that creates a hierarchy of users, some with more privileges than others. Of the software applications that I've mentioned above, only Blackboard and Google Docs have this feature, but it's becoming increasingly common as business managers learn to use technology to micro-manage their subordinates. This often means that the managers, and not the authors of documents, control their preservation and future use. Since the interests of managers are often opposed to the interests of their subordinates, this makes it far more likely that documents considered ``unimportant'' by managers will be discarded in the course of a change in technology.

Standardization

A related lesson is that when documents depend on software systems that are standardized, either de jure, by a neutral public standard, or de facto, by the release of source code, they are more likely to remain fully usable. The manufacturers and distributors of unstandardized software have strong incentives to keep changing it and no incentive to make it stable. Most of the failures that I have listed above, particularly changes in the run-time behavior of computer programs, were caused by my unwary reliance on unstandardized programming languages or markup systems. I could give many other examples from my own experience.

Observing standards is particularly important when a software system uses some special file format that does not consist entirely of plain, human-readable text. If a software system uses binary file formats that are not explained publicly, fully, and explicitly, entrusting your work to it probably means that you won't get it out again intact. In the worst case, it also means that you'll lose some of it when the manufacturer decides to change the file format, perhaps supplying a ninety-five-percent-accurate conversion program to accommodate current users and to encourage them to upgrade.

Free software

Another lesson that I draw from my experiences is that documents are more likely to remain fully usable if they depend on free software instead of proprietary software. Here I'm using the word `free' in a very specific sense, defined at length in a well-known essay at the Free Software Foundation's web site: Software is free when all of its users have the right to execute it for any purpose, to copy it for others, to read and learn from its source code, to improve and adapt it in ways that serve their own interests, and to publish their improvements and adaptations for the common good.

Of the software that I've talked about today, the following programs are not free: the GE Time-Sharing System and its implementation of BASIC, the WATFIV FORTRAN compiler, XED, EDT, RUNOFF, OpenVMS, MASS-11, Microsoft Office, SunOS, HP-UX, Microsoft FrontPage, Internet Explorer, Blackboard, Google Docs, and IBM Lotus Symphony. The following programs were or are free: the Yabasic implementation of BASIC; our current FORTRAN compiler, g77; the SNOBOL4 compilers (both ancient and modern); SEDT; SROF; SPELLER; TEX; GNU/Linux; the World Wide Web Consortium's validator; and OpenOffice.org.

You can see from this list that over the years I've gradually reduced my dependence on proprietary software and substituted free software instead. As manager of MathLAN, I've tried to move all MathLAN users towards a free-software environment. Of more than two thousand software packages that are available on MathLAN, only a few are proprietary (MATLAB, Maple, Mathematica, and Adobe Acrobat Reader).

It's easy to see why free software is better for preserving documents: It tends to remain available, while proprietary software disappears when the manufacturer goes of out business or decides that the product is unprofitable. Also, free software, once it reaches maturity, is stable, whereas the sellers of proprietary software generally feel that they have to keep changing it.

Littera scripta manet

I'll conclude this list with a more traditional, common-sense lesson: When in doubt, keep a paper copy. Littera scripta manet: the written word endures, more reliably than the digitized word, and the most important component of usability, which is readability, is very well supported by paper. The technology of printing on paper is less flexible and less dynamic than computer technology, but it is comparatively robust in what it does, and that's the important thing for endurance.


Front door ... Previous page ... Next page ... Executive summary


This document is available on the World Wide Web as

http://www.cs.grinnell.edu/~stone/essays/keeping-stuff/lessons.xhtml


created March 19, 2001
last revised February 10, 2009

John David Stone (stone@cs.grinnell.edu)