star-history.com is already the de-facto GitHub star history graph. Recently, we just finished a major update.
1. Generate high resolution chart image.
2. Timeline mode to align trajectory among repos debuted from different times.
3. Embed chart into other websites.
4. Temporarily toggle a particular repo.
We try to keep its original sketching feel while rewrite the entire site using modern stack (Vue + TailwindCSS + Vite).
Hope these improvements will make it more useful to open source project maintainers.
Tangential: I know there are people who collect stars on their projects and use them as badges of pride and perhaps put them on their resumes. I've never quite understood this. I never look at how many stars a project has and I have never starred a project as far as I am aware.
Stars are a soft indicator of community reach. Between any two similar projects, one with more stars has plausibly more people aware of its existence and more people who wanted to say "I like this".
"I never do X, therefore..." is a closed mindset that people should try to get away from. Ok, so you don't star projects. But clearly other people in general do star projects, so stars shouldn't be a huge mystery.
Yeah they’re a rough universal indicator. Unless you can mention a better one that’s just as simple I don’t think the counterpoint you’re making is very strong.
You can't judge a book by its cover. But when you have to judge an extremely large amounts of books, then you have to start introducing some metrics to help narrow them down.
It is relative to other tools in the same space and beyond a point it is meaningless.
I.e. I would be happy to find a library with 100 stars in say elixir and similar threshold would be say few thousands in JavaScript.
Beyond 10-20k it is just popularity. It is meaningless whether vue or react is more popular.
Also it is only one indicator between choosing libraries, how many active contributors, how many closed and open issues , when was the last release also matters as well.
Bottom line is you try to avoid something very few people use or only one guy is developing
That isn’t necessarily bad. Ability to engage community in any form is important, and it helps to know they are serious to spend time and effort building out the network.
People don’t buy IBM or Microsoft because they are the best, it is because of their commitment to support and maintain the product. It is similar with GitHub projects
A good chunk of open source comes from corporate support directly, whether old school IBM or Facebook /google of the world.
Companies influence what gets developed when, even kernel development is largely corporate funded. social network motives seem a bit more benign than say how oracle runs MySQL
> Ability to engage community in any form is important
When projects are riding the hype wave and getting popularized by reddit or HN it's not a proof of commitment. On the contrary, it takes more commitment to maintain a project that is not hype-driven.
There's already too much churn and focusing developer's effort on developing the hot new thing of the week to be github-famous is harmful.
Not every project is covered in HN/reddit. Social media impact is not feasible for every project. Some distortion shouldn't mean discard it for all projects. Staring on GitHub is slightly higher effort than say to like on Twitter/Instagram etc.
There are plenty of projects that I have used after seeing here, and say opened few issues or even made a MR or two.
Riding the social media wave is first step to getting users, issue responsiveness, project maturity all make a difference.
1000 star, 100 use , 10 create issues, 1 contributes. More eye balls in general can improve project quality. The maintainers have to be responsive yes, but that really is visible only with more exposure.
A challenge with open source is that people can use your stuff without ever telling you about it. It can sometimes feel like releasing software into the void - any glimmer of interest is motivating, and stars represent a glimmer of interest.
I feel the new list feature is missing the ability to have many lists. 10 (or whatever the max is, can't remember) is too little. I'd like to have many more categories available. What do you all think?
Removing the 16 lists limit has been a quite common request in the official feedback discussion, and as far as I can tell, there's been a promise to lift it quite soon: https://github.com/github/feedback/discussions/8633
1000 stars on GitHub are about as powerful as 1 million followers on Instagram. If you don't understand why 1 million followers on Instagram are life changing, well...
1. It's a proxy for measuring how interested the community is in your project.
2. A lot of people use star counts to determine whether or not your project is reputable.
3. As founder of a company with a major open source project, it's one of the only reliable data sources we have for benchmarking our own community growth. I can't see historical (or present) traffic numbers for other open source projects in the kubernetes space, but I can see the history of their star counts. That's really useful when you need to set goals for community growth
4. Some VCs care about it
As with most metrics, the metric in and of itself isn't important. What it measures (community growth) is. So be careful to optimize the latter and not the former
In the work context it's for me an indicator whether to choose a library or not - apart from last commit, handling of issues and PRs. It's frustrating to include deps with little community/contributor interest that sometimes even silently get delisted from package repositories.
I wish GitHub would provide some sort of recommended projects based on star clustering. They have something involving stars on the GitHub Explore page, but the results are not very good.
It's a bookmark, because then you can filter through your stars and quickly find a library about something that you need. How do you keep track of projects of interest?
Same here. Sometimes I'll go through bouts of starring tons of cool repositories that I find useful or interesting, to save them for later when I have time to fully check them out, or when I know they'll come in handy.
At Openbase.com we're building the star count charts by using the GitHub GraphQL API (as we use it for other things like collecting stats about commits, issues and PRs).
Looking at how star-history works, seems like you opted for using the GitHub REST API - what are the upsides / downsides of using the REST API?
This is very cool! I like that multiple repos can be added to the graph at once. Previously, I have used https://starchart.cc/, which is similar, but lacks this feature.
Star History is the gold standard of this..if any Python enthusiast is interested in implementing this in Python, this tutorial uses it to teach steeamlit https://youtu.be/TzF-OUA1Tlo
1. Generate high resolution chart image. 2. Timeline mode to align trajectory among repos debuted from different times. 3. Embed chart into other websites. 4. Temporarily toggle a particular repo.
We try to keep its original sketching feel while rewrite the entire site using modern stack (Vue + TailwindCSS + Vite).
Hope these improvements will make it more useful to open source project maintainers.