100-year Software: Half-baked musings and some citations

Imagine a computer program which, when run 100 years from now on whatever computers they have in 100 years, produces the same output (given the same input) as that program does today.

Should the data survive, even if new software is required to interpret it? And/or should the software itself survive, still functional? I think it depends on the nature of the application: whether it is productive (Microsoft Word) or performative (a video game). The real hard problems arise when the data format is so complex and/or incompletely specified as to require an essentially performative application (examples: Microsoft Word, web applications).

• http://www.gseis.ucla.edu/~howard/papers/sfs-longevity.html
  
  

  With a vast number of resources being committed to reformatting into digital form, we need to begin considering how we can assure that that digital information will continue to be accessible over a prolonged period of time. In this chapter we will first outline the general problem of information in digital form disappearing. We will then look closely at 5 key factors that pose problems for digital longevity. Finally, we will turn our attention to a series of suggestions that are likely to improve the longevity of digital information, focusing primarily on metadata. Though this chapter was written for the digital imaging community, the observations here will be useful for all communities wishing to assure the longevity of any type of digital information.

  
  
  In particular, this tragedy makes me sick:
  
  

  Though the advent of electronic storage is fairly new, a substantial amount of information stored in electronic form has deteriorated and disappeared. Archives of videotape and audiotape such as fairly recent interviews designed to capture the last cultural remnants of Navajo tribal elders may not be salvageable (Sanders 1997).

  
  
  

  How can we ever hope that the files we create today will be readable in our information environments 100 years from now?

  
  
  
• http://constantine-plotnikov.blogspot.com/2007/02/software-system-longevity-paradigms.html
  
  

  The basic principle is that we ensure that the data survives, and an application is a transient thing anyway. It could die any time. Upon restart it will be able to work with the data again. Some data could be lost, but this is a known risk that should have been calculated.

  
  
  
• http://lonesysadmin.net/2008/05/20/java-se-for-business-software-longevity/
  
  

  Now that virtual machines are killing the hardware replacement cycle I’m left with only my software lifecycles, which really aren’t all that much better than hardware cycles. If those get longer, and I can guarantee an operating environment for 15 years, the amount of staff time and effort it takes to maintain these operating environments will drop rapidly. I’ll be able to upgrade when it makes more business sense for me, like when I’m replacing an application, or I decide it’s too much work to support 7 different versions of Red Hat Enterprise Linux. Not just when a vendor decides they’re done with an OS.

  
  
  
• http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel4/52/15098/00687939.pdf?temp=x
  
  

  Software lives longer than most organizations expect — a mean age of 9.4 years for applications of fundamental importance to the organization, according to one study. And it is living longer than before, up from 4.75 years in 1980. Nonetheless, software should live longer yet. Long-living software has many advantages. First, as a software application survives, it works. It benefits the organization that created it and the users that use it, and it pays back its development cost. Second, as a software application survives, it changes continually, functionality being added and modified to meet changing needs. In this continual evolution or maintenance, software fulfills one of its characterizing functions: its modifiability, its capacity for change, its softness. Functions are embodied in software instead of in hardware expressly because they can be changed. Change, and the resources that go into change, are its mission. Finally, as a software application survives, its quality improves. Errors are encountered or found, and removed. An operational profile emerges, and the software is adapted to it. The users who access it and the applications that connect to it explore, exploit, and optimize its capabilities

  
  
  
• http://portal.acm.org/citation.cfm?id=284308.284365&dl=GUIDE&dl=GUIDE&CFID=20195306&CFTOKEN=59168537
  
  
• http://www.cs.berkeley.edu/~yelick/cs267-sp04/lectures/08/lect08-mpi-intro.pdf
  
  Interesting remarks on slide 1.