Hacker News Reader

Comment by c7DJTLrn | Hacker News Reader

I really don't like how GitHub has turned into a social network of sorts. The gamified elements are encouraging people to work for free and MS probably knows this. GitHub should just be a place to host and build code, not to flex your follower or star count. Some examples of gamified elements I find quite toxic:

  * Achievements on profiles
  * Highlights on profiles
  * "Activity overview" which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)

View on HN

I saw it today in someone who announced a package and in their README had a gif of a mouse clicking to add a "star" to the repo. Like the youtube videos that ask you to "like and subscribe".

"Star and watch for more great software"

I'm glad we don't see this in npm post-install hooks... yet

Don't give them ideas.

Let me take this opportunity to thank today's sponsor, Whatever dot org. Yadda yadda yadda.

.org is for the 90s.

we live .io era these days (sadly)

.io is already so yesteryear.

There is/was .ai for a bit but its less generic.

I promise to leave more high-value comments if you can get me a deal with Whatever.

"This dependency tree is sponsored by NordVPN. Staying safe online is an ever growing difficulty and you could be exploited by hackers. NordVPN allows you to change your IP address, making you harder to track, securing your privacy. Check out the link in the API docs to get 20% off for the first two months. Thanks NordVPN!"

It's not a new idea; npm had its run-in with ads a couple years back[0].

[0] - https://www.infoq.com/news/2019/08/npm-bans-package-ads/

`gh api --silent -X PUT user/starred/evil/pleasedont` seems like it'd work for many users who leave magic tokens in their $HOME...

I'm very much not a fan of ambient authorization.

That won't work because of CORSs, no?

A startup for which I had applied to a job opening few months ago reached back to me and asked me to check out one of their repos and star it if I thought their project was good. Never heard back from them about the job though

I am surprised that there is no widely-spread Starware license yet. “You are entitled to use this software after starring X/Y on GitHub.”

"If You institute a revocation of a GitHub star against any entity (including cross-repository and cross-user removals) alleging that the Work or a Contribution incorporated within the Work no longer constitutes a GitHub star, then any patent licenses granted to You under this License for that Work shall terminate immediately as of the date such a revocation is performed."

I've seen this on a lot of the hacktoberfest repos this year. The repo owner will only authorize the PR if you star them

And here I had just read the parent comments as sarcastic. Ugh.

At least you can revoke the star after the merge.

Begging for those interactions makes 15 seconds of every video telling me to smash that like, subscribe, bell, comment, share, rewatch 10x for good luck.

Should we limit the # of likes/stars one gets per period of time? Scarcity?

Try the SponsorBlock addon

Since it’s always the same comment it is easily compressible and should just be automatically generated and included as part of the pre roll ad. Then it could even be localized for the viewer!

this decade will be a giant sociological study

This is the social commentary where OSS and freedom respecting software intersect. It was called upfront when the split happened.

Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time.

Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.

Maybe this is a hijack, but IMO current packaging tools/workflows are a big part of the problem here. Forking a Python package to give it a new name is a giant pain, and if you don't rename it and only release it to a private pypi, you're inviting angst and confusion from your internal users. The only alternative is to put your git url and branch directly in a requirements.txt file, which is not remotely scalable.

These kinds of issues exist across npm, homebrew, apt, etc as far as I'm aware.

In contrast, Nix overrides allow patching in fixes at varying degrees of locality, making it trivially easy to maintain a long term fork or just apply unmerged fixes in the short term.

Composer also has a fairly robust patches plugin, I hate other ecosystems that basically require a full fork.

I feel like a fundamental issue is around human-assigned package names and linearly incrementing version numbers. Anyone who graduated from SVN to git understands about using hashes for true object identification, but it seems it's not nearly as widespread in the packaging world, other than for caches and lock files that most users never interact with directly, and rarely-if-ever for enabling nonlinear package evolutions.

Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.

I would not put it on linearly incrementing version numbers, as it is a great label to show known stable git hashes. But version numbers should not be the only way to fetch in packages.

Absolutely, and that's what Nix does. You can of course access anything in nixpkgs by named attribute, and it will have a human readable version number corresponding to the upstream source. But the internal representation is all based on input addressing and hashes.

