In order to keep it truly open, SGI formed the OpenGL Architecture Review Board (ARB), a group of companies with a vested interest in OpenGL's success (such as SGI, 3D Labs, and nVidia), as well as one or two companies with a vested interest in its failure (such as Microsoft). Through the ARB, formalized extensions to OpenGL are proposed and implemented, and occasionally they make their way into the mainstream API.
The way that OpenGL manages the hardware is that it gives the notion of "contexts," much like a process context, to the client program. The program is responsible for choosing which of its own contexts is active, and the OpenGL implementation is responsible for keeping track of the contexts' states. Because of the large amount of state stored in 3D accelerators, such as texture data, transformation matrices, and lighting, the underlying video card generally only stores one context at a time, and it is up to the OpenGL driver to ensure that the video card's context is the one which the currently-running program thinks it is. Otherwise, disastrous results happen - anywhere from displays being garbled to the entire system crashing.
To further complicate the issue, in most cases, the 3D hardware is part of the normal 2D video card. The typical setup in a UNIX environment is to have every process isolated from one another, and having all of the video managed by the X server. However, for decent performance, programs need direct access to the underlying hardware. This causes a conflict of interest, however, as not only does this circumvent the implicit protection of the X server, but it also requires that programs be able to directly write to the hardware, which is inherently insecure.
Operating systems such as Windows typically have no notion of protection. Operating systems such as IRIX have typically had OpenGL included from the ground up. Linux, however, has traditionally lacked the features necessary to include OpenGL in a secure but efficient way.