Answers

·	What are OpenBundles?
	OpenBundles solve existing problems with installation, encapsulation, icon registration and mimetype registration across all desktop systems (i.e. Gnome, KDE, etc). They are patterened after successful solutions from NeXTStep, MacOS X, and UNIX Sysadmin "encap" style package installation. OpenBundles are proposed to initially affect only graphical application installation. However, they have been seen to effectively organize everything from screensaver modules, to development frameworks (libraries and headers), to command line tools in past implementations. In addition, OpenBundles offer these other advantages: Locating resources for Localization Multi-architecture applications "Native" looking applications built with scripting languages No Windows style "registry" to maintain
·	Why do we need OpenBundles?
	Our mission statement pretty much sums it up: Distributors of third-party software should be able to build one install package which works on all UNIX systems. Desktop users should be able to easily download and install applications and locate those applications wherever they like on their machine. We need a method for simply and easily distributing binaries of third party software, such that they can be installed easily and simply. That distribution and installation method should provide application icons, mimetype registration, and any other services. Building the package should be independent of whether the end user of are using Gnome, KDE, GnuStep, or some other desktop system. The developer should only have to distribute one application package which should work on any system.
·	How do OpenBundles Work?
	At their simplest, OpenBundles locate all unmutable files for an application under a single subdirectory, and change application installation from an active operation on the part of a package system, to a passive one. Instead of requiring the package system to actively install data into Gnome, KDE, or other configuration systems, the application merely provides a passive set of information about itself. When a desktop system starts up, it can quickly scan the known application directories for applications and add their meta-information to the desktop filemanager. Any application which the user browses to outside of the known application directories is instantly recognized because of it's OpenBundle definition and can be launched immediately. Configuration information, preferences, and other mutable data should all be stored in some configuration system outside of the OpenBundle, and should not be required. This assures that installing an application on a machine is as simple as copying it's OpenBundle onto that machine, regardless of which desktop system, or even which architecture, that machine is running. Please read the Intro Article and Implementation Proposal for a complete description of OpenBundles.
·	I thought KDE and Gnome already solved these problems.
	KDE and Gnome have different standards for installing application icons and mimetypes. Worse, the installation system used must include the scripts which make the proper changes to Gnome and/or KDE based on the system which an application is being installed onto. The OpenBundle standard establishes a single way for applications to be represented when installed. Gnome, KDE, or other desktop systems are then free to passively interrogate the information inside the application bundle and represent the discovered information in their own ways.
·	I thought RPMs already solved these problems.
	RPMs are a mechanism for packaging changes which are made to specific parts of the filesystem while installing an application. RPM is not part of application launching or the icon, mimetype, and capability discovery process. Changes are required to the desktop systems themselves to fix these problems. OpenBundle is one such proposal. Applications distributed in OpenBundles may be distributed in RPM packages. Because they are fully relocatable and require no active-install scripts, they may also be distributed in simple .tar.gz or .zip compressed archives.
·	How are OpenBundles better than the Windows registry?
	Whenever applications are installed on Windows, the install wizard adds entries to the registry to (a) tell the OS where to find the application, (b) register any icons for the application, (b) register which document mimetypes and extensions this application can handle, (c) register the uninstaller. This method means that the data for an applicationt to correctly run is located in two places. The datafiles for the application are located in the install directory, while the registry contains information about where to find the application and what filetypes it handles. In fact, once you put a shortcut on the desktop or in the start menu, there are three different places which know about the application. Because these three systems have to be in sync, you can't touch an application without breaking it. If you want to do anything with an application you have to uninstall and reinstall. If you run out of space on a disk, and you want to move an application, you have to reinstall. If you want a new version of an application out of commission for a while as you do something with the old version, you have to uninstall it. Furthermore, sharing applications between machines over a network is complicated. There is no network layer to share registry entries or start menu items. Therfore you have to reinstall the application on every machine on the network if you want it to work at all. Unless you have purchased complicated software which can network install all the registry entries correctly, this means manually installing that application on each machine.
·	How did Bundles work in NeXTStep?
	See the Reference of other implementations.
·	Why not keep the directory in a single file such as .jar, .zip, or .wad file?
	In fact we would prefer to do this. However, most APIs are designed to handle individual filesystem files, and operating systems can only load shared library objects from individual filesystem files. In order to remain compatible with these existing mechanisms, the resources within an application bundle must be distinct files on the filesystem. While it might be possible to use single .jar style archive files using a loop filesystem device, VFS layer, or other trickery, such implementations would be unlikely to remain portable across different UNIX systems.
·	Why not use the exact same format as MacOS X bundles?
	In fact this is being considered. Currently we do not have thorough enough documentation of Apple's bundle standard for MacOS X to stay the same. If Apple standardized this bundle format we would certainly follow their guidelines.
·	Why dosn't the Parallel Install Standard address this?
	This standard advocates that packages use unique names for files they install. This is a good guideline, but the standard fails to address how packages become active. For example, Encap systems automatically build symlink directories to select certain versions. These trees might be built into /usr/local/ or ~/local/. Furthermore, the standard is pratically advocating that we make /usr/local/bin look like /usr/lib, with many versions of the same binaries named differently, and symlinks pointing around to decide what to run.
·	How is this different from Encap Systems? (more here)
	Encap systems are a good start at solving this problem. Encap systems accept the limitation that UNIX software compiles in hard-coded install paths. OpenBundle requires we update applications to remove this restriction. Many applications, such as those designed for KDE and Gnome, already have some amount of relocation capability. This is part of the reason we wish to start with graphical applications first.