That's a very interesting question. There are so many things you can look at. How is the documentation? Who are the primary maintainers? How are they funded? What are their motivations? Are the primary maintainers active on Stack Overflow, Reddit, Discord, etc...? How many contributors are there? How does their Github issues page look? What about the Github discussion page? How many maintainers are there total? How many downloads per week on NPM (for JS libraries)? From all of these things - how long do you expect this library to be maintained? And that's just the initial qualification research, nothing about how it will impact the actual code-base.

What did I miss? What's the best answer you've ever heard? How do you evaluate 3rd party dependencies?

You missed: look at the actual code.

Stars only mean something because of the people who do. They're the ones leading the herd. If you're just going off the social signals, then you're just monitoring where the herd is going.

Yep, this one is the headline item for me. Look at the code and, if it has further dependencies of its own, look at the code for those too.

The main question I'm asking myself while looking at the code is: if I had to fork this thing and maintain it myself, how would I feel about it? Because sometimes that happens.

You overlooked what I consider to be the first thing you should check — when was the repository last committed to. There are countless projects that rank high on every other metric, but are essentially abandonware.

Yeah good point... definitely something I would have checked, forgot to put it in the list. I'm baffled people have trouble coming up with more than "number of stars" for this.

Of course there can be libraries that are more or less "finished", so the last commit/frequency of commits isn't on its own a deciding factor, but in proper context/holistically it is definitely an important metric!

FWIW, I am not baffled by that, as the vast majority of programmers are not "talented professionals" (which is the specific category of potential employee I was balling at, along with enterprises and venture capital firms). So like, you ask your question, they say "star count", and you don't have to really continue the interview.

(When I was in high school, I used to work for a pre-Internet company that helped people pre-filter interview candidates for ads posted in classified sections of newspapers and what they did was have questions like this that could be asked by people well before they reached your calendar for an interview.)

However, some language ecosystems are more OK with "finished" software than others. It hasn't had a commit in 4 years because none were necessary. Needing constant updates is a sign the local ecosystem is driven by churn over quality.

I don't really think this generalization holds. TeX is one of the very few widely used pieces of software that's considered complete, more or less everything else is either getting updated or superseded by other things.

Clojure, Elixir, and Lisp (especially Clojure) all have slower acceptable churn rates than other language ecosystems. If it works sensibly (both in terms of being fully debugged and ergonomics) and the underlying system hasn't had significant changes, what good does a commit within the past six months do beyond signaling to the GitHub meta game?

A NFA library, for example, probably doesn't need to be constantly updated.

If you avoid building on something that's constantly shifting (the web) then the need to update goes down significantly.

Insights -> contributors, and number of active maintainers based on entire commit history of the project and frequency of commits. Also, network page which shows number of active forks. Also, PRs, and how are they handled.

Contributors is the most informative page for me. So many projects are 1 man show basically all the time. I don't mind that, it means passion, but it also mean it can dissaper any moment depending on circumstances.

I also look into issue details to see how maintainers communicate with community members that do due dilligence before aksing for help.

> How do you evaluate 3rd party dependencies?

I actually blogged my answer to that exact question recently (shameless plug):

https://philbooth.me/blog/how-to-evaluate-dependencies

I'd add support to that list. When it breaks, can I cut a contract and get an expert available to diagnose the problem within a few hours. Production outages are not the time for self help and digging around in other peoples code bases.

What kind of answer would make you happy?

I prefer to look at the recent commits, or any recent activity on the repo's issues, but I would like to know what else can be used as an indicator.

So, ask yourself for a moment: what is it you are actually caring about?

I'd like the project to not introduce security vulnerabilities or bugs into my code. I thereby care what language it was written in, what libraries they use, what their testing and QA/CI process is, and whether it is being used by any "critical" projects (like, if that library is embedded in Chrome, you have to bet there are tons of people like me every day trying to hack it).

As part of that, I care about if the project takes a cavalier attitude towards contributions: if I see a number of pull requests from random "contributors" being casually accepted, that is going to be a major major red flag; if possible, I want to see a core team doing most of the development and integration (and not merely most of the "review", add I see in some projects where the people in charge feel above doing work).

I definitely care that the project is being maintained and that there are people paying attention to issues, and it needs to have a culture of taking bug reports seriously... nothing is more dangerous than a project that tries to pretend they are responsive using bots to "automatically close" issues: I'd rather see bugs open for years than worry a critical issue was reported and subsequently lost.

I am certainly curious how work on the project is funded and whether I can trust that its license is going to hold constant over time: I don't want to end up relying on a dependency that is really the pet project of a small startup that is either going to disappear next year or will decide to redirect development to a closed-source fork. I'd thereby also prefer the project be run by a core committee of participants from multiple companies.

I honestly can't imagine caring two shits about how many stars a project had on GitHub... hell: what if the project isn't even on GitHub? What then? Do you just give up and decide it sucks? A world where everyone feels any incentive at all to put their code on a centralized platform is one where we have all failed as stewards of the future of software :(.