* I look at the code and determine, subjectively, whether this was written by first-rate developers or monkeys. I will consider this from various angles ranging from the overall program organization, to the details of how the programming language is used. If I spot bugs in this inspection, I will skip the project and look for something else. In particular anything that is a security flaw or could cause a crash is an instant deal-breaker. Not because everyone should be perfect and write error-free code the firs time, but because I was able to find it just by casually looking, whereas the maintainers have been working with that code for months and are blind to it---that erodes my confidence in the developers.<p>* I will look for a regression test suite: how extensive is it? If you don&#x27;t see any tests, that&#x27;s a big warning sign.<p>* If you don&#x27;t see any documentation, another warning sign: the behavior is not specified and could change.<p>* Who <i>uses</i> it?  If the code is reasonably widely used, that de-risks it for you quite a bit, particularly if the existing uses resemble your intended use. They trod through the code paths before you and uncovered the bugs.<p>* Lastly: if need be, can I just maintain this myself? How easily forkable is the thing? This point can overcome some other issues.  If some code is 95% of the way there, and is organized in a good way that I can take it the last 5%, I might just do it.