Furthermore, the open-source user community (those peers) is not
shy about nailing bugs, and its standards are high. Authors who put
out substandard work experience a lot of social pressure to fix
their code or withdraw it, and can get a lot of skilled help fixing
it if they choose. As a result, mature open-source packages are
generally of high quality and often functionally superior to any
proprietary equivalent. They may lack polish and have documentation
that assumes much, but the vital parts will usually work quite
well.
Besides the peer-review effect, another reason to expect better
quality is this: in the open-source world developers are never forced
by a deadline to close their eyes, hold their noses, and ship. A
major consequent difference between open-source practice and elsewhere
is that a release level of 1.0 actually means the software is ready to
use. In fact, a version number of 0.90 or above is a fairly reliable
signal that the code is production-ready, but the developers are not
quite ready to bet their reputations on it.
Looking at Linux distributions is another good way to find quality.
Distribution-makers for Linux and other open-source Unixes carry
a lot of specialist expertise about which projects are best-of-breed
— that's a large part of the value they add when they integrate
a release. If you are already using an open-source Unix, something
else to check is whether the package you are evaluating is already
carried by your distribution.