VISION

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