zlacker

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?

>>throw_+(OP)
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.

>>Ethery+x1
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!

>>throw_+(OP)
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.

>>throw_+(OP)
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.

>>jart+w8
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.

>>throw_+(OP)
> 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

>>throw_+b2
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.)

>>Ethery+x1
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.

>>throw_+(OP)
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.

>>BeFlat+kk
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.

>>Ethery+Qt
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.

>>Ethery+Qt
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?