[-empyre-] Games, histories and preservation

[Julian Oliver]

..on or around Wed, Mar 19, 2008 at 05:04:27AM -0700, Jim Andrews said:
> 
> > ahah, it's good to know that poor programming was at fault and not
> > Director itself. i've seen several time-broken pieces made in that
> > program and guessed that something must have been very wrong with the
> > way Director dealt with time.
> >
> > >
> > > But - yes!  it's precisely this problem that makes emulation/
> > > reconstruction difficult.  Even i don't really remember what some of my
> > > early works looked like!
> > >
> >
> > funny that in these cases it's time itself that needs conserving. time
> > will eat itself etc..
> 
> 
> in well-programmed work, time is engineered. with a knowledge of what will
> change over time and what will remain the same. a consciousness about time
> in the piece. not leaving it up to the defaults of the software.
> 
> so of course that knowledge also involves a realization that eventually,
> regardless of how well-engineered it is, it won't be running any more.
> 
> but that doesn't make it any more futile than other pursuits. that
> eventually won't be running anymore either.
> 
> however, these things do take time to emerge.
> 
> some work, you can see it is built to last. other work, you can't tell for
> some time. and some is obviously not going to last.
> 
> looking at the code is one of the ways to tell how robust it might be.
> robust code is engineered with a knowledge of computer science and best
> practices.
> 
> i worked on a preservation project at http://vispo.com/bp concerning
> programmed, kinetic work by the poet bpNichol from 1983. he was not a
> programmer. it was simple programming. and there's an emulator available for
> the apple iie. so it was relatively doable.
>

that site is an interesting read, cheers.

> but if an artist-programmer knows how to program and does something much
> more ambitious, they'd better really be on their game concerning best
> practices and documentation if they want it to stand a chance of surviving
> beyond their own work on the program.

yep, documentation is pretty vital in the interests of a digital work's
longevity. beyond well commented code, i sometimes scratch my head at
how to even run some of my own work only months after it's finished. 

i do believe, however, that this 'best practice' you're talking about
also increasingly implicates wide choice of copyright license. 

in the last 7 or 8 years i've made it a priority to release work under a
license such that the source-code remains transparently available after
distribution. this is so it can (ideally) be modified by me or someone
else to run on future hardware and/or operating systems. moreso the
license permits copying and subsequent distribution, adding redundancy
and increasing likelihood of contact with other programmers who may feel
encouraged to port and/or update the work. 

i saw this happen within a short time on my http://packetgarden.com
project: several people voluntarily made it run on OS X PPC and various
Linux distributions. i had help porting it to Windows and recently a few
people have expressed interest in porting it to OS X Intel. 

had i released a binary-only version of the project it would've reached
a very small audience and would perhaps suffer greatly from platform
rarefication and/or irresolveable bugs in future. worth mentioning is
that the commissioning organisation for that project made it explicitly
clear at the outset that they wanted to fund an open-source project.

a good sign perhaps.

cheers,

-- 
julian oliver
http://julianoliver.com
http://selectparks.net
messages containing HTML will not be read.