X Window System Protocols and Architecture - Design Principles

Design Principles

Bob Scheifler and Jim Gettys set out the early principles of X as follows (as listed in Scheifler/Gettys 1996):

• Do not add new functionality unless an implementor cannot complete a real application without it.
• It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
• The only thing worse than generalizing from one example is generalizing from no examples at all.
• If a problem is not completely understood, it is probably best to provide no solution at all.
• If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also Worse is better.)
• Isolate complexity as much as possible.
• Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.

The first principle was modified during the design of X11 to: Do not add new functionality unless you know of some real application that will require it.

X has largely kept to these principles since. The X.Org Foundation develops the reference implementation with a view to extension and improvement of the implementation, whilst keeping it almost entirely compatible with the original 1987 protocol.