First and foremost, you now have to contend with GPLv3, the recently updated version of the Free Software Foundation's General Public License. GPLv3 imposes restrictions on digital rights management and embedded Linux that might prove troublesome if your company plans to resell code based on open source.
GPLv3 applies to a minor part of open source code so far. Only 693 projects are issuing code under it. By comparison, 5,219 projects license under GPLv2 "or later," meaning the same code is available under both licenses. GPLv2 projects were never expected to convert en masse to GPLv3. That will happen gradually as developers decide on the merits of GPLv3 when releasing new or updated software.
The reliability of Linux, Apache, and Samba is well established, but that's not the case with newer projects. If you're assessing prototype code, project mailing lists provide a view into issues and features and give potential adopters a sense of what to watch out for. A list that airs a bug or security exposure also will supply the dates around when a problem appeared and got fixed. A project that has a major exposure that endures for six months might be code to avoid.
Sites such as SourceForge.net and Ohloh.net provide stats on a project's activity level. How many contributors are there? How frequently is code posted to the core build? How many bugs are awaiting fixes? The degree of activity can be signs of whether a community is thriving or waning.
There are a few ways that new code can be quickly vetted. Tools shown to work inside the Eclipse programmer's workbench or applications that work with OpenOffice.org have already passed a fundamental test of reliability and compatibility. Software that's been OK'd for inclusion in one of the software stacks, such as LAMP (Linux, Apache, MySQL, and Perl, Python, PHP) is another quick measure of reliability. SpikeSource, Covalent, Red Hat, Novell, and SourceLabs vouch for certain pieces of code working together. Sun Microsystems also tests and distributes PostgreSQL, MySQL, and the Apache Foundation's Derby Java database to work with Solaris and other Sun software.
Such ratifications by experienced groups are important. But you don't want to get in the situation where the software is theoretically compatible but the companies or groups behind it aren't and will stop short of troubleshooting joint operational problems.