Windows gives you a single implementation of a single desktop on top of a single implementation of a single API / framework, all done by Microsoft.
On Unix systems, you get an API / framework (X11 / X Window System) for which exist multiple implementations (Xorg, Xfree86), on top of which you get various "higher level" API / frameworks (GTK+, Qt, ...) because raw X11 is so primitive, on top of which you get various desktops (Gnome, KDE, ...), all done by different people.
Moreover, the X11 system has been designed from the ground up with remote GUIs in mind - i.e., a lokal machine displaying the GUI of a remotely running application - which introduces the concepts of a "X Server" and "X Client".
Then there is a nomenclature that "feels" the wrong way around for newcomers: Your local machine is running the "X Server" providing the "display a GUI" service, while the remote machine is the "X Client" making use of the services on your machine to display the GUI.
Well, that's the quick overview; once you got that sorted out, understanding any articles / forum posts on the subject should become much easier.
Edit: To answer the two first comments of the OP.
Yes, "X11" is merely a protocol, and Xorg / XFree86 are two implementations. At its basic level, X11 is only about drawing lines and dots, which is not terribly useful if you want to do a GUI.
On top of the X11 protocol, people implemented many things, and it is pretty difficult to do a 1:1 comparison with Windows because Microsoft never bothered to really keep things separate. Also I am not a GUI-type developer, i.e. my actual experience with either system is minimal.
At the bottom, a "window manager" provides a window (handling borders, close / minimize / maximize buttons, resizing etc.), and offers the "real estate" within the window to the widget toolset. There are many window managers, some mimicking other systems (Windows, MacOS, AmigaOS, whatever), and they are mostly interchangeable transparent to the remaining system.
The "widget toolset" offers you buttons, sliders, text fields etc. on which to build your GUI. This is what you (as an application developer) actually get to "see", API wise, and what decides most of the "look & feel" of your application.
A "desktop" builds a number of applications on top of a certain widget toolset / window manager combination, in order to provide a consistent look & feel. You don't have to bother with these unless you actually want to develop the desktop itself.
The desktop "Gnome" uses the widget toolset "GTK+" on top of the window manager "Metacity".
The desktop "KDE" uses the widget toolset "Qt" on top of the window manager "KWin".
Note that especially those two, GTK+ and Qt, have evolved far beyond simple "widget toolsets" into "application development frameworks". If you want to develop GUI apps for Linux, effectively you have to pick which one of those two you want to use. There are more choices, if you want a more "lightweight" app (not needing the big library dependencies), but today most systems have GTK+ and Qt libs already installed anyway.
It's perfectly possible to use Qt apps on a Gnome desktop or GTK+ apps on a KDE desktop (it wasn't always like that), so you have to worry little about compatibility. Given a choice between two apps of comparable functionality, people will usually prefer the app using the "native" widgets of their desktop of choice, but I wouldn't worry about that.
Other, more important bullet points in the choice of "widget toolset": Licensing terms, support for your language of choice, cross-platform compatibility.
Post Scriptum: Coming back several years later, I've picked up some GUI programming experience of my own, and realize one thing is missing in the above explanation if you're looking for a "which way to go" advice: wxWidgets. This is a framework that builds on top of whatever you're using natively, and allows transparently portable GUI development, without sacrificing performance or having any licensind strings attached. C++ API. It's the path I've chosen for my GUI needs, and I felt it should be mentioned for completeness.