In order to properly work, packages installed by WPM are required to follow a set of guidelines. Programs that adhere to these standards will install and uninstall cleanly and will present to the end user a (mostly) seamless experience when using the WPM package manager (which will be described elsewhere). Closed-source software manages to carve out its niche not because of features, but because they sell an end-to-end solution. The CD is put in the drive, it autoplays, it installs smoothly--if you compare this experience to open-source software, where the experience can be a bit jarring (less on Windows than on Linux, admittedly), it shows obvious reasons one would stick with closed-source software.
REGISTRY ENTRIES
Even Microsoft is telling programmers to avoid the registry as much as possible in favor of user-specific settings in the user's own directory. (Those who do not learn from UNIX are doomed to reinvent it, poorly.) Most open-source applications already do this--certainly the multi-platform ones do or should--and those that don't will need to be provided a library that handles registry entries.
One of the major selling-points of WPM is that outside of its "box," it avoids leaving any traces. Packages can be installed and uninstalled at will, because they don't leave dangling refrences anywhere. If the user wants to uninstall everything, then they just get rid of the WPM client and it all goes away.
Some programs do require some registry alterations. (It'd be nice to be able to hook the registry APIs for just our process, but I don't think that's possible--we'd be hooking them for every program running. Not exactly optimal. So we need an interaction library and (ugh) need to reroute registry changes through the library. For programs with heavy registry use, this could be time-consuming, and alternatives are greatly sought.
PROGRAM BEHAVIOR
Any program that saves and opens documents (for example, OpenOffice) must be capable of taking those documents as arguments to take advantage of Windows' file association. (Games and the like are obviously excepted, as many use a generic extension such as .SAV and would be better loaded in-game anyway.)
Programs can be launched either from the executable (I'm not entirely sure shortcuts are a good idea) or from the WPM program client. The package's XML manifest includes "menuchoice" items that will be used for (obviously) menu choices inside the WPM program client. The user will have the option to create Start Menu shortcuts as well, and this option will be disabled by default in order to acquaint users with the WPM program client's launching capabilities.
All of this is obviously subject to change.