This is an interesting idea: why not ship applications that have no customisation options?
One application suite that adheres to the 'zero options' methodology is the Gnome Screensaver family of screen savers. They have rejected requests for a settings dialog, a philosophy which has some validity, but that puts them in conflict with downstream users of the product.
It is clear, therefore, that even for an application as non-critical as a screen saver, many users have expectations that they can somehow customise the application. For something complex, like a database or an application server, expectations may be even higher. However, do users really, really want to spend hours tuning the garbage collection policies of the application server, or indexes of the database, or do they just want something that works out what the appropriate options for the specific installation actually are?
As an example of this, the Sun JVM has the option -XX:MaxPermSize to control the size of the permanent generation part of the heap. It also has an error, OutOfPermGenHeapSpace which is raised when this heap is full. The JRockit JVM does not have a split between permanent and transient heaps, and so does not run out of Permanent Generation Heap Space, except when the entire heap is full. Accordingly, it does not have any equivalent of the -XX:MaxPermSize option -the entire problem has been eliminated, along with the tuning parameter.
Even though SmartFrog can be used to build custom applications, there is no requirement for the configuration options to be pushed out to the end users. They can be given a self-contained system that is integrated and consistent, one that works out the box.