1. The License\u2014The most restrictive open-source license is the General Public License (GPL), but it applies only if you intend to modify the software and redistribute it. Vendors have to make the source code for their changes available or work out a deal with the copyright owner to be released from the GPL. (The Free Software Foundation, which developed the GPL, is now in the process of revising it.) If you have no intention of distributing your modifications to software governed by the GPL, or anything integrated to it, then GPL is fine. But if there\u2019s any chance you may distribute it outside your company, you should purchase an indemnified version. 2. The History\u2014If the open-source project is just getting started, it may not survive. The developers\u2019 initial enthusiasm can wane; the software may encounter bugs that can\u2019t be fixed; users may abandon the project if something better comes along. You don\u2019t want to end up with an orphan product, unloved and unsupported.3. The Community\u2014Most successful open-source projects have a leader who is respected by the developer community and is willing to delegate important pieces of the work to others. Delegation creates a healthy environment that attracts new developers. Look for projects that have a clear process for joining the community, for managing the project and for making contributions. Find the central communication core for the project (a message board or e-mail list) and read the history. 4. Code Ownership\u2014Companies are more likely to attract capital and build trust with customers if they own the copyright to the code they support and their developers are the project managers and primary contributors to the code base.5. The User Community\u2014Projects involving complex software need big, active, happy user communities. Big communities mean that the software is filling an important need and that it works well enough for users to invest time trying to make it better. Small, unhappy user communities usually mean the project is poorly managed or the software is flawed. Again, check the main discussion board.6. The Coverage\u2014Open source thrives only when it is attractive to a large group of users. That\u2019s why the most successful projects have been platform applications that can be used in virtually any company. Industry-specific or niche applications do not attract large communities. 7. How It Integrates\u2014Open source is usually designed to fill a specific gap or fix a specific problem, often without concern for how the software will play with others. Check bulletin boards to see if the project\u2019s developers are open to solving user integration problems. If they\u2019re not, tread carefully.8. Commercial Support\u2014This is one of the better indicators of a project\u2019s health. For CIOs who cannot afford to devote staff time to support, a robust commercial support ecosystem is critical.9. Your Costs\u2014It\u2019s easy to get carried away when something is free. Normal due diligence for open source is still in order because implementation time isn\u2019t free.10. Proof of Concept\u2014Don\u2019t overlook open source just because it doesn\u2019t scale or have all the bells and whistles. It can make a great testing platform or a proof of concept for a larger project that will use proprietary software.