Long time ago Sourceforge and then GitHub promoted into the current default the model of open source distribution which is not sustainable and I doubt it is something that the founding fathers of Free Software/Open Source had in mind. Open source licenses are about freedom of using and modifying software. The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user to better fit the user's needs. To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all. The currently default model of having an open issue tracker, accepting third party pull requests, doing code reviews, providing support by email or chat, timely security patches etc, has nothing to do with open source and is not sustainable. This is OK if it is done for a hobby project as long as the author is having fun doing this work, but as soon as the software is used for commercial, production critical systems, the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane. This is software support, it is a job, it should be paid.
Years ago, I built what I thought was a pretty basic static site generator using HapiJS. I was using it for personal projects and after some convincing by friends, put it up on Github. My friends went on Reddit and posted it and then told me about it afterwards.
It initially got some decent traction and then all of a sudden, all the pull requests came, all the feature requests and then all the bug reports.
I kept telling people this was a side project, if they want to fork it go ahead, but this is not something I'm going to spend a ton of time on. Then all the hate started about how I put something out into the OSS community with no desire to support it. I was bad person, my code was shit and I should stop being a developer.
That was my first and last OSS project.
I applaud and respect the people who are committed to getting OSS out there, but for me, it was a horrible experience.
Bitching is free and easier than making pull requests. And I bet it was 1 or 2 choads plus a variable pack of minions, not everyone. And Megacorp X can file all the bug reports they want, their lack of investment is not my urgency.
If you allow me to go on a meandering tangent/exploration:
___
I mean if you think about it, this outcome is more or less inevitable, given the environment we've created.
The foundational building block being that people will always optimize for their own benefit and personal gain. They fundamentally have to, because no one else will.
So that gives us a natural source of conflict, because not everyone is a builder (or at least not everyone believes that they would), meaning that they need to get someone else to do what they want to get done.
You as a builder of course operate no different to that. You also want to optimize for your own personal gain.
Where it is different though is that you do not rely that much on external resources to do that, given that you can create by your own.
So these are our building blocks.
To have a functioning societal system, we do want and need to allow people that don't to receive a decent-ish slice of the output of those that create for various reasons.
Something something shared humanity, but also the fact that a society built out of autonomous builders quickly collapses. Plus multi-dimensionality, meaning that person A might be a builder in discipline X, but needs others to sustain themself in discipline Y. Society and all. Shared workload.
The mechanism that regulates the flow of resources between these agents is friction.
For example, social shaming for not sharing the fair part of what you're earning is friction. That is a constant eroding force and cost that is supposed to shift your internal mental calculus to make contributing to society the most sensible outcome.
Equally so, the act of being protective of your time, demanding respect, boundaries and fair compensation is friction that is supposed to shift someone else's mental calculus to make fair treatment of you the most sensible outcome.
____
Okay, many words, but what the fuck am I on about?
Here's where this self-regulating system implodes:
In the last two decades or so, we have absolutely supercharged the mechanism of shaming and public pressure (rel: Twitter).
Simultaneously though, we've also _vastly_ nerfed any forms of friction a builder might employ. (rel: GitHub as the default, being "nice and professional" as the default, etc.)
And that is what simply is not working.
But we're not talking about that properly, because any platforms we currently have for talking about stuff are absolutely and utterly dominated by those that do not create; meaning that they get to dictate the rules.
In a very unsustainable way of course (see also collapse of democracy in general) but that is still the reality we find us in.
___
And that is _I think_ also where we can find solutions to these problems.
Don't get me wrong, I'm not proposing to return to linus and tell people that they should be retroactively aborted for having made a mistake.
There were many very important advancements we made culturally to push out toxicity.
We will need to reintroduce friction though.
Likewise, we will need re-engineer our communication spaces to shift the balance of power back to a sustainable equilibrium.
Which doesn't mean "cold uncaring meritocracy" (also, what even is merit?) but it will mean not handing out ever-larger megaphones based on who is already screaming the loudest.
___
Anyway, TL;DR:
It's the system, stupid. It is like this, because it can't be any else given the currently governing rules.
I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
The project managers also get a cut of all merges, testers also must approve of the merge and that feature X is the one they want. So the project manager gets to work and improve/reject features, the user gets control over the features of the project they want and developers get to pick specific features they would like to work on (sort of). everybody gets what they want (sort of). All via attaching $ to the issues of the software, not the people.
All we need to do is create Kalshi contracts! Users bet that a fix won't be created for Issue 123 by date XYZ, developers take the other side of the contract and then do the best kind of insider trading: changing the facts on the ground. We did it!
And a few weeks into that arbitrage traders will catch wind and start betting on the more likely bug closures and then the devs that fix the bug will end up owing money!
> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
Have a bot on GitHub that nags people about the pool of committed money towards each feature, to show that they care about it - with the money being placed into an escrow and being released once the feature is implemented and merged, or until a date is reached with no merge and it's given back to everyone / or when the request is closed with no changes. Ofc no idea how you'd validate each individual issue well enough to prevent someone from misusing it, but one could feasibly create such a system, even if it'd probably get a lot of opposition from everyone.
> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created
It might be good to have such a system as an option, but I wouldn't want it to become an expectation. I've got a couple of side projects that are out on GitHub. They have open source licenses and anyone is welcome to fork them, send bug reports, or pull requests, but I don't want to have any obligation of supporting those projects.
You know what would be nice? For these billionaires to start sponsoring people instead of sitting on the obscene heaps of money they have—a patronage system. Everyone wins.
That's actually how a number of OSS projects work, we'll give you what we want for free but if you want us to do what you want you'll need to pay us. Having to implement a compatibility mechanism for some company's buggy train wreck from 20 years ago is a lot easier when you know you'll get paid at the end of it. A number of OSS dual licenses have been created to accommodate this.
Are there any projects that have achieved anything close to this? I'm not against it in principle, but it seems like it ends up incurring issues from tiptoeing around wanting all the benefits of an incorporated business with employees or at least contractors without the stigma(?) of getting all official and putting someone in the hot seat of responsibility. Off the top of my head:
- A business has some intrinsic motivation however minuscule to fix unsexy issues like security problems or problems that aren't as visible to customers so they don't get hacked and sued and go under; in a pay-what-you-want bounty scheme all of your users are playing chicken to not be the one to put up the money for the fix. Instead they'll wait until it becomes a problem and fix it in their own branch; no reason to bother upstreaming it until someone comes forward putting up the money.
- IMO there's no way to measure cuts for something like this that can't be gamed. If you close out the bountied issue, but you make use of a bunch of utility code I contributed last week, who gets it? Or if the code I contributed is mostly a mechanical refactor of some very complex code someone else wrote? Do we divvy it up by lines of code, number of commits, etc, and that's just for the squint-and-it's-qualifiable metrics for engineers. No idea how you'd measure a cut for project managers. Someone also may be the steward of the repository and handle administrative work but not do a whole lot of feature-fixing, what cut do they get? Instead of juggling KPIs you can just pay all these people for their common contribution - time - and then you're back at something that businesses do really well.
- For any bounty system to work you need somewhere to track the bounties and hold money in escrow for payouts. Those services exist, they cost money to run, and they are going to take a cut. I'd assume they'd also invest and grow that money while they have it unless that's illegal for some reason I'm not aware of. An incorporated business keeps its bounties in the issue tracker, and its money in an account that accumulates interest that can go toward further development on the actual product instead of third-party support services. Crypto is a no-go here because that limits your contributor pool to exclusively crypto perverts, otherwise normal people have to speculate on it and convert it to normal useful money for a fee.
- I've worked at a place where the devs got to work on whatever they wanted. Required to, really, because there was very little interest or hands-on management from the owner in the direction of the product as long as sales were stable. We had a great time and got paid and we all learned a lot on company time and last I checked they are no longer in business.
- Timelines are a big factor too. If some open-source software I'm using is missing a big feature I'd like (and if post-2024, it's too substantial to just make a copy and have Copilot customize it for my use) I'm still not going to kick in the first $10 in the hopes that somebody someday builds that feature for me. I'm going to be dead or not using the software by then. If I thought the feature I wanted was worth $10,000 and I had $10,000 to kick towards it in the hopes that somebody somewhere would decide to build it, I would instead hire somebody on contract terms to do the work with a greater guarantee of results and some recourse if they screw me.
Those normal users are better off instead purchasing software. Then they will be listened to by developers if they report a bug or suggest a feature. Because they represent an incredibly valuable user segment: paying customers.
Users matter a ton to windows. Specifically, the users with a hundred thousand or more licenses. Their unhappiness threatens Windows' profits in a meaningful way. Why do you think all the new secure boot and TPM features were added to Windows 11? All that work wasn't free to implement. But big businesses really want that degree of secure fleet management, and they're the customers who matter.
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
Large entities asked Microsoft to stop simply bundling Copilot with all those services and instead relabel the services so that their usage could be counted as AI usage in their quarterly report whether or not they actually engage with the AI features?
I think it's clear the source comment was referencing end users. It's patently obvious at this point that a large number of people who directly use Windows are frustrated with it, and perceive it to be degrading rather than improving over time.
A corporate end user isn't a customer. The customer is the corporate department of purchases. What I mean in my original comment is that if you as an end user purchase software, then you will be listened to by developers.
Most users of Windows get it for somewhere between free and $150, the fact that there is still a home edition of Windows is practically a loss leader to keep the business side ingrained. Enterprise licensees are the ones with the money and Microsoft will dedicate full-time engineers to their features if they can afford it.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
Free Software sure, that wasn't the point.
Open Source, that was exactly the point. Eric S Raymond, one of the original promoters of the concept of Open Source coined Linus' Law:
Given enough eyeballs, all bugs are shallow
Which definitely points in the direction of receiving bug reports and patches from users of the application. He was also a proponent of the Bazaar model, where software is developed in public, as opposed to the Cathedral model where software is only released in milestones (he used GCC and Emacs as examples, which reinforces the part of your statement about the Free Software movement in particular).
ESR is also from a time where spamming countless reports/junk code wasn't really a concept.
They did have things like trolls and zealots that thought "Their one idea" was a gift from god and the maintainers were idiots for not adding it to the application. And eventually those people may have been banned from mailing lists. But in general the people posting code were typically well known and had some interest in fixing the application for some useful purpose.
Simply put, no idealism stands the test of time without change. Nature shows us that everything must evolve or it goes extinct. How 'free software' evolves is now up for debate.
Linus’ Law doesn’t really imply anything about maintainers behavior though. As an example, you can imagine maintainers that never update their repos. Every bug fix is a forking of the repo, and people only use the repo with the latest commits. Eventually, the bug count goes down as well!
I don’t agree with this newer idea that has arisen that FOSS authors are “victims.”
It’s up to you to set boundaries (or prices) and communicate them, like an adult. If one is still rude and entitled then ban them from the repo, or let people fork, but not before looking in the mirror first and reflecting at your own behavior.
(I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.)
As always it depends on the circumstances, but should default to quietly closing with WONTFIX. Others have said Daniel is typically helpful and respectful so there we go.
What you linked to is not really evidence, just an unsubstantiated allegation. Over the top public shaming is something that should be pretty easy to provide direct evidence of. When Linus Torvalds does it, it gets repeatedly brought up in forums like this for many years.
> I have no reason to believe it is a lie, and it sounds plausible
Except for all of the responses from people saying it doesn't sound plausible for the project in question, and for the acute lack of real evidence or even details to accompany the allegation.
Additionally, I think "last resort" is way too high a bar. It's totally reasonable for an open source project to have a zero-tolerance policy for AI-generated spam patches or bug reports, and to respond with public shaming after the first offense. Nobody should be expected to make any allowance for such egregious behavior.
A user who is genuine but simply doesn't know how to usefully communicate about their problem doesn't deserve that treatment and should simply be ignored if the devs don't have time to engage in the interrogation necessary to extract a useful bug report. But if the user decides to try to use an LLM to compensate for a lack of content in their bug report, that user would be earning a negative response by making a bad decision. (If you're going to use an LLM, ask it how to write a bug report, rather than asking it to make up a bug report for you.)
Afaict github allows you to disable 'Issues' per repo, yet few do. I presume that means they are okay engaging with issues on some level, but I find it odd almost none post a policy/expectations around them.
> I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.
... Did they try anything as petty as the xorg maintainers are nowadays?
Sourceforge is almost 30 years old. GitHub almost 20.
How long does something have to be done a certain way for it to be "to do with"?
I would say we're now two generations deep of software engineers who came up with open source software commonly being mediated through public issue trackers.
That isn't to say it needs to stay that way, just that I think a lot of people do in fact associate public project tracking with open source software.
I partially disagree. It does have to do with open source: Github (et al) are about creating a community around an open source project. It's hard to get adoption without a community; it gives you valid bug reports, use cases you didn't think of, and patches.
You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
> and is not sustainable
I 100% agree. People (including people at for profit companies) are taking advantage of the communities that open source maintainers are trying to build and manipulating guilt and a sense of duty to get their way.
The most insidious burnout I see is in disorganized volunteer communities. A volunteer is praised for jumping in with both feet, pushes themselves really hard, is rewarded vocally and often and with more authority, and is often the one applying the most pressure to themselves. There's no supervisor to tell them to pace themselves. And when their view switches from idealistic to realistic and then falls into pessimistic, they view the environment through a toxic lens.
> You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
Literally you cannot, you can turn off "Issues", but you cannot turn of pull requests, Microsoft/GitHub forces you to leave that open for others to submit PRs to your repositories no matter what you want.
Yea, and before we got issue trackers quite commonly issues and code chunks were shared via email lists that quite commonly had online archives. Think things kind of like the LKML.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
From the beginning, GNU projects welcomed contributions, and discussions of bugs and features were in the public. Sure it was on mailing lists, not on Github, but it was more than just shipping sources with the binaries.
That isn't to say you have to accept third party pull requests and have an open bug tracker to be free software/open source. Sqlite is a famous example that doesn't follow that model.
I dunno, I think at one point there was a similar merge as to what happened with "git and "github" where "open source the licensing" somehow became the same as "open source the collaborative and open software development process", and nowadays people get kind of confused when you say you're doing open source yet you don't accept pull/merge requests.
Maybe WTFPL can send the message across? Could maybe make a V3 and add as a second point to it: "1. And don't tell me/ask me about it, just DO WHAT THE FUCK YOU WANT TO"
> the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane.
I think there are many insane expectations out there, open source or not, so I don't personally see it that linked with the idea/ideal of open source.
> This is software support, it is a job, it should be paid.
Anything can be paid, nobody says otherwise. Some people prefer nobody pays for their source code (open source). Other people do support for free. And so on.
> The currently default model of having ... has nothing to do with open source and is not sustainable.
There were always arguments why open source will not be sustainable, many having some truth in them. But the current issue can be probably solved with some push-back on the speed of things or how attribution works. Something similar used to happen on some forums: you can't post a new thread for one month if you did not reply at least once without getting down-voted. For the current problem : if contributions are anonymous for the first 3 years of you contributing (if you are not banned) and your name becomes public only after, then all this "noise" for "advertisement" will die. Doubt this will discourage any well intentioned contributor.
Irrelevance. The moment you paywall a project, it’s a death sentence. Unless you have a unique and highly sought-after product (top 1%), someone else will just make a free alternative.
Well yes, but that accomplishes the goal of not working for free. Either you get money for your work, or your users move on, freeing you of the burden of supporting the software.
Exactly, that's an example of a top 1% project. It even has a detailed Wikipedia article in 35 languages. That model won't fly with small to medium-sized, regular projects.
If you have just thrown the code out there, in case someone can use it, then who cares? If it's not something you intend to spend more time on, what difference does it make?
I thought about this a lot recently and decided that the small, mostly complete, project I work on now, if I release it (I probably will), I will just post an archive somewhere with the source code, like in old days.
I kind of do that already with my most recent project, developing it in my local fossil repo and each release I have a script that copies it to a local git-repo, tags it, and pushes it to GitHub. So the GitHub history just has a series of release commits.
But the project is still open for issues and PRs. Can only be disabled on paid accounts, right? Never had anyone try yet. I had feedback through other channels, just not on GitHub, so maybe explicitly keeping all development offline has had the intended effect? I get a trickle of issues and PRs for my other repos where development is out in the open with every commit pushed to GitHub.
But if it was discovered by drive-by LLM contributors I would still have annoying extra work, for no obvious benefit compared to just sharing archives. I do not think anyone (out of at least dozens) discovering any of my repos do that on GitHub, but from seeing my posts elsewhere.
It's not like no one can fork a source code archive, even if it is like 3-4 git-commands to run instead of just a button to click.
Totally agree. The expectations around what an OSS project should - or even must - have, do, and accommodate is absolutely insane. It boggles my mind sometimes as someone who grew up on OSS. I still contribute OSS and maintain some (small) projects, but I certainly don't feel compelled to support people. I often license MIT. People are grown ups, they can go fix their own issues.
You mischaracterize the problem. You write like the problem would be corporate freeloaders forcing bug fixes on the open source.
Huge problem for successful OSS projects is like what we have for cURL right here - newbies trying to "earn badge of honor" for scoring CVE on high profile project. The variation of it is newbies trying to score OSS contribution on high profile project (hacktoberfest).
In the end all of it is propping own CV to land a software engineering job or cybersecurity job by wannabes.
As much as I don't want to do gatekeeping and especially "old" Linus Torvalds way of gatekeeping — cURL, Linux Kernel and many high profile projects require gatekeeping to go on forward. We didn't even start on the security side of things not to allow "shady contributors".
I hate "CV proppers", "OSS as great marketing tool", "corporate freeloaders", "APT threat actors using OSS as attack vector" because they break nice things that we could have.
Technically correct, but not an issue in practice. If you want a licence that's approved by the OSI but not the FSF, or vice versa, you have to go looking for it. If memory serves there are no licences in the latter category, and the few in the former category are very obscure.
The original model works, the new model significantly fails. LLMs have taken many cases that were on the border over the line into failure, by changing the resource management tradeoffs. (Both by giving valuable contributors a cheap way to get 'extra eyes' on their own terms, and by empowering a new generation of trisectors and trolls to flood out even the most efficient public submission pipelines).
> This is software support, it is a job, it should be paid.
It is paid, even if not in money. It seems like maybe you lack awareness of the other forms of capital and reward that exist, because your framing implicitly insists that financial capital is the only form of capital and that monetary reward is the only form of reward. But there are also a bunch of other forms of capital, like social, cultural, symbolic, etc. which you have missed, and there are non-capital (non-convertible) forms of reward, like feeling good about something. It's the entire reason why permissive licenses still preserve attribution.
To wit, people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things. There are both intrinsic and extrinsic non-monetary gains here.
Stallman makes the same critical error in his foundational writings, so at least you're not alone in this.
>people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things.
True, but the expectation means that taking on maintenance involves taking on and leveraging a large amount of reputational debt in a very risky way.
If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
It is incontrovertible that the entirety of the open source / free software world exists, in a very fundamental way, because people experience personal reward by doing work that they give away for zero dollars.
The existence of risk does not eliminate the existence of reward. It's called "expected value", and it's non-zero, and it's for the person to manage for themself like everything else in life. Working for equity also involves risk, and nobody says that it's not compensation.
> If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
This is like saying you suffer reputational damage by retiring from a career. The claim is clearly absurd. It's not hard to step down from leading a project in a way that preserves reputation in the same way that it's not hard to leave a company without burning bridges. Some people are bad at being people and fail at both.
My point is that the OP doesn't >lack awareness of other forms of capital, they're asserting that those aren't sufficient on their own, and that one of the reasons for that is the risk that stems from stepping down being something that you can fail at in the first place, with the consequences of cementing a reputation of "being bad at being a person" regardless of anything that's happened to that point. You don't have the opportunity of accumulating reputation without having that risk at the end, unlike a career, where you have the opportunity of taking a job that pays a regular paycheck regardless of whether you leave at the drop of a hat and burn all your bridges by doing so.
> My point is that the OP doesn't >lack awareness of other forms of capital, they're asserting that those aren't sufficient on their own
OP said "it should be paid" because "it is a job", and so the rejection of that claim is two-fold: 1) Uncertainty in the expected value of payment does not change the fact that it's payment, 2) Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
OP's specific written framing, that because it's a job it needs to be paid, which is only additive commentary if OP believes that it isn't being paid, disagrees with your prediction about what OP really secretly bases their statement on.
We can look further back in OP's comment as well:
> The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user
This is only fractionally true, and it is only true in an unpaid way for a desire to consume free software. It is not true in an unpaid way for the desires to produce or maintain free software. Those are done because the producers and maintainers experience some kind of reward from doing so.
> Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
I can't pay my rent or my server bills in "prestige". Entirely different.
I can't pay my rent or server bills in "bitcoins". I need to leverage my bitcoins in some way to get "dollars" that I can then pay my bills with. Non-monetary payment is still payment. Rare pokémon cards are payment too.
Also, in fact, people get things that otherwise cost money all the time based on prestige.
You absolutely can, because you can sell the bitcoins and turn them directly into money in your savings account. There are exchanges that declare their exact value. You can't do that with prestige. There's no exchange and no market.
Crucially, money, bitcoin, and pokemon cards are all transferrable. You can't transfer prestige to someone else, so it has no value in financial transactions.
Transference doesn't matter, because exchange is not a requirement for gain. People get things merely from having prestige/influence/power all the time. It's sometimes called an award, and sometimes called tribute, and sometimes called currying favor.
> you can sell the bitcoins
Prestige is influence, and you can absolutely sell the use or effects of influence.
> There are exchanges that declare their exact value.
Payment does not need to have exact value, just non-zero expected value, which prestige definitely has. There is no exact value to startup equity either, but it's still rightly considered to be compensation for investment of labor and money.
I've been helping a bit with OWASP documentation lately and there's been a surge of Indian students eagerly opening nonsensical issues and PRs and all of the communication and code is clearly 100% LLMs. They'll even talk back and forth with each other. It's a huge headache for the maintainers.
I suggested following what Ghostty does where everything starts as discussions - only maintainers create issues, and PRs can only come from issues. It seems like this would deter these sorts of lazy efforts.
Is this cultural? I ran a small business some years ago (later failed) and was paying for contract work to various people. At the I perceived the pattern that Indian contractors would never ever ask for clarifications, would never say they didn't know something, would never say they didn't understand something, etc. Instead they just ran with whatever they happened to have in their mind, until I called them out. And if they did something poorly and I didn't call them out they'd never do back as far as I can tell and wonder "did I get it right? Could I have done better?". I don't get this attitude - at my day job I sometimes "run with it" but I periodically check with my manager to make sure "hey this is what you wanted right?". There's little downside to this.
Your comment reminded me of my experience, in the sense that they're both a sort of "fake it till you make it".
Indian here (~15+ years in tech). I've seen this behavior a lot, and unfortunately, I did some of this myself earlier in my career.
Based on my own experience, here are a few reasons (could be a lot more):
1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
2. Our education system mainly rewards results, not how good or well-thought-out the results are. Sure, better answers get more marks, but the gap between "okay" and "excellent" is usually not emphasized much. This comes from scale problems (huge number of students), very low median income (~$2400/year), and poorly trained teachers, especially outside big cities. Many teachers themselves memorize answers and expect matching output from students. This is slowly improving, but the damage is already there.
3. Pay in India is still severely (serioualy low, with 12-14+ hour work days, even more than 996 culture of China) low for most people, and the job market is extremely competitive. For many students and juniors, having a long list of "projects", PRs, or known names on their resume most often the only way to stand out. Quantity often wins over quality. With LLMs, this problem just got amplified.
Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
> 1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
Way back, when I first started working with Indian offshore teams, the contracting company at the time had a kind of intercultural training that addressed that issue.
> Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
That's exactly the advice they gave. They advised was to try to make your relationships and interactions as peer-like as possible. The more "authority" is present in the relationship, the more communication breaks down in the way you describe.
I've seen an interesting behavior in India. If I ask someone on the street for directions, they will always give me an answer, even if they don't know. If they don't know, they'll make something up.
This was strange. I asked a lot of Indian people about it and they said that it has to do with "saving face". Saying "I don't know" is a disgraceful thing. So if someone does not know the answer, they make something up instead.
Have you seen this?
This behavior appears in software projects as well. It's difficult to work like this.
No, but I have noticed that somehow it's hard for them to say "no". This is impolite apparently. So you ask: "Can you do this before friday" and they say yes and then don't do it at all. Which of course is a lot less polite and causes a lot of friction.
However this was a thing 10-15 years ago. Lately I've not seen that.
> Which of course is a lot less polite and causes a lot of friction.
Most cultures have this, but it goes mostly unnoticed from the inside because one can read between the lines. "How are you?" can be asked just to be polite, and can cause friction when answered truthfully (rather than just politely, as the cultural dance requires). An Eastern European may not appreciate the insincerity of such a question.
I use "about the same", thanks to a friend. I love the reactions (from Americans, where everyone is expected is to say "Great" or "Good" or something similarly positive).
Is that just a reflex response though? I would expect people to be more deliberate in their interactions with medical professionals, but I can easily imagine hearing “How are you?” and my brain goes on autopilot.
Yeah, this is something I had to learn over my teenage/early 20s years. "How are you?" Is often not a question but just a generic greeting like "Hello" or "Nice to meet you". Sometimes it is though, but that's just one of the many examples of unwritten rules about how to tell whether someone literally means what they're saying or if there's a better way to interpret it.
Having only lived in the US, I don't have nearly enough firsthand experience with other cultures for me to be the one to comment on them, but I suspect that every culture has some things like this where the actual intent of the communication isn't direct. I suspect that if people in tech were asked to identify which cultures they considered to be the most direct in their communication, American culture probably wouldn't be ranked first. Generally the stereotypes of other cultures that are perceived as more direct get described in more pejorative terms like "blunt" though.
> that’s an example of a fixed answer to a fixed question.
That's my whole point! The expected answer seems pretty obvious to you, given the context, doesn't it? Why then are you surprised that a different culture has an equally obvious (to them) fixed answer ("Yes") to any question asked by someone with power/authority to their lesser? Both depend on mutual learned cultural awareness, and can fail spectacularly in cross-cultural contexts.
Edit: my regional favorite is "We should meet for lunch some time" which just means "I'm heading out now", but you have to decode the meaning from the nature of the relationship, passive voice usage, and the lack of temporal specificity.
similarly, in the west, when your boss takes you to HR for an honest and open discussion, it's not really an honest and open discussion. normies know this instinctively. I didn't.
A fairly common conversation starter for eastern europeans is "how are you doing?", "it sucks", "yeah it does, doesn't it?". The American style of being all flowers and butterflies can indeed be perceived as lying.
To be fair we Americans also poke fun at this. Here in the South I usually say, “Can’t complain,” and most people will finish the adage, “and it wouldn’t do any good if you did.”
It is fine if it is not lying but so often you ask how are you and get the flowers and butterflies response but when you sit 10 min more they start explaining how miserable they are: as a Dutchman, I do tend to ask why they said how great and excellent they were just minutes ago. And no, it is not just something you do out of politeness: if you just canned response to one thing, how do I know you don't have canned responses to many more things which are in fact lies at this point in time? I don't want to talk with Zendesk, I want to chat with someone I just met in the pub.
It isn’t lying, it is what we consider an appropriate level of sharing. We don’t tend to want to put our burdens on people who may not be interested in hearing it.
My experience is the same, to put it charitable a lot of people from that culture are often eager to please. I think about this a lot when I hear about billionaires like Elon Musk wanting more immigration from India specifically. I think this cultural trait often serves them well in western corporate contexts, despite the frustration it causes their coworkers.
> I've seen an interesting behavior in India. If I ask someone on the street for directions, they will always give me an answer, even if they don't know. If they don't know, they'll make something up.
Isn’t this the precise failure pattern that everybody shits on LLMs for?
Only on surface. The difference is the LLM doesn't know it doesn't know. An LLM provides the best solition it has regardless of whether that solution is in any way fit for purpose.
I’ve seen this with some of my Indian colleagues, though definitely not all. In fact, most are more than eager to disagree with me :D (even though I’m their superior)
> This behavior appears in software projects as well. It's difficult to work like this.
I have seen that across just about every culture in the software engineering world.
And not just in the 'business' itself. I still remember the argument I had with an Infosec guy where he absolutely insisted that every Jeep had AWD or 4WD from the factory, Even naming ones that didn't did nothing until I more or less passively aggressively sent him wikipedia links to a few vehicles.
At which point he proceeded to claim "No I said it was always a standard option" ... To be clear this whole argument started because someone asked why I swore by Subarus and mentioned 'Every US Model but the BRZ has AWD standard' but Heep owners gotta have false pride, idk.
People do weird shit with imposter syndrome sometimes, IDK.
> This was strange. I asked a lot of Indian people about it and they said that it has to do with "saving face". Saying "I don't know" is a disgraceful thing.
I've recently learned that this particular type of "saving face" has a name: "izzat". Look that up if you want to know more.
A lot of the stuff written on "izzat" is questionable or wrong, but it is true that India has a collective concept of saving face. This can be an adjustment even if you're used to the East Asian concept of saving face.
I'm not sure how to write that better, but the way you worded that made me suspect it was NSFW and I hesitated, but eventually decided I'd risk it. At least everything I found was work safe, and I learned a lot. I encourage everyone else who hasn't heard the word to look it up.
According to Hal Roach, the Irish do this too, because they don't want to disappoint you. I haven't asked for a lot of directions in Ireland, but I can imagine this is true, or that they will just keep you chatting and see if you forget about your question.
This reminds me of the time when I got lost when visiting LA about 20 year ago. Asked some guy on the street for help. He gave me directions as he was smirking at me. Turns out he pointed me in the opposite direction from where I was going to and most likely he was just being a dick.
> 1. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
Having worked in Japan, while there is a strong respect for authority, there's also much less hesitation about asking for clarification. I worked with an Indian offshore team and in a Japanese company and, while there's a lot to dislike in Japanese office culture, this kind of pattern of behaviour doesn't happen.
2 & 3 do make sense though.
I've had mixed result with your advice at the end. I'd say that it worked for about 30% of the offshore engineers I've worked with and indeed I had more success with juniors than with more senior developers.
I also worked with japanese, including on site in Tokyo and quickly learned that asking "did you understand it?" is useless. I always had to keep in mind to ask "what did you understand?".
> Pay in India is still severely (seriously low, with 12-14+ hour workdays, even more than the 996 culture of China) low for most people.
My employer outsources some work to Indian contractors. I know how much we are paying the contracting firm, which is low. Knowing the firm takes a cut before the contractors are paid, I feel terrible for how little they are compensated. I frequently wonder if we’d get better output if we paid more.
Avoid middlemen in India.. sorry for the word, but they are the biggest leechers. We hate them too here.
India is filled with small one-room service-based companies(the middlemens') that hire interns, for ZERO pay, make them work 12-14 hour days under extremely "humiliating" conditions and then when it comes to giving them internship completion certificate, they demand huge sums of money just to release them... think about it.
As for how you are gonna do without the middlemen, I dont have the anwer yet... ideas are welcome.
The good engineers in india know their value and get it. My company has offices in india because you have to manage them yourself not use middlemen. You can train the locals to be great managers (at least some).
wages for good people in india are worse similar people in the us, but often high than in europe. But there are other problems with europe and so it can be the better deal.
Responding to you in this thread, because this is the way: the only success I've seen to offshoing to india, is to actually run the office yourself, have an exec over there, manage and control hiring, pay above market rates, etc...
I've been with two companies that have been aquired, and the first thing the PE/New Companies do is aggressive offshoring for cutting costs.
1) worked, because the aquiring company had an established office in Hyderabad, and we flew the tech leads over to the US to spend six weeks embeddeed with the team, etc.
2) the second one failed miserably becasue we had an Exec VP who told our engineers that he was replacing them in India for half the price, and his strategy was to hire a contracting company.... after several months of "contractors" coming and going, someone else in the company realized what needed to happen....
> The good engineers in india know their value and get it.
The job market is not that efficient anywhere, especially India. Lots of people work their way up from crappy jobs to good ones, just like in the US.
>My company has offices in india because you have to manage them yourself not use middlemen. You can train the locals to be great managers (at least some).
"some members of this primitive tribe can be taught our sophisticated ways"
The issue with middlemen is they are basically labor arbitrageurs and have an incentive to hire the cheapest people possible and inflate their credentials/abilities. Same thing happens with onshore consulting firms.
>wages for good people in india are worse similar people in the us, but often high than in europe.
"Often higher than Europe" is a stretch. Typical big co with an India office pays maybe 20-30k USD per year for an engineer. And that is a good job relatively speaking. Top tech companies pay more but they also pay more in Europe
Senior/staff type engineers are not a union position so great people refuse promotions and responsibility because they don't want to leave the union. Thus they won't mentor juniors, and other things that you need great engineers for. (At least that is how the union people I work with in Europe are, there are other unions with different rules)
Like siblings comments, I would be really interested to know to which country and union you are referring to. In France it's certainly not true (I have a very senior engineering role and I am in a union and it never was an issue, and anyway, the percentage of unionized engineers here is so low that even if that was true, it would hardly be noticeable)
Which country is that in? Can you not offer them better conditions than the union? Are they forced to leave the union or just no longer required to be in it?
> Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
Semi related to this, one of the biggest 'breakthroughs' in building the right trust/rapport with an offshore team was sending an email to their leadership making it clear and on the record that "Comments against pull requests should not be used against the employee in reviews, if there is a recurring issue I will discuss it via other channels."
That one email changed PR back-and-forth entirely, cause yeah I guess sometimes they'd get dinged for too many PR comments on some metric. At first their management wasn't thrilled, thankfully there was a good enough improvement in quality and defect rate that in a couple months they were won over.
Do you mean that they were dinged if a PR they opened received too many comments? Can you elaborate on how the communication style changed after this? Like they were more willing to seek clarification/discussion?
> Can you elaborate on how the communication style changed after this? Like they were more willing to seek clarification/discussion?
More willing to seek clarification and less likely to try to defend choices with 'This is what the scope of work said'. And also more willing to jump in on colleagues and my own PRs to provide feedback.
Which was also an important part of how to frame the communication "I'm not telling them they are doing their jobs wrong, I am telling them how to do it better to make all the stakeholders happier."
> Do you mean that they were dinged if a PR they opened received too many comments?
It was never explicitly said at first, however the communication was inspired by past work experiences where yes, too many comments on a PR or similar review could get held against you for far longer than was productive or even healthy, and yes it was something the whole team had to deal with (i.e. very much a shared experience amongst colleagues.)
In fact I'd argue that the time I've been at shops where people weren't afraid to give feedback has been about 50-50, while also noting that the shops that had a culture shift where giving feedback became OK and safe for all parties, quickly became more productive.
Cause, the other thing to consider, is that people don't necessarily want to risk causing animosity by jumping into a colleague's PR and pointing out a problem, they don't want to be the guy that makes their colleague "look bad". Which is of course unhealthy, but again by re-framing the context of PR feedback for Taylorist robot management, you get better response from their management as far as buy in.
> Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
Very true. I’ve hired (super cheap) engineering talent and this is the key to getting a project to run the way a westerner expects; where everyone is constantly open to challenging each other, where everyone can bring ideas to the table, and where there’s no such thing as a stupid question. I’ve done this during a big phase of time others locally shunning this huge talent pool as the results were crappy/unpredictable. Even to the point they’ll hire local for 100x the cost. It’s just a management problem though and a pretty simple one at that. The other thing is if you train them in your style, keep using them on the next project if you can. It compounds if you have the ability to work with them over a longer time. You have to be very insistent that you’re not proposing the best solution at expect them as engineers to point out any opportunities for improvement. If something later has to be rebuilt or isn’t working well, sometimes it’s good (if it makes sense, case by case) to do a post mortem and understand why the version 2 wasn’t built during the version 1. I think that helps them really understand it in a concrete way if they’re struggling with it.
In any case, I’d much rather take a budget for 1 local dev and spend it on a whole team of Indians and take on the management burden if it means retaining more equity or profits or building something I otherwise wouldn’t do myself due to scale.
Particular topic (1) is also trained in cross cultural trainings.
Another topic is: do not expect a remote dev to pickup ambient knowledge, particular if they are juniors with no life experience. And since outsourcing to India is trying to get the resources for the lowest possible price, the result is: you get them as junior / fake senior / bad senior as you think. Pay better in India, get better people.
With higher salaries (is happening) and better quality of life (I do not know, do not life there). Within company obviously quality of the culture matters there.
However considering how things are worldwide right now, I think that trend stops soonish.
As a gent with some years under his belt, I have to humbly admit that it was quite late in my career before I realized how much culture influences how people operate. Two separate incidents with two different cultural contexts brought it to the fore about ten years ago. I sought some advice from a senior exec that I was close with and he just laid it out in very unflinching way. It was just one conversation but it has helped me tremendously in the years since.
I thought about it when I posted but it felt like an invitation to dunk on the cultures involved. In one case it was a communication pattern that I found to be very unprofessional by an entire team, the other was nearly instant and *intense* conflict between a former direct of mine and their new manager that I got sucked into the middle of.
> 1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
I was a manager at Deloitte in their tech consulting practice. I led fairly large teams of devs based in India. This is very true, and it takes a lot of time and trust-building to overcome. Making Indian devs, especially early-career ones, comfortable enough to oppose something or offer feedback is non-trivial, and often Indian engineering managers make it more difficult. Overcoming cultural hierarchy is hard.
This is one reason, the other is just fraud. Being from a developing country, I am well aware of the stigma of saying I don't know, which I had to strip out of me as I became an engineer to the point of me being immediately suspicious when someone tells me they know about some moldy complex topic, even if it's in their profession.
The fraud part is that I developing countries, almost all activities that require some skill have lots of people claiming to be experts. 99% of them are lying. You take your car to a shop and they tell you they will solve your problem. With skepticism, (because they asked no clarifying questions) you try to give them some context and they tell you not to worry.
1 day later they tell you parts X, Y and Z need to be replaced, it will just cost $$$. You ask if there is no way the current parts can just be repaired, and they tell you no, they must be replaced.
You ask what was the actual issue, and they tell you the parts are completely damaged, or worn out, need to replace.
Sure, you pay, and they give you the car, works for a few days, maybe week, then breaks down. You plug in a portable OBD scanner and it tells you the exact component they just put in is failing (likely not even compatible with the car).
You give them back the car, tell them since you paid $$$, you will only take the car back once it works perfectly, and you won't pay a cent more.
They then spend the next few days looking for an actual expert, that comes in and repairs the original parts, for $, and they take the "new" ones back to the store and give you your money back.
They don't know anything about cars, they experiment on yours, with your money, by swapping parts. This was easier when cars were less strict with parts.
This is fraud, not face saving, and it's in every developing country.
You’re not allowed to admit it’s fraud. It’s just a cultural difference. You explained it wrong. You didn’t pay enough. You were supposed to try to become their best friend first. Anything not to say “well some cultures just have no problem committing fraud at any opportunity”
Perfectly put. Scamming is a cottage industry. No ethics whatsoever.
What I do is I go to the top guy, tell him I need an expert and nothing else. No experimentation whatsoever on my vehicle etc. I pay slightly extra for the troubles. Before I go for repairs I try to learn as much as possible to know what they will screw up next. If you go in as a layman, then it is fraud and incompetence central all the way.
> Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
I've found that this is also true of American engineers, particularly those fresh out of college. So many people have internalized that open curiosity will yield no result at best and direct punishment at worst.
Work cultures are brutal in SEA and South Asia countries. And there is no job security, no social security, no labour laws(on paper they are, but, are not applied) and no liveable pay(this is changing though).
Thanks for all this, what you wrote and the discussion that followed has been genuinely helpful, and I think it might help bridge some cultural divides that I've experienced when working with Indian people.
Another question I'd like to ask of you is, do you see any aspects of the western style of cooperation that are the inverse? i.e. which create divides in which the westerner's ways of working can be the source of conflict?
1. Same here. I too learnt a lot more from the following discussions.
2. None. We absolutely adore the ways westerners work. Your ethics, discipline, hardwork, attention to detail, inventive and creative nature, the support structures, and fair pay (and many more).
Thank you for this cultural explanation - I've experienced the same thing with Japanese co-workers - there is often a "no" but to American ears its so subtle that it often goes in one ear and out the other.
Both the cultures suffer from "a senior is always right" mentality. Therefore, with my juniors, I used to intentionally (sometimes, and mostly during early days of their joinings) make stupid little mistakes (harmless) and used to let those folks figure that out and then appreciate them on catching it. Worked like wonder. Never ever anyone hesitated to discuss anything with me anytime.. even personal issues many times :)
You just have to make it easy for others to do their jobs. Removing barriers, of any kind, helps. This is even more true with juniors.
The sweet spot is being authoritative without being overbearing. When leadership feels supportive rather than controlling, people engage honestly... and that balance comes from experience.
Could this cultural difference explain why they're set up LLMs to do work for them, though? No authority asked them to, but I guess it would look nice in their resume if successful.
1. A lot more can be done in a given amount of time. Looks good on resume. Recall that India is still extremely poor (dont get influenced by the GDP numbers.. ) and getting a job as fast as you can after college can make a real difference to your living standards here.
2. Our education system is shit. And so are our teachers(mostly). Meaning, when folks are out of college, they generally are not as competitive as maybe their counterparts from western regions are(not in terms of hardwork, but, knowledge and hands-on tasks). LLM's makes it possible to do complete much more complex work than otherwise was possible at current experience.
Indians are extremely hard-working. The problem is people are extremely poor (~2400 median income... that's per YEAR). Even after adjusting for PPP. this translates to less than 10K USD/YEAR. Now think about living on 10K/year and supporting 5 family members (partner with 4 kids, or parents with 2 siblings).
my managers are indian, and honestly Im struggling. Do you have any advice? I feel like im not allowed to ask questions, a lot of our processes dont make sense to me.
Not the advice Im proud to give (or anyone should give), but the one that will work: Create dependency on yourself, company-wide, and make sure the boss knows about it. Avoid direct confrontation with your manager.
> 1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
Damn me, Scotland is going to be quite the culture shock for you.
Since we are talking about LLMs, what I've noticed about the Indian/Pakistani "LLM" is they follow this way of structuring thoughts:
1. They
2. Always
3. List
4. Things
... and end up with a conclusion/punchline/takeaway.
I always wanted to ask, is that due to training?
I could imagine all schools around there have a specific style, like all their assignments need to follow this general form, and then they just get used to it and it permeates to their everyday life.
It's due to training (I suspect both OpenAI/Microsoft and Google have been training on their entire corpus of internal comms and technical docs). After almost 10 years in a FAANG I also tend to write like that.
I bet you haven't seriously communicated with others in a language that is not native to you. You'll probably end up doing similar things if you have to.
An Indian person basically is used to not making any decisions for themselves until maybe they're married off (and even then, probably not until age 40). /s
This sounds like a real cross-cultural mismatch, but it’s doing too much work with nationality alone. In a lot of Indian (and broader South Asian) work contexts, questioning instructions can be read as challenging authority or admitting incompetence, so people default to executing without asking. That’s often reinforced by education systems and contractor dynamics where producing something quickly feels safer than pausing to clarify.
Add in time zones, language friction, and fear of losing work, and "just run with it" becomes a rational strategy. Meanwhile, many Western workplaces treat clarification and check-ins as professionalism, so the behavior reads as strange or careless.
The key point is that this usually isn’t lack of curiosity or reflection, but risk management under different norms. The pattern often disappears once expectations are explicit: ask questions, check back, iteration is expected.
Yeah, I agree, the time zones are killer, and this can't be ignored. I work at a company spread over most of the world, with SMEs coming and going as the globe spins.
Back-and-forth iteration and consultation is a genuinely hard problem. Certain kinds of feedback cycles have a minimum latency of "overnight". Which means we need to invest heavily in good communication.
But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.
A lot of the international teams I've seen pull this off are ones where an Eastern European or Indian team is just another permanent part of the company, with broad-based professional expertise. Contractors on any continent are a whole different story.
So I think what a lot of people try to blame on Indian management culture (or whatever) really is just a case of "we hired contractors in a different time zone." I mean, there are always cultural issues—Linus Torvalds came from a famously direct management culture, and many US managers tend to present criticism as a not-so-subtle "hint" in between two compliments—but professionals of intelligence and goodwill will figure all that out eventually.
> But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.
Very common pattern you see in literature about military strategy, actually. The answer is delegation, heavy use of NCOs, and in general explaining the plan all the way down to the individual soldier. Under the western school it all falls under "initiative".
Notably, a lot of non-western militaries are terrible at it, and a number of military failings in africa, the middle east, and the soviet union (*cough*russia*cough*) are viewed as failures in flexibility with very low initiative, as well as lacking/unskilled NCO corps.
Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.
> Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.
The most successful engagements I've had with contracting firms have been when we've shelled out for a team manager and a software architect (in addition to the number of straight developers we want).
The software architect builds a solid understanding of our solution space, and from then on helps translate requirements into terms their engineers are familiar with, and provides code reviews to ensure their contributions are in line with the project goals. The team manager knows how to handle the day-to-day reporting, making sure everyone is on task, escalates blockers over the fence to our engineers and managment, etc.
Without those two roles from the contracting firm's side, I find that timezones and cultural mismatches (engineering culture, that is) pretty much erase the impact of the additional engineering headcount when adding contractors.
Explaining the plan to the individual soldier also works better when the individual soldier is expected to care at all about the overall goal. (Such as believing in the mission of defending the home country.) When the soldier only has extrinsic motivation such as money, top-down command and control and treating soldiers solely as equipment to be spent makes more "sense", in a terrible way.
IT also only works if the soldier is well trained in the things he can do. I can teach you to shoot a machine gun in a couple hours - and half of that time will be figuring out how to shoot and clean it myself (I've used hunting rifles and have enough mechanical knowledge that I think I can figure out the rest - but someone who knows that gun can likely find something I would not figure out). That will be enough for "spray and pray" which is a large part of what a machine gun is used for.
However in a real war you need to figure out what direction to point the gun, and need to know when to fire and when to not. I don't know how the army handles "we are advancing now so don't shoot", or "we are crawling along the ground so make sure you shoot high": someone else needs to give anyone I train those orders. The army trains their machine gun operators better so they can figure a lot of that out without being told.
> the time zones are killer, and this can't be ignored
100% agree, especially when there is minimal overlap during normal office hours. I was managing a dev team in India from the US and it was a real challenge. The company ended up moving team to the US, relocating most of my team. Despite all the people being the same, management became much easier.
Since then I've done US and EU, and EU and IN, and those have all worked fine because we had sufficient overlap during business hours.
He didn't need 8 hours, but zero didn't work. The us and india are about 12 hours apart (there are 4 times zones in the us, day light savings time, and india is offset half an hour, but it rounds out to 12 hours for discussion)
> If you needed 8 hour overlap you were micromanaging?
...ok. I didn't need 8 hours of overlap.
As I mentioned in my first comment, I've also now done US/EU and EU/IN. Both of which have only partial overlap and things have gone well.
With US West Coast and India, I was often doing meetings at 7AM and my devs were doing meetings at 9 or 10PM. That was challenging, irrespective of any cultural differences.
> Contractors on any continent are a whole different story.
Having spent the last ~7 years working for different startups before pivoting, my advice to any founder is this: do not hire overseas consultants. They're good, competent people, but you and your company do not have the tools or the culture to actualize them.
In my experience trying to outsource to India, there is a strong systemic bias towards lying and cheating to get ahead (and that was even before AI), and a focus on milking as much money as possible rather than building great technology.
While there is real talent there, there is also a lot of overhead to find people you can trust.
This is probably just a reflection of the competitive nature of the market and the social ladder tech salaries enable there.
To add to that, it is culturally acceptable and even lauded in India to achieve something by "gaming the system", something usually considered unethical in the west (okay maybe less so in the US).
I would be ashamed to submit an AI slop PR or vulnerability report.
An indian might just say "I have 25 merged PRs in open source projects"
It is cultural - the whole "not losing face" thing. In a project, I once was squad lead - I was onsite, my squad members were in Bangalore of course. Same experience as you. Once I wanted to talk about a piece of code that we need to improve and refactor, and I was acting in good faith calling the dev that commited that code. When I braught up the code on my screen to start a pair programming, he immediately denied having written the code. Unfortunately for him, being a junior, he did not know about git blame - I entered it in the terminal and his name showed up on that code. Still, he would simply just deny that he wrote it. I then took the git commit hash and looked it up in gitlab, able to bring up the MR he created and the reviewer (wasn't me). Even with that on screen, he still denied being the author - with no arguments or alternative reasoning, he just constantly would repeat "No, I haven't written that". "No no, but I haven't written it". I pulled even the JIRA ticket up, that was about that feature and guess what - he was the assigne and moved it to "In Progress" and "Done". Still with that on screen all I got was a "no, haven't written it".
I had more of those interactions, and we also exchanged some of the indian devs (they were sold to the client by a big consulting group, and immediately replaced by someone else if we wished). I later found out, people that I have had replaced in my sqaud for not being qualified, ended up in different teams in the same corporation, they were basically just moving around inhouse.
After a few month in the project I swore to myself never to work with offshores again. And as a side note, the bank I did the project with, does not exist anymore :)
I’m Indian. I absolutely loathe this part of Indian culture. My uncle was once eating a pizza like a naan (ripping pieces off straight from the box) and I called him out on it, and he said he wasn’t doing anything like that…while holding a piece of naan and the pizza looking like rats had a party with it.
It happens basically constantly, I have never heard my family admit to a mistake unless violently confronted by someone with authority.
Leads to all sorts of issues and societal breakdowns, like police beating people up before even trying to communicate.
I'm curious if you tried to explain to the guy that lying to you undermined his reputation far more than any mistake he made in the first place, and if so how that went. That's something I would fire someone for if it was in my power. Making mistakes is ok, but lying about it is absolutely not.
Pretty sure the right move as soon as he said "I didn't write that" was to just say. "It isn't important who wrote it, we all make mistakes, let's see together how we could have done better."
Today, I would maybe agree and have grown wiser. But software engineering is 50% failure management. And admitting failure should be normal for every level, I am very open and outspoken that I (just as every other guy) makes errors all day. We literally have error management system in place because of that - Bugtrackers, Test pyramid, QA departments etc. It is simple not helpful if people not take accountability and grow on their mistakes.
Pretty sure that can be the wrong move in an instance where it does matter who wrote that. Freely allowing derogation of authorship soon fosters derogation of responsibility.
I don't know if it is, but I can swear every time I post a job opening (generally contracting work) on LinkedIn 95% of the applicants are Indians/Bangladesh/Pakistanis/Sri Lankans.
I ignore all of their resumes, not because I don't think there's valid individuals among them, I did hire them in the past, but:
1. because the signal to noise ratio is absurd. The overwhelming majority didn't even read the actual post.
2. Even when they are okay developers, communication is always a huge issue. Sync communication in call is though because urdu and other indian area accents are extremely heavy so I really struggle understanding their english, my bad but what can I do about it. If I try to keep it async or chat based then they tend to not ask feedback, clarifications, provide updates, etc. So you feel like you need to micro manage them half the time and they'd rather give you answers to make you immediately happy than surfacing problems.
3. Paying them is always an hassle. Wiring them money through bank accounts is difficult. They generally set up some Paypal or similar service or ask you to pay them on some Hong Kong account from a friend of theirs. I need traceable invoices and simple wires for tax purposes and when sending money to Pakistan multiple times anti-laundering got involved in my country, and we talking low hundreds of euros.
Still, props to the few good ones I've met, they've been critical on some projects of mine. Very professional and knowledgeable. But it's just too bad of a signal/noise ratio, seriously most applicants don't even read job descriptions.
That is a cultural thing, and one of the first things you learn to handle when working tightly together with Indians as an outsider.
I can't remember all the techniques but a simple trick is to ask them to repeat their understanding back to you before they start working on a thing.
But I don't think it's connected to sending "malicious" reports. That seems rather to be to pad their resume and online presence while studying to get an edge in hiring.
You know who also needs a lot of micro-management but doesn’t live in a time zone, is way faster than offshore contractors, scales up and down instantly, has no onboarding period and is (still) cheaper? Opus.
My guess would be yes, it's cultural. I'm not Indian but spent about 5 months there. Overall my impression was that people act much more on direct feedback.
It would be typical to do the first thing that comes to mind, then see what happens. No negative feedback? Done, move on. Negative feedback? Try the next best thing that makes the negative feed back go away.
People will not wonder whether they might bother you. Just start talking. Maybe try to sell you something. That's often annoying. But also just be curious, or offer tea. You react annoyed and tell them to go away? They most likely will and not think anything bad of it. You engage them? They will continue. Most likely won't take "hints" or whatever subtle non-verbal communication a Westerner uses.
I found it quite exhausting in the beginning, it feels like constantly having to defend myself when I want to be left alone. But after I started understanding this mode and becoming more firm in my boundaries, I started to find it quite nice for everyday interactions. Much less guessing involved, just be direct.
Professionally I haven't worked much with Indians, but my expectation would be that it's necessary to be more active in ensuring that things are in track. Ask them to reflect back to you what the stated goal is. Ask them for what you think are obvious implications from the stated goal to ensure they're not just repeating the words. Check work in progress more often.
Of course it’s cultural, they have to compete with thousands people just like them in environment where human life is cheap and anyone is replaceable. Any authority have huge weight, which comes from historical system how society is separated.
And then any education they receive assumes cheating at exams, then cheat with CV, then cheat with work they do. It’s all about appearances.
Maybe. I have hated crowds all my life. I can always see filth in people. I have helped people cheating at interviews. I want to vomit everytime somebody asks me to make a CV. Vomit in the sense I genuinely hate overselling myself but if I don't, I just don't. And what I'm open if you want to ask any question about me?
I had the same exact experience with an Indian contractor. I requested that he used git instead of Shopify CLI for his changes to a store's theme. He acknowledged my request but kept using the CLI. I once again asked him to use git and even offered a detailed, step-by-step guide on how to pull, branch and then push changes. He absolutely ignored everything and simply kept using the CLI. That was actually amazing to witness. The only hypothesis I have is that it's some kind of cultural thing where asking for help is worse than doing the opposite of what's expected from you. I don't know, but your story supports my hypothesis.
Ask culture scales a lot better in a fast changing world full of strangers. Guess culture saves friction, but only in situations where people are mostly guessing correctly because the social structure and expectations are fixed.
Many of my Indian friends say it is, but sometimes I feel they can be as self-critical of their country as many Americans are of the USA.
Demographics show that it doesn't have to be cultural - it could just be that India has 9x as many people under the age of 35 compared to the USA. Even if we were culturally similar, for every annoying US youngster "hustling" to try to get employment, there would be 9 early-career Indians doing the same. That alone is enough to drown the "Vox Agora" with Indian voices. Chinese citizens generally don't participate in English-language fora, so their large numbers would be massively under-represented.
If anything else is biasing the populations, the difference in numbers could be even more stark.
I used to work with colleagues from China in contracting and I had the same experience with them. If they don't know something they have hard time saying that they don't know something or don't understand something.
Ficticious Example could be
Q: is this car red?
A: it's not green.
Q: yeah I know it's not green. But is it red?
A: today is Thursday.
One thing I leaned it's not worth pressing forward and causing a scene. Instead it's better to use other ways of finding the information.
When guiding team members I always found it useful to have them explain back to me in their own words what they're tasked to do. It become immediately obvious if they were on the right track or not.
Exactly this. You just put them on the spot and they lose face and you're embarrassing them.
Besides this interaction has already made it know they they don't know the answer so what's the benefit of forcing them to announce they they don't know something?
I've only been in a peer to peer type of working relationships with people I'd consider coworkers so I wouldn't think it'd be very fruitful to start agitating people in such a position.
What position? If you let it pass, you encourage this kind of behaviour.
If they are working for a western company, they should adjust their behaviour, not the company. Just imagine working for an Indian company (or manager), and expecting them to tolerate your individualist behaviour and audacious questions. You would be punished immediately.
If it's a peer-to-peer relationship, all the more reason to be firm. If you don't speak up you will never be respected. And don't think that just because you keep quiet the shitty types of people won't stab you in your back at their first opportunity (ask me how I know).
The people having a terrible time with Indian contractors always deal with folks making 3k-10k USD/year. Of course the quality is bad.
For reference:
Good Indian devs out of college make atleast 30k USD. Good senior devs make atleast 50k. The really good ones make much more. Most American companies outsource to bottom of the barrel contracting companies like Infosys.
> Good Indian devs out of college make atleast 30k USD. Good senior devs make atleast 50k.
1. How can you be a good dev if you've never developed professionally in your life?
2. I know Indian numbers and this is complete bs. Like complete.
Maybe there are extremely rare exceptions to it, but this is like claiming that good US devs out of college make 350k. That's beyond rare, may happen, but it's beyond rare.
1. "out of college". I'm sure you can figure out how to interview new grads and identify good devs.
2. They are not. FAANG in India pays higher than what I quoted. My senior numbers are especially on the lower end of the spectrum. If your numbers are lower then you aren't working with good devs.
These are the numbers for good devs. The ones who get into great startups/companies. 95% make less and it shows in the quality. Infosys pays new grads 4000 USD/yr.
No you can't. Because the real difficulty is not bullshit leetcode questions, but professionalism, ability to handle pressure, requirements collection and research, soft skills, design, etc. you can't interview for those.
You build these skills by writing good software under constraints not by building personal pet projects and farming leetcode.
It's quite strange though when you consider the fastest way to get egg on your face is to do something badly because you didn't understand and just made it up instead of looking it up
I ran into this when I went to India to help train our team over there.
I tried specifically asking questions where the correct answer was “no” and they wouldn’t tell me no. In some cases I told them I was expecting them to say “no” and they still wouldn’t do it.
It was very difficult to figure out what they knew or didn’t know without putting them through a test and seeing how they did.
I've worked with mixed nationality teams at a certain 4 letter austinite corporation a couple thousand moons ago. One thing in common with my Asian colleagues back then (many of which i still keep in touch with to this day), is that they would usually refrain from saying things that could rock the boat or disappoint you. If they lacked knowledge for the task at hand, they wouldn't let you know. If they were late on a delivery, they'd insist it would be ready by a certain date. This led to situations where other regional managers would have to plan contingencies to work around the issue.
I recently heard from a friend that this is due to something called "izzat". Admitting any sort of wrongdoing would reflect poorly on them and their family, to the point they would rather lie or do the wrong thing than damage their family's reputation.
What I don't understand about this is that, if you become "the guy that always does the wrong thing", doesn't that also damage your family's reputation? I don't mean to come off insulting here, just trying to understand.
Culture and what companies want there. I was running a operational team with a couple of incredibly talented guys who had been escalation engineers for large software companies in India.
They were trained really hard to "restore" things in a way that hit some minimal level of the SLA, but not really. It created alot of issues initially in the organization as the "don't question anything" had really been ingrained into them. My observation there is that it made many of the useless support engagements I've experienced make sense, and that a place with that level of discipline and process must be pretty awful.
Could be, but there are a number of very popular Youtube and other video based classes/bootcamps (taught and targeted from/to Indian students) that teach how to work with git and github that show how to create PR's and comments in repos, and then a lot of students do that, on public (and popular) repos.
I was contacted by a guy who said he found a vulnerability on my site. Something like phpinfo being available or something. I informed them that I was aware of it and it's not a vulnerability but did offer to give them a small Amazon gift code if they wanted.
This might be part of the motivation. What's pocket change in the west might be good money in the 3rd world.
Its incentives. If you’re an Indian student in India, unless you go to a prestigious university, your prospects of landing a job, let alone a good one are very small. Even tech companies that claim to be meritocratic elsewhere, rarely screen resumes beyond the top universities in India. The only other real prospect is to get your resume to stand out. Open source contributions, research papers etc are some ways to do that. And the talented ones make contributions, while the rest just try to fake it in the hopes to make it (it obviously doesn’t work).
There are similar incentives if you want your college application to stand out if you’re trying to go abroad for higher education. And if you’re already outside India, those incentives extend to job applications outside India. If you’re an international student looking for a job, even if you have work experience at known multinational companies, if it’s in India, the experience doesn’t count.
Definitely not. Anyone growing up immersed in face-saving, high pressure, competition and possibly self-help influencers telling them how to achieve will exhibit these sorts of behaviors. Doesn't matter if you're white or black.
selfishness, laziness, lack of self-awareness, lack of shame, etc are obviously universal traits. But cultures absolutely reinforce them to different degrees. Many cultures around the world are built around the sorts of behaviors we both described.
Whereas other cultures have at least some (if not a lot of) resistance to it - eg publicly ridiculing when people step flagrantly out of line. This is good. My impression is that British culture is like this - "taking the piss", or worse, out of people whose egos start to get too large
Edit: what about this comment could possibly be worth a downvote...? Not that I care about points, but it just seems to be an objective assessment of human nature and cultures, without even singling out any cultures that need improvement.
people who actually have a life generally don't spend time hanging around internet forums so it's important to consider that a disconnection from reality is involved in places like these , thru my eyes you have restated the idea of low trust vs high trust societies without building on top of the idea , which isnt downvote worthy but isnt upvote worthy either
I didn't expect up votes. I also wasn't about to write a treatise. And saying "low trust vs high trust societies" wouldn't be meaningful, nor would it actually be accurate. The issue here isn't trust - it's humility, integrity, conscientiousness, etc. Trust often comes along with such traits, but it's not the core issue.
This is hilarious and reminded me of the two stints I had in India, for about 8 months in total at the turn of the century. I was a hippy traveler and asking directions for almost anything was par for the course. I never had anyone local say they didn't know where something was once asked, even though me following their directions lead to the intended target maybe 10% of the time. It was funny and infuriating at the same time :)
Absolutely. I've been traveling for the last 10 years and lived in 50+ countries. I believe that all cultures have unique pros and cons and that the cultural diversity of the world is an amazing thing. There are good and bad people everywhere, so I rarely leave a place with such a strong opinion as the multiple times I've been to India. I really wanted to love India because of their rich history and diversity, but I ended up leaving with a feeling that their culture is overwhelmingly objectively bad.
Possibly as a consequence of this, what I have observed working with Indians is a very hierarchical structure in which you have a "lead" or "architect" who spells out what to do and how to do it in minute details and micromanages, and "devs" who execute as instructed.
I've worked with offshore a number of times and had to recruit there. Even for mid to junior positions, you'd see most people you interview with senior-lead-architect (over heard a random design discussion at the cafeteria), master-of-the-engineering-quality (wrote disfunctional selenium tests), CTO-confounder-Founding-engineer (unpaid internship for his cousin who had an app idea), expert-senior-executive who managed teams of 60 people (summer job as a goat herder).
I guess that's one way to stand out when you are lost in an ocean of people, working thousands of kilometers away from the white dude exploiting you.
There are also a lot of Indian students (there are 1.4bn Indians). There are lots of IT jobs, therefore presumably lots of IT students, and unlike in China Internet access (e.g. to GitHub) is not restricted.
> At the I perceived the pattern that Indian contractors would never ever ask for clarifications, would never say they didn't know something, would never say they didn't understand something, etc. Instead they just ran with whatever they happened to have in their mind, until I called them out
It's desperational. The desperation of not having to lose any contract. The desperation of being just one bad year away from being on the streets and having to live a terrible life (no food security).
For students, often there is no pathway to actually become good due to lack of resources. So, the only way is to fake it into a job and then become good.
there are definitely cultural issues you have to be aware of, and it's not just India, there are many cultures where questioning authority or admitting to uncertainty are less welcome - and some companies and managers reinforce these.
Always consider relative status and power imbalance regardless of nationality too. If someone is afraid to say no you have to factor that in - and 'calling them out on it' is maybe not the most effective reaction, especially if in public.
I always had frustrations with this as a manager until I could establish a personal relationship. Sounds extra hard with short-term remote contractors!
I think it's mostly not cultural but just bad engineers lying. IT jobs pays the best in India, and it attracts people who have no skills in IT to just fake their way in.
So for every good developer in India there are probably 20 bad ones who have no idea what they are doing.
I honestly think its a symptom of having almost no "career mobility". If it's impossible to get promoted / find better jobs, then being skilled doesn't go as far as brown-nosing.
People will only apply themselves if they think it will help them get to a better place.
Not exactly - there is career mobility in IT, but for many IT is seen as the only place they can get it people who shouldn't be in IT go there.
There also seems to be an expectation that after about 30 you move into management. This means people experienced in IT are not socially valued (they can be paid well if they are great).
Resume glorification and LinkedIn / GitHub profile attention do that.
I am seeing a lot of people coming up with perceived knowledge that's just LLM echo chambers. Code they contribute comes straight out of LLMs. This is generally fine as long as they know what it does. But when you ask them to make some changes, some are as lost as ever.
Torvalds was right, code maintenance is going to be a headache thanks to LLMs.
At this point I won’t consider any GitHub activity after ~2024 as hiring signals unless it’s very substantial work on high profile projects that clearly have high bars.
We had a bootcamp in our city that had all students build a GitHub portfolio. They all built the same projects like a TODO app. Every person’s code would like almost identical because they all did them together and, I suspect, copied from past grads.
They all applied to the same local jobs, too. So we’d get a batch of their resumes with GitHub links, follow the GitHub links, and see basically the same codebase repeated everywhere.
I kind of suspected that some bootcamp or college or something is telling all these people to just go to GitHub, create an account, spam it with activity, and you'll get a job! At this point I don't think "has a GitHub account" can be used as any signal of programming ability whatsoever.
I mean I never considered having GitHub projects as anything. If you have project(s) that seem useful and have let's say a hundred stars or more (rough signal assuming no foul play), I'll have a look. If you say you have meaningful contributions to projects with a thousand stars or more, I may have a look as well.
Now my bars are so massively higher, 99.95% of juniors who don't have pre-2024 work to show can forget about it.
> Torvalds was right, code maintenance is going to be a headache thanks to LLMs.
I know someone in a senior engineering position at Epic who does nothing but clean up PR's from their off-shored Ukrainian sweat shop coders handing in AI slop because all they need to do is close a ticket to get paid. They wind up rewriting half or more of it. Epic doesn't seem to care so long as this "solution" works and saves them money by paying a few really smart people to code janitor until hopefully all of them can be replaced by LLMs.
As if I needed another reason not to hire people coming from Epic.
For a company as financially focused as Epic it's surprising to me they'll pay the offshored devs for simply submitting code even if it doesn't work and needs to be rewritten.
I’m actually of the mind it will be easier IF you follow a few rules.
Code maintenance is already a hassle. The solution is to maintain the intent or the original requirements in the code or documentation. With LLMs, that means carrying through any prompts and to ensure there are tests generated which prove that the generated code matches the intent of the tests.
Yes, I get that a million monkeys on typewriters won’t write maintainable code. But the tool they are using makes it remarkably easy to do, if only they learn to use it.
I’m not sure why the downvotes. I think the poster is basically saying the same thing as this YouTube-er. I read “Million monkeys” as referring to LLMs.
I've seen this - it's tiring even at low volume. Goes something like:
Someone creates a garbage issue. Someone else asks to be assigned. Someone from the project may say "we don't assign issues" (this step has zero effect over later steps).
Someone else submits a PR. Maybe someone else will submit another PR. Maintainers then agonise how they can close issues and PR(s) without being rude or discouraging to genuine efforts.
GitHub PM here working on how we can make this problem feel better for maintainers. Really appreciate how tiring this can be, especially when even low volume is sustained for many months.
Would love your thoughts on some of the things we're thinking about:
- Would it help to disable all PRs? All non-contributor PRs?
- Would a "close as admin" button help address the issue of not wanting to be rude or discouraging?
- What about Copilot doing an initial review and proposing to close anything that doesn't meet contribution guidelines - would that help a "close this" decision feel less personal?
Good questions, thanks. I'll share this thread with other maintainers. Is this the best place for feedback in a week or two? Or is there a GitHub meta discussion somewhere?
As someone on the other side of the PR, the current situation makes things awkward for me, too. Occasionally, I'll make an actual fix to scratch some particular itch I have with the software, and I'm hesitant to even open a PR, because it's just going to 1. pile yet another PR onto the maintainer, and 2. might get dismissed out of hand because it's mistaken for AI slop or other low-effort spam that these attackers are doing. So, I usually just fork, make the change in my own repo, and leave it at that.
Disabling PRs or limiting PRs to "contributors" would be a signal to me that I should just keep doing that and not contribute back to the main repo.
For me the answer to this is to let go of all expectations. Fix things for your own purpose, and then open PRs to give the maintainers the option to engage or ignore.
Obviously from my post above, with my maintainer hat on I often fail to let go of the emotions. But it's a goal.
The lowest-stress PRs to handle are the ones with clearest test cases, and minimal incidental changes. Don't refactor, reformat or rename things to your own preferences and then expect a maintainer to engage.
Reducing changes to the meaningful minimum will also make your fork easier to maintain if the PR is refused, or ignored for months+ as the upstream project continues to evolve.
Ultimately, opening a PR is in part self-serving - best case is my change is upstreamed, worst case is I have taken time to streamline it, and simplify integration of future upstream changes into my fork.
Totally get this. One thing we'd love to do is help make contribution patterns (not just guidelines) more visible to contributors, to help you get a better read of what's expected. Would that help? If so, where would you expect it to sit in your existing contribution flow?
I always thought it would be nice to see some kind of "maintainer profile" for each project, that the maintainers could set up: Is the project open to PRs? What is the quality bar for PRs? How much developer testing is expected before a PR is accepted? Are there any automated test coverage requirements/expectations? Sort of like a more structured version of CONTRIBUTING.md.
Also, statistics about past PRs: How long does it take, on average, before the maintainer responds to a PR, before it gets merged? What % are rejected or closed? How many edits do PRs for this project on average need before being accepted? What is the current incoming rate for PRs and what is the current merge rate? I could look at these and figure out if a project can sustain yet another incoming PR or if they are in over their heads. And it would help me understand what level of "done" they are expecting. Maybe some of these are even already available--i haven't really explored GitHub that much. Hope this helps.
Yeah, I kinda stopped involving myself in other people's OSS projects a while ago for that reason. If I have an itch to scratch, I just use my fork. It usually feels like my itch isn't theirs and I always feel like I'm imposing on the maintainer's vision or at best just taking time away from them. I think maintainers have a lot of pressure to accept things because "open source!".
You've been getting PRs? All I've ever seen is "can you assign this issue you me" spam and then disappear. I was nice to them for years but now I just delete the comment and block the users.
Yeah, the "can you assign the issue to me" is the most common. I don't even understand where it came from - does anyone ever actually formally assign issues to anyone?
But they absolutely also create PRs even if you say "don't create a PR. You don't know what you're talking about"
I'm pretty sure there's some guru/teacher that gives assignments to their students. The assignment is most likely "find a repo and ask if you can work on it." The student then either finds something easier to work on or gets points just for trying.
I contribute regularly to some major open source projects and it’s happening here too. So many issues that aren’t issues. Constant “fixing” of documentation that doesn’t need to be fixed. Bug reports that aren’t bugs, followed by a bad PR “fixing” the “bug.” Or YOLOing an LLM PR to change major behavior that users are relying on. And I click and the authors are always brand new, with only vibe coded or examples projects in their history, and have some truly awful LLM generated GitHub “about me” page complete with emojis and links to their GitHub “projects.”
My suspicion is somehow the perception became that if you’re brand new and land a PR in a major open source repo (even as simple as rewording a phrase in a doc that doesn’t need to be reworded), that would help them get a job (they’re always Open to Work on their GitHub about me page).
It’s so much noise that it’s hard to find the real issues.
GitHub PM here. From what we've seen, you're right about the motivation; I've also seen plenty of job ads where "significant contribution to open source" is something that's called out explicitly as a valid substitute for professional experience in the area. While that's always well-intentioned and creates many benefits for the OSS community, the flip side is that it can also lead to the kind of problems you're seeing. Many new users are also motivated by learning and community, and not familiar enough with the community expectations to know how to seek that differently.
We have tried a lot here in the past (good first issues, more community support for new users), but haven't found a perfect solution yet. Internally, we're looking at options for admins to disable PRs on repos, or limit PRs to collaborators only, for example. From your comment, it seems like part of the challenge you're experiencing as a user is around Issues specifically. We've also been looking at options to delete PRs and Issues individually and in bulk, which could help after the event. Would welcome any feedback on other paths we could take here.
I think a "PR quality score" would go a long way here. Doesn't even have to be displayed to the user, you can just flag it as a low-quality PR under a certain threshold and have it go to a separate view for the maintainer. Have a prominent 1-click button to close it as low quality/spam with a default message about useless PRs. To go along with this you'd probably want a "report" button on comments/PRs to flag them as (spam/AI generated/useless change/etc.)
You could estimate quality with: number of PRs accepted before (only counting repos >2 years old), age of account, size of diff, number of PRs reported as spam.
Thank you for looking into this. It's a huge problem for maintainers these days... something needs to be done.
It would help if PRs from newly-created or private accounts could stand out. And perhaps PRs from accounts that spam multiple PRs with dozes or hundreds of commits, would have some kind of a warning that only people with write access to repos can see. In fact perhaps GitHub could throttle those accounts from creating that many PRs in the first place.
Another suggestion would be trying to figure out if a PR was vibe-coded and marking them as such. Same as image-based social media tries to do.
That makes a lot of sense, and we've been considering some of those options too so good to know we're on the right track there. On trying to figure out whether a PR was vibe-coded: in some cases it's obvious, but in many cases it's hard to figure that out without AI, and we're not sure we love a solution that requires maintainers to use AI to tackle AI. My hope is that if we can provide some non-AI tools first (disabling PRs, creating more visibility around new users, etc), we can then build better management and triage tools with AI second. We're working on an Issues triage agent now that we hope to bring over to PRs too.
Make it possible to turn off PRs from new accounts, accounts with a low PR acceptance rate or accounts that create lots of PRs all at once in unrelated projects. Or mark those kinds of PRs in a visible special way. Or make those kinds of issues and PRs non-public so that maintainers can silently drop them without creating publicity for the slop-spammers.
Thanks a lot for taking this seriously. I regularly contribute but am not a “maintainer” so can’t really turn off PRs or anything, nor do I think that’s the right thing in this case. But some signal to spot these accounts at a glance before I go through and try to repro their issue or spend time engaging would be cool. Or immediate signal on “new accounts” (on HN usernames are green for like 30 days), or “account age vs PR velocity” would be interesting to me. Old accounts with regular PRs or Issues are not a prob, but the new accounts that just spam low quality issues and PRs are maddening.
Yep, totally get this. We're going to try and provide some quick solves first for the most affected maintainers, and then go back and make sure we can also help with the kind of nuance you describe.
Maybe you a mysterious hidden ELO score that effectively shadow bans people if they get a negative report from a high ELO maintainer. Perhaps look at how dating apps do it as they have to deal with a many persistent undesirable people.
Or just throw up a money hurdle. The reason you're seeing so many hustle bros from poorer countries is simply because the cost of accessing the internet is now effectively zero.
I pick the "block" option on the junk issue, and tick the "Send a user notification and show activity in timeline". The text says "A public timeline entry will show that this user was blocked" which I hope discourages them from wasting our time.
I'd argue that the or at least one major reason for the downfall of Stackoverflow (and not just a catalyst) has been a surge of Indian IT people triggering an avalanche of extremely low quality questions and answers. I've been a big fan of SO since about 2010. Not just didn't mind the harsh moderation but actually attribute to it learning how to properly ask a question. But at some point round about 2019/2020 it stopped being fun due to it going from knowledge base to garbage dump.
"According to the story, the British government, concerned about the number of venomous cobras in Delhi, offered a bounty for every dead cobra. Initially, this was a successful strategy; large numbers of snakes were killed for the reward. Eventually, however, people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped, and the cobra breeders set their snakes free, leading to an overall increase in the wild cobra population."
The funniest/saddest part is that you could just game it on your own repos, you never had to go out and spam any real projects. If you just made 5 PRs in a repo you owned with the appropriate hacktoberfest tags, that was enough to pass the mark and to get the free shirt and stickers.
worked well for a bit. but then the program became popular and that’s when it hit the curb. terrible loss, imo. it was a brilliant idea to encourage open source work with a token reward. it relied heavily on good intentions, which quickly disappeared with the popularity.
There is no limit to how low someone will stoop to get even a tiny token for free. I remember a local community fun event from a couple of years ago, which was set up by the library to encourage kids to read. They would count up these reading tokens at the end of it and give some tiny $2 teddy bear to the winners, and of course a bunch of adults swooped in, gamed the system, and all the toys went to them. People are totally shameless assholes when even an insignificant free prize is on the line.
It’s still ongoing. The difference is they now no longer offer t-shirts (at one point they planted trees instead, unsure if that still happens), and projects must opt-in.
> Swag - Get an exclusive Hacktoberfest T-Shirt, but its only for ‘Super Contributors’ who contribute 6 accepted PR/MRs to a worthy repository. (T&Cs Apply | Valid only for the first 10,000 contributors completing 6 PR/MR)
Reminds me of this Indian GitHub tutorial on how to open a PR on GitHub. The video got millions of views and has flooded a specific repo with countless README update PRs of people (mostly Indian) trying to append their name to the README.
they flooded THE major server side js framework and it's happening to this day, every day. Express is something to backend what jQuery was to frontend 15 years ago
Usually the protection against such spam is social shame but the internet is now full of people who have no shame because shame was never part of their culture. It would be more effective to use GeoIP in this case.
I wonder how much of it could be stopped just by charging $5 a month to contribute to public open source repos. Even if github gave the $5 back in LLM credits or something it would at least put up a barrier. The reason there is so much traffic from third world countries is because the cost of accessing the internet is effectively zero.
I seem to remember there was a large (indian?) educational YouTuber who did a tutorial on how to use Git where they forked a FOSS repo, made a change to the README.md and then made a PR. This caused a huge influx of garbage PRs for that particular repo and other FOSS repos.
I submit typo PRs sometimes. I just really like cleaning up docs, and some typos are important because they affect doc searchability. (But I do bundle them up so there's just one PR, and I generally won't do it for a single typo.)
Noticed it in corporate context too. About 40% of the performance feedbacks I saw this year were AI written. India and USA crowd. Everything from Europe looked pretty organic but imagine that’ll change too next cycle
I was reading some GitHub comments earlier and the AI tone and structure in the comments posted by some users made me feel really uneasy for some reason.
I know a Brazilian who puts lots of emails through ChatGPT because they aren't confident in their English, but this seemed to be AI generating the majority of the content of the message too.
That person should stop. I give a lot of leeway to anyway who ends with "(English is not my first language, sorry for mistakes)" or if they also post it in their original language (if I'm confused I can machine translate parts of it if the confusion isn't obvious, which it actually always has been for any continental language IME).
Little bit offtopic; is anyone getting more reports of site vulnerabilities I wonder? There are how many AI tools claiming to find those automatically and we get a lot of reports, some even have the tool name on. Thing is, most, well, all so far in the past months, are not true. They seem hallucinations or false positives. We have closed source SaaS products, so these are external scans making these reports.
It's likely because of Google Summer of Code. OWASP has participated as an org several times and it's highly likely that they'll participate this time too.
Students often start making PRs around this time to get more familiar with projects before they can put in a proposal when the time comes.
As someone who's been a programmer for a while now, I feel it's pretty easy to identify slop code and when someone is using an LLM to communicate on issues. I'm not against using LLMs for writing code or even for using it to improve your communication, but it cannot be a substitute for critical thinking.
If I was a maintainer of an OSS project, I'd be more likely to _not_ select students who put out slop PRs, proposals, or messages without thought. And also make this clear in the contributing guidelines so contributors know what they're getting into.
I've noticed this also. But I didn't ascribe it to LLMs, rather figured there is some sort of rogue educator in India who's instructing students to do this on public repos and they just don't know better. But the prof should.
The other side of the coin is that many real bug reports are dismissed out of hand. That is frustrating if you have spent hours or days triaging an issue and have submitted a well-written bug report. It would be useful if projects advertised what their de facto bug report policy is. If it involves snide remarks and pointless bureaucracy ("you did not check this box") then that should be stated to help others avoid wasting time. Perhaps an LLM could help with that: "The likelihood of an external bug report being acted upon is X%, given analysis of past interactions on bug tracker."
volume of low quality content, dsa/leetcode, etc. is so high, good people/content gets left out. networking, connections, nepotism so much high. getting job based on actual talent very rare.
MNCs which are good outside are so much sh8t here; well capitalism doesn't give a f8ck anyways.
I think you'll get downvoted to oblivion because outsiders often don't realize the ridiculousness of the whole thing.
I will try to give some context.
To give an example, the CSE undergrad from an average Indian college would've done 500 - 1000 leetcode "problems" for practice. But have little to no idea on how to survive in a UNIX shell, or to troubleshoot an actual problem. Hell, half of them haven't written more than 1000 lines of code for single purpose.
People early in their career (which is most SWEs including yours truly) follow whatever "influencers" on youtube (the local term being bhaiyya-didis), who give them rough "roadmaps" to "crack DSA" or "get high paying remote job". The result is that average CS guy spends most of his time navigating this rat race than studying computer science stuff that matters for the job.
I see similar kind of competition getting created at senior levels too, in the terms of people grinding theory and blog posts on "system design" interviews. I am not old^H^H^H senior enough to comment on it, though.
But it was not all bleak. IIRC, We were producing quite few good OSS contributions through GSoC, LFX etc... until few years ago (not considering my own among good ones). There were talented 1% or so (I known a few very talented people in personally). Nowadays these "hustler" variety people have started "How to crack GSoC" roadmaps [sic] too, and the spamming quoted above see may be related to this. This sort of insane rat race is not good for talented people. It's not good for companies either. Recruitment is basically lottery at higher levels too; I have seen people use AI to shamelessly lie on their resumes and get hired etc... Some of these problems may be present in west but India's scale makes some of these problems difficult.
this is a problem with all indian "education". I work in renewable energy and regularly chat with other Indians at IEEE conferences who are looking for work in the West.
These supposed electrical "engineers" have an IEEE "paper" to their name but regularly confuse power and energy. They have no curiosity, no interest in their work, atrocious communication skills (not language, communication) and swarm you like piranhas once word spreads.
All this combines to devalue Indian degrees and the reputation of Indian STEM talent. The genuinely good people are drowned under this avalanche and there's not much you can do to help them or to find them.
> These supposed electrical "engineers" have an IEEE "paper" to their name
"publication" is encouraged or in some cases "mandated" in certain institutions for course points. It's a lecherous system to game certain metrics which leads to pretend-play and not an ounce of productive work.
> there's not much you can do to help them or to find them.
In CS, If you want to find talented Indian folk, you can hang out in IRCs, hobbyist forums etc.. I have few friends who were Linux enthusiasts, compiler experts etc... who used to. Genuine interest is a pretty good initial filter.
IEEE might as well be a predatory publisher. None of their journals are serious anymore.
Hell, CVPR is now the top conference/journal in the world, beating out every medical journal, Nature, etc. NeurIPS I think is also beating out every medical journal ever.
If you're not targeting a top 20 listed conference/journal in your field as ranked by google scholar (i.e shows up on the leaderboards at all), you might as well not even publish, as those papers at worse venues act as a black stain on your academic career.
These folks should instead target workshops at prestigious venues.
Because their usernames are Indian and profiles have links to Indian universities, and sometimes descriptions of the 101 classes they're currently taking. That doesn't stop them from saying things like "I see this sort of vulnerability all the time"
Don't worry they'll change that too. Sadly I think we're going to need some kind of internet licence like a drivers license that they'd at least have to bribe their way into.
Subjecting every real contributor to the "AI guardian" would be unfair, and shadow banning is ineffective when you're dealing with a large number of drive-by nuisances rather than a small number of dedicated trolls. Public humiliation is actually a great solution here.
> Subjecting every real contributor to the "AI guardian" would be unfair
Had my first experience with an "AI guardian" when I submitted a PR to fix a niche issue with a library. It ended up suggesting that I do things a different way which would have to involve setting a field on a struct before the struct existed (which is why I didn't do that in the first place!)
Definitely soured me on the library itself and also submitting PRs on github.
I suspect people are doing it to pad their resume with "projects contributed to" rather than to troll the maintainers, so if they're paying any attention they probably do care...
what you say, is of course the only relavent issue.
I can attest to my own experiences on both sides of this situation, one running a small business that is bieng inundated by job seekers who are sending AI written letters and resumes, and dealing with larger companys that have excess capacity to throw at work orders, but an inability to understand detail, AND, AND!, my own fucking need to survive in this mess, that is forceing me to dismiss certain niceties and adhearance to "proffesional" (ha!), norms.
so while the inundation from people from India(not just), is sometimes irritating, I have also wrangled with some of them personaly, and under all that is generaly just another human, trying to make by best they can, so....
You could easily guard against bullshit issues. So you can focus on what matters. If the issue is legit goes ahead to a human reviewer. If is run of the mill ai low quality or irrelevant issue, just close. Or even nicer: let the person that opened the issue to "argue" with the ai to further explain that is legit issue for false positives.
I relate, and then realized that's been the basis of spam handling for decades now. It's depressing, and we aren't putting this genie back in the bottle unfortunately.
It's analogous in the sense that tons of machine-submitted emails exist for the sole purpose of being mechanically triaged. The technology might be slightly different (it may not be LLMs through and through), but the pattern is the same.
It's not happening because I'm not using an AI to summarize text. At the moment slop text is also fairly easy to recognise, so I can just ignore it instead.
It sounds funny, but it's not. I once issued a bug to them that didn't have enough information about how to reproduce... and I was lambasted on Reddit and eventually just deleted my account there it was so terrifying. Some dev teams do not mess around. In fact I've shied off most social media since and no longer issue bug reports to any company, I was scarred deep over the treatment.
I've read their reports before. When there's not enough information to reproduce, they do a good job of asking for more information first, and I've never seen a reasonable good-faith report elicit anything overt.
If you failed to give them proper reproduction information when asked, then yeah, you were wasting their time and they should rightfully close your issue.
I've never seen anyone on the curl team undeservedly "lambast" someone, and for a project that has a quite good reputation, I think the burden of proof is on you. Can you link to these supposedly terrifying comments?
It says in the curl file that they will ridicule time-wasters in public and here is one pression confirming that it happened to them, yet somehow that's not enough? Come on.
If you follow cURL’s development, what you’ll see is the main contributors tend to be extremely patient, helpful, and thankful of contributions. Sometimes too patient. If you look at the HackerOne slop reports cURL got, you’ll see Daniel accommodating people outright wasting their time.
So if you follow what’s been happening, you know the types of reports this message is talking about. What they consider time-wasters are slop reports where the reporter didn’t do any effort to even test the “bug” and then keeps pasting whatever the LLM says in replies and lying about using them.
In other words, for a legitimate report it’s hard to believe that was the reaction. I would expect them to be patient with a human contributor which really put in the work. It’s particularly hard to believe the maintainers would even waste their time to lambast someone on Reddit. Doesn’t seem like their style.
Maybe the person in this thread is exaggerating, maybe they misinterpreted it, or maybe it did happen. But it seems so out-of-character that some proof would be warranted, especially since it’s a single report.
When people don't provide a citation online when discussing some specific instance like this-- which could be provided with a couple clicks and would radically improve their argument a reasonable assumption is that the citation would undermine their argument.
We don’t need anecdotes, every single bug is public. Just looking now I see respectful responses to genuine reports. This document is clearly in response to AI slop and spam.
I skimmed the "slop" collection they maintain that was posted here yesterday, and even under those HackerOne submissions, Daniel was perfectly reasonable and respectful.
It is entirely possible I merely chanced upon his highlights, but this announcement to me really just signifies a final straw breaking than anything else. His historical conduct is all public and speaks for itself. I wish I had the patience and perseverance he does, and I wish he didn't need it.
But at the same time, sometimes you have to really persevere to get a bug fixed.
Consider the perspective of the maintainer of a popular project: to them, you're one person in a big queue of people all reporting problems. Most issues turn out to be "I need free technical support, which you don't offer, so I'll phrase it in the form of a bug", and it saps their time to look into the details of each issue to find whether it's genuine-bug or user-error.
So that's why you should try to give reproduction instructions as best you can, and be up-front if they're incomplete, or you only saw it happen once.
If the maintainer responds harshly, or even if you get commentary from others, remember they are (or should be) criticising the bug report, not you. Try not to take it personally.
And even if they decide to close it, or not investigate further, you've still done the world a favour by adding genuine details about something you saw. The bug report is still searchable when closed. Other people who get the same problem as you are likely to find it, and it might spur them to reproducing the bug where you couldn't, and re-opening or re-reporting the bug and driving it forward to completion.
It’s not my job to fix their bugs. It’s not my job to handhold them through it. You are better off anonymously posting the full bug online and let god sort it out.
You're paying exactly $0 for support for this software. So any support (eg: bug fixes) you get are a gift. That means that if you (1) use their software, (2) don't provide a good bug reports to help them fix their bugs, and (3) complain about how it's not your job to fix them then... you, my dear person, are acting like an entitled ass.
It's not hand-holding to provide a good bug report, it's essential to make the bug report actionable. curl is so widely-used that bugs often come from a combination of the software and the environment (OS, libraries, etc). Without enough details to reproduce a bug, then the bug is often impossible to track down. This means: recreate the environment, the actions that led to the bug, and create the bug itself.
That surprises me -- from what I've seen, Daniel is actually remarkably tolerant of incomplete/unclear reports. (Too tolerant.) But I imagine that could depend on the day.
(Now, if you used AI to generate the report, well... that's different. Especially if you didn't disclose it up front.)
On the flip side I’ve been following him for a while on Mastodon.
I’ve basically watched the AI crap cycle go from “this is a weird report, oh it’s fake” to “all the reports are trash, it’s so hard to find real humans in the flood” through his posts.
I suspect I would’ve stepped down long ago. I feel so bad for the open source maintainers who are just being assaulted with nonsense.
Not really. They said in their comment they deleted their whole account and everything. They probably don't want to continue to be ridiculed and to link the identity of that account with this one.
Please ignore everyone else and do not share any more information about this experience or yourself. These people do not have your best interests in mind and will not mind, or are intending to, make this experience even worse for you.
He rubs me the wrong way, too. Curl is overhyped and a pain to work with. And he's getting high on the "success" while crying about not being paid for something he offers for free. I think Americans have a nice phrase about having cake and eating it, too.
Not only is cURL not overhyped, it’s absolutely false that Daniel “[cries] about not being paid for something he offers for free”. He does get paid for cURL support.
He does criticise rich companies who don’t do anything to support cURL and demand preferential support, but that’s not the same thing (and does warrant criticism).
Seems like a lot of the problems had by the low friction of first eternal september and now LLM genrated reports and contributions, could be resolved by restoring friction. First time reporters/contributers could be required to send their report or PR by paper mail. Strict requirements for the sender: all text printed on postcards (no letter opening) as QR or other data codes according to a standard formatting. Anything even slightly off goes straight to the trash, high signal/interest contributors can still get their foot in the door.
The eternal-september; or its international equivalent, kills things because the nature of the public you are interacting with has changed.
These issues with reports and junk contributions come about because there is a huge payoff for pretending to be part of the community, but the benefit from actually contributing is generally less direct.
I dont think you can solve this with "friction", because the people you want to dissuade are more tolerant to these kinds of barriers than the ones you want invite in.
I'm not sure it helped in the end, afaik they did it since like 2003 until some years after the raid, but it still seemed like they didn't get the message and kept trying anyways, which from their perspective makes sense but still.
Projects are not going to be so open open their development process if they have to keep wading through emoji-filled and erroneous PRs. The Bazaar doesn't work so well if nobody can get around the piles of manure that are being delivered
It's not just open projects, it's anything that accepts unvetted information at all. Bug lists full of shit. Forums full of shit. News feeds full of fake shit. Ads full of fake shit. Cultural zeitgeist full of fake shit.
Culture and society has not figured out how to inoculate themselves yet.
This kind of automated industrial output is the foundation of our culture, it's not surprising that we aren't prepared for the virtual grey-goo of the LLM era that is our milieu brought to it's acme.
I am friends with a solo maintainer of a major open source project.
He repeatedly complains that at the beginning of some semester, he sees a huge spike of false/unproveable security weakness reports / GutHub issues in the project. He thinks that there is a Chinese university which encourages their students to find and report software vulns as part of their coursework. They don’t seem to verify what they describe is an actual security vuln or that the issue exists in his GitHub repo. He is very diligent and patient and tries to verify the issue is not reproducible, but this costs him valuable time and very scarce attention.
He also struggles because the upstream branch has diverged from what the major Linux distribution systems have forked/pulled. Sometimes the security vulns are the Linux distro package default configurations of his app, not the upstream default configurations.
And also, I’m part of the Kryptos K4 SubReddit. In the past ~6 months, the majority of posts saying “I SOLVED IT!!!1!” Are LLM copypasta (using LLM to try to solve it soup-to-nuts, not to do research, ideate, etc). It got so bad that the SubReddit will ban users on first LLM slop post.
I worry that the fears teachers had of students using AI to submit homework has bled over into all aspects of work.
As a human being I really enjoy knowing things and being challenged to grow.
While crypto style AI hype man can claim Claude is the best thing since sliced bread the output of such systems is brittle and confidently wrong.
We may have to ride out the storm, to continue investing in self learning as big tech cannot truly spend 1.5 trillion on the AI investment in 2025 without a world changing return on revenue, a one billion revenue last year from
OpenAI is nothing.
Kryptos K4 seems to me like a potential candidate for AI systems to solve if they're capable of actual innovation. So far I find LLMs to be useful tools if carefully guided, but more like an IDE's refactoring feature on steroids than an actual thinking system.
LLMs know (as in have training data) everything about Kryptos. The first three messages, how they were solved including failed attempts, years of Usenet / forum messages and papers about K4, the official clues, it knows about the World Clock in Berlin, including things published in German, it can certainly write Python scripts that would replicate any viable pen-and-paper technique in milliseconds, and so on.
Yet as far as I know (though I don't actively follow K4 work), LLMs haven't produced any ideas or code useful to solving K4, let alone a solution.
The typical graduation-requirement paper doesn't get published in a professional journal, so I think professional journals do provide significant curation.
Medical? What's the point? I'm happy with 98% of doctors being able to handle known conditions and only the few percent that are really interested to do research.
It makes the university look better if they do a lot of 'research' even if it's fake. There's not a real reason a doctor needs to do research for an MD.
I think this is probably less effective than if there was some sort of "credit" or reputational score for reporting that seems like something GitHub would have the information to implement.
Finally an explanation to why GitHub suddenly have way more bugs than usual for the last months (year even?), and seemingly whole UX flows that no longer work.
I don't understand how it happens, do developers not at least load the pages their changes presumable affects? Or is the developers doing 100% vibe-coding for production code? Don't get me wrong, I use LLMs for development too, but not so I can sacrifice quality, that wouldn't make much sense.
I just listened to podcast from a higher echelon MSFT person, the internal orders basically are “focus on AI”, non-AI work gets deprioritized company wide.
But that by itself shouldn't mean that people suddenly don't even review and think what they're doing, right? Again, I too use LLMs for lots of work, yet I'm putting out better code than before, because I'm a software engineer, not a software slopper, is this not the common workflow?
I wouldn’t be surprised if experienced people left because of policies like this. It doesn’t matter if you are reasonable your colleagues won’t necessarily be.
I think one of the last thing I'd like on the web is for Microsoft to start keeping a "social score" for developers who participate in FOSS.
I understand where it's coming from, and I too think the current situation sucks, but making Microsoft responsible for something like that is bound to create bad times for everyone involved.
Why no go the other direction and make it hard to identify a user, so people do not do it for fame. Open source worked before people were using it as self advertisement.
Might even be good for Microsoft - they would be the only one knowing who is who.
the berne convention copyright defines inalienable authors rights that can not be sold or taken away from the author. the author of any copyright works always has the right to identify themselves with the work, and therefore your suggestion is not legally possible.
I am not a lawyer, so can't propose the best way to implement this, but the Berne convention contains provisions for "anonymous and pseudonymous works", see Art 15.
This already exists on the previous platform curl was using (HackerOne), it does not prevent the slop.
At my previous employer, I had access to the company’s bug bounty submissions and I can assure you no matter what you try to do, people will submit slop anyway. This is why many companies will pay for “triage services” that do some screening to try to ensure that the exploit actually works.
Unfortunately this means that the first reply to many credible reports are from people who aren’t familiar with the service, meaning that reports often take a long time to be triaged for no reason other than the fact that the reporter assumed that the person reviewing the report would actually understand the product. It’s hard to write good, concise reports if you can’t assume this fact.
Honestly, I don’t know what can be done to fix all of this. It’s a bad situation for everyone involved, and only getting worse.
> Open source code library cURL is removing the possibility to earn money by reporting bugs, hoping that this will reduce the volume of AI slop reports.
> cURL has been flooded with AI-generated error reports. Now one of the incentives to create them will go away.
Why? If it is a purely machine generated report there is no need to have dozens of third parties that throw them around blindly. A project could run it internally without having to deal with the kind of complications third parties introduce, like duplicates, copy paste errors or nonsensical assertions that they deserve money for unrelated bugfixes.
A purely machine generated report without any meaningfull contribution by the submitter seems to be the first thing you would want to exclude from a bug bounty program.
Not necessarily. Reviewing an issue report is already enough time. Reviewing a patch is even more developer time.
The problem they had before was a financial incentive to sending reports, leading to crap reports that wasted time to review. Incentivizing sending reports + patches has the same failure mode, but they now have to waste even more time to review the larger quantity of input.
Anyway, for most cases I'd bet that Daniel can produce and get reviewed a correct patch for a given security bug quicker than the curl team can review a third-party patch for the same, especially if it's "correct, but ai-written".
I've read this idea that we could make people pay for security reports a few times here on HN (and you get back the money if the report is deemed good). That feels very wrong.
If I find a security issue, I'm willing to responsibly disclose it, but if you make me pay, I don't think I will bother.
Punishing bad behavior to disincentivize it seems more sensible.
For a person finding bugs for a living, an up-front fee to have their report reviewed by a maintainer would amount to an investment towards receiving a bug bounty if their report is valid and valuable. Just the cost of doing business.
It would discourage drive-by reports by people who just happened to notice a bug and want to let the maintainers know, but I think for a project that's high-profile enough to be flooded by bogus bug reports, bugs that random users just happen to notice will probably also get found by professional bug hunters at some point.
Only if the system is fair. If I as a maintainer want to scam I can just close the report as invalid, collect the $$$. Then a week latter I fix the issue with a commit that looks like it is unrelated.
I wouldn't do the above, but it is easy to see how I could run that scam.
You can look at how the maintainer dealt with previous bug reports to decide whether you can trust them or not. If there haven't been any previous bug reports but they nonetheless ask for a fee to help deal with the large volume of bug reports, yeah, that might be a scam. If you're running their software, maybe also check whether it's full of malware.
Good scammers pay out once in a while. Casinos hate it when everbody body loses, and love it when one person wins big - they need just enough losers to make money while enough winners to show off.
Punishing bad behaviour does close to nothing, because the problem at hand is one of high asymmetry between the low effort to submit vs the high effort to review. I do agree that paying for reports isn't ideal, and we should find other ways to level the playing field, but in the meantime I haven't heard of anything as effective.
> the problem at hand is one of high asymmetry between the low effort to submit vs the high effort to review
Hence the threat to shame publicly I suppose.
Actually, Daniel Stenberg previously responded to this proposal the same way as me [1] (and maybe would still do). Coincidentally, I was reading your answer at about the same time as this part of the talk.
I get what you're saying, but I don't think punishing bad behavior is practical here. It's like a "enumerating badness" problem - there's way more bad actors with nothing to lose and not much practical way to punish them. There's too many of them and they all have no reputation to damage.
Not saying I have a better solution, just that it's a hard problem. Maybe dissuading some good people who have genuine security issues but don't feel like paying just has to be a cost of doing business.
That sounds wonderfully meritocratic, but in the real world, a machine generating it is a very strong signal that it's bullshit, and the people are flooding maintainers using the machines. Maintainers don't have infinite time.
I wonder if there is a way to blanket prevent these types of problems.
Possible solutions I can think of:
- Require an account with a paid service. Fix = require money
- Require an account verified with real ID/passport etc. Fix = link to real person
- Automated reply system to "waste tokens" if it is an AI that is responding. Fix is increased cost of spammer.
- Have some kind of "vetting system" where you get on an allowed list to report these types of things. Seems not good to me, but perhaps there is something in it.
I wonder how much open source code is lost because maintainers must deal with this type of thing versus the "good" that AI can bring in productivity.
That would shut down all drive-by contributions, which may not be a good source of big improvements, but are a good source of information about bugs/maintenance issues. I.e. if I find a rare corner case where the code breaks, for an open source project I'd usually take some time to report it properly. But there's no way I'd pay for the privilege or bother to register with my governmental ID.
I agree, but if there were a common place where everyone did the registration once, it might be less of a problem. Something similar to the «verified» accounts on twitter etc.
I've thought about this some and there are benefits and detractions in the processes.
First requiring a deposit system. This might work in the sense that someone dedicated can put down $5 and report a bug, and even if it's not a bug but their work is legitimate they get refunded at the end of the process.
- This doesn't scale well globally as $5 is nothing to me, but significant to someone that lives in a place almost no one in the US can pronounce correctly.
- Once you become trusted you no longer need a deposit.
- Most people what would submit a single, real, bug won't do this and you lose this information.
- How is management of this deposit system paid for? How is fraud dealt with?
Could it actually be significantly lower than $5? Isn't the real benefit not the money, but that the payment creates a bit of friction plus a paper trail tied to an individual?
You could then build a reputation system, much like a spam blocklist, using some sort of hash of the payment details.
A few weeks ago i saw a repo in Github that had closed the issue-board and explained the users: to move on to the discussions.
If the discussion leads to the insight, that this is worth a feature, the maintainer will implement it.
I think the same goes for PRs. If you think you have made something cool, then discuss it and offer your implementation and the maintainer makes it fit with you to integrate.
On the other side, if you want a feature it just doesnt have, simply forking it and updating from the source-repo is fair enough.
- I notice a lot of stuff in github issues all the time
- For example, there is this +1 comment pasted like 500 times that I have seen a lot over issues
- Cant we have a github regex bot of sorts ^(\W+)?\+(\W+)?1(\W+)?$ that removes all such comments? or let the author of the repo control what kind of regex based stuff to remove?
- I know regex kind of sounds old fashioned in the age of LLMs but it is kinda simple to manage and doesnt require crazy infra to run
Yes you can, and those comments will then say "plus one", which you will add to your regex, and then they will say "++", which you will add to your regex, and then they will say "I agree", which you will add to your regex, and then they will say "me too", ......
Every site and every service is going to be swamped with AI-generated slop and will have to deal with it by banning it, and then detecting and deleting it.
This was entirely predictable. When you give everyone the ability to be good at something with no effort, everyone is going to do it (and think they are the first).
My partner recently bought a book from Amazon, and when it arrived, I looked at the cover, flicked through it, and said it was AI slop. She complained to Amazon, and they just refunded her, no questions asked, and the book went in the fire.
I was going to add “cURL: “ at the start of the title, but it didn’t fit. The current title is exactly the allowed length, so it seemed more appropriate to keep the message verbatim.
While I understand the frustration with bad reports, this is how you get more of them (from the spiteful) and fewer good reports from the people you just threatened.
I think this is the perfect application of a micro payment service. Each PR must be signed with a nominal amount of money, say $0.15 give or take. You send in a commit, with no expectation to get it back.
I think a deposit would be better then. You make a deposit of ¢15 for each issue and PR you open, and then the maintainers can decide to give it back to you if it was opened in good-faith/useful/merged/whatever policy they decide on.
Agreed. Could be fiat or some sort of crypto currency that requires the submitter to have a vested interest in the outcome.
Honestly, I would love it if I could front some money in order to have the devs look at my PRs. Half my PRs just go into the void and nobody looks at them until some staleness bot inevitably closes it.
This is a similar problem to resume spam. I always wish I could pay $5 when submitting a resume with the guarantee that someone would actually look at it and give me a fair shot. If I ever run a place I want to experiment with only accepting resumes through letter mail or in person.
I want to extend this idea to email. Use encryption, but for proof that the email can't be read, instead of for security/privacy (not that I'm against either of those).
Update the email protocol so that all messages must be encrypted. Not "by default", but by necessity. The server rejects them if they aren't encrypted and signed in a way that proves the decryption key is on a block chain.
The only way to put the key in the chain is to submit a micro payment. By "courtesy" , but completely subject to the recipient, the users client will refund the payment 48 hrs after it has been decrypted/read. Only if they click "spam" then the payment stays on their ledger. This would kill spam overnight.
The two downsides I see so far are that the chain is a single point of failure for everyone, and it would cost people a few bucks and some friction to get the clients set up. Plus the coin would have to be very low transaction cost, and still fully redeemable for actual value somewhere.
Unfortunately, I doubt that would work. Email is so popular because it's sort of a universal messaging protocol that so many old but critical pieces of infrastructure require. If this "Email 2.0" released, it would take years, if not decades, for critical infrastructure to switch over.
In the meantime, you'd still need an Email 1.0 client. So now you have a mix of your most important emails from critical infrastructure and just spam from bots who don't want to pay money for sending spam in your inbox.
You'll still need to deal with spam, but if anything it'll be even worse because now you have to double the amount of inboxes you have.
I think this idea doesn't go far enough. If it's money that's motivating slop, fine - let's make it about money. $50 to submit a bug report. If it's legitimate, we send you back $60; the judgement is on the curl maintainers' honor. If it wastes time, well, at least the curl maintainer gets a steak dinner.
It's been an issue for a while and it's even bigger now in the age of AI. Lots of people use security as a way to "have their moment" and don't really care about adding value.
But scaring people off from security reports also isn't a great idea either.
Creating crap vuln reports or PRs on popular OSS projects has been an issue long before LLMs. Remember Hacktoberfest?
Students would often abuse it since there’s no adult in the room to teach them how to behave. I guess this is one hard way to f around and find out. But this is by no means condoning this sort of behavior.
Point is, LLMs made the situation more dire: it’s cheap to generate code, whereas reviewing still scales sublinearly. The only way to prevent this is by being rude to people who are rude to you.
Moving off github into a more niche platform was the best choice I have ever made to curb such zero-effort issue and feature requests. It raises the barrier just enough.
On the other hand, I'm a dev, and I hate the "start a discussion first" gatekeeping. I participated in projects where the approach is to start a discussion on a forum first, and I get the same feeling you have as a tech guy calling ISP support on the phone.
The discussion requirement is often to prevent disappointment, waste of time, and anger, when maintainers simple close PRs, because it's not the direction they want the project to go. A lot of people will take this very personally, so it's much better to have a conversation about it beforehand.
Problem is that the LLM operators don't care if you're rude. They copy and paste your response to the LLM and probably don't read it themselves. If they do read it they don't suffer any ego hit from it because if there was any error it was the LLM's not theirs and their LLM is busy telling them how brilliant and unparalleled they are and how wrong the haters are in any case.
CURL is free to try it, but I'm doubtful being rude will meaningfully improve things. I'm confident it won't improve the ratio of good to bad reports because non-chatbot powered submitters are sensitive to rudeness or even the threat of potential rudeness, and so this approach could easily reduce total volume some but mostly in the reduction of good submissions.
This note isn't going to stop even 1% of the jackasses who would have submitted AI slop.
There are much better ways to communicate the intended message. This comes off as childish to me and makes me think that I'd rather not contribute to the project.
> This comes off as childish to me and makes me think that I'd rather not contribute to the project.
It's unfortunately the new normal, with FFmpeg's core team acting similarly. No doubt the result of what is considered socially acceptable expanding in ways it probably shouldn't.
that is a view many hold, until its their own time being wasted. Consider the responsibility these people have and take on their shoulders, only for a bunch of idiots to consider their AI slop worthy of pissing up and down their face. Most of them probably even know its just AI slop spraying spree
Why is cURL specifically receiving so many slop contributions? Or is this a recent phenomenon for every open-source project, and cURL are the ones most spoken of? First time commenting on HN!
cUrl as a project has a lot of conceptual attack surface for someone looking to find _anything_.
It is large, very popular (hence impact) and written in C. It supports many many many protocols with all of their real-world implementation quirks. Obscure or mainstream. And always handling user-controlled data.
If your motivation is a cool CVE for your CV, you'd pick such a project as the target of your efforts.
It’s not just them, but curl is one of the most popular open source projects in existence and it’s used in areas where security is a significant concern. The security industry has a lot of emphasis on someone’s portfolio for hiring, which isn’t bad (it beats “what frat were you in?”) but it means that there are a ton of early career people thinking that the path to a better job is getting credited for CVEs on major projects.
That’s a bad combination with LLMs which are almost perfect for letting the user think they’re being more productive than they actually are because the output sounds authoritative. You don’t have to be acting in bad faith to submit a slop report, just being inexperienced and over-confident will work if you don’t have enough experience in the area to reason about the security of the entire system.
One way this can backfire: if you have no reputation and are nobody, and get banned and publically ridiculed, this is now a badge of honor you can take to wealthy and deluded people convinced of the AI future, to say 'look, I have been shot at! I'm a true believer!'
Only if there's a wealthy political group that hates the thing you just got ridiculed by. When you get expelled from a climate conference you can become a right-wing figurehead, but when you get expelled from the cURL vulnerability program, nobody cares.
> We will ban you and ridicule you in public if you waste our time on crap
If shame worked, then slop reports would've stopped being made already. Public ridicule only creates a toxic environment where good faith actors are caught up in unnecessary drama because a maintainer felt their time was being wasted. Ban them, close your bug bounty program, whatever, but don't start attacking people when you feel slighted because that never ends well for anyone (including curl maintainers)
That's sort of the whole point of this thought exercise, no? If shame worked in an environment with anonymous/pseudonymous users, then we wouldn't be here. The only people you stand to harm are the ones who attach their real identities to their profile (and they're more likely to be good faith IMO)
Besides, I've seen plenty of profiles here on HN who advertise their real name and espouse (in my view) awful takes that would most likely not fly in real life. I'd recommend reading this article[0] for an example of when people, with their real names exposed, can still cause a shitstorm of misunderstanding.
This is 100% true. I've seen this happen over and over again.
Shaming does not work, you look like an idiot, people will start to despise you and then you end up ostracizing yourself from the rest of the community and the only ones left within your bubble, are circle jerk assholes.
It's one of those cases where you end up causing more harm than the ones you were complaining about.
> it deters people like me who aren't totally confident in sending reports
This is by design, you shouldn't be submitting reports on anything less than certainty. It's not the maintainers responsibility to prove out your idea. It's yours, and when you're sure, reproduceable, and documented it, then you can submit it.
The real problem here is that this is now the only way the maintainer/reporter can reasonably work.
Proving out a security vulnerability from beginning to end is often very difficult for someone who isn't a domain expert or hasn't seen the code. Many times I've been reasonably confident that an issue was exploitable but unable to prove it, and a 10s interaction with the maintainer was enough to uncover something serious.
Exhausting these report channels is making this unfeasible. But the number of issues that will go undetected, that would have been detected with minimal collaboration between the reporter and the maintainer, is going to be high.
> Nice. But it deters people like me who aren't totally confident in sending reports, trading false positives for false negatives
There's no such thing as a reasonable "false positive" on a security report. There is such a thing as a false positive on a bug report. (A real bug, that happens to have no security impact, is still a true positive, just without a security risk)
If you can make it crash, or behave incorrectly, or have some repeatable, weird behavior; but you have no idea how you could exploit that for an articulable advantage, or access to the system you shouldn't have. What you have is a bug, not a security issue. You can, and should submit a bug report.
Then, critically; "if you waste our time" seems to be an important part of the statement.
If you don't know, you suspect it's a security bug because you shouldn't be able to do this, and it is leaking information that you think is suspicious, and you can easily demonstrate that you can make it happen on demand. And you report that bug, and make it easy for them to understand and either confirm the security, or reject because [reason]. You haven't wasted anyone's time and this wouldn't apply to your bug.
"As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities"
Why have a code of conduct while being hostile to contributors?
But you won't. Let's be real here. Yeah, lets gently remind ai spammers that they are truly helping but submitting bogus Issues, PRs, bug bounties, or whatever. Just like scammers from fake call centers, they are only in it for the money and hoping one hit sticks.
"Contribute" comes from the Latin con- "with, together" and tribuere "bestow". We need a new word for these slop submissions. "Detribute" might work well, for something that takes away from the common good, rather than adding to it.
With the extra work that LLM slop has been causing to core maintainers, I think they're quite friendly. Hopefully the volume of the bullshit they receive goes down once they stop paying bug bounties. The people who got upset that their hacker alias got called out for submitting bullshit LLM slop got what they deserve.
Long time ago Sourceforge and then GitHub promoted into the current default the model of open source distribution which is not sustainable and I doubt it is something that the founding fathers of Free Software/Open Source had in mind. Open source licenses are about freedom of using and modifying software. The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user to better fit the user's needs. To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all. The currently default model of having an open issue tracker, accepting third party pull requests, doing code reviews, providing support by email or chat, timely security patches etc, has nothing to do with open source and is not sustainable. This is OK if it is done for a hobby project as long as the author is having fun doing this work, but as soon as the software is used for commercial, production critical systems, the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane. This is software support, it is a job, it should be paid.
Years ago, I built what I thought was a pretty basic static site generator using HapiJS. I was using it for personal projects and after some convincing by friends, put it up on Github. My friends went on Reddit and posted it and then told me about it afterwards.
It initially got some decent traction and then all of a sudden, all the pull requests came, all the feature requests and then all the bug reports.
I kept telling people this was a side project, if they want to fork it go ahead, but this is not something I'm going to spend a ton of time on. Then all the hate started about how I put something out into the OSS community with no desire to support it. I was bad person, my code was shit and I should stop being a developer.
That was my first and last OSS project.
I applaud and respect the people who are committed to getting OSS out there, but for me, it was a horrible experience.
Far from all OSS projects are like this. Eg. https://www.viblo.se/talks/
Bitching is free and easier than making pull requests. And I bet it was 1 or 2 choads plus a variable pack of minions, not everyone. And Megacorp X can file all the bug reports they want, their lack of investment is not my urgency.
Been there, done that, built walls.
If you allow me to go on a meandering tangent/exploration:
___
I mean if you think about it, this outcome is more or less inevitable, given the environment we've created.
The foundational building block being that people will always optimize for their own benefit and personal gain. They fundamentally have to, because no one else will. So that gives us a natural source of conflict, because not everyone is a builder (or at least not everyone believes that they would), meaning that they need to get someone else to do what they want to get done.
You as a builder of course operate no different to that. You also want to optimize for your own personal gain. Where it is different though is that you do not rely that much on external resources to do that, given that you can create by your own.
So these are our building blocks.
To have a functioning societal system, we do want and need to allow people that don't to receive a decent-ish slice of the output of those that create for various reasons.
Something something shared humanity, but also the fact that a society built out of autonomous builders quickly collapses. Plus multi-dimensionality, meaning that person A might be a builder in discipline X, but needs others to sustain themself in discipline Y. Society and all. Shared workload.
The mechanism that regulates the flow of resources between these agents is friction.
For example, social shaming for not sharing the fair part of what you're earning is friction. That is a constant eroding force and cost that is supposed to shift your internal mental calculus to make contributing to society the most sensible outcome.
Equally so, the act of being protective of your time, demanding respect, boundaries and fair compensation is friction that is supposed to shift someone else's mental calculus to make fair treatment of you the most sensible outcome.
____
Okay, many words, but what the fuck am I on about?
Here's where this self-regulating system implodes:
In the last two decades or so, we have absolutely supercharged the mechanism of shaming and public pressure (rel: Twitter).
Simultaneously though, we've also _vastly_ nerfed any forms of friction a builder might employ. (rel: GitHub as the default, being "nice and professional" as the default, etc.)
And that is what simply is not working. But we're not talking about that properly, because any platforms we currently have for talking about stuff are absolutely and utterly dominated by those that do not create; meaning that they get to dictate the rules.
In a very unsustainable way of course (see also collapse of democracy in general) but that is still the reality we find us in.
___
And that is _I think_ also where we can find solutions to these problems. Don't get me wrong, I'm not proposing to return to linus and tell people that they should be retroactively aborted for having made a mistake. There were many very important advancements we made culturally to push out toxicity.
We will need to reintroduce friction though.
Likewise, we will need re-engineer our communication spaces to shift the balance of power back to a sustainable equilibrium. Which doesn't mean "cold uncaring meritocracy" (also, what even is merit?) but it will mean not handing out ever-larger megaphones based on who is already screaming the loudest.
___
Anyway, TL;DR:
It's the system, stupid. It is like this, because it can't be any else given the currently governing rules.
Thanks for attending my Ted Talk.
I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
The project managers also get a cut of all merges, testers also must approve of the merge and that feature X is the one they want. So the project manager gets to work and improve/reject features, the user gets control over the features of the project they want and developers get to pick specific features they would like to work on (sort of). everybody gets what they want (sort of). All via attaching $ to the issues of the software, not the people.
All we need to do is create Kalshi contracts! Users bet that a fix won't be created for Issue 123 by date XYZ, developers take the other side of the contract and then do the best kind of insider trading: changing the facts on the ground. We did it!
And a few weeks into that arbitrage traders will catch wind and start betting on the more likely bug closures and then the devs that fix the bug will end up owing money!
Then, the people who actually want the fix will bet it back up so the dev is incentivized to fix it!
People who work on making money, tend to have more money and leverage. It’s not an even playing field.
> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created, if the user wants feature X then he should be able to give an incentive towards that feature to be added into the software that they use, developers do bounties instead, the user doesn't have to give much only a dollar, but if many users want feature X, then the money/donations pool creating higher incentives until the task itself matches the level of work to be performed to achieve it until merged.
Have a bot on GitHub that nags people about the pool of committed money towards each feature, to show that they care about it - with the money being placed into an escrow and being released once the feature is implemented and merged, or until a date is reached with no merge and it's given back to everyone / or when the request is closed with no changes. Ofc no idea how you'd validate each individual issue well enough to prevent someone from misusing it, but one could feasibly create such a system, even if it'd probably get a lot of opposition from everyone.
> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created
It might be good to have such a system as an option, but I wouldn't want it to become an expectation. I've got a couple of side projects that are out on GitHub. They have open source licenses and anyone is welcome to fork them, send bug reports, or pull requests, but I don't want to have any obligation of supporting those projects.
You know what would be nice? For these billionaires to start sponsoring people instead of sitting on the obscene heaps of money they have—a patronage system. Everyone wins.
That's actually how a number of OSS projects work, we'll give you what we want for free but if you want us to do what you want you'll need to pay us. Having to implement a compatibility mechanism for some company's buggy train wreck from 20 years ago is a lot easier when you know you'll get paid at the end of it. A number of OSS dual licenses have been created to accommodate this.
Are there any projects that have achieved anything close to this? I'm not against it in principle, but it seems like it ends up incurring issues from tiptoeing around wanting all the benefits of an incorporated business with employees or at least contractors without the stigma(?) of getting all official and putting someone in the hot seat of responsibility. Off the top of my head:
- A business has some intrinsic motivation however minuscule to fix unsexy issues like security problems or problems that aren't as visible to customers so they don't get hacked and sued and go under; in a pay-what-you-want bounty scheme all of your users are playing chicken to not be the one to put up the money for the fix. Instead they'll wait until it becomes a problem and fix it in their own branch; no reason to bother upstreaming it until someone comes forward putting up the money.
- IMO there's no way to measure cuts for something like this that can't be gamed. If you close out the bountied issue, but you make use of a bunch of utility code I contributed last week, who gets it? Or if the code I contributed is mostly a mechanical refactor of some very complex code someone else wrote? Do we divvy it up by lines of code, number of commits, etc, and that's just for the squint-and-it's-qualifiable metrics for engineers. No idea how you'd measure a cut for project managers. Someone also may be the steward of the repository and handle administrative work but not do a whole lot of feature-fixing, what cut do they get? Instead of juggling KPIs you can just pay all these people for their common contribution - time - and then you're back at something that businesses do really well.
- For any bounty system to work you need somewhere to track the bounties and hold money in escrow for payouts. Those services exist, they cost money to run, and they are going to take a cut. I'd assume they'd also invest and grow that money while they have it unless that's illegal for some reason I'm not aware of. An incorporated business keeps its bounties in the issue tracker, and its money in an account that accumulates interest that can go toward further development on the actual product instead of third-party support services. Crypto is a no-go here because that limits your contributor pool to exclusively crypto perverts, otherwise normal people have to speculate on it and convert it to normal useful money for a fee.
- I've worked at a place where the devs got to work on whatever they wanted. Required to, really, because there was very little interest or hands-on management from the owner in the direction of the product as long as sales were stable. We had a great time and got paid and we all learned a lot on company time and last I checked they are no longer in business.
- Timelines are a big factor too. If some open-source software I'm using is missing a big feature I'd like (and if post-2024, it's too substantial to just make a copy and have Copilot customize it for my use) I'm still not going to kick in the first $10 in the hopes that somebody someday builds that feature for me. I'm going to be dead or not using the software by then. If I thought the feature I wanted was worth $10,000 and I had $10,000 to kick towards it in the hopes that somebody somewhere would decide to build it, I would instead hire somebody on contract terms to do the work with a greater guarantee of results and some recourse if they screw me.
Those normal users are better off instead purchasing software. Then they will be listened to by developers if they report a bug or suggest a feature. Because they represent an incredibly valuable user segment: paying customers.
One of the most used paid and proprietary software is windows, and its users do not matter at all to how it implements its features.
Users matter a ton to windows. Specifically, the users with a hundred thousand or more licenses. Their unhappiness threatens Windows' profits in a meaningful way. Why do you think all the new secure boot and TPM features were added to Windows 11? All that work wasn't free to implement. But big businesses really want that degree of secure fleet management, and they're the customers who matter.
So going back to the GP - pay for software where you're in the largest organized user class. That's how you get power. Paying alone doesn't suffice.
I genuinely doubt the users with a hundred thousand or more licenses asked for Copilot 365 Suite.
It's the easiest possible way for large entities to jump on the AI bandwagon. They're definitely asking for it.
Large entities asked Microsoft to stop simply bundling Copilot with all those services and instead relabel the services so that their usage could be counted as AI usage in their quarterly report whether or not they actually engage with the AI features?
I think it's clear the source comment was referencing end users. It's patently obvious at this point that a large number of people who directly use Windows are frustrated with it, and perceive it to be degrading rather than improving over time.
A corporate end user isn't a customer. The customer is the corporate department of purchases. What I mean in my original comment is that if you as an end user purchase software, then you will be listened to by developers.
Yours was not the source comment I was referring to.
Most users of Windows get it for somewhere between free and $150, the fact that there is still a home edition of Windows is practically a loss leader to keep the business side ingrained. Enterprise licensees are the ones with the money and Microsoft will dedicate full-time engineers to their features if they can afford it.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
Free Software sure, that wasn't the point.
Open Source, that was exactly the point. Eric S Raymond, one of the original promoters of the concept of Open Source coined Linus' Law:
Which definitely points in the direction of receiving bug reports and patches from users of the application. He was also a proponent of the Bazaar model, where software is developed in public, as opposed to the Cathedral model where software is only released in milestones (he used GCC and Emacs as examples, which reinforces the part of your statement about the Free Software movement in particular).ESR is also from a time where spamming countless reports/junk code wasn't really a concept.
They did have things like trolls and zealots that thought "Their one idea" was a gift from god and the maintainers were idiots for not adding it to the application. And eventually those people may have been banned from mailing lists. But in general the people posting code were typically well known and had some interest in fixing the application for some useful purpose.
Simply put, no idealism stands the test of time without change. Nature shows us that everything must evolve or it goes extinct. How 'free software' evolves is now up for debate.
Linus’ Law doesn’t really imply anything about maintainers behavior though. As an example, you can imagine maintainers that never update their repos. Every bug fix is a forking of the repo, and people only use the repo with the latest commits. Eventually, the bug count goes down as well!
ESR was from a time that was radically different than the the VSCode / brew / macOS / Ubuntu centric era we have today.
I don’t agree with this newer idea that has arisen that FOSS authors are “victims.”
It’s up to you to set boundaries (or prices) and communicate them, like an adult. If one is still rude and entitled then ban them from the repo, or let people fork, but not before looking in the mirror first and reflecting at your own behavior.
(I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.)
I think "we will ban and publicly shame you if you waste our time" is a very clear and adult boundary.
i remember my first time being a chanop on IRC.
It could be a childish overreaction. See this comment: https://news.ycombinator.com/item?id=46718635
As always it depends on the circumstances, but should default to quietly closing with WONTFIX. Others have said Daniel is typically helpful and respectful so there we go.
What you linked to is not really evidence, just an unsubstantiated allegation. Over the top public shaming is something that should be pretty easy to provide direct evidence of. When Linus Torvalds does it, it gets repeatedly brought up in forums like this for many years.
I have no reason to believe it is a lie, and it sounds plausible. A 'public shaming' should be a last resort is my assertion, and I stand by it.
> I have no reason to believe it is a lie, and it sounds plausible
Except for all of the responses from people saying it doesn't sound plausible for the project in question, and for the acute lack of real evidence or even details to accompany the allegation.
Additionally, I think "last resort" is way too high a bar. It's totally reasonable for an open source project to have a zero-tolerance policy for AI-generated spam patches or bug reports, and to respond with public shaming after the first offense. Nobody should be expected to make any allowance for such egregious behavior.
A user who is genuine but simply doesn't know how to usefully communicate about their problem doesn't deserve that treatment and should simply be ignored if the devs don't have time to engage in the interrogation necessary to extract a useful bug report. But if the user decides to try to use an LLM to compensate for a lack of content in their bug report, that user would be earning a negative response by making a bad decision. (If you're going to use an LLM, ask it how to write a bug report, rather than asking it to make up a bug report for you.)
The point is to deter further contributions of the same form, including from other users.
This is not the first time the curl project complains about bogus and excessive bug reports.
Afaict github allows you to disable 'Issues' per repo, yet few do. I presume that means they are okay engaging with issues on some level, but I find it odd almost none post a policy/expectations around them.
> I’m trying to imagine folks painting xfree86 maintainers as victims back in the day when xorg forked them for intransigence. The point is disagreements happen, deal with them.
... Did they try anything as petty as the xorg maintainers are nowadays?
How long does something have to be done a certain way for it to be "to do with"?
I would say we're now two generations deep of software engineers who came up with open source software commonly being mediated through public issue trackers.
That isn't to say it needs to stay that way, just that I think a lot of people do in fact associate public project tracking with open source software.
Thanks for making me feel old.
I'll just say that I once installed Emacs from a 9-track magtape that someone mailed to me.
> has nothing to do with open source
I partially disagree. It does have to do with open source: Github (et al) are about creating a community around an open source project. It's hard to get adoption without a community; it gives you valid bug reports, use cases you didn't think of, and patches.
You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
> and is not sustainable
I 100% agree. People (including people at for profit companies) are taking advantage of the communities that open source maintainers are trying to build and manipulating guilt and a sense of duty to get their way.
The most insidious burnout I see is in disorganized volunteer communities. A volunteer is praised for jumping in with both feet, pushes themselves really hard, is rewarded vocally and often and with more authority, and is often the one applying the most pressure to themselves. There's no supervisor to tell them to pace themselves. And when their view switches from idealistic to realistic and then falls into pessimistic, they view the environment through a toxic lens.
Then they vanish.
> You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
Literally you cannot, you can turn off "Issues", but you cannot turn of pull requests, Microsoft/GitHub forces you to leave that open for others to submit PRs to your repositories no matter what you want.
> You can, if you want, turn off PRs, issues, and literally any feedback from the outside world. But most people don't want that.
Just a note, you actually can't turn off PR's on Github repos. At least not permanently.
Yea, and before we got issue trackers quite commonly issues and code chunks were shared via email lists that quite commonly had online archives. Think things kind of like the LKML.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind.
From the beginning, GNU projects welcomed contributions, and discussions of bugs and features were in the public. Sure it was on mailing lists, not on Github, but it was more than just shipping sources with the binaries.
That isn't to say you have to accept third party pull requests and have an open bug tracker to be free software/open source. Sqlite is a famous example that doesn't follow that model.
I've also noticed this expectation. Where does it come from?
FOSS means that the code to be free and open-source, not the schedule or the direction of its developer(s).
I dunno, I think at one point there was a similar merge as to what happened with "git and "github" where "open source the licensing" somehow became the same as "open source the collaborative and open software development process", and nowadays people get kind of confused when you say you're doing open source yet you don't accept pull/merge requests.
I propose the FOOSSNO license, fuck off its open source, no obligation, for communication purposes. ;-)
Maybe WTFPL can send the message across? Could maybe make a V3 and add as a second point to it: "1. And don't tell me/ask me about it, just DO WHAT THE FUCK YOU WANT TO"
> the default expectation that authors will be promptly responding to new GitHub issues, bug reports and provide patches for free is insane.
I think there are many insane expectations out there, open source or not, so I don't personally see it that linked with the idea/ideal of open source.
> This is software support, it is a job, it should be paid.
Anything can be paid, nobody says otherwise. Some people prefer nobody pays for their source code (open source). Other people do support for free. And so on.
> The currently default model of having ... has nothing to do with open source and is not sustainable.
There were always arguments why open source will not be sustainable, many having some truth in them. But the current issue can be probably solved with some push-back on the speed of things or how attribution works. Something similar used to happen on some forums: you can't post a new thread for one month if you did not reply at least once without getting down-voted. For the current problem : if contributions are anonymous for the first 3 years of you contributing (if you are not banned) and your name becomes public only after, then all this "noise" for "advertisement" will die. Doubt this will discourage any well intentioned contributor.
> This is software support, it is a job, it should be paid.
What's stopping any open source maintainer from charging for their work?
Irrelevance. The moment you paywall a project, it’s a death sentence. Unless you have a unique and highly sought-after product (top 1%), someone else will just make a free alternative.
Well yes, but that accomplishes the goal of not working for free. Either you get money for your work, or your users move on, freeing you of the burden of supporting the software.
Some projects were successful at charging for custom work and special support — sqlite for instance.
Exactly, that's an example of a top 1% project. It even has a detailed Wikipedia article in 35 languages. That model won't fly with small to medium-sized, regular projects.
If you have just thrown the code out there, in case someone can use it, then who cares? If it's not something you intend to spend more time on, what difference does it make?
I thought about this a lot recently and decided that the small, mostly complete, project I work on now, if I release it (I probably will), I will just post an archive somewhere with the source code, like in old days.
What about posting it read only on Github so folks can download and fork it but not bother you with inbound requests (discussions, PR, issues)?
I kind of do that already with my most recent project, developing it in my local fossil repo and each release I have a script that copies it to a local git-repo, tags it, and pushes it to GitHub. So the GitHub history just has a series of release commits.
But the project is still open for issues and PRs. Can only be disabled on paid accounts, right? Never had anyone try yet. I had feedback through other channels, just not on GitHub, so maybe explicitly keeping all development offline has had the intended effect? I get a trickle of issues and PRs for my other repos where development is out in the open with every commit pushed to GitHub.
But if it was discovered by drive-by LLM contributors I would still have annoying extra work, for no obvious benefit compared to just sharing archives. I do not think anyone (out of at least dozens) discovering any of my repos do that on GitHub, but from seeing my posts elsewhere.
It's not like no one can fork a source code archive, even if it is like 3-4 git-commands to run instead of just a button to click.
Totally agree. The expectations around what an OSS project should - or even must - have, do, and accommodate is absolutely insane. It boggles my mind sometimes as someone who grew up on OSS. I still contribute OSS and maintain some (small) projects, but I certainly don't feel compelled to support people. I often license MIT. People are grown ups, they can go fix their own issues.
I fully agree. The psychological burden is also high, what makes the maintainer feel miserable over time.
You mischaracterize the problem. You write like the problem would be corporate freeloaders forcing bug fixes on the open source.
Huge problem for successful OSS projects is like what we have for cURL right here - newbies trying to "earn badge of honor" for scoring CVE on high profile project. The variation of it is newbies trying to score OSS contribution on high profile project (hacktoberfest).
In the end all of it is propping own CV to land a software engineering job or cybersecurity job by wannabes.
As much as I don't want to do gatekeeping and especially "old" Linus Torvalds way of gatekeeping — cURL, Linux Kernel and many high profile projects require gatekeeping to go on forward. We didn't even start on the security side of things not to allow "shady contributors".
I hate "CV proppers", "OSS as great marketing tool", "corporate freeloaders", "APT threat actors using OSS as attack vector" because they break nice things that we could have.
> To create Free software, you ship sources together with your binaries and one of the OSI-approved licenses, that is all.
Untrue. Shopping source with _some_ OSI-approved licenses makes the work Free software. Shipping it with others merely makes it open source software.
Technically correct, but not an issue in practice. If you want a licence that's approved by the OSI but not the FSF, or vice versa, you have to go looking for it. If memory serves there are no licences in the latter category, and the few in the former category are very obscure.
> I doubt it is something that the founding fathers of Free Software/Open Source had in mind
Who cares? That was 30 years ago. How different were computers, programming, and the world back then?
Things change over time. The world is not immutable.
The original model works, the new model significantly fails. LLMs have taken many cases that were on the border over the line into failure, by changing the resource management tradeoffs. (Both by giving valuable contributors a cheap way to get 'extra eyes' on their own terms, and by empowering a new generation of trisectors and trolls to flood out even the most efficient public submission pipelines).
> This is software support, it is a job, it should be paid.
It is paid, even if not in money. It seems like maybe you lack awareness of the other forms of capital and reward that exist, because your framing implicitly insists that financial capital is the only form of capital and that monetary reward is the only form of reward. But there are also a bunch of other forms of capital, like social, cultural, symbolic, etc. which you have missed, and there are non-capital (non-convertible) forms of reward, like feeling good about something. It's the entire reason why permissive licenses still preserve attribution.
To wit, people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things. There are both intrinsic and extrinsic non-monetary gains here.
Stallman makes the same critical error in his foundational writings, so at least you're not alone in this.
(A foundational read on the subject of the different forms of capital is Pierre Bourdieu's The Forms of Capital: https://www.scribd.com/document/859144970/P-Bourdieu-the-For...)
(See also: https://en.wikipedia.org/wiki/Motivation#Intrinsic_and_extri...)
>people maintain things literally all the time either purely for prestige, or because being a contributing member of a community, even a small one, makes them feel good, or because knowing that maintaining things leads others to also maintain things.
True, but the expectation means that taking on maintenance involves taking on and leveraging a large amount of reputational debt in a very risky way.
If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
It is incontrovertible that the entirety of the open source / free software world exists, in a very fundamental way, because people experience personal reward by doing work that they give away for zero dollars.
The existence of risk does not eliminate the existence of reward. It's called "expected value", and it's non-zero, and it's for the person to manage for themself like everything else in life. Working for equity also involves risk, and nobody says that it's not compensation.
> If you release something to the world and place yourself in a high-visibility maintainer position, burn out on it and then decide to drop it, it's very hard to ensure that your legacy and reputation in perpetuity will be "released something great and did the world a solid by maintaining it for a while" as opposed to "person who overcommits, bails, and leaves the world in a jam".
This is like saying you suffer reputational damage by retiring from a career. The claim is clearly absurd. It's not hard to step down from leading a project in a way that preserves reputation in the same way that it's not hard to leave a company without burning bridges. Some people are bad at being people and fail at both.
My point is that the OP doesn't >lack awareness of other forms of capital, they're asserting that those aren't sufficient on their own, and that one of the reasons for that is the risk that stems from stepping down being something that you can fail at in the first place, with the consequences of cementing a reputation of "being bad at being a person" regardless of anything that's happened to that point. You don't have the opportunity of accumulating reputation without having that risk at the end, unlike a career, where you have the opportunity of taking a job that pays a regular paycheck regardless of whether you leave at the drop of a hat and burn all your bridges by doing so.
> My point is that the OP doesn't >lack awareness of other forms of capital, they're asserting that those aren't sufficient on their own
OP said "it should be paid" because "it is a job", and so the rejection of that claim is two-fold: 1) Uncertainty in the expected value of payment does not change the fact that it's payment, 2) Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
OP's specific written framing, that because it's a job it needs to be paid, which is only additive commentary if OP believes that it isn't being paid, disagrees with your prediction about what OP really secretly bases their statement on.
We can look further back in OP's comment as well:
> The movement grew out of frustration that commercial software cannot be freely improved and fixed by the user
This is only fractionally true, and it is only true in an unpaid way for a desire to consume free software. It is not true in an unpaid way for the desires to produce or maintain free software. Those are done because the producers and maintainers experience some kind of reward from doing so.
> Payment in units other than dollars is still payment. If I get paid in bitcoins, the bitcoin market could completely collapse before I cash out. It's not different than that.
I can't pay my rent or my server bills in "prestige". Entirely different.
I can't pay my rent or server bills in "bitcoins". I need to leverage my bitcoins in some way to get "dollars" that I can then pay my bills with. Non-monetary payment is still payment. Rare pokémon cards are payment too.
Also, in fact, people get things that otherwise cost money all the time based on prestige.
You absolutely can, because you can sell the bitcoins and turn them directly into money in your savings account. There are exchanges that declare their exact value. You can't do that with prestige. There's no exchange and no market.
Crucially, money, bitcoin, and pokemon cards are all transferrable. You can't transfer prestige to someone else, so it has no value in financial transactions.
Transference doesn't matter, because exchange is not a requirement for gain. People get things merely from having prestige/influence/power all the time. It's sometimes called an award, and sometimes called tribute, and sometimes called currying favor.
> you can sell the bitcoins
Prestige is influence, and you can absolutely sell the use or effects of influence.
> There are exchanges that declare their exact value.
Payment does not need to have exact value, just non-zero expected value, which prestige definitely has. There is no exact value to startup equity either, but it's still rightly considered to be compensation for investment of labor and money.
It's been known in creative fields - including software - forever that payment in "influence" is worthless.
It's been a meme for decades.
http://www.fyoupay.me/
I've been helping a bit with OWASP documentation lately and there's been a surge of Indian students eagerly opening nonsensical issues and PRs and all of the communication and code is clearly 100% LLMs. They'll even talk back and forth with each other. It's a huge headache for the maintainers.
I suggested following what Ghostty does where everything starts as discussions - only maintainers create issues, and PRs can only come from issues. It seems like this would deter these sorts of lazy efforts.
> Indian students
Is this cultural? I ran a small business some years ago (later failed) and was paying for contract work to various people. At the I perceived the pattern that Indian contractors would never ever ask for clarifications, would never say they didn't know something, would never say they didn't understand something, etc. Instead they just ran with whatever they happened to have in their mind, until I called them out. And if they did something poorly and I didn't call them out they'd never do back as far as I can tell and wonder "did I get it right? Could I have done better?". I don't get this attitude - at my day job I sometimes "run with it" but I periodically check with my manager to make sure "hey this is what you wanted right?". There's little downside to this.
Your comment reminded me of my experience, in the sense that they're both a sort of "fake it till you make it".
Indian here (~15+ years in tech). I've seen this behavior a lot, and unfortunately, I did some of this myself earlier in my career.
Based on my own experience, here are a few reasons (could be a lot more):
1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
2. Our education system mainly rewards results, not how good or well-thought-out the results are. Sure, better answers get more marks, but the gap between "okay" and "excellent" is usually not emphasized much. This comes from scale problems (huge number of students), very low median income (~$2400/year), and poorly trained teachers, especially outside big cities. Many teachers themselves memorize answers and expect matching output from students. This is slowly improving, but the damage is already there.
3. Pay in India is still severely (serioualy low, with 12-14+ hour work days, even more than 996 culture of China) low for most people, and the job market is extremely competitive. For many students and juniors, having a long list of "projects", PRs, or known names on their resume most often the only way to stand out. Quantity often wins over quality. With LLMs, this problem just got amplified.
Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
> 1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
Way back, when I first started working with Indian offshore teams, the contracting company at the time had a kind of intercultural training that addressed that issue.
> Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
That's exactly the advice they gave. They advised was to try to make your relationships and interactions as peer-like as possible. The more "authority" is present in the relationship, the more communication breaks down in the way you describe.
To what degree did this change the results?
I've seen an interesting behavior in India. If I ask someone on the street for directions, they will always give me an answer, even if they don't know. If they don't know, they'll make something up.
This was strange. I asked a lot of Indian people about it and they said that it has to do with "saving face". Saying "I don't know" is a disgraceful thing. So if someone does not know the answer, they make something up instead.
Have you seen this?
This behavior appears in software projects as well. It's difficult to work like this.
No, but I have noticed that somehow it's hard for them to say "no". This is impolite apparently. So you ask: "Can you do this before friday" and they say yes and then don't do it at all. Which of course is a lot less polite and causes a lot of friction.
However this was a thing 10-15 years ago. Lately I've not seen that.
> Which of course is a lot less polite and causes a lot of friction.
Most cultures have this, but it goes mostly unnoticed from the inside because one can read between the lines. "How are you?" can be asked just to be polite, and can cause friction when answered truthfully (rather than just politely, as the cultural dance requires). An Eastern European may not appreciate the insincerity of such a question.
Great example.
I work in a radiology practice and greet patients regularly.
99% of them say the are good/great etc.
It’s quite a striking response when they are limping, bandaged and on crutches.
I sometimes answer “each day better then the next”, no one seems to notice.
I use "about the same", thanks to a friend. I love the reactions (from Americans, where everyone is expected is to say "Great" or "Good" or something similarly positive).
That's good as well.
I think I actually gave my line in a 1:1 to my manager at a job, they did not pick up on it. I was gone not long after.
I’ve always interpreted that question to mean emotionally. Yes, clearly I’m physically injured, but I still have a positive outlook.
When I do hear people respond in the negative it tends to be an opening up about stress.
Is that just a reflex response though? I would expect people to be more deliberate in their interactions with medical professionals, but I can easily imagine hearing “How are you?” and my brain goes on autopilot.
Yeah, this is something I had to learn over my teenage/early 20s years. "How are you?" Is often not a question but just a generic greeting like "Hello" or "Nice to meet you". Sometimes it is though, but that's just one of the many examples of unwritten rules about how to tell whether someone literally means what they're saying or if there's a better way to interpret it.
Having only lived in the US, I don't have nearly enough firsthand experience with other cultures for me to be the one to comment on them, but I suspect that every culture has some things like this where the actual intent of the communication isn't direct. I suspect that if people in tech were asked to identify which cultures they considered to be the most direct in their communication, American culture probably wouldn't be ranked first. Generally the stereotypes of other cultures that are perceived as more direct get described in more pejorative terms like "blunt" though.
The greeting is generally in the waiting room. I’d do exactly the same if I was them.
These days I do a 'eh' and shrug when someone asks a random 'how are you'?
That’s not really an example of cultural lying- that’s an example of a fixed answer to a fixed question.
When somebody sneezes and you say “bless you” you’re not expressing your belief in god, and you’re not lying about one either.
> that’s an example of a fixed answer to a fixed question.
That's my whole point! The expected answer seems pretty obvious to you, given the context, doesn't it? Why then are you surprised that a different culture has an equally obvious (to them) fixed answer ("Yes") to any question asked by someone with power/authority to their lesser? Both depend on mutual learned cultural awareness, and can fail spectacularly in cross-cultural contexts.
Edit: my regional favorite is "We should meet for lunch some time" which just means "I'm heading out now", but you have to decode the meaning from the nature of the relationship, passive voice usage, and the lack of temporal specificity.
They're called phatic expressions.
At the yearly colonoscopy I say "you can tell me after how I am".
similarly, in the west, when your boss takes you to HR for an honest and open discussion, it's not really an honest and open discussion. normies know this instinctively. I didn't.
No, most cultures don’t have this, unless you measure by biomass.
Some cultures are better than others, where “better” might mean better at doing stuff (no comment on morally/socially)
A fairly common conversation starter for eastern europeans is "how are you doing?", "it sucks", "yeah it does, doesn't it?". The American style of being all flowers and butterflies can indeed be perceived as lying.
To be fair we Americans also poke fun at this. Here in the South I usually say, “Can’t complain,” and most people will finish the adage, “and it wouldn’t do any good if you did.”
It is fine if it is not lying but so often you ask how are you and get the flowers and butterflies response but when you sit 10 min more they start explaining how miserable they are: as a Dutchman, I do tend to ask why they said how great and excellent they were just minutes ago. And no, it is not just something you do out of politeness: if you just canned response to one thing, how do I know you don't have canned responses to many more things which are in fact lies at this point in time? I don't want to talk with Zendesk, I want to chat with someone I just met in the pub.
It isn’t lying, it is what we consider an appropriate level of sharing. We don’t tend to want to put our burdens on people who may not be interested in hearing it.
My experience is the same, to put it charitable a lot of people from that culture are often eager to please. I think about this a lot when I hear about billionaires like Elon Musk wanting more immigration from India specifically. I think this cultural trait often serves them well in western corporate contexts, despite the frustration it causes their coworkers.
> I've seen an interesting behavior in India. If I ask someone on the street for directions, they will always give me an answer, even if they don't know. If they don't know, they'll make something up.
Isn’t this the precise failure pattern that everybody shits on LLMs for?
Only on surface. The difference is the LLM doesn't know it doesn't know. An LLM provides the best solition it has regardless of whether that solution is in any way fit for purpose.
If you inspect the Chain of Thought summaries, the LLM often knows full well what it is doing.
That's not knowing. That's just parotting in smaller chunks.
Yes.
Hence proved
AGI = A Guy/Gal in India
Ah so that's what Anthropic's Amodei meant when saying AGI was attained - they actually reached that guy/gal.
Perhaps they meant detained.
Hopefully, retained. But, a tained for sure.
This is really funny.
--
Almost like…technology embeds the latent behaviors of the data that produced it!
Imagine that
Someone should really write a paper on that (hint: it’s the entire basis of information theory)
It's the same in the UK (when it comes to giving directions). Maybe for completely different reasons. I guess they just want to be nice and helpful.
And always with a cheerful: "...you can't miss it."
Yeah, sure.
I’ve seen this with some of my Indian colleagues, though definitely not all. In fact, most are more than eager to disagree with me :D (even though I’m their superior)
> In fact, most are more than eager to disagree with me :D (even though I’m their superior)
They must have spent a lot of time out of India or they are in senior roles.
> This behavior appears in software projects as well. It's difficult to work like this.
I have seen that across just about every culture in the software engineering world.
And not just in the 'business' itself. I still remember the argument I had with an Infosec guy where he absolutely insisted that every Jeep had AWD or 4WD from the factory, Even naming ones that didn't did nothing until I more or less passively aggressively sent him wikipedia links to a few vehicles.
At which point he proceeded to claim "No I said it was always a standard option" ... To be clear this whole argument started because someone asked why I swore by Subarus and mentioned 'Every US Model but the BRZ has AWD standard' but Heep owners gotta have false pride, idk.
People do weird shit with imposter syndrome sometimes, IDK.
> This was strange. I asked a lot of Indian people about it and they said that it has to do with "saving face". Saying "I don't know" is a disgraceful thing.
I've recently learned that this particular type of "saving face" has a name: "izzat". Look that up if you want to know more.
A lot of the stuff written on "izzat" is questionable or wrong, but it is true that India has a collective concept of saving face. This can be an adjustment even if you're used to the East Asian concept of saving face.
Oh I wonder how dating works.
... normally? they don't have the same "30% of adults will never marry because of arbitrary bullshit" that modern/western countries have.
First I've heard of izzat...
I'm not sure how to write that better, but the way you worded that made me suspect it was NSFW and I hesitated, but eventually decided I'd risk it. At least everything I found was work safe, and I learned a lot. I encourage everyone else who hasn't heard the word to look it up.
sounds like an LLM :)
According to Hal Roach, the Irish do this too, because they don't want to disappoint you. I haven't asked for a lot of directions in Ireland, but I can imagine this is true, or that they will just keep you chatting and see if you forget about your question.
So it's like an LLM?
Every time I hear any Indian trope, I find it interesting that it's only people in online forum who experience it.
Somehow none of my non/Indian colleagues over the course of more than a decade have faced these ridiculous situations. They must be unlucky.
Many wouldn't be comfortable discussing this with coworkers.
I got this so often in every part of the United States that some decades ago I just stopped asking anyone for directions.
Strange. Never had it happen regularly in the US.
I've never once experienced this nor literally ever heard anyone say someone gave them made-up directions in the US.
The only time I've ever experienced made-up directions were trying to get out of the souk in Marrakech.
> I've never once experienced this nor literally ever heard anyone say someone gave them made-up directions in the US.
Wouldn’t know. After the first two instructions I can never remember what came next.
I was unclear. I’m pretty sure the wrong directions I routinely got in the US (I was born and raised in NYC) were not made up, just wrong.
This reminds me of the time when I got lost when visiting LA about 20 year ago. Asked some guy on the street for help. He gave me directions as he was smirking at me. Turns out he pointed me in the opposite direction from where I was going to and most likely he was just being a dick.
> 1. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
Having worked in Japan, while there is a strong respect for authority, there's also much less hesitation about asking for clarification. I worked with an Indian offshore team and in a Japanese company and, while there's a lot to dislike in Japanese office culture, this kind of pattern of behaviour doesn't happen.
2 & 3 do make sense though.
I've had mixed result with your advice at the end. I'd say that it worked for about 30% of the offshore engineers I've worked with and indeed I had more success with juniors than with more senior developers.
I also worked with japanese, including on site in Tokyo and quickly learned that asking "did you understand it?" is useless. I always had to keep in mind to ask "what did you understand?".
I worked with a lot of Israelis and Eastern Europeans - They's say no and argue even when they agreed :) it was fine.
> Pay in India is still severely (seriously low, with 12-14+ hour workdays, even more than the 996 culture of China) low for most people.
My employer outsources some work to Indian contractors. I know how much we are paying the contracting firm, which is low. Knowing the firm takes a cut before the contractors are paid, I feel terrible for how little they are compensated. I frequently wonder if we’d get better output if we paid more.
Avoid middlemen in India.. sorry for the word, but they are the biggest leechers. We hate them too here.
India is filled with small one-room service-based companies(the middlemens') that hire interns, for ZERO pay, make them work 12-14 hour days under extremely "humiliating" conditions and then when it comes to giving them internship completion certificate, they demand huge sums of money just to release them... think about it.
As for how you are gonna do without the middlemen, I dont have the anwer yet... ideas are welcome.
The good engineers in india know their value and get it. My company has offices in india because you have to manage them yourself not use middlemen. You can train the locals to be great managers (at least some).
wages for good people in india are worse similar people in the us, but often high than in europe. But there are other problems with europe and so it can be the better deal.
Responding to you in this thread, because this is the way: the only success I've seen to offshoing to india, is to actually run the office yourself, have an exec over there, manage and control hiring, pay above market rates, etc...
I've been with two companies that have been aquired, and the first thing the PE/New Companies do is aggressive offshoring for cutting costs.
1) worked, because the aquiring company had an established office in Hyderabad, and we flew the tech leads over to the US to spend six weeks embeddeed with the team, etc.
2) the second one failed miserably becasue we had an Exec VP who told our engineers that he was replacing them in India for half the price, and his strategy was to hire a contracting company.... after several months of "contractors" coming and going, someone else in the company realized what needed to happen....
> The good engineers in india know their value and get it.
The job market is not that efficient anywhere, especially India. Lots of people work their way up from crappy jobs to good ones, just like in the US.
>My company has offices in india because you have to manage them yourself not use middlemen. You can train the locals to be great managers (at least some).
"some members of this primitive tribe can be taught our sophisticated ways"
The issue with middlemen is they are basically labor arbitrageurs and have an incentive to hire the cheapest people possible and inflate their credentials/abilities. Same thing happens with onshore consulting firms.
>wages for good people in india are worse similar people in the us, but often high than in europe.
"Often higher than Europe" is a stretch. Typical big co with an India office pays maybe 20-30k USD per year for an engineer. And that is a good job relatively speaking. Top tech companies pay more but they also pay more in Europe
Could you expand on the other problems with Europe other than hiring and firing laws?
Senior/staff type engineers are not a union position so great people refuse promotions and responsibility because they don't want to leave the union. Thus they won't mentor juniors, and other things that you need great engineers for. (At least that is how the union people I work with in Europe are, there are other unions with different rules)
There is probably more.
Like siblings comments, I would be really interested to know to which country and union you are referring to. In France it's certainly not true (I have a very senior engineering role and I am in a union and it never was an issue, and anyway, the percentage of unionized engineers here is so low that even if that was true, it would hardly be noticeable)
Which country is that in? Can you not offer them better conditions than the union? Are they forced to leave the union or just no longer required to be in it?
Never heard of that, and I've worked in about 7 EU countries...
Never heard of that, nor of a union in tech. What part of Europe?
What union ? In which country ?
Don't apologize for saying "leech", man. That's part of the problem.
Yes, you would (speaking from experience)
I worked for a company that created an Indian subsidiary to cut out the middlemen. The results were the same.
> Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
Semi related to this, one of the biggest 'breakthroughs' in building the right trust/rapport with an offshore team was sending an email to their leadership making it clear and on the record that "Comments against pull requests should not be used against the employee in reviews, if there is a recurring issue I will discuss it via other channels."
That one email changed PR back-and-forth entirely, cause yeah I guess sometimes they'd get dinged for too many PR comments on some metric. At first their management wasn't thrilled, thankfully there was a good enough improvement in quality and defect rate that in a couple months they were won over.
I missed adding this to the advice section. But glad you pointed it out and shared your positive experience with it. Thanks..
Do you mean that they were dinged if a PR they opened received too many comments? Can you elaborate on how the communication style changed after this? Like they were more willing to seek clarification/discussion?
> Can you elaborate on how the communication style changed after this? Like they were more willing to seek clarification/discussion?
More willing to seek clarification and less likely to try to defend choices with 'This is what the scope of work said'. And also more willing to jump in on colleagues and my own PRs to provide feedback.
Which was also an important part of how to frame the communication "I'm not telling them they are doing their jobs wrong, I am telling them how to do it better to make all the stakeholders happier."
> Do you mean that they were dinged if a PR they opened received too many comments?
It was never explicitly said at first, however the communication was inspired by past work experiences where yes, too many comments on a PR or similar review could get held against you for far longer than was productive or even healthy, and yes it was something the whole team had to deal with (i.e. very much a shared experience amongst colleagues.)
In fact I'd argue that the time I've been at shops where people weren't afraid to give feedback has been about 50-50, while also noting that the shops that had a culture shift where giving feedback became OK and safe for all parties, quickly became more productive.
Cause, the other thing to consider, is that people don't necessarily want to risk causing animosity by jumping into a colleague's PR and pointing out a problem, they don't want to be the guy that makes their colleague "look bad". Which is of course unhealthy, but again by re-framing the context of PR feedback for Taylorist robot management, you get better response from their management as far as buy in.
> Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
Very true. I’ve hired (super cheap) engineering talent and this is the key to getting a project to run the way a westerner expects; where everyone is constantly open to challenging each other, where everyone can bring ideas to the table, and where there’s no such thing as a stupid question. I’ve done this during a big phase of time others locally shunning this huge talent pool as the results were crappy/unpredictable. Even to the point they’ll hire local for 100x the cost. It’s just a management problem though and a pretty simple one at that. The other thing is if you train them in your style, keep using them on the next project if you can. It compounds if you have the ability to work with them over a longer time. You have to be very insistent that you’re not proposing the best solution at expect them as engineers to point out any opportunities for improvement. If something later has to be rebuilt or isn’t working well, sometimes it’s good (if it makes sense, case by case) to do a post mortem and understand why the version 2 wasn’t built during the version 1. I think that helps them really understand it in a concrete way if they’re struggling with it.
In any case, I’d much rather take a budget for 1 local dev and spend it on a whole team of Indians and take on the management burden if it means retaining more equity or profits or building something I otherwise wouldn’t do myself due to scale.
Particular topic (1) is also trained in cross cultural trainings.
Another topic is: do not expect a remote dev to pickup ambient knowledge, particular if they are juniors with no life experience. And since outsourcing to India is trying to get the resources for the lowest possible price, the result is: you get them as junior / fake senior / bad senior as you think. Pay better in India, get better people.
How do you stop the better people from moving out of India (and/or to another firm) once they have your work exp on their resume?
Q: How do you stop anyone from moving to a better company or better-paying role?
A: You don't. Unless there isn't a better company or better-paying role.
If a person is motivated to move out of the country altogether it's got nothing to do with you and there's nothing you can do.
With higher salaries (is happening) and better quality of life (I do not know, do not life there). Within company obviously quality of the culture matters there.
However considering how things are worldwide right now, I think that trend stops soonish.
As a gent with some years under his belt, I have to humbly admit that it was quite late in my career before I realized how much culture influences how people operate. Two separate incidents with two different cultural contexts brought it to the fore about ten years ago. I sought some advice from a senior exec that I was close with and he just laid it out in very unflinching way. It was just one conversation but it has helped me tremendously in the years since.
Any chance you could expand that story?
I thought about it when I posted but it felt like an invitation to dunk on the cultures involved. In one case it was a communication pattern that I found to be very unprofessional by an entire team, the other was nearly instant and *intense* conflict between a former direct of mine and their new manager that I got sucked into the middle of.
If you are interested in this cultural topic and how to practically modify your communication, check The Culture Map book.
This is extremely valuable insight for me, a non-Indian manager.
Thanks a lot!
Glad it was of help :)
Alternatively you could hire people from cultures where this crap doesn’t fly.
But that might cost more money! Trust me they'll be able to continue the work while you sleep!
> 1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
I was a manager at Deloitte in their tech consulting practice. I led fairly large teams of devs based in India. This is very true, and it takes a lot of time and trust-building to overcome. Making Indian devs, especially early-career ones, comfortable enough to oppose something or offer feedback is non-trivial, and often Indian engineering managers make it more difficult. Overcoming cultural hierarchy is hard.
This is one reason, the other is just fraud. Being from a developing country, I am well aware of the stigma of saying I don't know, which I had to strip out of me as I became an engineer to the point of me being immediately suspicious when someone tells me they know about some moldy complex topic, even if it's in their profession.
The fraud part is that I developing countries, almost all activities that require some skill have lots of people claiming to be experts. 99% of them are lying. You take your car to a shop and they tell you they will solve your problem. With skepticism, (because they asked no clarifying questions) you try to give them some context and they tell you not to worry.
1 day later they tell you parts X, Y and Z need to be replaced, it will just cost $$$. You ask if there is no way the current parts can just be repaired, and they tell you no, they must be replaced.
You ask what was the actual issue, and they tell you the parts are completely damaged, or worn out, need to replace.
Sure, you pay, and they give you the car, works for a few days, maybe week, then breaks down. You plug in a portable OBD scanner and it tells you the exact component they just put in is failing (likely not even compatible with the car).
You give them back the car, tell them since you paid $$$, you will only take the car back once it works perfectly, and you won't pay a cent more.
They then spend the next few days looking for an actual expert, that comes in and repairs the original parts, for $, and they take the "new" ones back to the store and give you your money back.
They don't know anything about cars, they experiment on yours, with your money, by swapping parts. This was easier when cars were less strict with parts.
This is fraud, not face saving, and it's in every developing country.
You’re not allowed to admit it’s fraud. It’s just a cultural difference. You explained it wrong. You didn’t pay enough. You were supposed to try to become their best friend first. Anything not to say “well some cultures just have no problem committing fraud at any opportunity”
Perfectly put. Scamming is a cottage industry. No ethics whatsoever.
What I do is I go to the top guy, tell him I need an expert and nothing else. No experimentation whatsoever on my vehicle etc. I pay slightly extra for the troubles. Before I go for repairs I try to learn as much as possible to know what they will screw up next. If you go in as a layman, then it is fraud and incompetence central all the way.
> Advice: If you want better results from Indian engineers(or designers or anyone else really), especially juniors (speaking as of now, things might change in near future), try to reduce the "authority" gap early on. Make it clear you are approachable and that asking questions is expected. For the first few weeks, work closely with them in the style you want them to follow.. they usually adapt very fast once they feel safe to do so.
I've found that this is also true of American engineers, particularly those fresh out of college. So many people have internalized that open curiosity will yield no result at best and direct punishment at worst.
> 996 culture.
I hadn’t heard of this, thanks.
Working 9am to 9pm, 6 days a week.
https://en.wikipedia.org/wiki/996_working_hour_system
Work cultures are brutal in SEA and South Asia countries. And there is no job security, no social security, no labour laws(on paper they are, but, are not applied) and no liveable pay(this is changing though).
Thanks for all this, what you wrote and the discussion that followed has been genuinely helpful, and I think it might help bridge some cultural divides that I've experienced when working with Indian people.
Another question I'd like to ask of you is, do you see any aspects of the western style of cooperation that are the inverse? i.e. which create divides in which the westerner's ways of working can be the source of conflict?
1. Same here. I too learnt a lot more from the following discussions.
2. None. We absolutely adore the ways westerners work. Your ethics, discipline, hardwork, attention to detail, inventive and creative nature, the support structures, and fair pay (and many more).
Thank you for this cultural explanation - I've experienced the same thing with Japanese co-workers - there is often a "no" but to American ears its so subtle that it often goes in one ear and out the other.
Both the cultures suffer from "a senior is always right" mentality. Therefore, with my juniors, I used to intentionally (sometimes, and mostly during early days of their joinings) make stupid little mistakes (harmless) and used to let those folks figure that out and then appreciate them on catching it. Worked like wonder. Never ever anyone hesitated to discuss anything with me anytime.. even personal issues many times :)
You just have to make it easy for others to do their jobs. Removing barriers, of any kind, helps. This is even more true with juniors.
In my experience working with developers from India, there are two ways:
1. You have no authority and they ignore you. 2. You have authority and they become yes-men.
Real dialogue: - Is it done? - Yes! But not yet.
The sweet spot is being authoritative without being overbearing. When leadership feels supportive rather than controlling, people engage honestly... and that balance comes from experience.
Could this cultural difference explain why they're set up LLMs to do work for them, though? No authority asked them to, but I guess it would look nice in their resume if successful.
Two broad reasons (as far as I can think of):
1. A lot more can be done in a given amount of time. Looks good on resume. Recall that India is still extremely poor (dont get influenced by the GDP numbers.. ) and getting a job as fast as you can after college can make a real difference to your living standards here.
2. Our education system is shit. And so are our teachers(mostly). Meaning, when folks are out of college, they generally are not as competitive as maybe their counterparts from western regions are(not in terms of hardwork, but, knowledge and hands-on tasks). LLM's makes it possible to do complete much more complex work than otherwise was possible at current experience.
Indians are extremely hard-working. The problem is people are extremely poor (~2400 median income... that's per YEAR). Even after adjusting for PPP. this translates to less than 10K USD/YEAR. Now think about living on 10K/year and supporting 5 family members (partner with 4 kids, or parents with 2 siblings).
my managers are indian, and honestly Im struggling. Do you have any advice? I feel like im not allowed to ask questions, a lot of our processes dont make sense to me.
Not the advice Im proud to give (or anyone should give), but the one that will work: Create dependency on yourself, company-wide, and make sure the boss knows about it. Avoid direct confrontation with your manager.
> 1. Unlike most developed countries, in India (and many other develping countries), people in authority are expected to be respected unconditinally(almost). Questioning a manager, teacher, or senior is often seen as disrespect or incompetence. So, instead of asking for clarification, many people just "do something" and hope it is acceptable. You can think of this as a lighter version of Japanese office culture, but not limited to office... it's kind of everywhere in society.
Damn me, Scotland is going to be quite the culture shock for you.
Since we are talking about LLMs, what I've noticed about the Indian/Pakistani "LLM" is they follow this way of structuring thoughts:
1. They
2. Always
3. List
4. Things
... and end up with a conclusion/punchline/takeaway.
I always wanted to ask, is that due to training?
I could imagine all schools around there have a specific style, like all their assignments need to follow this general form, and then they just get used to it and it permeates to their everyday life.
It's due to training (I suspect both OpenAI/Microsoft and Google have been training on their entire corpus of internal comms and technical docs). After almost 10 years in a FAANG I also tend to write like that.
That's how all LLMs structure content, not just Indian/Pakistani LLMs.
I bet you haven't seriously communicated with others in a language that is not native to you. You'll probably end up doing similar things if you have to.
I am doing that right now.
Well, imagine that you noticed 3 things instead of only one.
1. The first thing
2. The second thing
3. The last thing
Makes perfect sense in that case.
An Indian person basically is used to not making any decisions for themselves until maybe they're married off (and even then, probably not until age 40). /s
This sounds like a real cross-cultural mismatch, but it’s doing too much work with nationality alone. In a lot of Indian (and broader South Asian) work contexts, questioning instructions can be read as challenging authority or admitting incompetence, so people default to executing without asking. That’s often reinforced by education systems and contractor dynamics where producing something quickly feels safer than pausing to clarify.
Add in time zones, language friction, and fear of losing work, and "just run with it" becomes a rational strategy. Meanwhile, many Western workplaces treat clarification and check-ins as professionalism, so the behavior reads as strange or careless.
The key point is that this usually isn’t lack of curiosity or reflection, but risk management under different norms. The pattern often disappears once expectations are explicit: ask questions, check back, iteration is expected.
Yeah, I agree, the time zones are killer, and this can't be ignored. I work at a company spread over most of the world, with SMEs coming and going as the globe spins.
Back-and-forth iteration and consultation is a genuinely hard problem. Certain kinds of feedback cycles have a minimum latency of "overnight". Which means we need to invest heavily in good communication.
But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.
A lot of the international teams I've seen pull this off are ones where an Eastern European or Indian team is just another permanent part of the company, with broad-based professional expertise. Contractors on any continent are a whole different story.
So I think what a lot of people try to blame on Indian management culture (or whatever) really is just a case of "we hired contractors in a different time zone." I mean, there are always cultural issues—Linus Torvalds came from a famously direct management culture, and many US managers tend to present criticism as a not-so-subtle "hint" in between two compliments—but professionals of intelligence and goodwill will figure all that out eventually.
> But also, it means more people need to have the "big picture", and they need to be able to make good decisions (not just arbitrary ones). So the ideal goal is to prevent people from going off in random nonsensical directions based on miscommunication, and equip them to actually think strategically about the overall plan. Continent X might make different decisions than continent Y, but they're all talking, and enough people see the goal.
Very common pattern you see in literature about military strategy, actually. The answer is delegation, heavy use of NCOs, and in general explaining the plan all the way down to the individual soldier. Under the western school it all falls under "initiative".
Notably, a lot of non-western militaries are terrible at it, and a number of military failings in africa, the middle east, and the soviet union (*cough*russia*cough*) are viewed as failures in flexibility with very low initiative, as well as lacking/unskilled NCO corps.
Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.
> Dunno how you apply that to an organization, but maybe sending skilled workers as a kind of non-comissioned officer could work. Who knows.
The most successful engagements I've had with contracting firms have been when we've shelled out for a team manager and a software architect (in addition to the number of straight developers we want).
The software architect builds a solid understanding of our solution space, and from then on helps translate requirements into terms their engineers are familiar with, and provides code reviews to ensure their contributions are in line with the project goals. The team manager knows how to handle the day-to-day reporting, making sure everyone is on task, escalates blockers over the fence to our engineers and managment, etc.
Without those two roles from the contracting firm's side, I find that timezones and cultural mismatches (engineering culture, that is) pretty much erase the impact of the additional engineering headcount when adding contractors.
Army manual FM 22-100 is a very good read on this topic. The impact of giving NCOs both freedom amd guardrails is immense.
link here (ironically, on a blog that critiques it)
https://armyoe.com/army-leadership-doctrinal-manuals/
Explaining the plan to the individual soldier also works better when the individual soldier is expected to care at all about the overall goal. (Such as believing in the mission of defending the home country.) When the soldier only has extrinsic motivation such as money, top-down command and control and treating soldiers solely as equipment to be spent makes more "sense", in a terrible way.
Maybe that applies to software orgs too, somehow.
IT also only works if the soldier is well trained in the things he can do. I can teach you to shoot a machine gun in a couple hours - and half of that time will be figuring out how to shoot and clean it myself (I've used hunting rifles and have enough mechanical knowledge that I think I can figure out the rest - but someone who knows that gun can likely find something I would not figure out). That will be enough for "spray and pray" which is a large part of what a machine gun is used for.
However in a real war you need to figure out what direction to point the gun, and need to know when to fire and when to not. I don't know how the army handles "we are advancing now so don't shoot", or "we are crawling along the ground so make sure you shoot high": someone else needs to give anyone I train those orders. The army trains their machine gun operators better so they can figure a lot of that out without being told.
> the time zones are killer, and this can't be ignored
100% agree, especially when there is minimal overlap during normal office hours. I was managing a dev team in India from the US and it was a real challenge. The company ended up moving team to the US, relocating most of my team. Despite all the people being the same, management became much easier.
Since then I've done US and EU, and EU and IN, and those have all worked fine because we had sufficient overlap during business hours.
If you needed 8 hour overlap you were micromanaging?
Was that because of the above cultural differences?
He didn't need 8 hours, but zero didn't work. The us and india are about 12 hours apart (there are 4 times zones in the us, day light savings time, and india is offset half an hour, but it rounds out to 12 hours for discussion)
> If you needed 8 hour overlap you were micromanaging?
...ok. I didn't need 8 hours of overlap.
As I mentioned in my first comment, I've also now done US/EU and EU/IN. Both of which have only partial overlap and things have gone well.
With US West Coast and India, I was often doing meetings at 7AM and my devs were doing meetings at 9 or 10PM. That was challenging, irrespective of any cultural differences.
> Contractors on any continent are a whole different story.
Having spent the last ~7 years working for different startups before pivoting, my advice to any founder is this: do not hire overseas consultants. They're good, competent people, but you and your company do not have the tools or the culture to actualize them.
> questioning instructions can be read as challenging authority or admitting incompetence, so people default to executing without asking
That’s ego, assuming doing is the value, not doing RIGHT.
Doing alone has almost zero value.
It’s how not to get fired, ostracized, etc. I don’t understand how you read that as ego.
Way to be culturally blind.
> That’s ego, assuming doing is the value, not doing RIGHT.
No. That's lack of labor protection laws and the effect that this causes on how companies are run.
In my experience trying to outsource to India, there is a strong systemic bias towards lying and cheating to get ahead (and that was even before AI), and a focus on milking as much money as possible rather than building great technology.
While there is real talent there, there is also a lot of overhead to find people you can trust.
This is probably just a reflection of the competitive nature of the market and the social ladder tech salaries enable there.
To add to that, it is culturally acceptable and even lauded in India to achieve something by "gaming the system", something usually considered unethical in the west (okay maybe less so in the US).
I would be ashamed to submit an AI slop PR or vulnerability report.
An indian might just say "I have 25 merged PRs in open source projects"
Term for this is "chalaki"
It is cultural - the whole "not losing face" thing. In a project, I once was squad lead - I was onsite, my squad members were in Bangalore of course. Same experience as you. Once I wanted to talk about a piece of code that we need to improve and refactor, and I was acting in good faith calling the dev that commited that code. When I braught up the code on my screen to start a pair programming, he immediately denied having written the code. Unfortunately for him, being a junior, he did not know about git blame - I entered it in the terminal and his name showed up on that code. Still, he would simply just deny that he wrote it. I then took the git commit hash and looked it up in gitlab, able to bring up the MR he created and the reviewer (wasn't me). Even with that on screen, he still denied being the author - with no arguments or alternative reasoning, he just constantly would repeat "No, I haven't written that". "No no, but I haven't written it". I pulled even the JIRA ticket up, that was about that feature and guess what - he was the assigne and moved it to "In Progress" and "Done". Still with that on screen all I got was a "no, haven't written it".
I had more of those interactions, and we also exchanged some of the indian devs (they were sold to the client by a big consulting group, and immediately replaced by someone else if we wished). I later found out, people that I have had replaced in my sqaud for not being qualified, ended up in different teams in the same corporation, they were basically just moving around inhouse.
After a few month in the project I swore to myself never to work with offshores again. And as a side note, the bank I did the project with, does not exist anymore :)
Denial in the face of incontrovertible evidence undermines trust to an extent incompatible with working in any serious organisation.
I’m Indian. I absolutely loathe this part of Indian culture. My uncle was once eating a pizza like a naan (ripping pieces off straight from the box) and I called him out on it, and he said he wasn’t doing anything like that…while holding a piece of naan and the pizza looking like rats had a party with it.
It happens basically constantly, I have never heard my family admit to a mistake unless violently confronted by someone with authority.
Leads to all sorts of issues and societal breakdowns, like police beating people up before even trying to communicate.
I'm curious if you tried to explain to the guy that lying to you undermined his reputation far more than any mistake he made in the first place, and if so how that went. That's something I would fire someone for if it was in my power. Making mistakes is ok, but lying about it is absolutely not.
Pretty sure the right move as soon as he said "I didn't write that" was to just say. "It isn't important who wrote it, we all make mistakes, let's see together how we could have done better."
Today, I would maybe agree and have grown wiser. But software engineering is 50% failure management. And admitting failure should be normal for every level, I am very open and outspoken that I (just as every other guy) makes errors all day. We literally have error management system in place because of that - Bugtrackers, Test pyramid, QA departments etc. It is simple not helpful if people not take accountability and grow on their mistakes.
If someone isn't willing to admit a mistake, it's not someone you ever want to work with. Or live with for that matter.
Pretty sure that can be the wrong move in an instance where it does matter who wrote that. Freely allowing derogation of authorship soon fosters derogation of responsibility.
Mistakes are allowed is a good lesson. Lying is allowed is a bad lesson.
I don't know if it is, but I can swear every time I post a job opening (generally contracting work) on LinkedIn 95% of the applicants are Indians/Bangladesh/Pakistanis/Sri Lankans.
I ignore all of their resumes, not because I don't think there's valid individuals among them, I did hire them in the past, but:
1. because the signal to noise ratio is absurd. The overwhelming majority didn't even read the actual post.
2. Even when they are okay developers, communication is always a huge issue. Sync communication in call is though because urdu and other indian area accents are extremely heavy so I really struggle understanding their english, my bad but what can I do about it. If I try to keep it async or chat based then they tend to not ask feedback, clarifications, provide updates, etc. So you feel like you need to micro manage them half the time and they'd rather give you answers to make you immediately happy than surfacing problems.
3. Paying them is always an hassle. Wiring them money through bank accounts is difficult. They generally set up some Paypal or similar service or ask you to pay them on some Hong Kong account from a friend of theirs. I need traceable invoices and simple wires for tax purposes and when sending money to Pakistan multiple times anti-laundering got involved in my country, and we talking low hundreds of euros.
Still, props to the few good ones I've met, they've been critical on some projects of mine. Very professional and knowledgeable. But it's just too bad of a signal/noise ratio, seriously most applicants don't even read job descriptions.
That is a cultural thing, and one of the first things you learn to handle when working tightly together with Indians as an outsider.
I can't remember all the techniques but a simple trick is to ask them to repeat their understanding back to you before they start working on a thing.
But I don't think it's connected to sending "malicious" reports. That seems rather to be to pad their resume and online presence while studying to get an edge in hiring.
You know who also needs a lot of micro-management but doesn’t live in a time zone, is way faster than offshore contractors, scales up and down instantly, has no onboarding period and is (still) cheaper? Opus.
Ehh nothx. I like my slop human powered
Random interjection: if all roads lead to management, I guess I'd prefer a robot
My guess would be yes, it's cultural. I'm not Indian but spent about 5 months there. Overall my impression was that people act much more on direct feedback.
It would be typical to do the first thing that comes to mind, then see what happens. No negative feedback? Done, move on. Negative feedback? Try the next best thing that makes the negative feed back go away.
People will not wonder whether they might bother you. Just start talking. Maybe try to sell you something. That's often annoying. But also just be curious, or offer tea. You react annoyed and tell them to go away? They most likely will and not think anything bad of it. You engage them? They will continue. Most likely won't take "hints" or whatever subtle non-verbal communication a Westerner uses.
I found it quite exhausting in the beginning, it feels like constantly having to defend myself when I want to be left alone. But after I started understanding this mode and becoming more firm in my boundaries, I started to find it quite nice for everyday interactions. Much less guessing involved, just be direct.
Professionally I haven't worked much with Indians, but my expectation would be that it's necessary to be more active in ensuring that things are in track. Ask them to reflect back to you what the stated goal is. Ask them for what you think are obvious implications from the stated goal to ensure they're not just repeating the words. Check work in progress more often.
Of course it’s cultural, they have to compete with thousands people just like them in environment where human life is cheap and anyone is replaceable. Any authority have huge weight, which comes from historical system how society is separated. And then any education they receive assumes cheating at exams, then cheat with CV, then cheat with work they do. It’s all about appearances.
Maybe. I have hated crowds all my life. I can always see filth in people. I have helped people cheating at interviews. I want to vomit everytime somebody asks me to make a CV. Vomit in the sense I genuinely hate overselling myself but if I don't, I just don't. And what I'm open if you want to ask any question about me?
I had the same exact experience with an Indian contractor. I requested that he used git instead of Shopify CLI for his changes to a store's theme. He acknowledged my request but kept using the CLI. I once again asked him to use git and even offered a detailed, step-by-step guide on how to pull, branch and then push changes. He absolutely ignored everything and simply kept using the CLI. That was actually amazing to witness. The only hypothesis I have is that it's some kind of cultural thing where asking for help is worse than doing the opposite of what's expected from you. I don't know, but your story supports my hypothesis.
From a half-Indian friend of mine, he described this as "ask vs guess" culture. https://medium.com/redhill-review/navigating-ask-and-guess-c...
Ask culture scales a lot better in a fast changing world full of strangers. Guess culture saves friction, but only in situations where people are mostly guessing correctly because the social structure and expectations are fixed.
Thank you for sharing the article! Now I'm puzzled this about myself - what I am...
> Is this cultural?
Many of my Indian friends say it is, but sometimes I feel they can be as self-critical of their country as many Americans are of the USA.
Demographics show that it doesn't have to be cultural - it could just be that India has 9x as many people under the age of 35 compared to the USA. Even if we were culturally similar, for every annoying US youngster "hustling" to try to get employment, there would be 9 early-career Indians doing the same. That alone is enough to drown the "Vox Agora" with Indian voices. Chinese citizens generally don't participate in English-language fora, so their large numbers would be massively under-represented.
If anything else is biasing the populations, the difference in numbers could be even more stark.
I used to work with colleagues from China in contracting and I had the same experience with them. If they don't know something they have hard time saying that they don't know something or don't understand something.
Ficticious Example could be
Q: is this car red? A: it's not green. Q: yeah I know it's not green. But is it red? A: today is Thursday.
One thing I leaned it's not worth pressing forward and causing a scene. Instead it's better to use other ways of finding the information.
When guiding team members I always found it useful to have them explain back to me in their own words what they're tasked to do. It become immediately obvious if they were on the right track or not.
> it's not worty pressing forward and causing a scene
Tell me more. Why?
Probably because they find it uncomfortable to be pressed and the net result is a less productive relationship.
Exactly this. You just put them on the spot and they lose face and you're embarrassing them. Besides this interaction has already made it know they they don't know the answer so what's the benefit of forcing them to announce they they don't know something?
Understood.
But is it productive to cooperate with someone who will never admit lack of information?
Because the tail should not be wagging the dog.
If they cannot take a step towards another culture, why should I?
I've only been in a peer to peer type of working relationships with people I'd consider coworkers so I wouldn't think it'd be very fruitful to start agitating people in such a position.
What position? If you let it pass, you encourage this kind of behaviour.
If they are working for a western company, they should adjust their behaviour, not the company. Just imagine working for an Indian company (or manager), and expecting them to tolerate your individualist behaviour and audacious questions. You would be punished immediately.
If it's a peer-to-peer relationship, all the more reason to be firm. If you don't speak up you will never be respected. And don't think that just because you keep quiet the shitty types of people won't stab you in your back at their first opportunity (ask me how I know).
How much are the contractors being paid?
The people having a terrible time with Indian contractors always deal with folks making 3k-10k USD/year. Of course the quality is bad.
For reference:
Good Indian devs out of college make atleast 30k USD. Good senior devs make atleast 50k. The really good ones make much more. Most American companies outsource to bottom of the barrel contracting companies like Infosys.
> Good Indian devs out of college make atleast 30k USD. Good senior devs make atleast 50k.
1. How can you be a good dev if you've never developed professionally in your life?
2. I know Indian numbers and this is complete bs. Like complete.
Maybe there are extremely rare exceptions to it, but this is like claiming that good US devs out of college make 350k. That's beyond rare, may happen, but it's beyond rare.
1. "out of college". I'm sure you can figure out how to interview new grads and identify good devs.
2. They are not. FAANG in India pays higher than what I quoted. My senior numbers are especially on the lower end of the spectrum. If your numbers are lower then you aren't working with good devs.
These are the numbers for good devs. The ones who get into great startups/companies. 95% make less and it shows in the quality. Infosys pays new grads 4000 USD/yr.
No you can't. Because the real difficulty is not bullshit leetcode questions, but professionalism, ability to handle pressure, requirements collection and research, soft skills, design, etc. you can't interview for those.
You build these skills by writing good software under constraints not by building personal pet projects and farming leetcode.
People can do leetcode AND all the things you talk about. Or do you really think engineers at companies who ask leetcode are all bad at their jobs?
> you can't interview for those
Also yes you absolutely can!
This is called "saving face"[0] and it's very common in some Asian cultures. Western societies prefer directness, and eastern ones prefer harmony.
0: https://en.wikipedia.org/wiki/Face_(sociological_concept)
I wish every indian developer to spend 6 months working with dutch people.
That would be interesting.
It's quite strange though when you consider the fastest way to get egg on your face is to do something badly because you didn't understand and just made it up instead of looking it up
That is western culture. Somehow it doesn't apply to India. I don't get it, but I've seen it.
> never ever ask for clarifications, would never say they didn't know something, would never say they didn't understand something
I experienced this same thing working with offshore Indian contractors 20 years ago. Interesting to hear someone else echo my observations.
I ran into this when I went to India to help train our team over there.
I tried specifically asking questions where the correct answer was “no” and they wouldn’t tell me no. In some cases I told them I was expecting them to say “no” and they still wouldn’t do it.
It was very difficult to figure out what they knew or didn’t know without putting them through a test and seeing how they did.
> Is this cultural?
https://burakpsych.weebly.com/uploads/5/6/0/6/56066915/ethni...
https://en.wikipedia.org/wiki/Power_distance
https://en.wikipedia.org/wiki/Hofstede%27s_cultural_dimensio...
I believe it has to do with saving face.
I've worked with mixed nationality teams at a certain 4 letter austinite corporation a couple thousand moons ago. One thing in common with my Asian colleagues back then (many of which i still keep in touch with to this day), is that they would usually refrain from saying things that could rock the boat or disappoint you. If they lacked knowledge for the task at hand, they wouldn't let you know. If they were late on a delivery, they'd insist it would be ready by a certain date. This led to situations where other regional managers would have to plan contingencies to work around the issue.
I recently heard from a friend that this is due to something called "izzat". Admitting any sort of wrongdoing would reflect poorly on them and their family, to the point they would rather lie or do the wrong thing than damage their family's reputation.
What I don't understand about this is that, if you become "the guy that always does the wrong thing", doesn't that also damage your family's reputation? I don't mean to come off insulting here, just trying to understand.
Culture and what companies want there. I was running a operational team with a couple of incredibly talented guys who had been escalation engineers for large software companies in India.
They were trained really hard to "restore" things in a way that hit some minimal level of the SLA, but not really. It created alot of issues initially in the organization as the "don't question anything" had really been ingrained into them. My observation there is that it made many of the useless support engagements I've experienced make sense, and that a place with that level of discipline and process must be pretty awful.
Indians gaming the system, discussed before the AI on Hacker News, about Hacktoberfest
https://news.ycombinator.com/item?id=24658052
> > Indian students
> Is this cultural?
Could be, but there are a number of very popular Youtube and other video based classes/bootcamps (taught and targeted from/to Indian students) that teach how to work with git and github that show how to create PR's and comments in repos, and then a lot of students do that, on public (and popular) repos.
There are a couple very famous examples of this.
I was contacted by a guy who said he found a vulnerability on my site. Something like phpinfo being available or something. I informed them that I was aware of it and it's not a vulnerability but did offer to give them a small Amazon gift code if they wanted.
This might be part of the motivation. What's pocket change in the west might be good money in the 3rd world.
> Is this cultural?
Its incentives. If you’re an Indian student in India, unless you go to a prestigious university, your prospects of landing a job, let alone a good one are very small. Even tech companies that claim to be meritocratic elsewhere, rarely screen resumes beyond the top universities in India. The only other real prospect is to get your resume to stand out. Open source contributions, research papers etc are some ways to do that. And the talented ones make contributions, while the rest just try to fake it in the hopes to make it (it obviously doesn’t work).
There are similar incentives if you want your college application to stand out if you’re trying to go abroad for higher education. And if you’re already outside India, those incentives extend to job applications outside India. If you’re an international student looking for a job, even if you have work experience at known multinational companies, if it’s in India, the experience doesn’t count.
It’s all about incentives and responding to them.
Definitely not. Anyone growing up immersed in face-saving, high pressure, competition and possibly self-help influencers telling them how to achieve will exhibit these sorts of behaviors. Doesn't matter if you're white or black.
> Doesn't matter if you're white or black.
Disingenuous. Other groups can and do create different cultures that are more tolerant of asking for help, clarification and feedback.
Yes it's "fake till you make it" without the making part
selfishness, laziness, lack of self-awareness, lack of shame, etc are obviously universal traits. But cultures absolutely reinforce them to different degrees. Many cultures around the world are built around the sorts of behaviors we both described.
Whereas other cultures have at least some (if not a lot of) resistance to it - eg publicly ridiculing when people step flagrantly out of line. This is good. My impression is that British culture is like this - "taking the piss", or worse, out of people whose egos start to get too large
Edit: what about this comment could possibly be worth a downvote...? Not that I care about points, but it just seems to be an objective assessment of human nature and cultures, without even singling out any cultures that need improvement.
people who actually have a life generally don't spend time hanging around internet forums so it's important to consider that a disconnection from reality is involved in places like these , thru my eyes you have restated the idea of low trust vs high trust societies without building on top of the idea , which isnt downvote worthy but isnt upvote worthy either
I didn't expect up votes. I also wasn't about to write a treatise. And saying "low trust vs high trust societies" wouldn't be meaningful, nor would it actually be accurate. The issue here isn't trust - it's humility, integrity, conscientiousness, etc. Trust often comes along with such traits, but it's not the core issue.
This is hilarious and reminded me of the two stints I had in India, for about 8 months in total at the turn of the century. I was a hippy traveler and asking directions for almost anything was par for the course. I never had anyone local say they didn't know where something was once asked, even though me following their directions lead to the intended target maybe 10% of the time. It was funny and infuriating at the same time :)
> Is this cultural?
Absolutely. I've been traveling for the last 10 years and lived in 50+ countries. I believe that all cultures have unique pros and cons and that the cultural diversity of the world is an amazing thing. There are good and bad people everywhere, so I rarely leave a place with such a strong opinion as the multiple times I've been to India. I really wanted to love India because of their rich history and diversity, but I ended up leaving with a feeling that their culture is overwhelmingly objectively bad.
> Is this cultural?
In my experience, yes, but I hope that's just my personal experience over the past 20 years.
Possibly as a consequence of this, what I have observed working with Indians is a very hierarchical structure in which you have a "lead" or "architect" who spells out what to do and how to do it in minute details and micromanages, and "devs" who execute as instructed.
I've worked with offshore a number of times and had to recruit there. Even for mid to junior positions, you'd see most people you interview with senior-lead-architect (over heard a random design discussion at the cafeteria), master-of-the-engineering-quality (wrote disfunctional selenium tests), CTO-confounder-Founding-engineer (unpaid internship for his cousin who had an app idea), expert-senior-executive who managed teams of 60 people (summer job as a goat herder).
I guess that's one way to stand out when you are lost in an ocean of people, working thousands of kilometers away from the white dude exploiting you.
There are also a lot of Indian students (there are 1.4bn Indians). There are lots of IT jobs, therefore presumably lots of IT students, and unlike in China Internet access (e.g. to GitHub) is not restricted.
GitHub is a poor example of Chinese internet restrictions, since access to it is usually fine from China.
Indian students were the reason that Google's Hacktoberfest was critiziced and ultimately terminated
Indian students have a long history of disrupting free/libre projects, this is nothing new
Hacktoberfest was run by Digital Ocean. You might be mixing it up with Google's summer of code.
> At the I perceived the pattern that Indian contractors would never ever ask for clarifications, would never say they didn't know something, would never say they didn't understand something, etc. Instead they just ran with whatever they happened to have in their mind, until I called them out
Sounds like an LLM
Askers vs Guessers: https://www.theatlantic.com/national/2010/05/askers-vs-guess...
It's desperational. The desperation of not having to lose any contract. The desperation of being just one bad year away from being on the streets and having to live a terrible life (no food security).
For students, often there is no pathway to actually become good due to lack of resources. So, the only way is to fake it into a job and then become good.
there are definitely cultural issues you have to be aware of, and it's not just India, there are many cultures where questioning authority or admitting to uncertainty are less welcome - and some companies and managers reinforce these.
Always consider relative status and power imbalance regardless of nationality too. If someone is afraid to say no you have to factor that in - and 'calling them out on it' is maybe not the most effective reaction, especially if in public.
I always had frustrations with this as a manager until I could establish a personal relationship. Sounds extra hard with short-term remote contractors!
they probably assumed you knew what you were asking for.
it's interesting how it parallels the issue with llms today, they are basically perverse instantiation genies. your wish is my command.
I worked at a company where we had a untouchable manager who had some Brahman caste devs report to him and they absolutely HATED this.
Brahmin. Brahman both is you and reports to you, as it were.
https://en.wikipedia.org/wiki/Brahman
I think it's mostly not cultural but just bad engineers lying. IT jobs pays the best in India, and it attracts people who have no skills in IT to just fake their way in.
So for every good developer in India there are probably 20 bad ones who have no idea what they are doing.
I honestly think its a symptom of having almost no "career mobility". If it's impossible to get promoted / find better jobs, then being skilled doesn't go as far as brown-nosing.
People will only apply themselves if they think it will help them get to a better place.
Not exactly - there is career mobility in IT, but for many IT is seen as the only place they can get it people who shouldn't be in IT go there.
There also seems to be an expectation that after about 30 you move into management. This means people experienced in IT are not socially valued (they can be paid well if they are great).
>Indian students
Resume glorification and LinkedIn / GitHub profile attention do that.
I am seeing a lot of people coming up with perceived knowledge that's just LLM echo chambers. Code they contribute comes straight out of LLMs. This is generally fine as long as they know what it does. But when you ask them to make some changes, some are as lost as ever.
Torvalds was right, code maintenance is going to be a headache thanks to LLMs.
>This is generally fine as long as they know what it does.
Thanks to their LLM reliance they'd soon not know what it does, and forget even the little they know about coding
At this point I won’t consider any GitHub activity after ~2024 as hiring signals unless it’s very substantial work on high profile projects that clearly have high bars.
Sadly that was already the case prior to LLMs.
We had a bootcamp in our city that had all students build a GitHub portfolio. They all built the same projects like a TODO app. Every person’s code would like almost identical because they all did them together and, I suspect, copied from past grads.
They all applied to the same local jobs, too. So we’d get a batch of their resumes with GitHub links, follow the GitHub links, and see basically the same codebase repeated everywhere.
I kind of suspected that some bootcamp or college or something is telling all these people to just go to GitHub, create an account, spam it with activity, and you'll get a job! At this point I don't think "has a GitHub account" can be used as any signal of programming ability whatsoever.
I mean I never considered having GitHub projects as anything. If you have project(s) that seem useful and have let's say a hundred stars or more (rough signal assuming no foul play), I'll have a look. If you say you have meaningful contributions to projects with a thousand stars or more, I may have a look as well.
Now my bars are so massively higher, 99.95% of juniors who don't have pre-2024 work to show can forget about it.
> Torvalds was right, code maintenance is going to be a headache thanks to LLMs.
I know someone in a senior engineering position at Epic who does nothing but clean up PR's from their off-shored Ukrainian sweat shop coders handing in AI slop because all they need to do is close a ticket to get paid. They wind up rewriting half or more of it. Epic doesn't seem to care so long as this "solution" works and saves them money by paying a few really smart people to code janitor until hopefully all of them can be replaced by LLMs.
As if I needed another reason not to hire people coming from Epic.
For a company as financially focused as Epic it's surprising to me they'll pay the offshored devs for simply submitting code even if it doesn't work and needs to be rewritten.
> As if I needed another reason not to hire people coming from Epic.
I don't understand, are you threatening to avoid hiring talented people or just their brain dead management?
> Resume glorification and LinkedIn / GitHub profile attention do that.
I wondered why people would video themselves going around slapping strangers in public then shouting "its just a prank bro" - turns out it works.
Regard to code maintenance:
I’m actually of the mind it will be easier IF you follow a few rules.
Code maintenance is already a hassle. The solution is to maintain the intent or the original requirements in the code or documentation. With LLMs, that means carrying through any prompts and to ensure there are tests generated which prove that the generated code matches the intent of the tests.
Yes, I get that a million monkeys on typewriters won’t write maintainable code. But the tool they are using makes it remarkably easy to do, if only they learn to use it.
I’m not sure why the downvotes. I think the poster is basically saying the same thing as this YouTube-er. I read “Million monkeys” as referring to LLMs.
https://youtu.be/DNN8cHqRIB8?si=s2VBjZXrP21yziXa
I've seen this - it's tiring even at low volume. Goes something like:
Someone creates a garbage issue. Someone else asks to be assigned. Someone from the project may say "we don't assign issues" (this step has zero effect over later steps). Someone else submits a PR. Maybe someone else will submit another PR. Maintainers then agonise how they can close issues and PR(s) without being rude or discouraging to genuine efforts.
GitHub PM here working on how we can make this problem feel better for maintainers. Really appreciate how tiring this can be, especially when even low volume is sustained for many months.
Would love your thoughts on some of the things we're thinking about: - Would it help to disable all PRs? All non-contributor PRs? - Would a "close as admin" button help address the issue of not wanting to be rude or discouraging? - What about Copilot doing an initial review and proposing to close anything that doesn't meet contribution guidelines - would that help a "close this" decision feel less personal?
Good questions, thanks. I'll share this thread with other maintainers. Is this the best place for feedback in a week or two? Or is there a GitHub meta discussion somewhere?
My ideal is copilot that would evaluate the PR against some basic guidelines that maintainers write down.
And perhaps a way to filter PRs to just contributor PRs would be easy to implement and pretty useful
As someone on the other side of the PR, the current situation makes things awkward for me, too. Occasionally, I'll make an actual fix to scratch some particular itch I have with the software, and I'm hesitant to even open a PR, because it's just going to 1. pile yet another PR onto the maintainer, and 2. might get dismissed out of hand because it's mistaken for AI slop or other low-effort spam that these attackers are doing. So, I usually just fork, make the change in my own repo, and leave it at that.
Disabling PRs or limiting PRs to "contributors" would be a signal to me that I should just keep doing that and not contribute back to the main repo.
> I'm hesitant to even open a PR, because...
For me the answer to this is to let go of all expectations. Fix things for your own purpose, and then open PRs to give the maintainers the option to engage or ignore.
Obviously from my post above, with my maintainer hat on I often fail to let go of the emotions. But it's a goal.
The lowest-stress PRs to handle are the ones with clearest test cases, and minimal incidental changes. Don't refactor, reformat or rename things to your own preferences and then expect a maintainer to engage.
Reducing changes to the meaningful minimum will also make your fork easier to maintain if the PR is refused, or ignored for months+ as the upstream project continues to evolve.
Ultimately, opening a PR is in part self-serving - best case is my change is upstreamed, worst case is I have taken time to streamline it, and simplify integration of future upstream changes into my fork.
Totally get this. One thing we'd love to do is help make contribution patterns (not just guidelines) more visible to contributors, to help you get a better read of what's expected. Would that help? If so, where would you expect it to sit in your existing contribution flow?
I always thought it would be nice to see some kind of "maintainer profile" for each project, that the maintainers could set up: Is the project open to PRs? What is the quality bar for PRs? How much developer testing is expected before a PR is accepted? Are there any automated test coverage requirements/expectations? Sort of like a more structured version of CONTRIBUTING.md.
Also, statistics about past PRs: How long does it take, on average, before the maintainer responds to a PR, before it gets merged? What % are rejected or closed? How many edits do PRs for this project on average need before being accepted? What is the current incoming rate for PRs and what is the current merge rate? I could look at these and figure out if a project can sustain yet another incoming PR or if they are in over their heads. And it would help me understand what level of "done" they are expecting. Maybe some of these are even already available--i haven't really explored GitHub that much. Hope this helps.
Yeah, I kinda stopped involving myself in other people's OSS projects a while ago for that reason. If I have an itch to scratch, I just use my fork. It usually feels like my itch isn't theirs and I always feel like I'm imposing on the maintainer's vision or at best just taking time away from them. I think maintainers have a lot of pressure to accept things because "open source!".
You've been getting PRs? All I've ever seen is "can you assign this issue you me" spam and then disappear. I was nice to them for years but now I just delete the comment and block the users.
Yeah, the "can you assign the issue to me" is the most common. I don't even understand where it came from - does anyone ever actually formally assign issues to anyone?
But they absolutely also create PRs even if you say "don't create a PR. You don't know what you're talking about"
I'm pretty sure there's some guru/teacher that gives assignments to their students. The assignment is most likely "find a repo and ask if you can work on it." The student then either finds something easier to work on or gets points just for trying.
This is precisely what we've seen
Those maintainers should be using LLMs to crate their breakup letter with the Issue/PR submitters!
I contribute regularly to some major open source projects and it’s happening here too. So many issues that aren’t issues. Constant “fixing” of documentation that doesn’t need to be fixed. Bug reports that aren’t bugs, followed by a bad PR “fixing” the “bug.” Or YOLOing an LLM PR to change major behavior that users are relying on. And I click and the authors are always brand new, with only vibe coded or examples projects in their history, and have some truly awful LLM generated GitHub “about me” page complete with emojis and links to their GitHub “projects.”
My suspicion is somehow the perception became that if you’re brand new and land a PR in a major open source repo (even as simple as rewording a phrase in a doc that doesn’t need to be reworded), that would help them get a job (they’re always Open to Work on their GitHub about me page).
It’s so much noise that it’s hard to find the real issues.
GitHub PM here. From what we've seen, you're right about the motivation; I've also seen plenty of job ads where "significant contribution to open source" is something that's called out explicitly as a valid substitute for professional experience in the area. While that's always well-intentioned and creates many benefits for the OSS community, the flip side is that it can also lead to the kind of problems you're seeing. Many new users are also motivated by learning and community, and not familiar enough with the community expectations to know how to seek that differently.
We have tried a lot here in the past (good first issues, more community support for new users), but haven't found a perfect solution yet. Internally, we're looking at options for admins to disable PRs on repos, or limit PRs to collaborators only, for example. From your comment, it seems like part of the challenge you're experiencing as a user is around Issues specifically. We've also been looking at options to delete PRs and Issues individually and in bulk, which could help after the event. Would welcome any feedback on other paths we could take here.
I think a "PR quality score" would go a long way here. Doesn't even have to be displayed to the user, you can just flag it as a low-quality PR under a certain threshold and have it go to a separate view for the maintainer. Have a prominent 1-click button to close it as low quality/spam with a default message about useless PRs. To go along with this you'd probably want a "report" button on comments/PRs to flag them as (spam/AI generated/useless change/etc.)
You could estimate quality with: number of PRs accepted before (only counting repos >2 years old), age of account, size of diff, number of PRs reported as spam.
Thank you for looking into this. It's a huge problem for maintainers these days... something needs to be done.
It would help if PRs from newly-created or private accounts could stand out. And perhaps PRs from accounts that spam multiple PRs with dozes or hundreds of commits, would have some kind of a warning that only people with write access to repos can see. In fact perhaps GitHub could throttle those accounts from creating that many PRs in the first place.
Another suggestion would be trying to figure out if a PR was vibe-coded and marking them as such. Same as image-based social media tries to do.
That makes a lot of sense, and we've been considering some of those options too so good to know we're on the right track there. On trying to figure out whether a PR was vibe-coded: in some cases it's obvious, but in many cases it's hard to figure that out without AI, and we're not sure we love a solution that requires maintainers to use AI to tackle AI. My hope is that if we can provide some non-AI tools first (disabling PRs, creating more visibility around new users, etc), we can then build better management and triage tools with AI second. We're working on an Issues triage agent now that we hope to bring over to PRs too.
I get a lot of unsolicited PRs on my projects that I don't actually want
Turning off PRs would be a good option for several of my repos
Great, we're on it
Make it possible to turn off PRs from new accounts, accounts with a low PR acceptance rate or accounts that create lots of PRs all at once in unrelated projects. Or mark those kinds of PRs in a visible special way. Or make those kinds of issues and PRs non-public so that maintainers can silently drop them without creating publicity for the slop-spammers.
Thanks a lot for taking this seriously. I regularly contribute but am not a “maintainer” so can’t really turn off PRs or anything, nor do I think that’s the right thing in this case. But some signal to spot these accounts at a glance before I go through and try to repro their issue or spend time engaging would be cool. Or immediate signal on “new accounts” (on HN usernames are green for like 30 days), or “account age vs PR velocity” would be interesting to me. Old accounts with regular PRs or Issues are not a prob, but the new accounts that just spam low quality issues and PRs are maddening.
Yep, totally get this. We're going to try and provide some quick solves first for the most affected maintainers, and then go back and make sure we can also help with the kind of nuance you describe.
Maybe you a mysterious hidden ELO score that effectively shadow bans people if they get a negative report from a high ELO maintainer. Perhaps look at how dating apps do it as they have to deal with a many persistent undesirable people.
Or just throw up a money hurdle. The reason you're seeing so many hustle bros from poorer countries is simply because the cost of accessing the internet is now effectively zero.
Everything about this is exactly what is happening in OWASP repos.
I pick the "block" option on the junk issue, and tick the "Send a user notification and show activity in timeline". The text says "A public timeline entry will show that this user was blocked" which I hope discourages them from wasting our time.
I'd argue that the or at least one major reason for the downfall of Stackoverflow (and not just a catalyst) has been a surge of Indian IT people triggering an avalanche of extremely low quality questions and answers. I've been a big fan of SO since about 2010. Not just didn't mind the harsh moderation but actually attribute to it learning how to properly ask a question. But at some point round about 2019/2020 it stopped being fun due to it going from knowledge base to garbage dump.
Related, every time you see on SO "please mark this answer as correct" it's usually not correct
Heh, reminds me of that free T-shirt contest thing... Submit crap PRs to random FOSS projects for a chance of winning a shirt, what could go wrong?
https://ongchinhwee.me/shitoberfest-ruin-hacktoberfest/
Classic perverse incentive.
From https://en.wikipedia.org/wiki/Perverse_incentive
"According to the story, the British government, concerned about the number of venomous cobras in Delhi, offered a bounty for every dead cobra. Initially, this was a successful strategy; large numbers of snakes were killed for the reward. Eventually, however, people began to breed cobras for the income. When the government became aware of this, the reward program was scrapped, and the cobra breeders set their snakes free, leading to an overall increase in the wild cobra population."
The funniest/saddest part is that you could just game it on your own repos, you never had to go out and spam any real projects. If you just made 5 PRs in a repo you owned with the appropriate hacktoberfest tags, that was enough to pass the mark and to get the free shirt and stickers.
worked well for a bit. but then the program became popular and that’s when it hit the curb. terrible loss, imo. it was a brilliant idea to encourage open source work with a token reward. it relied heavily on good intentions, which quickly disappeared with the popularity.
I have one of these and it was really nice in the first 1-n years.
People gamified it and then it sucked, but the idea wasn't so bad. One would expect people would not stoop this low for a free T-Shirt.
There is no limit to how low someone will stoop to get even a tiny token for free. I remember a local community fun event from a couple of years ago, which was set up by the library to encourage kids to read. They would count up these reading tokens at the end of it and give some tiny $2 teddy bear to the winners, and of course a bunch of adults swooped in, gamed the system, and all the toys went to them. People are totally shameless assholes when even an insignificant free prize is on the line.
It’s still ongoing. The difference is they now no longer offer t-shirts (at one point they planted trees instead, unsure if that still happens), and projects must opt-in.
They offered T-Shirts in 2025
Thank you for the correction. I thought they had stopped that but I see you’re right. Seems to be more restrictive, though.
https://hacktoberfest.com/participation/
> Swag - Get an exclusive Hacktoberfest T-Shirt, but its only for ‘Super Contributors’ who contribute 6 accepted PR/MRs to a worthy repository. (T&Cs Apply | Valid only for the first 10,000 contributors completing 6 PR/MR)
this is why we cant have nice things
Reminds me of this Indian GitHub tutorial on how to open a PR on GitHub. The video got millions of views and has flooded a specific repo with countless README update PRs of people (mostly Indian) trying to append their name to the README.
Article about it here: https://socket.dev/blog/express-js-spam-prs-commoditization-...
Holy cow, what a mess - https://github.com/expressjs/express/pull/6956
they flooded THE major server side js framework and it's happening to this day, every day. Express is something to backend what jQuery was to frontend 15 years ago
Usually the protection against such spam is social shame but the internet is now full of people who have no shame because shame was never part of their culture. It would be more effective to use GeoIP in this case.
It’s not just the Internet. It’s politicians and businesspeople and more generally, shameless citizens.
There’s a lot to dislike about shame as an enforcement mechanism but I’m starting to miss some of the upside it delivered.
I wonder how much of it could be stopped just by charging $5 a month to contribute to public open source repos. Even if github gave the $5 back in LLM credits or something it would at least put up a barrier. The reason there is so much traffic from third world countries is because the cost of accessing the internet is effectively zero.
GitHub has zero incentive to do this because it would hurt their analytics/metrics.
Internet reputation became easy to launder, thus meaningless.
I seem to remember there was a large (indian?) educational YouTuber who did a tutorial on how to use Git where they forked a FOSS repo, made a change to the README.md and then made a PR. This caused a huge influx of garbage PRs for that particular repo and other FOSS repos.
The typo PR's are top-cringe.
I submit typo PRs sometimes. I just really like cleaning up docs, and some typos are important because they affect doc searchability. (But I do bundle them up so there's just one PR, and I generally won't do it for a single typo.)
January 01 race to open hundreds of "update year in readme" PRs
Noticed it in corporate context too. About 40% of the performance feedbacks I saw this year were AI written. India and USA crowd. Everything from Europe looked pretty organic but imagine that’ll change too next cycle
I was going to comment something similar.
I was reading some GitHub comments earlier and the AI tone and structure in the comments posted by some users made me feel really uneasy for some reason.
I know a Brazilian who puts lots of emails through ChatGPT because they aren't confident in their English, but this seemed to be AI generating the majority of the content of the message too.
That person should stop. I give a lot of leeway to anyway who ends with "(English is not my first language, sorry for mistakes)" or if they also post it in their original language (if I'm confused I can machine translate parts of it if the confusion isn't obvious, which it actually always has been for any continental language IME).
Stuff like this video is a huge source https://www.youtube.com/watch?v=Ez8F0nW6S
Check the closed PR's on express https://github.com/expressjs/express
Yikes!
Little bit offtopic; is anyone getting more reports of site vulnerabilities I wonder? There are how many AI tools claiming to find those automatically and we get a lot of reports, some even have the tool name on. Thing is, most, well, all so far in the past months, are not true. They seem hallucinations or false positives. We have closed source SaaS products, so these are external scans making these reports.
It's likely because of Google Summer of Code. OWASP has participated as an org several times and it's highly likely that they'll participate this time too.
Students often start making PRs around this time to get more familiar with projects before they can put in a proposal when the time comes.
As someone who's been a programmer for a while now, I feel it's pretty easy to identify slop code and when someone is using an LLM to communicate on issues. I'm not against using LLMs for writing code or even for using it to improve your communication, but it cannot be a substitute for critical thinking.
If I was a maintainer of an OSS project, I'd be more likely to _not_ select students who put out slop PRs, proposals, or messages without thought. And also make this clear in the contributing guidelines so contributors know what they're getting into.
I've noticed this also. But I didn't ascribe it to LLMs, rather figured there is some sort of rogue educator in India who's instructing students to do this on public repos and they just don't know better. But the prof should.
It's Hacktoberfest all year long, baby!
https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama
The other side of the coin is that many real bug reports are dismissed out of hand. That is frustrating if you have spent hours or days triaging an issue and have submitted a well-written bug report. It would be useful if projects advertised what their de facto bug report policy is. If it involves snide remarks and pointless bureaucracy ("you did not check this box") then that should be stated to help others avoid wasting time. Perhaps an LLM could help with that: "The likelihood of an external bug report being acted upon is X%, given analysis of past interactions on bug tracker."
> everything starts as discussions - only maintainers create issues, and PRs can only come from issues.
would be so awesome if github supported all that. probably kills their business model though
I mean, if people adopt, I guess they can also flood the discussions with LLM nonsense. But for now it seems like the better solution.
What issue added GPU acceleration to Ghostty? It seems silly to add that to a terminal.
i f8cking hate being born here.
volume of low quality content, dsa/leetcode, etc. is so high, good people/content gets left out. networking, connections, nepotism so much high. getting job based on actual talent very rare.
MNCs which are good outside are so much sh8t here; well capitalism doesn't give a f8ck anyways.
I think you'll get downvoted to oblivion because outsiders often don't realize the ridiculousness of the whole thing.
I will try to give some context.
To give an example, the CSE undergrad from an average Indian college would've done 500 - 1000 leetcode "problems" for practice. But have little to no idea on how to survive in a UNIX shell, or to troubleshoot an actual problem. Hell, half of them haven't written more than 1000 lines of code for single purpose.
People early in their career (which is most SWEs including yours truly) follow whatever "influencers" on youtube (the local term being bhaiyya-didis), who give them rough "roadmaps" to "crack DSA" or "get high paying remote job". The result is that average CS guy spends most of his time navigating this rat race than studying computer science stuff that matters for the job.
I see similar kind of competition getting created at senior levels too, in the terms of people grinding theory and blog posts on "system design" interviews. I am not old^H^H^H senior enough to comment on it, though.
But it was not all bleak. IIRC, We were producing quite few good OSS contributions through GSoC, LFX etc... until few years ago (not considering my own among good ones). There were talented 1% or so (I known a few very talented people in personally). Nowadays these "hustler" variety people have started "How to crack GSoC" roadmaps [sic] too, and the spamming quoted above see may be related to this. This sort of insane rat race is not good for talented people. It's not good for companies either. Recruitment is basically lottery at higher levels too; I have seen people use AI to shamelessly lie on their resumes and get hired etc... Some of these problems may be present in west but India's scale makes some of these problems difficult.
this is a problem with all indian "education". I work in renewable energy and regularly chat with other Indians at IEEE conferences who are looking for work in the West.
These supposed electrical "engineers" have an IEEE "paper" to their name but regularly confuse power and energy. They have no curiosity, no interest in their work, atrocious communication skills (not language, communication) and swarm you like piranhas once word spreads.
All this combines to devalue Indian degrees and the reputation of Indian STEM talent. The genuinely good people are drowned under this avalanche and there's not much you can do to help them or to find them.
> These supposed electrical "engineers" have an IEEE "paper" to their name
"publication" is encouraged or in some cases "mandated" in certain institutions for course points. It's a lecherous system to game certain metrics which leads to pretend-play and not an ounce of productive work.
> there's not much you can do to help them or to find them.
In CS, If you want to find talented Indian folk, you can hang out in IRCs, hobbyist forums etc.. I have few friends who were Linux enthusiasts, compiler experts etc... who used to. Genuine interest is a pretty good initial filter.
IEEE might as well be a predatory publisher. None of their journals are serious anymore.
Hell, CVPR is now the top conference/journal in the world, beating out every medical journal, Nature, etc. NeurIPS I think is also beating out every medical journal ever.
If you're not targeting a top 20 listed conference/journal in your field as ranked by google scholar (i.e shows up on the leaderboards at all), you might as well not even publish, as those papers at worse venues act as a black stain on your academic career.
These folks should instead target workshops at prestigious venues.
> capitalism doesn't give a f8ck anyways
It doesn't until suddenly it does. A glut of junk can eventually trigger a flight to quality.
Sadly, possibly not on a timeline which works for a given individual.
Yet again poor communal behavior ruining it for the rest of society, and why we can't have nice things and colonize the stars.
>Indian students
How do you know this?
Because their usernames are Indian and profiles have links to Indian universities, and sometimes descriptions of the 101 classes they're currently taking. That doesn't stop them from saying things like "I see this sort of vulnerability all the time"
Don't worry they'll change that too. Sadly I think we're going to need some kind of internet licence like a drivers license that they'd at least have to bribe their way into.
Apologies - looks like you have clear evidence for the "student" part.
Sir, I agree with moralestapia. Not a singular one of the 20 lakh lines in the PR were written by ChaiGPT.
Lol. I found it of interest since it's quite hard to make an LLM write like a stereotypical Indian.
If I was an Indian student, I would prompt it to avoid that style instead of keeping it.
Also, generally, people can just make stuff up on the internet so ...
Ever been on Stack Overflow before LLMs became a thing?
"Students" sounds very speculative. "Indian" likely based on usernames, which are often a South Asian first name followed by a random integer.
Why you don’t just put an AI guardian to close or to ask them to change the story. Or shadow ban
Subjecting every real contributor to the "AI guardian" would be unfair, and shadow banning is ineffective when you're dealing with a large number of drive-by nuisances rather than a small number of dedicated trolls. Public humiliation is actually a great solution here.
> Subjecting every real contributor to the "AI guardian" would be unfair
Had my first experience with an "AI guardian" when I submitted a PR to fix a niche issue with a library. It ended up suggesting that I do things a different way which would have to involve setting a field on a struct before the struct existed (which is why I didn't do that in the first place!)
Definitely soured me on the library itself and also submitting PRs on github.
How effective is it against people who just simply does not care?
I suspect people are doing it to pad their resume with "projects contributed to" rather than to troll the maintainers, so if they're paying any attention they probably do care...
Most people do, and those who don't still get banned so...
what you say, is of course the only relavent issue. I can attest to my own experiences on both sides of this situation, one running a small business that is bieng inundated by job seekers who are sending AI written letters and resumes, and dealing with larger companys that have excess capacity to throw at work orders, but an inability to understand detail, AND, AND!, my own fucking need to survive in this mess, that is forceing me to dismiss certain niceties and adhearance to "proffesional" (ha!), norms. so while the inundation from people from India(not just), is sometimes irritating, I have also wrangled with some of them personaly, and under all that is generaly just another human, trying to make by best they can, so....
You could easily guard against bullshit issues. So you can focus on what matters. If the issue is legit goes ahead to a human reviewer. If is run of the mill ai low quality or irrelevant issue, just close. Or even nicer: let the person that opened the issue to "argue" with the ai to further explain that is legit issue for false positives.
How is an llm supposed to identify an llm-generated bullshit issue...? It's the fox guarding the henhouse.
Just try and you'll see if it can work. Just copy paste some of these issues give context of the project and ask if makes sense
the only way to stop a bad guy with a llm is with a good guy with a llm
That's just shoveling money to tech companies
I intensely dislike the idea that we need more AI in order to deal with AI.
If I ever need to start using an AI to summarize text that someone else has generated with AI from a short summary, I'm gonna be so fucking done.
Small brain: create a solution looking for a problem
Big brain: create a solution solving an existing problem
Galaxy brain: create a solution that creates its own problems
I relate, and then realized that's been the basis of spam handling for decades now. It's depressing, and we aren't putting this genie back in the bottle unfortunately.
How so?
Spam, for decades, has been a matter of just shoveling truckloads of emails out the door and hoping that one or two get a gullible match.
Blocking spam, for decades, has been a matter of heuristic pattern-matching.
I don't see how that is the same as "fighting LLMs with LLMs", or how it could be said to be the same as how spam is made and used.
It's analogous in the sense that tons of machine-submitted emails exist for the sole purpose of being mechanically triaged. The technology might be slightly different (it may not be LLMs through and through), but the pattern is the same.
You're done dude. I'm sure it's already happening.
What are you going to do now?
It's not happening because I'm not using an AI to summarize text. At the moment slop text is also fairly easy to recognise, so I can just ignore it instead.
It sounds funny, but it's not. I once issued a bug to them that didn't have enough information about how to reproduce... and I was lambasted on Reddit and eventually just deleted my account there it was so terrifying. Some dev teams do not mess around. In fact I've shied off most social media since and no longer issue bug reports to any company, I was scarred deep over the treatment.
I've read their reports before. When there's not enough information to reproduce, they do a good job of asking for more information first, and I've never seen a reasonable good-faith report elicit anything overt.
If you failed to give them proper reproduction information when asked, then yeah, you were wasting their time and they should rightfully close your issue.
I've never seen anyone on the curl team undeservedly "lambast" someone, and for a project that has a quite good reputation, I think the burden of proof is on you. Can you link to these supposedly terrifying comments?
It says in the curl file that they will ridicule time-wasters in public and here is one pression confirming that it happened to them, yet somehow that's not enough? Come on.
If you follow cURL’s development, what you’ll see is the main contributors tend to be extremely patient, helpful, and thankful of contributions. Sometimes too patient. If you look at the HackerOne slop reports cURL got, you’ll see Daniel accommodating people outright wasting their time.
So if you follow what’s been happening, you know the types of reports this message is talking about. What they consider time-wasters are slop reports where the reporter didn’t do any effort to even test the “bug” and then keeps pasting whatever the LLM says in replies and lying about using them.
In other words, for a legitimate report it’s hard to believe that was the reaction. I would expect them to be patient with a human contributor which really put in the work. It’s particularly hard to believe the maintainers would even waste their time to lambast someone on Reddit. Doesn’t seem like their style.
Maybe the person in this thread is exaggerating, maybe they misinterpreted it, or maybe it did happen. But it seems so out-of-character that some proof would be warranted, especially since it’s a single report.
When people don't provide a citation online when discussing some specific instance like this-- which could be provided with a couple clicks and would radically improve their argument a reasonable assumption is that the citation would undermine their argument.
We don’t need anecdotes, every single bug is public. Just looking now I see respectful responses to genuine reports. This document is clearly in response to AI slop and spam.
I skimmed the "slop" collection they maintain that was posted here yesterday, and even under those HackerOne submissions, Daniel was perfectly reasonable and respectful.
It is entirely possible I merely chanced upon his highlights, but this announcement to me really just signifies a final straw breaking than anything else. His historical conduct is all public and speaks for itself. I wish I had the patience and perseverance he does, and I wish he didn't need it.
That is sad, sorry to hear it.
But at the same time, sometimes you have to really persevere to get a bug fixed.
Consider the perspective of the maintainer of a popular project: to them, you're one person in a big queue of people all reporting problems. Most issues turn out to be "I need free technical support, which you don't offer, so I'll phrase it in the form of a bug", and it saps their time to look into the details of each issue to find whether it's genuine-bug or user-error.
So that's why you should try to give reproduction instructions as best you can, and be up-front if they're incomplete, or you only saw it happen once.
If the maintainer responds harshly, or even if you get commentary from others, remember they are (or should be) criticising the bug report, not you. Try not to take it personally.
And even if they decide to close it, or not investigate further, you've still done the world a favour by adding genuine details about something you saw. The bug report is still searchable when closed. Other people who get the same problem as you are likely to find it, and it might spur them to reproducing the bug where you couldn't, and re-opening or re-reporting the bug and driving it forward to completion.
It’s not my job to fix their bugs. It’s not my job to handhold them through it. You are better off anonymously posting the full bug online and let god sort it out.
You're also free to not use their free software.
You're paying exactly $0 for support for this software. So any support (eg: bug fixes) you get are a gift. That means that if you (1) use their software, (2) don't provide a good bug reports to help them fix their bugs, and (3) complain about how it's not your job to fix them then... you, my dear person, are acting like an entitled ass.
It's not hand-holding to provide a good bug report, it's essential to make the bug report actionable. curl is so widely-used that bugs often come from a combination of the software and the environment (OS, libraries, etc). Without enough details to reproduce a bug, then the bug is often impossible to track down. This means: recreate the environment, the actions that led to the bug, and create the bug itself.
ahhh, the old "I expect everyone to read my mind about extremely nuanced and specific things, and those who can't are idiots" mentality at play
It’s literally not their job, either.
It's not their job to fix your bug.
That surprises me -- from what I've seen, Daniel is actually remarkably tolerant of incomplete/unclear reports. (Too tolerant.) But I imagine that could depend on the day.
(Now, if you used AI to generate the report, well... that's different. Especially if you didn't disclose it up front.)
On the flip side I’ve been following him for a while on Mastodon.
I’ve basically watched the AI crap cycle go from “this is a weird report, oh it’s fake” to “all the reports are trash, it’s so hard to find real humans in the flood” through his posts.
I suspect I would’ve stepped down long ago. I feel so bad for the open source maintainers who are just being assaulted with nonsense.
How does Reddit come up in this?
The only official community spaces they maintain are:
- their GitHub projects (Issues, Pull Requests, Discussions)
- their mailing lists
- their HackerOne page
If you were harassed on Reddit that is still shitty of course, but it's not gonna be on the project's dev team:
> Some dev teams do not mess around.
Unless some of the devs have verifiable, pseudo-official presence there at least.
There's a strange irony in the replies here, where people apparently lack the necessary information to reproduce your experience.
What was the bug?
Wouldn’t it be ironic if GP never answered this request for simple follow-up.
Not really. They said in their comment they deleted their whole account and everything. They probably don't want to continue to be ridiculed and to link the identity of that account with this one.
It's not "funny" ironic but still ironic, given jb1991's ambiguous accusation around his past ambiguity, with no follow-up information to clarify.
Yeo without any sort of context, it's just like throwing a stone and then running away.
Yeah I had to downvote because of this. If you don't bring receipts then it's just slander.
Gotta let the legal team know about that I hadn't heard they changed it.
It sounds like a karma farm victim fish story.
Share the issue or reddit thread.
Please ignore everyone else and do not share any more information about this experience or yourself. These people do not have your best interests in mind and will not mind, or are intending to, make this experience even worse for you.
He rubs me the wrong way, too. Curl is overhyped and a pain to work with. And he's getting high on the "success" while crying about not being paid for something he offers for free. I think Americans have a nice phrase about having cake and eating it, too.
Not only is cURL not overhyped, it’s absolutely false that Daniel “[cries] about not being paid for something he offers for free”. He does get paid for cURL support.
https://daniel.haxx.se/job.html
He does criticise rich companies who don’t do anything to support cURL and demand preferential support, but that’s not the same thing (and does warrant criticism).
Daniel is also not an american
Seems like a lot of the problems had by the low friction of first eternal september and now LLM genrated reports and contributions, could be resolved by restoring friction. First time reporters/contributers could be required to send their report or PR by paper mail. Strict requirements for the sender: all text printed on postcards (no letter opening) as QR or other data codes according to a standard formatting. Anything even slightly off goes straight to the trash, high signal/interest contributors can still get their foot in the door.
The eternal-september; or its international equivalent, kills things because the nature of the public you are interacting with has changed.
These issues with reports and junk contributions come about because there is a huge payoff for pretending to be part of the community, but the benefit from actually contributing is generally less direct.
I dont think you can solve this with "friction", because the people you want to dissuade are more tolerant to these kinds of barriers than the ones you want invite in.
Ah, brings back memories when TPB did something similar to when MPAA and their "associates" emailed them. I think this is probably the best page where one could still see them: https://web.archive.org/web/20111223101839/http://thepirateb...
I'm not sure it helped in the end, afaik they did it since like 2003 until some years after the raid, but it still seemed like they didn't get the message and kept trying anyways, which from their perspective makes sense but still.
Projects are not going to be so open open their development process if they have to keep wading through emoji-filled and erroneous PRs. The Bazaar doesn't work so well if nobody can get around the piles of manure that are being delivered
https://en.wikipedia.org/wiki/Brandolini%27s_law
Should be a highlight of the 2020's decade.
It's not just open projects, it's anything that accepts unvetted information at all. Bug lists full of shit. Forums full of shit. News feeds full of fake shit. Ads full of fake shit. Cultural zeitgeist full of fake shit.
Culture and society has not figured out how to inoculate themselves yet.
This kind of automated industrial output is the foundation of our culture, it's not surprising that we aren't prepared for the virtual grey-goo of the LLM era that is our milieu brought to it's acme.
I am friends with a solo maintainer of a major open source project.
He repeatedly complains that at the beginning of some semester, he sees a huge spike of false/unproveable security weakness reports / GutHub issues in the project. He thinks that there is a Chinese university which encourages their students to find and report software vulns as part of their coursework. They don’t seem to verify what they describe is an actual security vuln or that the issue exists in his GitHub repo. He is very diligent and patient and tries to verify the issue is not reproducible, but this costs him valuable time and very scarce attention.
He also struggles because the upstream branch has diverged from what the major Linux distribution systems have forked/pulled. Sometimes the security vulns are the Linux distro package default configurations of his app, not the upstream default configurations.
And also, I’m part of the Kryptos K4 SubReddit. In the past ~6 months, the majority of posts saying “I SOLVED IT!!!1!” Are LLM copypasta (using LLM to try to solve it soup-to-nuts, not to do research, ideate, etc). It got so bad that the SubReddit will ban users on first LLM slop post.
I worry that the fears teachers had of students using AI to submit homework has bled over into all aspects of work.
As a human being I really enjoy knowing things and being challenged to grow.
While crypto style AI hype man can claim Claude is the best thing since sliced bread the output of such systems is brittle and confidently wrong.
We may have to ride out the storm, to continue investing in self learning as big tech cannot truly spend 1.5 trillion on the AI investment in 2025 without a world changing return on revenue, a one billion revenue last year from OpenAI is nothing.
Kryptos K4 seems to me like a potential candidate for AI systems to solve if they're capable of actual innovation. So far I find LLMs to be useful tools if carefully guided, but more like an IDE's refactoring feature on steroids than an actual thinking system.
LLMs know (as in have training data) everything about Kryptos. The first three messages, how they were solved including failed attempts, years of Usenet / forum messages and papers about K4, the official clues, it knows about the World Clock in Berlin, including things published in German, it can certainly write Python scripts that would replicate any viable pen-and-paper technique in milliseconds, and so on.
Yet as far as I know (though I don't actively follow K4 work), LLMs haven't produced any ideas or code useful to solving K4, let alone a solution.
In china medical students are required to publish original papers. Instead they just pay someone to write it for them and pollute the literature.
So much for the curation argument of the price justification of professional journals.
The typical graduation-requirement paper doesn't get published in a professional journal, so I think professional journals do provide significant curation.
Medical? What's the point? I'm happy with 98% of doctors being able to handle known conditions and only the few percent that are really interested to do research.
It makes the university look better if they do a lot of 'research' even if it's fake. There's not a real reason a doctor needs to do research for an MD.
>I worry that the fears teachers had of students using AI to submit homework has bled over into all aspects of work.
As one does in academia, so to the market, because now we have financial incentive. It ain't going to stop.
I think this is probably less effective than if there was some sort of "credit" or reputational score for reporting that seems like something GitHub would have the information to implement.
> seems like something GitHub would have the information to implement.
But not the motivation. GitHub incentives this type of behaviour, they push you to use their LLMs.
GitHub is under Microsoft’s AI division.
https://www.geekwire.com/2025/github-will-join-microsofts-co...
> GitHub is under Microsoft’s AI division.
Finally an explanation to why GitHub suddenly have way more bugs than usual for the last months (year even?), and seemingly whole UX flows that no longer work.
I don't understand how it happens, do developers not at least load the pages their changes presumable affects? Or is the developers doing 100% vibe-coding for production code? Don't get me wrong, I use LLMs for development too, but not so I can sacrifice quality, that wouldn't make much sense.
I just listened to podcast from a higher echelon MSFT person, the internal orders basically are “focus on AI”, non-AI work gets deprioritized company wide.
But that by itself shouldn't mean that people suddenly don't even review and think what they're doing, right? Again, I too use LLMs for lots of work, yet I'm putting out better code than before, because I'm a software engineer, not a software slopper, is this not the common workflow?
I wouldn’t be surprised if experienced people left because of policies like this. It doesn’t matter if you are reasonable your colleagues won’t necessarily be.
I think one of the last thing I'd like on the web is for Microsoft to start keeping a "social score" for developers who participate in FOSS.
I understand where it's coming from, and I too think the current situation sucks, but making Microsoft responsible for something like that is bound to create bad times for everyone involved.
I’d hate to see GitHub assigning reputation to users.
Why no go the other direction and make it hard to identify a user, so people do not do it for fame. Open source worked before people were using it as self advertisement.
Might even be good for Microsoft - they would be the only one knowing who is who.
the berne convention copyright defines inalienable authors rights that can not be sold or taken away from the author. the author of any copyright works always has the right to identify themselves with the work, and therefore your suggestion is not legally possible.
I am not a lawyer, so can't propose the best way to implement this, but the Berne convention contains provisions for "anonymous and pseudonymous works", see Art 15.
This already exists on the previous platform curl was using (HackerOne), it does not prevent the slop.
At my previous employer, I had access to the company’s bug bounty submissions and I can assure you no matter what you try to do, people will submit slop anyway. This is why many companies will pay for “triage services” that do some screening to try to ensure that the exploit actually works.
Unfortunately this means that the first reply to many credible reports are from people who aren’t familiar with the service, meaning that reports often take a long time to be triaged for no reason other than the fact that the reporter assumed that the person reviewing the report would actually understand the product. It’s hard to write good, concise reports if you can’t assume this fact.
Honestly, I don’t know what can be done to fix all of this. It’s a bad situation for everyone involved, and only getting worse.
Yeah this seems like a good idea. Plenty of games have "you have to have this much reputation to play in ranked games" sort of things.
I guess people would complain if it was tied to Github.
The new era of AI.
Everybody saw it coming. Frankly I'm surprised it took this long.
Not everybody. Some very mentally ill individuals thought we’d all be living in some start-trek post scarcity TV show.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it." - Upton Sinclair
It's kind of like people who live at the base of a giant dam but cannot comprehend that it could ever fail.
Context: [1, 2]
> Open source code library cURL is removing the possibility to earn money by reporting bugs, hoping that this will reduce the volume of AI slop reports.
> cURL has been flooded with AI-generated error reports. Now one of the incentives to create them will go away.
[1] https://news.ycombinator.com/item?id=46701733
[2] https://etn.se/index.php/nyheter/72808-curl-removes-bug-boun...
Money for a report and a patch, with convincing test cases, might be worthwhile. Even if a machine generates them.
> Even if a machine generates them.
Why? If it is a purely machine generated report there is no need to have dozens of third parties that throw them around blindly. A project could run it internally without having to deal with the kind of complications third parties introduce, like duplicates, copy paste errors or nonsensical assertions that they deserve money for unrelated bugfixes.
A purely machine generated report without any meaningfull contribution by the submitter seems to be the first thing you would want to exclude from a bug bounty program.
Not necessarily. Reviewing an issue report is already enough time. Reviewing a patch is even more developer time.
The problem they had before was a financial incentive to sending reports, leading to crap reports that wasted time to review. Incentivizing sending reports + patches has the same failure mode, but they now have to waste even more time to review the larger quantity of input.
Anyway, for most cases I'd bet that Daniel can produce and get reviewed a correct patch for a given security bug quicker than the curl team can review a third-party patch for the same, especially if it's "correct, but ai-written".
I've read this idea that we could make people pay for security reports a few times here on HN (and you get back the money if the report is deemed good). That feels very wrong.
If I find a security issue, I'm willing to responsibly disclose it, but if you make me pay, I don't think I will bother.
Punishing bad behavior to disincentivize it seems more sensible.
For a person finding bugs for a living, an up-front fee to have their report reviewed by a maintainer would amount to an investment towards receiving a bug bounty if their report is valid and valuable. Just the cost of doing business.
It would discourage drive-by reports by people who just happened to notice a bug and want to let the maintainers know, but I think for a project that's high-profile enough to be flooded by bogus bug reports, bugs that random users just happen to notice will probably also get found by professional bug hunters at some point.
Only if the system is fair. If I as a maintainer want to scam I can just close the report as invalid, collect the $$$. Then a week latter I fix the issue with a commit that looks like it is unrelated.
I wouldn't do the above, but it is easy to see how I could run that scam.
You can look at how the maintainer dealt with previous bug reports to decide whether you can trust them or not. If there haven't been any previous bug reports but they nonetheless ask for a fee to help deal with the large volume of bug reports, yeah, that might be a scam. If you're running their software, maybe also check whether it's full of malware.
Good scammers pay out once in a while. Casinos hate it when everbody body loses, and love it when one person wins big - they need just enough losers to make money while enough winners to show off.
Punishing bad behaviour does close to nothing, because the problem at hand is one of high asymmetry between the low effort to submit vs the high effort to review. I do agree that paying for reports isn't ideal, and we should find other ways to level the playing field, but in the meantime I haven't heard of anything as effective.
> the problem at hand is one of high asymmetry between the low effort to submit vs the high effort to review
Hence the threat to shame publicly I suppose.
Actually, Daniel Stenberg previously responded to this proposal the same way as me [1] (and maybe would still do). Coincidentally, I was reading your answer at about the same time as this part of the talk.
[1] https://www.youtube.com/watch?v=6n2eDcRjSsk&t=1823s (via https://news.ycombinator.com/item?id=46717556#46717822)
Doesn't work when using throwaway accounts, the low effort gets only marginally higher.
I get what you're saying, but I don't think punishing bad behavior is practical here. It's like a "enumerating badness" problem - there's way more bad actors with nothing to lose and not much practical way to punish them. There's too many of them and they all have no reputation to damage.
Not saying I have a better solution, just that it's a hard problem. Maybe dissuading some good people who have genuine security issues but don't feel like paying just has to be a cost of doing business.
> Even if a machine generates them.
That sounds wonderfully meritocratic, but in the real world, a machine generating it is a very strong signal that it's bullshit, and the people are flooding maintainers using the machines. Maintainers don't have infinite time.
What was a kind design to thank good contributors is now a lottery.
Throw enough AI crap at enough projects and you may get a payout.
The incentives fail in the face of no-effort flooding. They accidentally encourage it.
To be clear, no, it is not, because of the opportunity cost of all the other slop. That's what this is all about.
Then no bug reports and no fixes. Sounds good enough.
Of course there are still bug reports and fixes without financial compensation. The proof is all of open-source, including cURL.
They'll still get bug reports and fixes from people who actually give a shit and aren't just trying to get some quick money.
I wonder if there is a way to blanket prevent these types of problems.
Possible solutions I can think of:
- Require an account with a paid service. Fix = require money - Require an account verified with real ID/passport etc. Fix = link to real person - Automated reply system to "waste tokens" if it is an AI that is responding. Fix is increased cost of spammer. - Have some kind of "vetting system" where you get on an allowed list to report these types of things. Seems not good to me, but perhaps there is something in it.
I wonder how much open source code is lost because maintainers must deal with this type of thing versus the "good" that AI can bring in productivity.
That would shut down all drive-by contributions, which may not be a good source of big improvements, but are a good source of information about bugs/maintenance issues. I.e. if I find a rare corner case where the code breaks, for an open source project I'd usually take some time to report it properly. But there's no way I'd pay for the privilege or bother to register with my governmental ID.
I agree, but if there were a common place where everyone did the registration once, it might be less of a problem. Something similar to the «verified» accounts on twitter etc.
I can imagine GitHub becoming this filter somehow
I've thought about this some and there are benefits and detractions in the processes.
First requiring a deposit system. This might work in the sense that someone dedicated can put down $5 and report a bug, and even if it's not a bug but their work is legitimate they get refunded at the end of the process.
- This doesn't scale well globally as $5 is nothing to me, but significant to someone that lives in a place almost no one in the US can pronounce correctly.
- Once you become trusted you no longer need a deposit.
- Most people what would submit a single, real, bug won't do this and you lose this information.
- How is management of this deposit system paid for? How is fraud dealt with?
Could it actually be significantly lower than $5? Isn't the real benefit not the money, but that the payment creates a bit of friction plus a paper trail tied to an individual?
You could then build a reputation system, much like a spam blocklist, using some sort of hash of the payment details.
A lot of solutions have been suggested over the past few months, including those. They have drawbacks and it’s not how they want to run the project.
https://youtu.be/6n2eDcRjSsk?t=1664
A few weeks ago i saw a repo in Github that had closed the issue-board and explained the users: to move on to the discussions.
If the discussion leads to the insight, that this is worth a feature, the maintainer will implement it.
I think the same goes for PRs. If you think you have made something cool, then discuss it and offer your implementation and the maintainer makes it fit with you to integrate.
On the other side, if you want a feature it just doesnt have, simply forking it and updating from the source-repo is fair enough.
- I notice a lot of stuff in github issues all the time
- For example, there is this +1 comment pasted like 500 times that I have seen a lot over issues
- Cant we have a github regex bot of sorts ^(\W+)?\+(\W+)?1(\W+)?$ that removes all such comments? or let the author of the repo control what kind of regex based stuff to remove?
- I know regex kind of sounds old fashioned in the age of LLMs but it is kinda simple to manage and doesnt require crazy infra to run
Yes you can, and those comments will then say "plus one", which you will add to your regex, and then they will say "++", which you will add to your regex, and then they will say "I agree", which you will add to your regex, and then they will say "me too", ......
There's going to be avalanches of code everywhere. You can no longer expect some human to know what some code does or maintain it.
Which is exactly what the AI companies want. An unmaintainable mountain of code that you need their cloud-based, paywalled LLMs to handle for you.
Yep. Vendor-locking, AI-locking and also human-locking. The last one is where the code can only be maintained by specific persons.
You certainly can expect “some” human to know what “some” code does.
Things you cannot expect:
- ALL humans to know what SOME code does
- SOME humans to know what ALL code does.
The policy link[0] page still has a link to the bug bounty program[1] which still discuss monetary compensation.
[0] https://curl.se/dev/vuln-disclosure.html
[1] https://curl.se/docs/bugbounty.html
Although it's not mentioned in those, it's going away at the end of the month: https://news.ycombinator.com/item?id=46701733 https://news.ycombinator.com/item?id=46678710
Every site and every service is going to be swamped with AI-generated slop and will have to deal with it by banning it, and then detecting and deleting it.
This was entirely predictable. When you give everyone the ability to be good at something with no effort, everyone is going to do it (and think they are the first).
My partner recently bought a book from Amazon, and when it arrived, I looked at the cover, flicked through it, and said it was AI slop. She complained to Amazon, and they just refunded her, no questions asked, and the book went in the fire.
> When you give everyone the ability to be good at something with no effort
When you give them the ability to think they’re good. If they truly became good, this wouldn’t be an issue.
Somehow, I knew this would be curl before finishing reading the headline. Good on them!
I was going to add “cURL: “ at the start of the title, but it didn’t fit. The current title is exactly the allowed length, so it seemed more appropriate to keep the message verbatim.
Bots/LLMs don't care if you ban and ridicule them in public.
While I understand the frustration with bad reports, this is how you get more of them (from the spiteful) and fewer good reports from the people you just threatened.
Links to all those crap reports: https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...
(from https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...)
Can anyone tell me in 2025 how much big tech made in revenue from AI..
Revenue or profit?
My instinct to this was: "This is literally patronizing"
Threats are what every parent tells their child: "If you do X, I'll take away Y"
For parenting, a limited form of this probably makes sense, because the parent has an authority over the child given by The Nature of Things.
But between adults this mode of communication is grotesque, and it is more and more common.
Especially amongst redditors, forum moderators, and other geeks of the ilk.
Having an overly long captcha for bug bounties / reports may be the one place where it serves a purpose
they're suffering from this big time: https://www.youtube.com/watch?v=6n2eDcRjSsk&t=2453s
This is great actually. I can feel the sentiment of the slop they've had to deal with.
Fair play to them.
Seems fair.
It is a bit naive to expect Indian students to even know about /security.txt existence, let alone reading it.
I think this is the perfect application of a micro payment service. Each PR must be signed with a nominal amount of money, say $0.15 give or take. You send in a commit, with no expectation to get it back.
I think a deposit would be better then. You make a deposit of ¢15 for each issue and PR you open, and then the maintainers can decide to give it back to you if it was opened in good-faith/useful/merged/whatever policy they decide on.
Agreed. Could be fiat or some sort of crypto currency that requires the submitter to have a vested interest in the outcome.
Honestly, I would love it if I could front some money in order to have the devs look at my PRs. Half my PRs just go into the void and nobody looks at them until some staleness bot inevitably closes it.
This is a similar problem to resume spam. I always wish I could pay $5 when submitting a resume with the guarantee that someone would actually look at it and give me a fair shot. If I ever run a place I want to experiment with only accepting resumes through letter mail or in person.
I want to extend this idea to email. Use encryption, but for proof that the email can't be read, instead of for security/privacy (not that I'm against either of those).
Update the email protocol so that all messages must be encrypted. Not "by default", but by necessity. The server rejects them if they aren't encrypted and signed in a way that proves the decryption key is on a block chain.
The only way to put the key in the chain is to submit a micro payment. By "courtesy" , but completely subject to the recipient, the users client will refund the payment 48 hrs after it has been decrypted/read. Only if they click "spam" then the payment stays on their ledger. This would kill spam overnight.
The two downsides I see so far are that the chain is a single point of failure for everyone, and it would cost people a few bucks and some friction to get the clients set up. Plus the coin would have to be very low transaction cost, and still fully redeemable for actual value somewhere.
Unfortunately, I doubt that would work. Email is so popular because it's sort of a universal messaging protocol that so many old but critical pieces of infrastructure require. If this "Email 2.0" released, it would take years, if not decades, for critical infrastructure to switch over.
In the meantime, you'd still need an Email 1.0 client. So now you have a mix of your most important emails from critical infrastructure and just spam from bots who don't want to pay money for sending spam in your inbox.
You'll still need to deal with spam, but if anything it'll be even worse because now you have to double the amount of inboxes you have.
I think this idea doesn't go far enough. If it's money that's motivating slop, fine - let's make it about money. $50 to submit a bug report. If it's legitimate, we send you back $60; the judgement is on the curl maintainers' honor. If it wastes time, well, at least the curl maintainer gets a steak dinner.
Fair enough.
It's been an issue for a while and it's even bigger now in the age of AI. Lots of people use security as a way to "have their moment" and don't really care about adding value.
But scaring people off from security reports also isn't a great idea either.
Creating crap vuln reports or PRs on popular OSS projects has been an issue long before LLMs. Remember Hacktoberfest?
Students would often abuse it since there’s no adult in the room to teach them how to behave. I guess this is one hard way to f around and find out. But this is by no means condoning this sort of behavior.
Point is, LLMs made the situation more dire: it’s cheap to generate code, whereas reviewing still scales sublinearly. The only way to prevent this is by being rude to people who are rude to you.
It's never fine to be rude.
Moving off github into a more niche platform was the best choice I have ever made to curb such zero-effort issue and feature requests. It raises the barrier just enough.
On the other hand, I'm a dev, and I hate the "start a discussion first" gatekeeping. I participated in projects where the approach is to start a discussion on a forum first, and I get the same feeling you have as a tech guy calling ISP support on the phone.
The discussion requirement is often to prevent disappointment, waste of time, and anger, when maintainers simple close PRs, because it's not the direction they want the project to go. A lot of people will take this very personally, so it's much better to have a conversation about it beforehand.
> On the other hand, I'm a dev, and I hate the "start a discussion first" gatekeeping
Seems like a completely appropriate way to handle things if you're still on Github. You said yourself the spam drove you off.
They could let people who are proven not to be spammers open PRs directly.
> You said yourself the spam drove you off.
Yes, indeed. But I still stand by the gatekeeping though.
Sadly, it's a tragedy due to how popular github (and similar services) have become.
These sites were supposed to be by developers for developers.
Problem is that the LLM operators don't care if you're rude. They copy and paste your response to the LLM and probably don't read it themselves. If they do read it they don't suffer any ego hit from it because if there was any error it was the LLM's not theirs and their LLM is busy telling them how brilliant and unparalleled they are and how wrong the haters are in any case.
CURL is free to try it, but I'm doubtful being rude will meaningfully improve things. I'm confident it won't improve the ratio of good to bad reports because non-chatbot powered submitters are sensitive to rudeness or even the threat of potential rudeness, and so this approach could easily reduce total volume some but mostly in the reduction of good submissions.
> ridicule you in public
love this. more projects should use this kind of language. cut the bullshit
I love curl.
This note isn't going to stop even 1% of the jackasses who would have submitted AI slop.
There are much better ways to communicate the intended message. This comes off as childish to me and makes me think that I'd rather not contribute to the project.
> This comes off as childish to me and makes me think that I'd rather not contribute to the project.
It's unfortunately the new normal, with FFmpeg's core team acting similarly. No doubt the result of what is considered socially acceptable expanding in ways it probably shouldn't.
that is a view many hold, until its their own time being wasted. Consider the responsibility these people have and take on their shoulders, only for a bunch of idiots to consider their AI slop worthy of pissing up and down their face. Most of them probably even know its just AI slop spraying spree
Many people deal with worse every day and don't resort to acting like a child.
Wouldn’t be surprised if there’s a fork of curl that addresses it.
Why is cURL specifically receiving so many slop contributions? Or is this a recent phenomenon for every open-source project, and cURL are the ones most spoken of? First time commenting on HN!
They offered a bug bounty, so people think "let me just use ChatGPT to make money for myself".
But from I hear it affects other projects too. It affected curl more because with the bug bounty they actually need to invest work and look at those.
[1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...
[2] https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...
cUrl as a project has a lot of conceptual attack surface for someone looking to find _anything_.
It is large, very popular (hence impact) and written in C. It supports many many many protocols with all of their real-world implementation quirks. Obscure or mainstream. And always handling user-controlled data.
If your motivation is a cool CVE for your CV, you'd pick such a project as the target of your efforts.
It’s not just them, but curl is one of the most popular open source projects in existence and it’s used in areas where security is a significant concern. The security industry has a lot of emphasis on someone’s portfolio for hiring, which isn’t bad (it beats “what frat were you in?”) but it means that there are a ton of early career people thinking that the path to a better job is getting credited for CVEs on major projects.
That’s a bad combination with LLMs which are almost perfect for letting the user think they’re being more productive than they actually are because the output sounds authoritative. You don’t have to be acting in bad faith to submit a slop report, just being inexperienced and over-confident will work if you don’t have enough experience in the area to reason about the security of the entire system.
I'll leave this chart to speak for itself https://ourworldindata.org/grapher/number-of-internet-users?...
Dog whistle to AI. Love it.
AI doesn't mind you'll be ridiculing it in public
Not yet
I like the idea of refundable submission fee for bug bounties. No refunds for slop and poorly researched submissions.
One way this can backfire: if you have no reputation and are nobody, and get banned and publically ridiculed, this is now a badge of honor you can take to wealthy and deluded people convinced of the AI future, to say 'look, I have been shot at! I'm a true believer!'
And then maybe they will give you money.
Only if there's a wealthy political group that hates the thing you just got ridiculed by. When you get expelled from a climate conference you can become a right-wing figurehead, but when you get expelled from the cURL vulnerability program, nobody cares.
lol, fair and square
Why do I always hear the cURL guy's opinions on this and that?
> We will ban you and ridicule you in public if you waste our time on crap
If shame worked, then slop reports would've stopped being made already. Public ridicule only creates a toxic environment where good faith actors are caught up in unnecessary drama because a maintainer felt their time was being wasted. Ban them, close your bug bounty program, whatever, but don't start attacking people when you feel slighted because that never ends well for anyone (including curl maintainers)
It worked well for me when people were stealing my articles, pretending they wrote them. One tweet or mention in Linkedin and the article is gone.
Plagiarism is much different than collaborating on open source projects but I'm glad that calling them out worked.
Test your hypothesis by attaching your offline name to your internet profiles.
That's sort of the whole point of this thought exercise, no? If shame worked in an environment with anonymous/pseudonymous users, then we wouldn't be here. The only people you stand to harm are the ones who attach their real identities to their profile (and they're more likely to be good faith IMO)
Besides, I've seen plenty of profiles here on HN who advertise their real name and espouse (in my view) awful takes that would most likely not fly in real life. I'd recommend reading this article[0] for an example of when people, with their real names exposed, can still cause a shitstorm of misunderstanding.
0: https://lwn.net/Articles/973782/
This is 100% true. I've seen this happen over and over again.
Shaming does not work, you look like an idiot, people will start to despise you and then you end up ostracizing yourself from the rest of the community and the only ones left within your bubble, are circle jerk assholes.
It's one of those cases where you end up causing more harm than the ones you were complaining about.
Just pathetic behaviour.
Nice. But it deters people like me who aren't totally confident in sending reports, trading false positives for false negatives
> it deters people like me who aren't totally confident in sending reports
This is by design, you shouldn't be submitting reports on anything less than certainty. It's not the maintainers responsibility to prove out your idea. It's yours, and when you're sure, reproduceable, and documented it, then you can submit it.
The real problem here is that this is now the only way the maintainer/reporter can reasonably work.
Proving out a security vulnerability from beginning to end is often very difficult for someone who isn't a domain expert or hasn't seen the code. Many times I've been reasonably confident that an issue was exploitable but unable to prove it, and a 10s interaction with the maintainer was enough to uncover something serious.
Exhausting these report channels is making this unfeasible. But the number of issues that will go undetected, that would have been detected with minimal collaboration between the reporter and the maintainer, is going to be high.
> Nice. But it deters people like me who aren't totally confident in sending reports, trading false positives for false negatives
There's no such thing as a reasonable "false positive" on a security report. There is such a thing as a false positive on a bug report. (A real bug, that happens to have no security impact, is still a true positive, just without a security risk)
If you can make it crash, or behave incorrectly, or have some repeatable, weird behavior; but you have no idea how you could exploit that for an articulable advantage, or access to the system you shouldn't have. What you have is a bug, not a security issue. You can, and should submit a bug report.
Then, critically; "if you waste our time" seems to be an important part of the statement.
If you don't know, you suspect it's a security bug because you shouldn't be able to do this, and it is leaking information that you think is suspicious, and you can easily demonstrate that you can make it happen on demand. And you report that bug, and make it easy for them to understand and either confirm the security, or reject because [reason]. You haven't wasted anyone's time and this wouldn't apply to your bug.
From https://curl.se/docs/code-of-conduct.html:
"As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities"
Why have a code of conduct while being hostile to contributors?
I think they should handle this differently.
I don't think that telling a LLM to create a fake bug report is "contributing".
There's no mention of LLMs in the link. Humans are perfectly able to generate "crap reports" on their own.
I think the parent is correct in calling out the inconsistency of promoting personal attacks when that is explicitly forbidden in the CoC.
They are not contributors, they are spammers. There is a difference. Do you reply to spammers with friendly greetings?
I should really. They are also people. Probably bored at "work" in some slum in Nigeria.
I'll try to strike a conversation with a spammer next time I can't sleep. Thanks for a great suggestion.
But you won't. Let's be real here. Yeah, lets gently remind ai spammers that they are truly helping but submitting bogus Issues, PRs, bug bounties, or whatever. Just like scammers from fake call centers, they are only in it for the money and hoping one hit sticks.
"Contribute" comes from the Latin con- "with, together" and tribuere "bestow". We need a new word for these slop submissions. "Detribute" might work well, for something that takes away from the common good, rather than adding to it.
With the extra work that LLM slop has been causing to core maintainers, I think they're quite friendly. Hopefully the volume of the bullshit they receive goes down once they stop paying bug bounties. The people who got upset that their hacker alias got called out for submitting bullshit LLM slop got what they deserve.
Perhaps because they are not really contributors, so it doesn't apply.
Then they should exclude specific groups from their CoC.
"You can't be a contributor if you're an Indian using AI".
I don't think this is the way ..
The simpler part is to say that AI generated text / code is not a contribution and will be banned if found, probably.
You won't get a hundred percent hit rate on identifying it, but it at least filters really low effort obvious stuff?
all curl team came here to downvote you, don't be so cruel :D
Heh.
I understand they people hate to to waste time. They should just be polite about it.
Or you know .. update or delete the CoC.
Well, I guess this could be considered an update:
> We will ban you and ridicule you in public if you waste our time on crap reports.