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
- …has a codebase with a long source history
- …took an estimated 23 years of effort (COCOMO model)
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.