of GitHub developers who answered a 2018 survey (567 of 777) said they look at the star count before using or contributing to a project (Borges and Valente, "What's in a GitHub Star?", Journal of Systems and Software, 2018).
Short answer: stars are worth earning, not worth chasing. Developers do read your star count, so it matters as a first impression. But only about a third of surveyed developers said they starred a repository because they used it, bought stars lose their effect within two months, and GitHub treats automated starring as abuse. Grow the star count as a side effect of a tool people use, and track adoption with signals that are harder to fake.
What does a GitHub star actually mean?
A GitHub star is a one-click bookmark on a repository. GitHub's own docs give it two jobs: it "makes it easy to find a repository or topic again later" and it "shows appreciation to the repository maintainer". GitHub also uses it as an input: "many of GitHub's repository rankings depend on the number of stars" (GitHub Docs, Saving repositories with stars).
When researchers asked developers why they starred a specific repository, usage came third:
So a star is mostly a "nice, maybe later". It says the README made an impression. It does not say anyone installed the tool.
Do developers judge a tool by its star count?
Yes, but rarely by stars alone. In the same survey, the developers who said yes split into groups:
The other factors are where a tool wins or loses. In GitHub's own open source survey, 93% of respondents had run into incomplete or outdated documentation, and 64% called an open source license very important when deciding whether to use a project (GitHub Open Source Survey 2017, 5,500 random respondents). In our view, a visitor who sees 2,000 stars and a README with no quickstart still leaves.
How big is the market for fake GitHub stars?
Big enough that a research team built a tool to measure it. StarScout scanned every public star event on GitHub from July 2019 to December 2024 (He et al., "Six Million (Suspected) Fake Stars in GitHub", arXiv 2412.13459, v2 revised September 2025). The authors stress that these are suspected fakes and that some false positives remain.
Most fake stars went to short-lived phishing and malware repositories. The rest mostly promoted AI and LLM projects, blockchain projects, tools and apps, and tutorials (He et al., 2025, abstract and section 4.3). The paper also explains why startups buy: "VCs (and managers) refer to GitHub stars for product viability".
What happens to a repository after it buys stars?
The study measured how real stars changed after fake ones arrived. The effect is small, and it turns negative:
-
Month 1
A small lift
Each 1% more fake stars goes with about 0.07% more real stars. Real stars do about five times as much.
-
Month 2
The lift fades
The same 1% goes with about 0.03% more real stars.
-
After 2 months
It becomes a liability
Each 1% more fake stars now goes with about 0.04% fewer real stars.
-
By January 2025
Most of it is gone
90.42% of repositories and 57.07% of accounts in fake star campaigns had been deleted, against 5.03% and 3.54% in the authors' baseline sample.
Source for every step: He et al., 2025, sections 3.4 and 4.4. These are associations from a regression model, not a controlled experiment, but they all point the same way.
GitHub's Acceptable Use Policies list "rank abuse, such as automated starring or following" and taking part in "secondary markets" for inauthentic activity as banned spam (GitHub Acceptable Use Policies, section 4). In our view, rounding up friends to star on launch day sits close to that line too.
Which popularity myths should a founder drop?
A star means someone uses your tool.
Only 36.7% of developers in the 2018 survey starred a repository because they used it. Appreciation and bookmarking came first (Borges and Valente, 2018).
npm downloads count your users.
npm counts every tarball it serves, including build servers, mirrors and robots, and calls the numbers "definitely not the same as the number of users" (npm blog, How npm download counts work, 2014).
A few hundred bought stars give a launch a lasting push.
The measured lift lasts less than two months and then turns into a drag on real star growth (He et al., 2025, Finding 8).
Which signals show real adoption of a developer tool?
No single number proves adoption. Read them together, and weight the ones that need real work from someone else.
| Signal | What it counts | Who can see it | How easy to inflate (our judgement) |
|---|---|---|---|
| Stars | Bookmarks and appreciation; about a third of surveyed developers starred because they used the project (Borges and Valente) | Everyone | Easy: stars are sold |
| npm downloads | Tarballs served, bots and CI included (npm) | Everyone | Medium: any CI loop adds up |
| Traffic: views, unique visitors, clones, referring sites | Past 14 days; clones are full clones, not fetches (GitHub Docs) | People with push access only | Not public, so nobody gains by faking it |
| "Used by" and the Dependents tab | Public repositories that depend on your package; "Used by" shows once more than 100 do (GitHub Docs) | Everyone, for public repositories | Hard: each one is a real repository with your package in its manifest |
| Issues and pull requests from strangers | People who ran the tool and hit something | Everyone | Hard: needs a real problem or a real fix |
The last two rows are the ones to show an investor next to the star count. They are also what a careful developer checks after the stars.
What is the difference between chasing stars and earning them?
Chasing stars
- "Star us!" at the top of the README, before the reader knows what the tool does
- Star-for-star swaps, launch day star requests to friends, or a seller
- Reports the star count as the growth metric
- Ends with a number that stops matching usage, and a policy risk
Earning stars
- A quickstart that gets a stranger to a working result first
- One plain line at the end of the README for people it helped
- Reports dependents, active issues and clones next to stars
- Ends with a slower number that holds up when someone checks it
How do you grow stars the honest way?
-
Make the first five minutes work
Most stars are a reaction to the README. Put an install command and a visible result at the top. Our guide on how developers discover and adopt new tools has a README skeleton and a 5-minute cold-start audit.
-
Ask once, after the value
A short "if this saved you time, a star helps others find it" below the quickstart is honest. Since GitHub rankings use stars, it also helps discovery.
-
Show up where developers look
Post where your users already are, under each place's rules, and link back to the repository. The top pages that send visitors show up under Referring sites in Traffic (search engines and GitHub itself are left out). A listing on CodeTrendy puts the tool in front of developers browsing for new tools.
-
Track the hard signals every week
Write down stars, clones, unique visitors, dependents and issues opened by people you do not know. Traffic data only covers 14 days, so copy it out or it is gone.
-
Never buy, swap or automate
It breaks GitHub's policy, the lift fades within two months, and an inflated count is visible to anyone who compares stars to issues and dependents.
Questions founders ask about GitHub stars
How many GitHub stars is "good" for a new developer tool?
There is no reliable benchmark, and we will not invent one. Compare your stars to your own usage signals instead: if stars grow and dependents, clones and outside issues grow with them, the count is healthy.
Do investors look at GitHub stars?
Some do. In their background section, the StarScout authors note that startups buy stars partly because "VCs (and managers) refer to GitHub stars for product viability" (He et al., 2025, section 2.3). In our view, that is also why a star count with no matching usage invites questions from anyone who checks.
Can GitHub remove fake stars from my repository?
GitHub bans automated starring and can remove accounts and repositories that break its policies. By January 2025, 90.42% of repositories and 57.07% of accounts in the fake star campaigns the study found had been deleted. The authors think most of the deleted repositories were phishing malware, so this shows removals happen, not that every fake star on every repository gets cleaned up (He et al., 2025, sections 3.4 and 4.3).
Is it wrong to ask people to star my repository?
A plain request to real users is normal. Automated starring, buying stars and trading in "secondary markets" for them are banned by GitHub's Acceptable Use Policies.
Are forks a better signal than stars?
In a small 2018 pilot survey of 54 Stack Overflow users, 83% scored stars 3 or 4 out of 4 as a measure of popularity, against 72% for forks and 67% for watchers (Borges and Valente, 2018, Figure 2). For adoption, dependents and outside issues say more than either.
Sources: Borges and Valente, "What's in a GitHub Star?", 2018; He et al., "Six Million (Suspected) Fake Stars in GitHub", 2025; GitHub Docs: stars; GitHub Acceptable Use Policies; GitHub Docs: traffic; GitHub Docs: dependency graph; npm blog: download counts; GitHub Open Source Survey 2017.
Ready to list your website?
Submit to CodeTrendy and get a free public listing with a link to your site - or upgrade to a paid plan for featured placement and priority visibility in front of relevant visitors.
Submit Your WebsiteWritten by
CodeTrendy Editorial Team
The CodeTrendy team writes about launching, product discovery, and distribution. Advice in these articles is editorial opinion unless a source is linked next to it.
