Most of the comments here seem to assume buying stars is about making personal profiles more attractive to hiring.
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.
This. I've seen a couple open core startups that are less than a year old with thousands of stars on their repositories, so I decided to have a look at some of these profiles who starred the project. Most of them have weird usernames that resemble spam accounts, almost all of them cannot be pointed to some other profile on a different platform (Twitter, LinkedIn, HN etc.).
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.
> 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.
Upvoted. Nobody even clicked through to read the first paragraphs :D
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).
Is this really a thing or just some local phenomena? I can't remember that the github profile played a role in any hiring committee i've been part of (western europe) as people understood that most of the experienced software developers aren't active open source contributors.
In my experience it's a positive sign to have an active Github profile or open source contributions, but it is not a negative sign if a candidate doesn't have one.
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.
Yeah, when your GitHub profile looks like _that_! I would take that into account as well as a hiring manager. I do regularly click through candidates’ GH profiles and they’re usually not noteworthy so don’t count them for or against them. If they looked like yours though I would definitely read more deeply.
What bugs me is when an applicant prominently includes a link to their GitHub profile in their resume and then that profile has zero activity. All I can gather from that is that they aren't paying attention to what they're doing: they created a profile solely because some seminar said to put it on a resume. If you don't have anything to show, simply don't include the link!
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.
I had a friend working with a well known startup founder. The founder was interested in me from what my friend told him, all he wanted to see was my github profile. All of my github projects are private. That was the end of that, even after he already knew that my experience was perfect for their company. So ya, some people definitely put too much emphasis on the github profile.
If you were to share your current job's private repos with me, I wouldn't hire you since that's a signal that you would do the exact same when you leave my company.
this is a perfectly reasonable decision when hiring for a startup, why waste hours, that you don't have, on interviews testing the candidate when you can lookup their past work
Considering how important networking is to startup businesses, you'd think a startup founder would put a little more weight on an employee referral than only considering their GitHub profile.
I can anecdotally attest to contact and employment happening solely based on Github profile - without it containing anything impressive - in Scandinavia, as well as a few cases where the profile was used as input in a regular interview process.
I doubt many people cheat stars to get hired, it’s just not a major signal there. But with stars being a signal of traction for open source startups, I definitely think there are some companies out there buying them.
Particularly in crypto where people want to quantify “community” and star count is a crude but very available way to do that.
When I get a resume for someone I've been asked to interview, I'll certainly look at any github profiles, and if there's something relevant there, I'll often use their project as a basis for whatever coding exercise we do, such as extend this class to add X functionality. Or use it as a basis for design questions.
Except it's pretty much standard. If there isn't a github link, I'm still going to tailor the programming questions to a context that I infer from the past experience on their resume (as in, they said they did X, so they should know about Y) but with a bit less accuracy.
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.
I think the nuance here is if you tailor ALL interviews for a specific job based on each candidate to the point where the interviews are no longer directly comparable, that could constitute a hiring practice that would run afoul of some laws in various places.
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.
I've seen it more in the context of security, if you want developers to use a malicious library or extension, you can buy stars to give it a fake reputation boost making people more likely to use it.
Most experienced software developers in the US also aren't active open source contributors. Most experienced developers who have contributed to open source probably did so as part of their job whether because they worked for an open source business or because they fixed an issue with an open source project that was important to their employer's business.
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.
Yep. For those who don’t do much open source collab, it entered our lives as an open source project discovery, evaluation, and distribution system. Now, of course, it’s also where lots of us push our code that we write for pay, but that’s why we started visiting.
Yep, this was exactly how I got into it at first. Didn't even really notice the social features for years and even now I'm only aware of the social features and don't actually engage with them.
I agree GitHub is not popular because of its minimal and pointless social features. It became popular because Git is good and they nailed the cloud part of source control.
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 agree GitHub is not popular because of its minimal and pointless social features.
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.
The only reason I have my projects on Github and not on our self-hosted server, is because of the network effect of users having accounts that makes it easier for them to report bugs and contribute.
I liked having a web frontend to git, which was often much less cumbersome than figuring out the right diff/log/branch incantations. Also, as a cvs refugee, I felt weird committing to just my local repo and not having another place where "the truth" lived.
None of this functionality had anything to do with social features; it simply helped act as my bridge between centralized and distributed source control.
> The modern version is: Every s/w evolves until it becomes facebook...
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.
This reminds me a SV company I worked for a couple years ago. The EM was always going on about impact. I was a staff engineer, needed to have organizational-level impact with my project... on and on. Meanwhile, I'd get so many interruptions for code reviews, meetings, etc. it was almost impossible to get any actual work done.
> This reminds me a SV company I worked for a couple years ago. The EM was always going on about impact. I was a staff engineer, needed to have organizational-level impact with my project... on and on. Meanwhile, I'd get so many interruptions for code reviews, meetings, etc. it was almost impossible to get any actual work done.
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.
I eventually left. I hated the culture. They would literally shame people for not hitting 90% of their sprint goals, meanwhile the interruptions were constant and never ending. Also, despite all the time spent on code reviews, the code base was incredibly difficult to work with. Technical debt did not begin to describe it. 5000 line single file "modules", decade old dependencies nobody dared upgrade, not to mention Python 2.7 (in 2022), multiple ORMs, on and on.
I just use it, because it works well, and saves me a lot of elbow grease. I've managed local servers with Git and Perforce on them, and it's a pain.
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.
Quite a few people seem to be using github as a place to put a cv. Social media behaviors are creeping in, slowly but surely.
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.
Other platforms have ways of making this difficult. For example kaggle doesn't count upvotes from users with too little prior involvement, and stack overflow's new user votes also don't count until that user has enough reputation.
I made a comment here yesterday how you can't use github accounts alone to measure someone's ability for similar reasons(I was arguing how IT/security certs have their place because they're proctored).
A significant number of folks (especially non-professional developers) make a choice on which library/project to use based on the number of GitHub stars. For these people, the more number of stars, the more it means the 'package is good/useful'. You can argue it isn't the best/most effective way but it's quite common.
I find myself (as a professional software dev) trying to break that mindset frequently, especially on GitHub, when looking at libraries to use for a task if there's more than 1.
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.
- 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.
in old languages that don't encourage tons of dependencies like C, it's okay to call a library finished and stop developing it, so last commit 4 years ago is ok
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
Maybe 4 years isn't the right time frame but at some point there were sweeping changes in the language, like futures and async/await, that invalidated large parts of the ecosystem overnight (if you made a bet on a particular ecosystem you would either be stuck at maintaining an evolutionary dead end, or eventually migrate to tokio). It seems that Rust evolution is slowing down though.
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
I was about to say there needs to be a tool that accounts for all these metrics and generates a summary with a score, but then I realized that if a rating algorithm is out in the open, people will game it.
And whether the project owner/originator/maintainers are open to suggestions, how they interact with people, and whether those issues are linked to commits.
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)
It’s common, but also absurd, to hold your own teammates to a higher standard than you do some internet rando contributing a big block of code to your project.
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.
Agreed, I haven't ever really looked at stars, mainly I look at number of/most recent commit and the state of the issues tab, with more importance assigned to the latter.
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).
That's the argumentum ad populum ("popular = good") fallacy[0] which is probably most of the most common logical fallacies. You can tell quite a bit about a person, not just as a developer but in general, by whether they always go with whatever's popular, they always go with something obscure or they go with a mixture of popular and obscure.
If we look at “best” more broadly, popularity isn’t a terrible metric. I want a library to be actively fixing bugs and I want support if things aren’t behaving as expected. Stars is a rough measure, but we can look at resolved issues as a better metric.
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.
That's quite delusional, unless you are the creator of brew or something popular and useful, chances are I won't open your github and I'll stop at your resume
Thanks Remotespyhacker for your good works. i have seen lots of recommendations about you on different platforms that's why i gave you a try to help me know if my husband was cheating on me and successfully you got the job done without any trace . Right now my partner is apologizing to me . you helped me get access to his snapchat, whatsapp. hidden photos and even deleted messages. You are the best i have ever met. keep up with the good works. Anyone in such need of your services can reach out to you ( remotespyhacker @gm ail c om ).
