As a programmer I spoke from that perspective but code is certainly not all there is in many projects.
Geeks do tend to be too cute about names and I find that to be asinine, but that's up to the project owner. Most of the time the open source project I may pull in is not user-visible so the name is a lot less important.
As for the installing/configuring, I've hit good and bad on both the open and non-open sides. The open source side tends toward the hobbyist so it may be worse in this respect for a randomly selected project. For many of projects on Linux the package maintainer, whether it be for apt or yum or some other system, often takes care of a lot of the that particular ugliness. I have a far simpler time installing a working web server with [insert backend language here] and [sql backend] using open source tools on Linux than I do on Windows. In many cases its little more than one command "apt-get install X Y X" where it goes out and finds everything, confirms I really want this, and does all the work for me.
I'm not convinced that commercial apps I've used are not just as graphically ugly as many of the open source ones, but then again most of the projects I deal with are libraries so I have less emphasis on the graphical elements. From the big companies, like MS, Apple, or Google, yes the graphical polish will be nicer, but at least many open source projects can get someone to make english sentences in user-visible dialogs unlike my "Smart TV" manufacturer (panasonic).
As for documentation, in the open source world it sometimes does not exist and that is a *major* issue for those projects. In the close source world it make exist more often but can also be completely unusable. I'm not sure which is worse in the end. With one I know from the get-go that I'm on my own or that I have to use community resources. With the other I may struggle with it for a long time before I figure out that I should just ignore the docs and look at what the damn library is actually doing.... but I usually can't.
When it comes to testing I've had poorly tested from each side and no chance of fixing one but some change of fixing the other. There's shit on both sides of the fence.
I'd like to come back to my original point that financial incentives are not the only incentives. I spoke of code because I write code, not because it is the only important thing. It's the thing I can speak of from personal experience. I would argue that other types of work that are done because someone wants to impress others, wants to scratch their own itch, or just wants to help a good cause are often done better than tasks done strictly for pay. Hopefully we all have jobs doing what we love, but when that isn't the case there's a great chance that you do something better in your off time because you really give a shit about it.
Was there a good reason to structure your post as a series of snide questions and a flippant remark?