Not that it's hard, anyway. You don't need any actual libraries to use OpenGL. You just need up-to-date headers, and a way to link to the system's OpenGL library. The easiest way to get those is to use an extension loading library, which provides those headers, links to OpenGL at run-time (same thing that Direct3D does) and makes all of the available extensions available automatically.
Complaining about libraries like GLUT, GLFW, or SDL is completely irrelevant. If you were using Direct3D, you'd be writing windowing code directly on top of the Win32 API, which you can still do with OpenGL. If you want to use one of these libraries to handle the platform-specific windowing and OpenGL setup, you can. You don't have to - even in portable games, you can still just write your own platform-specific windowing and OpenGL setup code.
So the development setup and libraries are different. So what? It's fairly simple to work out for anyone but a complete beginner. On platforms like iOS or Mac OS X, OpenGL is actually trivial - everything you need is included in the platform's SDK. Same with Android. Same, to an extent, with Linux. OpenGL is only really awkward on Windows, and you can guess who's to blame for that.
But there are plenty of legitimate complaints about OpenGL.
The API is much more complex than Direct3D. There are dozens of ways to do things, with no way to tell which is the best way (short of looking at what Direct3D is doing, and copying that). Behaviour and performance is inconsistent between driver vendors, versions of driver from the same vendor, and across platforms. Some OpenGL drivers (Intel's on Windows, until very recently) are effectively unusable, or don't expose all of the hardware's functionality that Direct3D does. There are lots of legacy issues to carefully creep around, and they can still bite you even if you're not using the legacy features. The shader compilers aren't consistent between different vendors, and are often incredibly slow. Linking shaders is kind of clumsy. Since the API and drivers are much more complex, it's more common to run into severe performance issues caused by the driver than it is with Direct3D (and consoles are better than Direct3D in this regard, because their graphics drivers are so thin that they essentially don't exist).
Even picking a decent subset of OpenGL to use is a pain. Do you use OpenGL 2.x and ignore large chunks of it to get a reasonable API, and broad support? Do you go for OpenGL 3.x or 4.x instead? Which version? Which set of extensions? It's dead easy for OpenGL ES, though - 1.x (fixed function) or 2.x (shaders), neither of which carry around the legacy crap that OpenGL still carries.
Dealing with all of that is the problem with using OpenGL, not working out how to link to it.
Oh, and documentation. That really is shocking, mostly because the majority of documentation or guidelines you might find are written for OpenGL 1.x, and are completely obsolete.
There are some good beginner-level guides to getting started with modern OpenGL:
http://www.arcsynthesis.org/gltut/ (OpenGL 3.3) http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Tab... (OpenGL 2.0, not using the legacy stuff)
