The SPRUCE Mashup Manifesto

This a rough collection of approaches, working practices and mindsets for developers participating in a SPRUCE Mashup. Comments/additions/corrections welcome!

• Be agile
  • Develop/prototype in short bursts, then demo and get feedback from your practitioner(s)
  • Practitioner+Developer=Success^2
  • If you don’t achieve results within a few hours, you are probably doing it wrong. Try a different approach
  • Get crude results quick, perfect and polish later
  • Scripting languages can be useful for delivering quick results
• Re-use, don't re-invent the wheel
  • Most problems have already been solved, although often not by the preservation community
  • Someone else in the room will have experience of other tools to try
  • Experiment with existing solutions first
  • 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
  • Think about how someone else will integrate your tool in a workflow
• Make it easy to use, build on, or re-purpose
  • Share your source
  • Automate your build
  • Package for easy install
• Share outputs, exchange knowledge, learn from each other
  • Write up your experiences and share them (sharing less than successful experiences is just as valuable as successful ones!)
  • Publish results for evaluation and comparison with other tools
  • Shout about it, blog it, tweet it, and [add a tool registry entry]

This manifesto was developed from wiki posts by Maurice de Rooij, along with discussions over the years with clever people such as Andrew Jackson, Carl Wilson and David Tarrant.

See this page for more on SPRUCE Mashups.