Live data from Hacker News

GitHub's fake star economy

awesomeagents.ai

171–180 of 403 posts

Re: GitHub's fake star economy

#171

Earlier quoted context omitted.

Owners don’t care about winning, but about profitability. And you can make a lot of money with a failing football team (selling/trading draft picks, etc) and your fans get used to losing …

Right, I forgot you guys have "The Draft", so failing is an advantage, doubly so if you can sell your draft picks, because then you can keep losing by having sold away the mechanism for getting you competitive again. I am so glad the proposed "European super league" was killed off so hard, so that we don't get a franchise model, it produces so many adverse incentives.

The thing I like about EU football is that if your team sucks arse through a garden hose too long, your entire team gets demoted to a lower league.

That would put a fire under some asses!

Re: GitHub's fake star economy

#173

Earlier quoted context omitted.

Owners don’t care about winning, but about profitability. And you can make a lot of money with a failing football team (selling/trading draft picks, etc) and your fans get used to losing …

More to the point, in the US losing teams get rewarded in the form of draft picks, which sometimes creates perverse incentives. This doesn't exist in European football. (Disclaimer: I know almost nothing about American sports.)

Draft picks + salary caps and the various workarounds involved there make it more of a financier's dream than a competitive sport.

Re: GitHub's fake star economy

#175

I don't think I have ever used stars in making a decision to use a library and I don't understand why anyone would. Here are the things I look at in order: * last commit date. Newer is better * age. old is best if still updating. New is not great but tolerable if commits aren't rapid * issues. Not the count, mind you, just looking at them. How are they handled, what kind of issues are lingering open. * some of the co…

But to someone else, it is a meaningful metric that you bookmarked something. It doesn't matter that the star isn't you saying you liked something. It's already telling enough merely that you wanted to bookmark it. It's only not meaningful because of how other people can game it and fabricate it, but everything you just said, if it was only people like you, that would be a very meaningful number. It doesn't even matt…

> it still does mean something

Yes...which is why I said it is an indirect variable, as caused by the other things I pointed out above. Age, quality, code, utility, whether issues are addressed, interest, etc. Or fraud. Pretty cut and dry.

FWIW, I almost never star repos. Even ones I use or like. I don't see the utility for myself.

Aim for a more concise post and don't couch your statements in doubt next time if you want a productive conversation, because I don't know what you are trying to say.

Re: GitHub's fake star economy

#176

I don't think I have ever used stars in making a decision to use a library and I don't understand why anyone would. Here are the things I look at in order: * last commit date. Newer is better * age. old is best if still updating. New is not great but tolerable if commits aren't rapid * issues. Not the count, mind you, just looking at them. How are they handled, what kind of issues are lingering open. * some of the co…

I use stars to try and protect myself from dependency confusion attacks. For example, let’s say I want to run some piece of software that I’ve heard about, and let’s say I trust that the software isn’t malware because of its reputation. Most of the time, I’d be installing the software from somewhere that’s not GitHub. A lot of package managers will let anyone upload malware with a name that’s very similar to the soft…

Sure, I suppose that is one solution, but given that buying stars has been around for at least 5 years, and I have been aware of people faking stars for longer than that, I am not sure why you would rely on stars as a primary metric.

There are many other far more useful metrics to look at first, and to focus on first, and to think about. Every time you think about stars, you'll forget the other stuff, or discount it in favor of stars.

Forget stars. They now no longer mean anything. Even if they did before, they don't anymore.

Re: GitHub's fake star economy

#177
post #169

Can anyone explain why on earth VC's are making actual investment decisions based on imaginary internet points ? This would be like an NFL team drafting a quarterback based on how many instagram followers they have rather than a relevant metric like pass completion, or god forbid, doing some work and actually scouting candidates. Maybe the Cleveland Browns would do that[0], but it's not a way to mount a serious Super…

[flagged]

Listening to All In is a real eye opening experience. Especially when they have guests on and they're exactly like the regulars.

Re: GitHub's fake star economy

#180
post #143

I don't think I have ever used stars in making a decision to use a library and I don't understand why anyone would. Here are the things I look at in order: * last commit date. Newer is better * age. old is best if still updating. New is not great but tolerable if commits aren't rapid * issues. Not the count, mind you, just looking at them. How are they handled, what kind of issues are lingering open. * some of the co…

> I don't think I have ever used stars in making a decision to use a library and I don't understand why anyone would I do it all the time, whenever there are competing libraries to choose among. It's a heuristic that saves me time. If one library has 1,000 stars and the other has 15, I'm going to default to the 1,000 stars. I also look at download count and release frequency. Basically I don't want to use some obscur…

> It's a heuristic that saves me time.

A bad one.

I listed many other useful heuristics. Do you not find value in them? Do you find stars more valuable than them?

Take a moment to consider stars as a useful metric may only be useful for packages created prior to ~2015 when they weren't such a strong vanity metric, and are already very well established. This is preconditioning you to think "stars can still sometimes be useful, because I took a look at Facebook's React GH and it has a quarter million stars".

Sure, it's useful for that. But you aren't going to evaluate if the "React" package is safe. You already trivially know it is.

You'll be evaluating packages like "left-pad". Or any number of packages involved in the latest round of supply chain attacks.

For that matter, VCs are the ones stars are being targeted at, and potential employers (something this article doesn't cover, but some potential hires do hope to leverage on their resume).

If you are a VC, or an employer, it is a negative metric. If you are a dev evaluating packages, it is a vacuous metric that either tells you what you already know, or would be better answered looking at literally anything else within that repo.

The article also called out how download count can be faked trivially. I admit I have relied upon this in the past by mistake. Release frequency I do use as one metric.

When I care about making decisions for a system that will ingest 50k-250k TPS or need to respond in sub-second timings (systems I have worked on multiple times), you can bet "looking at stars" is a useless metric.

For personal projects, it is equally useless.

I care about how many tutorials are online. And today, I care more about if there was enough textual artifacts for the LLMs to usefully build it into their memory and to search on. I care if their docs are good so I spend less tokens burning through their codebase for APIs. I care if they resolve issues in a timely manner. I care if they have meaningful releases and not just garbage nothings every week.

I didn't mean for this to sound like a rant. But seriously, I just can't imagine in any scenario where "I look at stars" as a useful metric. You want to add it to the list? Sure. That is fine. But it should not be a deciding factor. I have chosen libraries with less stars because it had better metrics on things I cared about, and it was the correct choice (I ended up needing to evaluate them both anyhow. But I had my preference from the start).

Choosing the wrong package will waste you so much more time. Spend the 5 minutes evaluating for stuff that is important to your project.

Post reply on HN