Impacts of removing /stargazers #201209
Replies: 32 comments 28 replies
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
|
Removing /stargazers has a bigger ecosystem effect than it might appear at first, because stars are not only vanity metrics; they are also one of the few lightweight public trust signals available for open-source discovery and abuse detection. The challenge, of course, is balancing that against scraping and abuse pressure. A middle ground might be to reduce bulk extraction while still preserving some limited transparency, for example capped recent stargazer visibility, delayed access, or aggregate metadata that lets tools reason about authenticity without full public enumeration. Right now the abrupt 404 cuts off both legitimate ecosystem analysis and abuse-detection use cases. |
|
you're not the only one upset about this; I too am, and whole open-source community has been complaining since that changelog dropped : ( GitHub's main excuse for killing /stargazers was to stop bot rings from scraping user lists for spam and to cut down on massive API abuse. But like you said, it completely nuked legit tools like Star History and OSS Insight in the crossfire. Right now, the only real alternative is using the GraphQL API to get raw counts, but you totally lose the historical timeline and user details. Leaving this feedback here is the best move so their product team sees how badly this broke community tools. Hopefully they walk it back or at least give maintainers a dedicated analytics endpoint. |
|
That's the idea, get people to speak up. |
|
Us developers circle; we are planning to run campaigns on our own; on insta, github, X, reddit, and all the platforms. Hope it'll get it done 😟 |
|
The stargazers page was useful when I wanted to check whether a repo might have fake stars. It's not 100% accurate, but if I noticed several stargazers had also starred the same set of repositories, it was a strong signal that something was suspicious. Unfortunately, that's no longer possible. |
|
That, and also it is entirely possible for a repository owner to star their own repo. For repositories with not very much stars, this is huge. |
|
Can Github bring back the public version at least in an anonymized fashion? It was useful to see star history for a repo and then compare that against things like how many people talking about it on reddit and other places. Useful signal - now it's like if Amazon hid reviews because some people were scraping the usernames from the reviews. |
|
Hard agree here. I can understand wanting to hide large numbers of usernames and such, but I don't see why they still couldn't provide timestamps of stars so we can see growth over time. Hoping GitHub eventually plans to re-add a more limited stars endpoint. |
|
Ii created gitranc.com to be able to compare repositories for myself and now i am also affected by this. At least give pro users the ability to do the same thing on the domain github.com. |
|
Let's hope GitHub sees this thread and perhaps comes up with some compromise solution. Tracking stars over time is a pretty big use case, most of the tooling doesn't care about the user names. Though for those looking into the credibility of the project that does help. |
|
Wholeheartedly agree, it's an extremely useful metric for credibility |
|
I strongly oppose this change. The For small and niche repositories, the list of stargazers was often one of the best ways to discover people working with similar technologies, find related projects through their profiles, understand what kind of community was forming around a repository, and connect with developers who shared the same interests. Many small projects have few issues, pull requests, forks, or discussions, so their stargazer list may be the only visible signal of the people interested in them. Removing the entire public page because some actors abused it is a disproportionate response. GitHub could address scraping and spam through authentication requirements, stricter rate limits, pagination limits, abuse detection, partial visibility, anonymized historical data, or privacy controls for individual users. Blocking all legitimate access should not be the default solution. This change turns stars from a public expression of interest into an opaque counter. That weakens project discovery, community formation, ecosystem research, and trust assessment across open source. Please restore the public stargazers page, even in a limited form, or provide a replacement that preserves both star history and the ability to discover the community around a project. |
|
no, really, read this ^^^ I fully agree with the entirety of it |
|
these fuckin people. i'm am livid pissed at github and MSFT about this. did they fuckin talk to a single person who has worked on the community-building side of things, or who grows the systems they profit from? grrrrr |
|
Time to fork github and host our open source projects elsewhere. In all seriousness not happy about this either |
|
Literally leaving github. Btw, earlier this day, github has sneakily added the stargazer restriction to GraphQL as described in emanuelef/daily-stars-explorer#363. |
|
resending this message i said from another related topic: i feel like visibility to /stargazers on public repositories should at least be limited to users with a minimum age honestly... |
|
Can someone confirm. Is the |
|
I've only seen this for projects I'm not a part of. |
|
Thanks for reply, wanted to rule that out. It was my PAT token in the end, didn't have repo scope. |
|
It's worth noting the absurdity of deprecating |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
At the very least make "hiding stargazers" optional for repos, and marking it |
|
Not all stars are equal, if I look at a new project and see it has stars from 4 or 5 well known people, I know it's a new project that's going somewhere; vs looking at a new project with 30 stars from faceless accounts. Not being able to see the people makes stars just a useless and meaningless metric that does not matter at all. The world of software is driven by real people who are coders, not the organizations or companies they hop between, not the tools they hop between, not even the projects they hop between. What matters is the people. SourceForge forgot that, GitHub needs to not make the same mistakes. |
|
This here is the best example of what you are talking about. https://github.com/ruvnet It's the most obvious botnet botting bot you can find on the internet, and yet even after numerous reports it has not been taken down. You can not verify that all of his repos are bullshit any more. (I mean you can, but not at first glance) Some of his repos claim 7k forks and are more successful than programming languages themselves. Github has became a soulless company, its just a skeleton moving. If codeberg wasn't that bad, maybe a move would make sense now. |
|
@SnoozeFreddo Yep, that's a good example! When the stars, and commits, and forks, and real conversations become tracked as "engagement" statistics, they become meaningless numbers that can be gamed. Instead being able to look around and see real people doing real things, it's just number-go-up, number-go-up, number-go-up. Not being able to differ the real from the fake, this is what invites the botting behavior in the first place. And you brought up a good point, it's harder to see now, harder to verify what's real vs fake. And I expect the stars being anonymous now will just fuel the botting even more going forward. |
|
you only need look at this as well , its currently the highest rated growth project for stars https://github.com/mattpocock/skills and its a project full of markdown files. |
This comment was marked as spam.
This comment was marked as spam.
|
Looks cool! Is it please possible to also provide a graph (like star-history.com did) covering more than 30 days offered in the big badge? Or does the "svg replacement" already aim to do that, just the collected history is too short? And can you perhaps offer a way for maintainers with proper access to GitHub API to export historic data and upload it to you? Perhaps a github action they could put in a side branch and run once (so you sort of trust what it does - not feed false numbers - and runs in their access context to get those numbers), and uploads an artifact that you scrape or sends a webhook or something. |
This comment was marked as spam.
This comment was marked as spam.
|
I would rather defer to you - on one hand, alas busy catching up with a day-job release, on another I had a rough idea and you seem to know more exactly what should be done on tech side :) |
|
Also, what are "public GitHub event archives" and can they be used for arbitrary repositories, fixing this problem overall? :) Another idea I had is to let (anyone? project maintainers?) download the raw "date-amount" numbers you have, so the existence of your server is not a long-term bottleneck (that eventually people might have a need to migrate elsewhere and would have the tools/data to do so). Bus factor and all that... |
This comment was marked as spam.
This comment was marked as spam.
|
The docs need updating. I wasted about a half hour yesterday reviewing them while trying to compare star histories of my project to a few others (and getting token permission errors). This change was not announced loudly enough or executed precisely enough, and it's very disappointing. I hope as a compromise Github can provide historical (even grouped into average-per-month is fine) access to star counts. |
|
GitHub Fell Off. #BringBackStarGazers |
|
If the only reason for locking away the stargazers list is to stop scraper abuse (what we call the “black-gray industry” in China Mainland), then the result may be the opposite of what was intended. Those who operate in the black-gray industry have no bottom line. They will only move faster and more recklessly than us, the real developers who actually write code and love open source, to manufacture piles of fake high-star projects. For ordinary developers like us, the stargazers list has never been just a number. It is the medal of the long road a project has traveled. It is the quiet mark left by people who truly cared and supported you. It is the path we want to show to those who come after us. For the sake of these real developer friends, please bring the stargazers list back to us. |
|
To add to the discussion, I was just inspecting an ai-agent extension repo that, when installed, auto-updates. If this repo is artificially inflated to make it seem trustworthy, users will install that agent extension that auto-updates itself, it seems like a really easy attack vector |
|
This sucks :/ |
|
That sums it up with brevity! |
|
wow |
|
I hate this. Getting to see who stared a project was such a valuable tool for me to find people with similar interests and to find other projects those people starred. This is especially useful when you are interested in very niche things and it helped me discover many very cool projects. What is wrong you github. Why do you intentionally make your side less useful. |
|
GitHub introduced a privacy-safe API for star history data. For example, Star History is working again. See their blog post: https://www.star-history.com/blog/new-github-star-history-api |
|
Neat! After some glitch with star-history asking for some API KEY, setting it to empty just worked!
|
I cant think of a bigger pile of BS that could be used to justify this change. |
|
I understand that having these "star lists" can potentially cause spam. At the same time, we're now blind to knowing anything about who is starring a repo. It could be 1,000 bot accounts or 1,000 real accounts and no one would know except the maintainer who might be the "bad guy" in this case. |
|
Thanks for raising this. I agree that removing access to the Stars have become a useful signal for the open-source ecosystem—not only as a popularity metric, but also for understanding project growth, sustained interest, and community engagement. Tools such as Star History and OSS Insight have also built valuable analysis around this data. While there may be valid privacy, abuse-prevention, or infrastructure reasons behind the change, I think there is a middle ground that could preserve much of the value without exposing individual user information. Proposed alternative: instead of completely removing access to star data, GitHub could provide an official, privacy-preserving API that exposes aggregated statistics, such as:
This would allow projects and open-source analytics tools to continue measuring project growth and sustained interest without requiring GitHub to expose sensitive information about individual users. Given how many tools and workflows depend on star data, providing an official alternative would be preferable to removing the functionality entirely. |
|
Holy fuck. We got microsofted so badly here. i used to love looking into stargazers and see who I recognized from the early pages. It was such a rad social signal, that was easy to click into. I feel so disappointed that MSFT couldn't see the value here -- just lock it behind sign-in. jeez, what enshittification.
This is nothing but a data play under the guise of user privacy. MSFT isn't fooling anyone who cared enough to notice |
|
You got it 100% right. |
|
Yet another absolutely moronic decision. First they screwed up the homepage / feed, now this. Enshittification of GitHub continues... |
|
I use to reach out to niche people from the stargazer history of my small projects to be part of the community, all that is lost for small super interested people |
|
You can still see who stars your own projects just not others. |
That is useless if you want to find people with similar interests and look at the other projects they have starred. |
|
Yes I agree but they were saying something that's not true. I don't like this change more than anyone hence why I created the discussion in the first place. |
|
Stargazers public list should not be removed but for people who don't want to be in a public list, a privacy option to hide their profile could be added (per project in case they want to be hidden on some projects only, e.g. a "Star privately" option). |
|
That's a good idea. Hide me from the list or make it just an anonymous entry. |
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Product Feedback
Body
As of June 30 all repositories now return a 404 for /stargazers.
https://github.blog/changelog/2026-06-30-upcoming-access-restrictions-to-public-api-endpoints-and-ui-views/
While I somewhat understand the motivation, this has such a huge impact on the overall open source ecosystem. Being able to view stars provided some insights into who likes a project, if they are real accounts etc.
It kills a site like https://www.star-history.com/. This was a valuable resource to study the trend of a project. Did all it's stars just come because of a popular post but then it trailed off or is there sustained interest over time? It's a quick signal that can be used in combination with downloads, issues filed etc.
Sites like https://ossinsight.io/ will also be degraded in functionality.
So while I'm sure there was a good idea behind this change, it's worth reconsidering given what we lose. It's not in the spirit of what GitHub was originally about.
All reactions