Just about every software project uses massive amounts of open source libraries. Sometimes carefully chosen, often mostly pulled in via transitive dependencies. Some projects are very aware of what they use, other’s are happily ignorant about it. In almost all cases it is wise to keep a catalog and some idea about the quality of the code you depend on.

There are several ways to keep a catalog. A very formal way is to evaluate everything using some sort of open source maturity model. Based on the score you can make a judgement, or at least indicate the risks involved. A very informal way could be to describe a project shortly in words. This is obviously not as scientific as it should be, but at least you are forced to spend some time thinking about what you will make your project depend on. I like the Ohloh summary format for projects:

In a Nutshell, Jackson JSON processor…

• …has had 1,970 commits made by 3 contributors
  representing 90,577 lines of code
• …is mostly written in Java
  with an average number of source code comments
• …has a codebase with a long source history
  maintained by one developer
  with decreasing year-over-year commits
• …took an estimated 23 years of effort (COCOMO model)
  starting with its first commit in March, 2008
  ending with its most recent commit 2 days ago

When you are forced to write about statistics like this, you find out interesting facts about a project like: “maintained by one developer”…  interesting. Better find an alternative, or start contributing.