When developing code, you often want to glue in third-party components. If you're writing commercial software, and are pulling in commercial components, it's traditional for the manager deciding to be motivated by Fear or Greed. That is, to either buy from the biggest vendor (No-one Got Fired For Buying IBM), or the one offering the biggest freebies and kickbacks (a nice meal out with the vendors, you say?). Often the two factors point in the same direction, making the choice especially easy. The actual quality of the software can be completely irrelevant - it's basically marketing-driven.
When pulling in open source software, you can be properly objective, right?
So, what do you look at? You download the various alternatives. Read their docs, look at their APIs, build them and prototype with them. Perhaps look at the source to see what the quality's like. If one has a slight technical advantage, you'd probably go with that?
Wrong choice! You actually still want to go for something a little more like the PHB approach. Technical quality and appropriateness is still vital, but so is the community surrounding the software. You could argue that how they deal with bugs and support are parts of the technical quality, but that's missing the point. If you have to choose between two similar packages, don't choose the one with the minor technical edge, choose the one that'll be around in a few years' time!
What determines this? The momentum. Choose the one which is going places, with lots of happy contributing users, ongoing improvements, and fundamentally where the developers understand marketing. You're not using the product because you're a fool who is easily swayed by marketing, but because others are. It's a networking effect, and you want to be using the winning product.
As a clever developer, it's really cool to find an underdog project that's technically better than the obvious choice. It marks you out as part of the cognescenti. This can even be made to work - if it's technically much better, and you can support it yourself if it goes nowhere, or it's an underdog with clear positive momentum, it can be a good choice. Most of the time though, even in open source, the pure technical choice may not be the right one.