The black market in GitHub stars
wired.com
wired.com
I doubt that's the motivation here. I think this is about projects themselves wanting a high star count in order to attract users, customers and investors.
My initial read of just the headline was similar. It reminded me of those devs whose YouTube videos or repo READMEs ask (beg?) for you to star their repo.
But this is clearly about investors who invest in open source projects and use Github stars as a proxy for community engagement and velocity (whether right or wrong).
Another giveaway is the ratio of stars to watchers / forks. I remember one project with thousands of stars but only 10 users "watching" it. They went on to raise a sizable seed round too.
Not necessarily indicative of foul play. I have two projects like this (https://github.com/smacke/ffsubsync and https://github.com/ipyflow/ipyflow) and I attribute it to not having great developer documentation.
It never served a a cheat-code, or a skip-the-line or any such goodness. What it did was serve as a conversation starter, “I see project Y in strange language X. What is the story there?”
That’s your cue to sell yourself, your skills, your experience, etc.
I could never know, but perhaps having it also got me on the short-list for an interview to begin with?
I would say GitHub has featured in at about half of my interviews.
It is safer and easier to use a one size fits all interview.
Most of the interview is getting the candidate to show me that they know _something_ in depth and I'm not super concerned with exactly what it is. (If they've learned something in depth, I expect they can also learn the details of what we do. :) So the exact same questions to every candidate serves no one's interests.
However, what you're describing sounds reasonable to me - you're offering the same overall interview structure, just tailoring the question to delve more into someone's bespoke experience. That's a hell of a lot more work than a one size fits all (ala leetcoding style) question - kudos to you.
Do what you want with that info.
Same as for linkedin
At higher levels (Principal, Distinguished) you often have to show external contributions to the industry, and some companies count open source towards this.
I can honestly say that my profile has been a huge benefit to my career, but that's more due to 20 years of open source contributions and a very customized (and automated) profile page.
I can share my random side projects... but what is the use of that? They aren't that impressive compared to my actual work.
My fear is that I will have to put lots of advertising into myself for things that don't describe what I actually do.
that's probably true for western europe. compared to the US there is significant less open source projects,businesses and developers.
I personally have contributions to an open source project because I was employed by it for around 3 years but I generally spend my free time on hobbies other than writing code.
Particularly in crypto where people want to quantify “community” and star count is a crude but very available way to do that.
I would assert that github became popular because it offered free online git repo hosting.
The social media stuff was only long after the fact, and accelerated under M$ ownership.
An old adage was: Every s/w evolves until it becomes an email client
The modern version is: Every s/w evolves until it becomes facebook...
Companies look at what's "popular" and try to make their products into that.
This is a significant contributor to s/w failing to perform its "primary" function...
This is primarily due to the SV promotion-driven development culture - where Engineering managers don't do anything but performance reviews while offloading all tech work to tech leads. Then, they force every engineer to magically produce "impact" every 6 months or else...
It sounds great because surely "impact" must be getting produced every 6 months right? Except, all that has happened is that engineers and product managers are spending months figuring out crap (such as github social, badges etc.) or sometimes boosting some BS metrics. The other side effect is that the work culture has become toxic because every developer is pitted against each other.
The outcome? Enshittification of once beloved services. Because the stewards of said services are trapped in a cycle of perverse incentives.
Been there. The obsession with levels and career ladder documents is too much sometimes. It is so hard to be an IC with constant org-wide impact as opposed to being a manager whose impact is automatically wider due to reporting structure.
However, social was definitely there as part of the original pitch. The tagline was "social coding" for a long time.
But also if you're buying GitHub stars or worrying about people's contribution squares, you're probably not doing great work.
I'm not sure I agree.
I believe that having a profile for open source work, tracking issues, comments, tagging people in comments, assigning tasks, etc, are all core to GitHub's popularity. Now with issue and comment upvotes, following users, etc, it's even better.
A couple of years ago I went through a phase where I was convinced that GitLab is "more open source" so I wanted to push my code to GitLab (and back then they had a significantlybetter CI/CD and Pages/static site hosting offering). In the end, I gave up, because (almost) nobody used GitLab for open source, neither as code maintainers, nor as contributors in the form of reporting issues, and people wanted a Github profile, not a GitLab profile at job applications.
Github's original 2008 tagline was "social code hosting". I'd argue the social nature is what made github, as well as git, popular.
The path from here to "Are you currently hiring?" and "You had so many people looking at your profile, unlock your opportunities with a premium subscription" etc. is not that long.
But I dont want to pretent I really know how to enshittify a platform.
None of this functionality had anything to do with social features; it simply helped act as my bridge between centralized and distributed source control.
I like the PR concept. It takes a service like GH to implement it well.
I like GH Issues. JIRA is a nightmare (source: Former JIRA admin).
If I were doing high-security stuff, I'd probably run my own server (and charge beaucoup bucks), but I don't, so GH is fine. When we run our own servers, backup is a really big deal, and that can be worse than actually running the server. GH handles all that for me. It also basically acts as an offsite backup.
As far as stars, I could give a rat's ass. I'm 61, and a tired old warhorse. Status games are for young turks.
I did once come across a profile that had a solid bright green activity log. I suspect the chap had a private repo, with a script that checked the same file in, multiple times per hour. I have also heard of people gaming the activity log to display pictures.
Mine's fairly solid, but that's just because I stay busy.
1. lots of other people used it
2. it provided auditable provenance for all contributions to dlang
3. I got tired of people copying my code and then claiming I stole it from them. Github ended all that
4. it provides a great distributed backup
5. nobody complained about it :-/
6. Dlang is in the D business, not the repository business. Best to not invent our own.
7. it provides everything we need
8. I didn't think git or github was going to go dark on us
I went down the rabbit hole of buying GitHub Stars, so you won't have to - https://news.ycombinator.com/item?id=36151140 - June 2023 (178 comments)
Tracking the Fake GitHub Star Black Market - https://news.ycombinator.com/item?id=35207020 - March 2023 (284 comments)
Ask HN: Has GitHub stars become a gamed metric? - https://news.ycombinator.com/item?id=33225477 - Oct 2022 (19 comments)
I think it is hireing trying to acknowledge success and cheating that success occurring.
After all hiring managers have forever fought against lying on Resume/CV/Interview.
https://news.ycombinator.com/item?id=35207020
The linked article there has some interesting data analysis
What I try to focus on now is more so the commit and release cadence / frequency since in my mind frequent activity means it's more likely to have bugs fixed and security issues handled.
Would love to hear other's input on this.
- look at "latest commit." 4 years ago is not good. 2 days ago is good.
The 30-second test:
- total number of commits. number of active branches. number of PRs.
The 5 minute test:
- are there PRs? How many open PRs vs how many closed? Is there lively discussion in PRs?
- how many different contributors are there? 1 contributor is OK (and often means that the library will be very coherent) but multiple "main" contributors is better.
- are there good code examples available? Are there commits that indicate that examples are kept up to date?
I have never ever used stars to evaluate anything.
Evaluating each repo does happen as you wrote, though.
Open vs Closed, and meat in the issues. Will tell if people are actually using something.
There's one project that, if I'd known how unhelpful the lead dev would be, I'd have never used that project. (Not going to name names)
in a language like rust or typescript, depending on what the library does, and specially if it has a lot of dependencies, should probably be maintained continually. so in Rust last commit 4 years ago looks very bad
Rust libraries from 4 years ago are still working, js libraries are a hit or miss
Then frontend is way worse than backend
Overall if the code is old but well written, I'm happy to own a fork
Now if the library has tons of dependencies, regardless of language, it's very brittle to bring it unmaintained, because your own dependencies may be expected to interoperate with them. This is actually a plus because with C you may be required to do manual data conversions etc, but it also means that keeping old dependencies is a liability
With exception of a handful of “pillar” dependencies used throughout the industry, you should be reviewing your dependencies with the same eye for detail that you bring to pull/merge reviews in your own organization. And you should do it again every time you explicitly tell your package manager to reference a new version.
If you care about the quality of your own project, it doesn’t matter how many stars there are, or the commit frequency, or the responsiveness to issues. What matters is that the code is legible, that it meets your own standards of quality and reliability, and that you understand in detail what it’s doing.
If you can’t do that because a dependency is too large or fast-churning to review, then you should consider whether its actually suitable for your project. Often, in these cases, you’ll remind yourself that you only need 1% of what the dependency provides and that it’s actually less work and better for your skill development to tackle that 1% on your own or with a more narrow dependency that you can properly vet.
But of course, your product manager probably won’t have the patience for any of this, and your colleagues will look at you like you’re a paranoid freak. And that’s why software quality is garbage now and getting constantly worse.
If there are any important unresolved issues, it's a fail. If the issues have been resolved, it's a potential pass.
If there aren't any issues, I'll think about the complexity of the project relative to the number of commits/time since most recent commit, since if there aren't many commits and haven't been any for a while, it's more likely that the library isn't used by other people enough and may be buggy. But if it's still an active project, it might be worth trying anyway since I might be able to work with the maintainers to resolve potential issues (especially if there aren't any better options).
A popular project will have a healthy distribution of types of issues, from novices asking newbie questions to experienced devs making feature PRs. It will also have several contributors.