1. The case for an agile and user driven
approach to digital preservation
development
(Or why user driven hackathons kick ass)
Paul Wheatley
SPRUCE Project Manager
University of Leeds
Twitter: @prwheatley
http://openplanetsfoundation.org/blogs/paul

2. What I’m going to talk about...
All about SPRUCE Mashups:
http://bit.ly/spruce-mashup
users/practitioners/
problem owners
developers/techs/
hackers/solution providers
Image:DimaYagnyuk,fromTheNounProject

3. What’s the problem with developing DP tools?
Rants and examples, just in case you don’t believe me:
http://openplanetsfoundation.org/blogs/paul
• Great solution to the
wrong problem
• Even with a good result,
no users = no feedback,
no bug reports: tool dies
• Reinventing the wheel,
getting nowhere
• And lots more...
Without strong user focus, awareness and communications...

4. Putting the user in the driving seat
• working with specific,
concrete user challenges
• actual user data
• make the user own the
problem
• separate problem owner
and solution provider roles
• engage with problem owner
at *each* iteration of
development
Image:P.J.Onori,fromTheNounProject

5. Sharing and communications
• Capture and *share* the
requirements/challenges/use cases.
–Eg. Datasets, Issues, Solutions,
http://bit.ly/spruce-results
• Publicise intention to pursue a
particular approach, to validate it
• Share the data
–Eg. OPF Format Corpus on Github
https://github.com/openplanets/format-corpus
• Make results easy for others to pick
up and reuse: atomic tools,
packaging, simple interface...

6. Example: Broken JP2s and Jpylyzer
• More information:
–http://openplanetsfoundation.org/software/jpylyzer
• Also see page on JP2 preservation risks:
–http://wiki.opf-labs.org/display/TR/JP2
Before and after:
Broken JP2
example
Jpylyzer was
written by
@bitsgalore of the
@scapeproject

7. Blatant plug...
OPF Mashup, Disk images, emulation and forensics
Chapel Hill, North Carolina, 3rd - 5th June 2013
More information and registration:
http://bit.ly/dft-ch

8. Mashup Manifesto (SPRUCE)
• Make it practitioner/user led
– Solve concrete problems
• Re-use, don't re-invent the wheel
– Most problems have already been solved, although often not by this community
– Re-use existing code where possible
• Keep it small, keep it simple
– Functional preservation tools should be atomic
– Modularise in the face of growing requirements
– Ensure results can be exploited and integrated with other orchestration/repository
platforms
• Make it easy to use, build on, re-purpose and ultimately, maintain
– Share your source
– Automate your build
– Package for easy install
• Share outputs, exchange knowledge, learn from each other
– Write up dev and user experiences and share them
– Publish data about usage
– Shout about it, blog it, tweet it, and add it to tool/service registry (or three)
• Adapted from: the SPRUCE Mashup Manifesto