We at OpenVZ use kernels from Red Hat Enterprise Linux as a base for our OpenVZ kernels. This is because vendors such as Red Hat invest a lot of work into making their kernels really stable. The usual recipe for a super-stable kernel is to pick a mainstream kernel and marinate it in QA for at least half a year (more for the best results), doing bugfixing and cherry-picking of fixes and driver updates from the mainstream. This way one have enough time to test it, plus (at least in theory) one get new fixes but do not get new bugs slipped into one's kernel. This is what Red Hat (and other guys such as Novell/SUSE) does for their kernels, and believe me it's quite a lot of work to do, and the end result is of great value.
Here comes the beauty of free software: now everybody can use the result of Red Hat's work. Yes, this is exactly what we do. At this point you might stand up saying: all right, Red Hat invested a lot of resources into something you use for free, this does not look like a fair deal.
Fortunately I have a good answer. Here is the list of bug (i.e. software defect) reports that were fixed in Red Hat Enterprise Linux kernels thanks to OpenVZ team (in some way): #405521, #247379, #205335 , #210852, #168659, #243252, #207463, #228461, #243263, #224541, #232209, #232211, #239767, #220971, #400651, #214778, #203894, #212144, #215715, #241096, #241096, #439670. These 22 bugs are all kernel bugs, most are security-related (and therefore quite serious). Almost all the bug reports from the list include patches (i.e. changes to code to fix a problem reported), so those are not like "hey, you have a problem", but rather "you have a problem and here's the solution".
The majority of those bugs were found while testing OpenVZ kernels. This is what we contribute back. This is also a lot of work and of great value -- some of those bugs were really hard to find and/or fix.
The latest (23rd) addition to the above list is bug #454865, which is actually a regression in a new version of RHEL4 kernel. Again, this report not only includes a clear description of what's wrong, but also a test case program which reproduces the bug, and a patch to fix it. Clear test cases are very important because those can be included into a validation test suite, to make sure bugs are not popping out for the second time (which sometimes happens in the real world).
This is just one example, a close-up picture. The big picture is free software developers and users helping other developers and users. Unus pro omnibus, omnes pro uno.