Wizard originally grew out of a simple itch for MIT Scripts autoinstallers: we had grown a suite of tools for letting users easily install web applications, but we had been completely negligent in keeping these applications up to date. There was automation to be built, and Wizard originally was meant to let us perform updates on these autoinstallers. As subsystems started being built, I started to notice that Wizard was starting to develop into something more generally applicable than just "mass upgrades for Scripts autoinstalls"-- perhaps the first instance of this was when I noticed that there wasn't really any good reason that 'wizard upgrade' couldn't be run by the user, and not just us in the process of a mass upgrade. Wizard wants to solve three problems: 1. It is a better package manager for web applications. This means making it easy to install and upgrade web applications, all of which may be coexisting on the same machine (something traditional package managers don't manage well.) It also means bringing a /consistent/ interface for maintaining all applications it supports. 2. It solves the problem of maintaining your own patchsets on top of an application, and not just getting those blindly written over and getting intelligent merging and conflict markers of these patches. 3. It enables to do this on a large scale, on the order of thousands of installs. To do this, we also standardize an interface for backing up filesystem and non-filesystem data as well.