> Hard to fork and maintain my own version

apt-get source xxxx

put patch in debian/patches

dch --increase

dpkg-buildpackage.

Copy the patch and rebuild next time a new version comes out.

Creating bridges that allow Apt to become the overarching package manager for all sorts of language-specific packages would be extremely interesting.

$ apt rdepends debhelper

Most languages have that already.

> Hard to start with a package and float my own changes.

Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches

The social aspect to GitHub is very much not front and center, so it seems very innocuous. How are badges toxic?

It certainly seems like a waste of their development time. I looks at these badges for a moment and think "neat" but nothing else. And profiles I just ignore, especially the ones people Myspace-ify...

Badges are toxic because they divert a subset of people away from their current open source workflow to focus on getting badges. In reality, the incentive of a lot of these badges is for GitHub's best interest and not necessarily a project's. This is insidious.

To finish my badge collection, I need:

* Merged a pull request without a review - 100% toxic.

* Answer 32 discussions - this is a strong incentive to enable GitHub Discussions on a project, which is the wrong move

* Create a repository and get 4096 stars - diverting focus from the projects I maintain (although I'm a core contributor to a project which meets this requirement, I didn't create it)

* Coauthor 38 more commits on merged pull requests - this'll happen over time. Not a 'bad' thing, but not something I want to take time to achieve.

Above needs to be more prominent.

Why is enabling Discussions "the wrong move"?

Genuinely curious, as I've gotten help from maintainers using Discussions.

(personal opinion)

Last month we had ~25 code contributors and ~2.32 million users. About 100,000 users per code contributor.

As a user-facing app, rather than 'open source infrastructure', we receive a very large number of support queries from end-users. A significant number of these will be users who are entirely non-technical, or don't speak English at all (looking at my last support efforts, ~20% were non-English + resolved via screenshots, videos + Google Translate).

I'd much rather have our community triage via one of: Forum, Discord, Reddit, StackExchange, Google Play, Mailing List, Twitter, or Facebook Messenger and leave GitHub for code/documentation-level discussions.

Opening up GitHub discussions adds another level of distraction to GitHub notifications, and provides little benefit in return given the existing established support channels.

EDIT: I do have GitHub discussions on other repos, but they're not always suitable.

Yes, this is a good summary of how I feel about discussions too. Non-technical users are going to be more comfortable using non-Github platforms anyway, and for technical users issues or chat are probably a better fit in 95% of cases. Not worth opening an entirely separate forum for.

Is there a badge for using powers of 2 in the wrong places in an attempt to look nerdy like eyeglasses with window glass lenses?

Powers of 2 are just as arbitrary as any other number.

Just turn them off in your account settings. I did the day the badges feature went live.

I don't badge hunt. Others do, and it's worth pointing out the toxicity occasionally.

By staying quiet, we're incentivising the following:

https://stackoverflow.com/questions/72662385/how-to-merge-a-...

He could have just created a second account to farm it by himself.

1) That's against the GitHub ToS. Both accounts will be banned and the user will be permanently banned from setting up a new account.

2) Even if it was kosher, how exactly is this improving Open Source?

1. Only if they catch you.

2. What does farming weird achievement have to do with freedom?

I'm with the grandparent poster in that I see a badge/achievement/whatever and think "neat," but I don't feel a visceral compulsion to collect the whole set.

It seems there are people who do feel that way. I wonder if the folks who set up the badge system are all of the first type, and didn't realize that some people would be thrown completely off the rails by it.

> Merged a pull request without a review - 100% toxic.

There's a case where this is not just ok, but healthy (especially on smaller teams) - if you're comfortable doing trunk-based development then you can use a PR to "snapshot" a set of changes and either invite commentary or just have a link to share as an FYI around the change, without the awkwardness of linking to an unnamed commit sequence.

https://martinfowler.com/articles/ship-show-ask.html

I would say this is never healthy, even for a team of 2 people. These days merging code without at least asking for a review should be anathema for devs. Even a 'rubber stamping' review at least signifies a shared awareness of changes.

Other workflows exist; pretty silly to act like you’ve found the One True Way.

