Sign-up going very well – over halfway with a few more spaces still available…

Knowledge as well as code: often preserving the code is good, but the understanding that went into the code is better. Some of this will be captured in requirements, design and testing docs but these would need to contain the rationale for decisions, and not just the decisions themselves, for the understanding to be truly caught. Of course, such deep understanding isn’t always needed: for instance, preservation for software reuse only requires the functional elements (and the assurance that it works properly!) to be documented.

Distributed systems makes things difficult: notions that software is always self-contained, always runs on a single machine, etc are out-dated. Take web services for instance: functionality comes from combinations of different services from different servers, including some from outside your domain and from around the world. How do you preserve that?!

Reputation is key: how does, or might, software preservation enhance reputation? Peer recognition from other developers, leading to kudos? Possible but not guaranteed. Tied in with this is the close link between transparency and preservation: reputation might easily be lost if poor code is published and picked up on by others. This seeming asymmetry leads to a fear of publishing code. To counter this, the idea of a publishing amnesty (!) was floated.

Those are the major synthesised findings for me from the workshop…