I had to read this headline once. Then twice. Then a third time, really slowly, to actually parse its meaning. After doing that, I was fed up with the article already so didn’t read it.
Probably a simple way without looking at ANY code is to just look at a few key points on GitHub (or GitLab or other):
Stars This is the number of people who have favourited the package. In general, if a package has more stars (500+, 1000+) it is probably good and has had a lot of people looking at it and using it. Beware packages with only a few stars (fewer than 20, but context matters.)
Forks Also look at the number forks the repo has. In general, the more forks it has, the more people in the community have contributed to it, fixing bugs, tightening security, etc. Again, the more eyes the package has on it, the higher the chance that key vulnerabilities have been identified and fixed.
Number of Contributors same reason as forks.
When last the files in the repo were updated Occasionally you’ll find a package that meets the above heuristics very well, but was only last updated 5 to 10 years ago. Avoid these as they aren’t up to date and therefore have vulnerabilities.
All these points are just rough heuristics and there will be exceptions but can generally point even experienced developers in the right direction.
When I retire, I- I don't want to just disappear to an island somewhere. I wanna be the guy who gives everything back. I want it to be, like "Hey, who donated that hospital wing that is saving so many lives?" "Um, well, I don't know. It was anonymous." "Well, guess what." That was Michael Scott." "But it was anonymous. How do you know?" "Because I'm him."
It’s definitely a froth-worthy game. But I played it way back when it came out in 2002. I think nostalgia plays a big role in my enjoyment of it.