If you don't care about code reviews, why care about a PR process? don't protect the branch and just make your commits. The notion of a pull request is you're requesting someone pull in your changes. But you don't want them to review those changes?!

Yes, you can get that badge safely only if you adjust your project's development flow.

This exactly proves the central point of the article - gamification affects software developers.

Viewed from a different lens, these achievements seem intended for new GitHub users.

I recall merging my OWN pr into my own new repo. I was surprised with a badge. No harm in that.

I play a lot of video games and I also don't get the appeal. Then again maybe because I play actual games that makes the gamification feel stupid.

Use https://sourcehut.org/ then. It is against such gamification elements and Drew has been quite vocal abut this issue.

If you are also down with requiring that your would-be contributors conform to his preference for email patches. https://man.sr.ht/git.sr.ht/send-email.md

"SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such."

https://news.ycombinator.com/item?id=23038520

(And therefore, perhaps, ill-advised to recommend it as such)

Does Drew prefer email, or prefer not doing more work than he already does?

Hmm - review is not a part of git, in fact it is antithetical to git (concept from cvs/svn with centralized systems).

A pull request, literally, need only be moving code from one repo to another.

The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means.

That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics.

E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.

>Hmm - review is not a part of git

Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.

Those are tools to facilitate moving the code from one repo to another, not to facilitate a review of that code. So I think the GP's point stands.

I mean, it facilitates code review as well. You just reply to the email. This is how Linux is developed, for instance.

Yes, but you do not reply via git. You review the patches in the MUA of your choice (outside of git) or in editor or IDE of your choice, after applying them in your local repository clone (applied maybe by git, maybe by the "patch" command, but viewed and evaluated completely without git), then you compose a reply in your MUA or maybe have a direct chat with someone about it (again, outside of git).

Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them.

Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.

Alright, sure, but you're picking nits and I'm not sure what your underlying point is.

I do not believe it's nitpicking. I was supporting the post you replied to (https://news.ycombinator.com/item?id=33313036), which claimed that git indeed does not have review tools, and that the review tools/flows are and should be external to git. You claimed otherwise, and I argued that you were incorrect in that claim.

Isn't that what discussion board is for? I agree that this particular topic is not life-and-death important, but still worth discussing, IMHO. If you think otherwise, just walk away, you do not owe anybody anything.

It isn't picking nits, git does patch management, there is nothing and shouldn't be for review.

It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling.

(Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things.

Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.

SourceHut author here. Not sure what you're trying to say. The opposite is also true: using GitHub requires that your would-be contributors conform to the pull request workflow instead -- and many people prefer emails.

If anyone is skeptical about the email workflow, here's a write-up from another skeptic:

https://blog.brixit.nl/git-email-flow-versus-github-flow/

What I am saying is that, both in what I've seen and what you've stated, SourceHut is emphatically not trying to be "Github but just without the gamification elements", so if that's what people are looking for, they probably want to look elsewhere.

> "Github but just without the gamification elements"

Where did this quote come from? You just made it up?

You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?

No, I am not trying to retort/rebuff, and this thread seems unexpectedly confrontational.

The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.

> This exchange positions SourceHut as "Github, but without gamification elements"

No, it doesn't, and it's dishonest to try to make that move—just as it is dishonest to manufacture quotes (that are, in this case, designed to provide the opportunity for that attempt).

"Github but just without the gamification elements" does not appear anywhere outside of your own comments and is, in fact, much stronger than what was claimed in the original comment you responded to; the person to whom you responded and to whom you were being needlessly confrontational pointed to SourceHut as an option for people who dislike gamification and are looking for a provider that is just "a place to host and build code". There was no claim about the suitability of SourceHut for anyone who doesn't meet that description, let alone anyone who requires/seeks/prefers(/whatever) "Github, but without gamification elements".

Please stop manufacturing quotes, and please stop defending their use by pleading that "[t]he quotation paraphrases". That word sequence alone is a dense contradiction. Making up false quotes is especially troublesome when they are freely mixed into discussions where a person has otherwise already previously made use of genuine quotes (such as the way you did when quoting the creator's remarks that "SourceHut is not GitHub/GitLab/Gitea[...]"). To do so is pernicious, and the entire practice is against HN's rules.

<https://news.ycombinator.com/item?id=13602947>

<https://news.ycombinator.com/item?id=15891418>

Thanks for letting me know about the quote rule! While "pernicious" is IMO overdramatized, avoiding that shorthand is a sensible-enough community practice for a venue where people often skim and get heated about things; I won't repeat it.

I still think you're reading a lot into this thread that is not there, and ratcheting this up to the level of accusations of dishonesty is a pretty interesting/illuminating choice. However, I don't actually have a dog in the fight; consider all points ceded.

Not interested in deflection, and not interested in passive aggressive quips like "is a pretty interesting/illuminating choice", either.

> I still think you're reading a lot into this thread that is not there

To reiterate the background for this discussion: a participant in this thread went a step further than what you're saying here and literally* wrote things in that weren't really there.

* literally literally, not the other kind

Fair point. Codeberg.org is more GitHub-like and has fewer gamification elements, for what it's worth, but many platforms which aim, more or less, to be GitHub clones, often include these elements without much critical analysis.

SourceHut is very modular though. Could we make a separate app that implements pull requests? :thinking:

> conform to his preference for email patches

How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.

Right – something else like Github, the component under discussion, which is dissimilar to SourceHut in more ways than the gamification elements under discussion.

If I start pestering them now, the security team at my LARGE_CORP employer might allow me access to sorucehut.org in about 3-4 months.

Part of using Github is that it's from Microsoft therefore on the 'approved' list.

… turned into?

GitHub’s motto VERY EARLY ON was “social coding”. They kept that motto for a long time.

Yes, one of the earliest archive.org snapshots from 14 years ago shows this:

https://web.archive.org/web/20080906001759/http://github.com...

Love that self-presentation from 2008:

https://web.archive.org/web/20080905195808/http://logicalawe...

Yes. And it did that perfectly well five years ago before they bolted on all this bloat nonsense.

Yep, many people forget GitHub was trying to be Facebook but for coders from the very start. Back in late 2000s when FB was the hottest startup everyone was trying to do "the Facebook of X" knockoffs.

Now we need a Facebook for sharing photos, videos, events and posts with our friends and adjacent social circles.

Fediverse on a curated homeserver is getting there. Or having importable killfiles

  - photos :: instagram
  - videos  :: tiktok, youtube
  - posts :: HN, reddit, dev.to, substack, mailing lists (yes, people still use those)
  - events :: messengers (telegram, whatsapp, etc), email.

Missing from all these is a social network of "our friends and adjacent social circles". And perhaps, on top of it, a service aggregating output of all the ones you listed, so as a user, I can have (for a lack of better term) "people-first" mode of interaction. By this I mean, I want it to answer the question, "what have X been up to recently?", where X is a scope I can alter - from "all my friends" to "a particular group" to "particular friend".

I.e. what Facebook used to be, before the "great social network unbundling".

That was what Google plus wanted to be lol

This paper is about how gamification affects behavior, not about it being some sort of social platform. Every platform was "social X" around the time github started up. Lots of sites have social elements and it never amounted to them being called social X either. Sure you can use those features in some sort of gamesmanship, but generally it's not used that way and so few people care that it's laughable.

> "social coding"

Social coding is not Github's primary function and it's hasn't been promoted in earnest, this way because it's secondary at best. Ostensibly, it's hosted git. That's the naming, the function, and most developers think of it as such. The vast majority of users are either corporate developers who work for some company and can't care less about the "social" aspects of it or insular developers with projects that never see the light of day.

Notably, this paper only sourced public repositories, where many people use it as an element of their work portfolio. This doesn't speak to "all of github".

It's GitHub, not GitHost.

hub /həb/

noun

    1.
    the central part of a wheel, rotating on or with the axle, and from which the spokes radiate.

2. the effective center of an activity, region, or network. "the city has always been the financial hub of the country"

Maybe it should become GitHost then. The only thing I want from GitHub is a pretty web page where I can browse git repositories.

So a website used by millions should become what you want it to become, not what others use it for?

If this thread is any indication, yes. GitHub only gets ever more toxic with this gamified social media stuff.

You're under the impression that the few people in this thread complaining about the social aspects on Github is a greater force than the massive amount of people USING their social aspects?

Actually yeah. The stuff we're discussing here matters. The behavior of developers is being shaped by these designs in absolutely harmful ways. I would know, I've been down that rabbit hole myself with video games and other "gamefied" apps.

Look at the article:

> We find that the unannounced removal of daily activity streak counters from the user interface (from user profile pages) was followed by significant changes in behavior.

> Long-running streaks of activity were abandoned and became less common.

> Weekend activity decreased and days in which developers made a single contribution became less common.

> Focusing on a set of software developers that were publicly pursuing a goal to make contributions for 100 days in a row, we find that some of these developers abandon this quest following the removal of the public streak counter.

Look at this bullshit. People doing work just to maintain their streaks. People making literally one contribution just to keep it up. That's fucked up and needs to be fixed. Nobody deserves this operant conditioning stuff.

There's fixes that can be made (and Github is aware of), without turning Github into cgit. I don't want that and pretty much nobody wants that - those who do, already use cgit.

Conceptually, I like that Github has social aspects to it. But Github needs to be more careful about what they emphasise. IMHO the existing mechanisms they have reward rather toxic behaviour.

> So a website used by millions should become what you want it to become, not what others use it for?

The name is irrelevant. The vast majority use it for hosting. What someone wants or doesn't want has already been decided in the market.

https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb

Git is absolutely trivial to use in a fully decentralized fashion. GitHub and GitLabs success shows how much people don't want to run their own servers.

social networks are hub-and-spoke? which of us is the hub?

financial hubs don't _host_ financial institutions and their assets?

IMO this is the main thing GitHub has over GitLab. Most platforms which support GitHub also support GitLab, GitLab has equivalents for many of GitHub's features like actions, and GitLab even has comparable free tier storage (as they've decided not to delete inactive free projects [1])

If someone just wants to host and build code there are many alternatives (like Sourcehut). The only reason GitHub is so dominant is because of its already huge following and exploration / networking which relies on said following.

[1] https://news.itsfoss.com/gitlab-inactive-projects-policy/

GitLab is most known, most trusted, most featureful, most funded. It may be politically suspect, but that's not a priority for most people.

Did you mean GitHub?

There have been a lot of red flags with GitLab recently. This (aborted) plan to delete projects was one of them, but the recent limits on CI they impose on open-source projects get in the way quickly compared to GitHub: 2,000 minutes per month.

Personally I am planning to move to GitHub soon. The CI limit is very small for an active project testing across a few different Python versions, I am reaching it just with a couple pushes per day.

Consider sinking capital or asking for donations for your own CI then - sure you might get something for "free", but if you aren't paying anything then you might just be the product.

Serious downsides to being the product include: * No means of production - whatever profit you hoped to have can simply be taken away from you. * No control over your likeness, IP * Limited legal protections * Finding yourself being sold in ways you find unethical.

I'd reconsider your planned move, unless I guess you really just don't care about your project longevity...

GitHub's just a tool to me. I can put my project any number of places, including my own server, any time I want. Why would I pay for compute ("means of production") or contend with a lower limit when I can get it for free from GitHub?

I don't know what you mean by "taken away from you" or "control over likeness" or even "legal protections". Code is intangible, it can be multiple places. If you're referring to Copilot, my code can already be taken whether I use GitHub as my base of operations or not, because it is public and GitHub feels the thing is "fair use"...

You throw around big words that apply to other industries, but what specifically do you think I lose with software?

"GitHub's just a tool to me."

Tools are not made all equal, and there's this fallacy that just because it is a tool it is probably OK and as easy to use as abuse.

To borrow from the medical industry - yes, opiate drugs are absolutely useful _in specific cases of extreme acute pain_, but that doesn't make them good tools for dealing with a headache.

A tool can be bad, even if it can be used well, likewise a tool can be good even if it can be used for bad.

"Code is intangible, it can be multiple places" - you should study law, especially wrt existing legal precedents. If this were true, things like software patents would not be a problem, and I would evaluate how much you really can lay claim to your code, especially now Microsoft has played their hand here...

In a world where digital media and electronics remain an important part of every industry, and large rich tech companies exist, these are absolutely concerns, this is not some idle ideological patter. Your IP matters, (F)OSS has IP as well, that's part of why any of this matters.

Choose your blade wisely lest it cut you.

if i may be so bold, this is an encroaching effort from multiple large players, FAANG included. its a pretty ham-fisted, transparent attempt to get the kids excited about code in much the same way your spanish teacher tried to pump the kids up to learn with a fiesta.

The idea is to increase the number of programmers, decrease the median pay rate of the average programmer, and recapture the excess capital lost from the past 60 years of nerd-shaming that led us to consume more code and tech than we produce.

the only people whining about code not being fun and pushing gamification are the very people who shouldnt be doing it.

What does "consume more code and tech than we produce" mean?

Parent thinks there is a fix amount of code needed in the world, and the only reason (some) programmers earn a lot of money is that a relatively small number of people produce that code. They ignore that the cast majority of code generates demand for more code.

Exactly! A successful software project creates a building block. A basic human desire is a) to modify the successful design to perform some other task, and/or 2) to use an existing building block to build something bigger and more complex.

