Week 1: What makes software dead?

The opening lecture — what software archaeology is, why abandoned code matters, and how to choose a dig site.

22 February 2027

Open the slides

Learning outcomes#

By the end of this week you should be able to:

1. distinguish abandonment from dormancy and from completion, and state what evidence separates them
2. situate software decay within the existing literature on software ageing and evolution
3. select and justify a dig site adequate to twelve weeks of sustained enquiry

Outline#

• What is software archaeology? The term, the literature, the practice
• The scale of abandonment: how many npm packages, PyPI packages, and GitHub repos have no human commit in the last two years
• Dead vs dormant vs done: three kinds of silence
• Case study: Google Reader — a product killed by strategy, mourned by users, archived by nobody
• Choosing a dig site: size, licence, history depth, diagnosability
• The semester plan: one codebase, twelve methods, one exhibit

Required reading#

• Parnas, D.L. (1994) ‘Software Aging’, Proceedings of the 16th International Conference on Software Engineering (ICSE-16), pp. 279–287.
• Eghbal, N. (2020) Working in Public: The Making and Maintenance of Open Source Software. Stripe Press. Chapters 1–2.

Further reading#

• Lehman, M.M. (1980) ‘Programs, Life Cycles, and Laws of Software Evolution’, Proceedings of the IEEE 68(9), pp. 1060–1076.
• Kirschenbaum, M.G. (2008) Mechanisms: New Media and the Forensic Imagination. MIT Press. Introduction and Chapter 1 on forensic and formal materiality.

Seminar questions#

1. Parnas argues software ages for two distinct reasons. Which of the two is visible in a commit history, and which is not?
2. Is ‘dead’ a property of a codebase, of its community, or of its users’ expectations? Does your answer change which projects count as dead?
3. Eghbal reframes open source as a maintenance problem rather than a production problem. What does that reframing make visible that the ‘bazaar’ account does not?