4 ms·

People use stars to get a gutcheck on how serious a project is. I'll be honest, I've been trained to look at Github stars, most recent commits, and how responsi

People use stars to get a gutcheck on how serious a project is. I'll be honest, I've been trained to look at Github stars, most recent commits, and how responsive the project is to issues to see if I should use something...

latchkey 3y ago
I look to see if a project has a test suite and how many open issues without any response.
verbify 3y ago
I look at 'most recent commits', but sometimes with smaller pieces of software, no commits for a year or two can mean it's very stable and it does that one thing very well...
chaxor 3y ago
This is ridiculous, obviously flawed in its efficacy. My way is way better - just simply look at the entire code base, read every file, make sure nothing phones home, internally criticize the design choices, realize I could have written something way better, start on the project, get halfway done, realize I wasted a lot of time trying to do a stupid project just to save a few keystrokes on a tiny program I almost never use, give up, and finally, realize I didn't want that package anyway. Clearly. obviously. better. (There's probably a krazam on this, but /s if anyone needs it)
- pizzafeelsright 3y ago
  I don't remember posting this comment.
- marcus_holmes 3y ago
  I have no idea why you're marking it /s. This is my life
- athorax 3y ago
  undiagnosed ADHD be like
- taneq 3y ago
  This is the first time I've run across Krazam and wow this is hilarious. Thanks!
paddy_m 3y ago
I first check projects for regular commit history, and long commit history. Next I try to read through issues and PRs to see how the maintainers deal with the community. Finally I try to develop a bit with the package. Stars generally don't factor in.
SkyPuncher 3y ago
Yep. When we evaluate new open source packages we look at a lot of factors, but they include stars, age, commit frequency, issues, etc. * stars - the likelihood that an issue affecting us will affect someone else. More people affected, the more likely it gets fixed. * age and commit frequency - old projects with continuous commit history are preferable. It's okay for recent commits to become trivial/minor. Likely a sign of mature software in a maintenance mode. It's _very_ concerning when there are no commits. * issues. This is typically a lot harder to simulate simply by buying likes. There are four factors here: * Do the number of issues line up with the seeming popularity of the project? * Do the types of issues line up with the types of problems you'd expect from the project? * Are there any issues, particularly open issues, that block certain functionality or use cases? * Do the maintainers actually interact/discuss issue?
- hobofan 3y ago
  > stars - the likelihood that an issue affecting us will affect someone else. More people affected, the more likely it gets fixed So you are equating stars with adoption, which they are really aren't a good measure of. Even in the most favorable interpretation stars can only serve as a proxy for adoption when used in combination with a lot of other signals. Especially for hyped topics, even ungamed stars are more directly a proxy for interest rather than adoption. And as many startup founders of failed freemium products can tell you, very often interest doesn't translate to adoption. I had to learn that myself the hard way when I helped create a top 5 starred Rust project at the time (~5k stars), which I can tell you for certain no more than a handful of people outside the company used.
  - SkyPuncher 3y ago
    Well, that's why we don't use stars on their own. As I explained, we're building an aggregate view across a bunch of metrics with human judgement making the final call. Further, we're often comparing against alternatives so this isn't really a Yes/No type of thing (especially on stars). It's a general sense of a project's well-being and stability. ---- LangChain is a great example: * 44k stars, 5.1k forks * Roughly 8 months old (very young) * Very active commit history * Insane number of issues * Lots of open PRs This is a tool that we'd be hesitant to use without proper risk mitigations. It's young, it's moving very quickly. While it has a lot of visibility, it's not clear if that's all moving in the right direction. By contrast, underscore: * 27k stars, 5.6k forks * 11+ years old * Stalling commit history * Some issues, but not many. * Not many open PRs This is clearly a project on the opposite side of the spectrum. If you didn't know about mature alternatives (lodash, rambda, etc), it'd be a safe project to approve.

latchkey 3y ago

I look to see if a project has a test suite and how many open issues without any response.

verbify 3y ago

I look at 'most recent commits', but sometimes with smaller pieces of software, no commits for a year or two can mean it's very stable and it does that one thing very well...

chaxor 3y ago

This is ridiculous, obviously flawed in its efficacy. My way is way better - just simply look at the entire code base, read every file, make sure nothing phones home, internally criticize the design choices, realize I could have written something way better, start on the project, get halfway done, realize I wasted a lot of time trying to do a stupid project just to save a few keystrokes on a tiny program I almost never use, give up, and finally, realize I didn't want that package anyway. Clearly. obviously. better. (There's probably a krazam on this, but /s if anyone needs it)

pizzafeelsright 3y ago
I don't remember posting this comment.
marcus_holmes 3y ago
I have no idea why you're marking it /s. This is my life
athorax 3y ago
undiagnosed ADHD be like
taneq 3y ago
This is the first time I've run across Krazam and wow this is hilarious. Thanks!

paddy_m 3y ago

I first check projects for regular commit history, and long commit history. Next I try to read through issues and PRs to see how the maintainers deal with the community. Finally I try to develop a bit with the package. Stars generally don't factor in.

SkyPuncher 3y ago

Yep. When we evaluate new open source packages we look at a lot of factors, but they include stars, age, commit frequency, issues, etc. * stars - the likelihood that an issue affecting us will affect someone else. More people affected, the more likely it gets fixed. * age and commit frequency - old projects with continuous commit history are preferable. It's okay for recent commits to become trivial/minor. Likely a sign of mature software in a maintenance mode. It's _very_ concerning when there are no commits. * issues. This is typically a lot harder to simulate simply by buying likes. There are four factors here: * Do the number of issues line up with the seeming popularity of the project? * Do the types of issues line up with the types of problems you'd expect from the project? * Are there any issues, particularly open issues, that block certain functionality or use cases? * Do the maintainers actually interact/discuss issue?

hobofan 3y ago
> stars - the likelihood that an issue affecting us will affect someone else. More people affected, the more likely it gets fixed So you are equating stars with adoption, which they are really aren't a good measure of. Even in the most favorable interpretation stars can only serve as a proxy for adoption when used in combination with a lot of other signals. Especially for hyped topics, even ungamed stars are more directly a proxy for interest rather than adoption. And as many startup founders of failed freemium products can tell you, very often interest doesn't translate to adoption. I had to learn that myself the hard way when I helped create a top 5 starred Rust project at the time (~5k stars), which I can tell you for certain no more than a handful of people outside the company used.
- SkyPuncher 3y ago
  Well, that's why we don't use stars on their own. As I explained, we're building an aggregate view across a bunch of metrics with human judgement making the final call. Further, we're often comparing against alternatives so this isn't really a Yes/No type of thing (especially on stars). It's a general sense of a project's well-being and stability. ---- LangChain is a great example: * 44k stars, 5.1k forks * Roughly 8 months old (very young) * Very active commit history * Insane number of issues * Lots of open PRs This is a tool that we'd be hesitant to use without proper risk mitigations. It's young, it's moving very quickly. While it has a lot of visibility, it's not clear if that's all moving in the right direction. By contrast, underscore: * 27k stars, 5.6k forks * 11+ years old * Stalling commit history * Some issues, but not many. * Not many open PRs This is clearly a project on the opposite side of the spectrum. If you didn't know about mature alternatives (lodash, rambda, etc), it'd be a safe project to approve.