The “Lump of Code” fallacy

my first "wtf" was seeing the "pull shark" badge... really? I do like that they give you the option to disable showing your achievements in the settings.

The badges are just not that compelling. Feels like an "everyone gets an award" thing. You shouldn't get an award for making a PR.. Show an award when your repo reaches 10,000 stars or something.

I've always seen the activity overview as a way to see if the account is abandoned and nothing else.

Personally, I haven't even noticed any of these...

FWIW I don't notice it in my usage of GitHub... but yet I've still noticed it because projects I've been involved in which happen to use GitHub end up with people showing up who clearly just want the badges or who explicitly admit they are wasting my time trying to get a "contributor" status on the project so their icon shows up somewhere and while at the end of the day the problem can of course be blamed on these people who fall for this stuff, GitHub knows what they are doing as these features have no legitimate use case other than to gamify their platform.

I don’t disagree that GitHub should tone down the gamification. However, I do disagree with this:

> which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)

Reviewing code and triaging issues is real work.

Isn't designing and programming also real work?

If you don't like how GitHub has become a social network of sorts, you really won't like how LinkedIn is apparently the new Facebook.

I have even seen a number of creepy screenshots from horny single men on LinkedIn sending unsolicited messages to women they think are attractive, trying to use it as a dating website.

GitHub and linkedin are both owned by MS and trying really hard to be social networks, so the follow on social consequences of mass adoption seem almost inevitable.

