All of these implementations share two things in common. The most prominent (though technically least important) feature is that they are all based on Mesa at their core. This is necessary for both Utah-GLX and the DRI because not all features are implemented on all hardware, and so the driver needs to be able to fall back for software rendering in order to correctly render unsupported features. Technically neither DRI nor Utah-GLX drivers need be based on Mesa, however, and they can feel free to use any other OpenGL-conforming backend (or even non-conforming backends for increased, if inaccurate, performance).
The other feature that all three driver architectures share is that the rendering library can get directly at the hardware in some circumstance. This is always necessary for the greatest possible performance. Utah-GLX and the DRI are very similar in their methodology, namely in having the X server delegate authority between the different client programs.
DRI is very similar to fxMesa in that they both use a kernel module for the low-level hardware access, and that the client program directly links in the low-level hardware driver. In this way, fxMesa appears to be somewhat of an intellectual precursor to DRI. Utah-GLX, when run as root, is even more similar to fxMesa due to the nature of the unbridled, insecure, and unreliable direct hardware access, except that even when run as root, Utah-GLX still communicates with the X server in order to synchronize events, whereas with fxMesa there is no need, due to the clear separation between the 2D and 3D graphics hardware.
Although fxMesa, Utah-GLX and the DRI were all separate projects, there is a clear evolution between the three. More to the point, the DRI is basically a combination of Utah-GLX and fxMesa into something which is actually usable, robust, and stable.