Wow that's a tangent.

Seems on point to me, another example of how everything Microsoft touches turns sour...

Just focus on fixing your nightmare OS and maybe stop building nonsense everywhere...

Star count has some interesting side effects. On one hand, it incentivizes people to produce something popular — and by proxy something useful. On the other hand it can be cause addictive behaviors.

What’s even worse is the notion that my employer requires me to use a social networking site for my day to day operations.

https://bower.sh/github-as-social-network

Popular and good are only loosely related.

Star counts on a repo are both essential for devs who need to assess a range of libraries/products for possible use in their own product (as indirect indicators of support, community, etc), and yet also toxic for anyone trying to build a new library/product in an established niche (everyone ignores repos with low star counts).

Clearly if I was serious about marketing/promoting my library then asking people to star the repo would be high on the list of asks. Sadly I am not that person.

On the other hand, having starring a repo made into a game will skew the stars' usability in gauging a project's popularity or quality. Maybe the "most starred repo for X" is just made by someone who's really into collecting badges or marketing.

I think it is fine. If you lack consciousness to notice when you are, as you suggest, tricked to working for free, you have much worse issues. I started my programming due to a social network need in the first place.

Don’t blame the users for wanting to change a predatory system. They’ve already identified the problem — telling them to simply ignore it is dismissing their humanity. We’re not machines and need to work inside those constraints

you can turn them all off, at least for your own profile

It was but people want more.

Everyone should be forced to read the Linux mailing lists to see how git is meant to be used.

Reply on news.ycombinator.com