Being blocked from contributing to lodash(c.ruatta.com)
c.ruatta.com
Being blocked from contributing to lodash
https://c.ruatta.com/on-being-blocked-from-contributing-to-lodash/
52 comments
There wasn't even a "what is this" or "please explain". I feel like blocking should be reserved for disruptive behavior or spam. At best this seems like an accident, at worst it seems wildly immature.
But to my eyes, this PR does look like spam. It has no description, its title and commit messages are meaningless. Changing random auxiliary files is also a common sign of PR spam. This PR really looks no different from other spam PRs that popular GH repos have to deal with all the time.
This is not the right way to contribute to a project. If I were the maintainer, I wouldn't engage with it either, just like I don't reply to spam emails.
This is not the right way to contribute to a project. If I were the maintainer, I wouldn't engage with it either, just like I don't reply to spam emails.
> But to my eyes, this PR does look like spam
Your spam detector is broken. It was opened by an account that's clearly human with more than 10 years of history. It was closed by the author themselves 2 hours after they opened it. It's got WIP commits that were clearly written by a human thinking through the process.
What about this reads as spam to you? They just forgot to fill the description portion of the PR
Your spam detector is broken. It was opened by an account that's clearly human with more than 10 years of history. It was closed by the author themselves 2 hours after they opened it. It's got WIP commits that were clearly written by a human thinking through the process.
What about this reads as spam to you? They just forgot to fill the description portion of the PR
If someone opens a PR to one of my repos with no context, I ban them.
There’s too much AI spam out there right now.
Publishing ‘@provenance-labs/lodash’ as a test, I suppose. Ok. Leaving it up? Looks like spam.
Badgering the author an a private email? Mmm. Definitely not.
This isn’t a bug, it’s a feature. There’s a contributing guide which clearly says; unless a feature gets community interest, it’s not happening. If you want a feature, talk about it rouse community interest.
Overall: maybe this wasn’t the right way to engage.
Sometimes you just have to walk away from these situations, because the harder you chase, the more it looks like you’re in the wrong.
…it certainly looks, right now, like the lodash author wasn’t out of line with this, to me.
There’s too much AI spam out there right now.
Publishing ‘@provenance-labs/lodash’ as a test, I suppose. Ok. Leaving it up? Looks like spam.
Badgering the author an a private email? Mmm. Definitely not.
This isn’t a bug, it’s a feature. There’s a contributing guide which clearly says; unless a feature gets community interest, it’s not happening. If you want a feature, talk about it rouse community interest.
Overall: maybe this wasn’t the right way to engage.
Sometimes you just have to walk away from these situations, because the harder you chase, the more it looks like you’re in the wrong.
…it certainly looks, right now, like the lodash author wasn’t out of line with this, to me.
Foreign PRs with malicious GitHub Actions attached are a common vector for the very supply chain attacks OP was trying to mitigate, from what i understand. At first glance a PR like that is incredibly suspicious.
I sympathize with the OP, GitHub makes it outrageously easy to accidentally open an upstream PR when you meant to open one on your own fork, it's happened to me twice. But i don't blame lodash for blocking them.
Regardless, opening an issue about their release process obviously should have been done first.
I sympathize with the OP, GitHub makes it outrageously easy to accidentally open an upstream PR when you meant to open one on your own fork, it's happened to me twice. But i don't blame lodash for blocking them.
Regardless, opening an issue about their release process obviously should have been done first.
Agreed. It seems there was no initial communication, consideration of the existing maintainers opinions or evaluation of current deployment processes.
OP simply pushed his personal opinion on how lodash (extremely popular library) should be deployed. Proceeds to get confused and upset when this is rejected.
I suggest to OP to work on his social skills.
OP simply pushed his personal opinion on how lodash (extremely popular library) should be deployed. Proceeds to get confused and upset when this is rejected.
I suggest to OP to work on his social skills.
Closing a PR immediately after realizing human error should NOT get a ban.
When you start contributing to an open source project, you should start with tackling an open issue, or opening an issue and contributing per their process. Jumping in, opening random pull requests, forks, tagging, and trying to alter the build process is not a good way to do so. Changing the build process, which affects every single person that touches the code, and can also interact with CICD platforms you don't have access to, is possibly the worst place to jump into, especially when they don't show any interest in this.
The lack of commits for months was also a good clue that this wasn't a good place to contribute. Getting insta-banned is still weird, though. If someone makes a PR and then immediately closes it, that strongly implies human error rather than spam or any other malice. The right move is the default one: ignore it until something actually happens.
I guess it also didn't help that these kind of PRs are most commonly generated with AI.
There's a lot of attention around increasing malicious contributors. Someone I don't know with no history contributing to my project immediately jumping into packaging, distribution, provenance would really have me questioning their intentions.
Am I being paranoid? Probably, but given recent history I don't think so. Would I ban them for that? Dunno, but it would be a consideration.
Either way, I don't find the decision to ban someone from contributing for that to be all that surprising.
Am I being paranoid? Probably, but given recent history I don't think so. Would I ban them for that? Dunno, but it would be a consideration.
Either way, I don't find the decision to ban someone from contributing for that to be all that surprising.
I would also block/reject a person like this. I had my fair share of these phishing attemts so I'm not asking questions if someone is trying to touch my infra.
Without conversation, despite email? What's your project so I cns make sure not to use it then?
This sort of contribution seems easy enough to review.
This sort of contribution seems easy enough to review.
It's always the same story with these posts.
This kind of attestation doesn’t realistically add any value. It just lets downstream users assert that the build happened on a host managed by Microsoft. That doesn’t reflect anything with regards to the package content itself — although it may allow ticking some compliance checkbox somewhere.
Reproducible builds are a lot more valuable. They let downstream consumers verify that the package was actually generated with the documented sources and inputs.
Reproducible builds are a lot more valuable. They let downstream consumers verify that the package was actually generated with the documented sources and inputs.
Assuming you trust GitHub CI, why doesn't attestation bring the same value?
I haven't really looked into what it entails in establishing an attestation for a CI-built package, though, but I thought the idea was that you will at least get a git commit id that will describe the work, and that the attestation says that that's the work that's been done?
Reproducible building would be useful for removing the need to trust GitHub. But then what do you need the builds for anyway, you would always need to build it yourself anyway?
I haven't really looked into what it entails in establishing an attestation for a CI-built package, though, but I thought the idea was that you will at least get a git commit id that will describe the work, and that the attestation says that that's the work that's been done?
Reproducible building would be useful for removing the need to trust GitHub. But then what do you need the builds for anyway, you would always need to build it yourself anyway?
Having both is really where things are at. That way you can verify that the tools being used for the build aren't doing something behind your back and that the code that you see is what you're getting.
GitHub actions encourages using mutable references for “workflows”, so the inputs used during the build process can change before and after the build.
That seems like an obvious vector for doing something behind your back.
That seems like an obvious vector for doing something behind your back.
I see a lot of folks complain about not getting help on OSS projects; I also see a lot of people turning a blind eye to people trying to help (however naively it may be). It's an intesting dichotomy.
> people trying to help (however naively it may be)
As soon as you are giving free attention and mentoring to people unable to make a somewhat useful contribution, you are giving up even more of your life for free.
There are people who know how to pick appropriate issues and send PRs with test cases. It might be better to look for them than try to mentor ineffective contributors.
As soon as you are giving free attention and mentoring to people unable to make a somewhat useful contribution, you are giving up even more of your life for free.
There are people who know how to pick appropriate issues and send PRs with test cases. It might be better to look for them than try to mentor ineffective contributors.
Yup, it's interesting. I think a major cause is just a lack of perspective. Maintainers are likely working for free, have their own jobs and the like. They will appreciate it if you make their jobs easier, and will be extremely cautious if you are changing fundamental/core components as a new guy in town.
One needs to study on their own, use forums or get in touch in some other way that isn't a PR if they want help. Also, while studying the codebase, finding low hanging fruit is going to be easy. That's where everyone should start.
One needs to study on their own, use forums or get in touch in some other way that isn't a PR if they want help. Also, while studying the codebase, finding low hanging fruit is going to be easy. That's where everyone should start.
It can take a lot of effort to integrate random contributions.
One of the questions you as a maintainer have to ask yourself when coming across some PR, Issue or similar is "Does this Person want to help, or are they interested in obtaining the identity of a 'helping person'".
This blog post existing points at the latter.
Depending on how you run your project, you might want to play along with that story regardless, to extract some value and make the whole thing a two-way transaction instead of a one-way one. That however requires there to be some significant value to be extracted or else you end up with a net negative.
It is however also possible to reject transactionality entirely.
___
What is interesting in this case specifically, is that the author did manage to extract value eventually. If not by being the savior of lodash, then by becoming the victim of lodash.
This might be another detail hinting at why whoever maintains lodash might've decided to react with a block and nothing else.
Further receipts for this read of the situation include the immense clout-to-effort ratio of the PR just adding a new GitHub action that "adds more security" and the Blogpost itself opening with the actual mission statement of "improving the ecosystem".
This blog post existing points at the latter.
Depending on how you run your project, you might want to play along with that story regardless, to extract some value and make the whole thing a two-way transaction instead of a one-way one. That however requires there to be some significant value to be extracted or else you end up with a net negative.
It is however also possible to reject transactionality entirely.
___
What is interesting in this case specifically, is that the author did manage to extract value eventually. If not by being the savior of lodash, then by becoming the victim of lodash.
This might be another detail hinting at why whoever maintains lodash might've decided to react with a block and nothing else.
Further receipts for this read of the situation include the immense clout-to-effort ratio of the PR just adding a new GitHub action that "adds more security" and the Blogpost itself opening with the actual mission statement of "improving the ecosystem".
If OSS project maintainers don't want to work with you then just fork it and move on. No need for drama.
A fork does not accomplish the goal here. And tossing out bans for nothing is significantly more of a drama generator than a postmortem.
My only theory is maybe they thought the author was a bot? It seems very odd to block someone over one PR.
You'd be amazed at what people do. I believe that they liked googled the name found something offensive and blocked.
A reminder to all, that it is hacktober.
I tried to contribute in the past and the owner was an unprofessional jerk. Instead of replying the PR rejection with arguments, he posted memes and shit
Every project does not need CI/CD. This greatly raises the cost and complexity above hosting repos.
As the industry has grown a lot of practices around software engineering from FAANG have become more widespread (reviews, CI, linting, etc) but these were designed for professional team environments. They aren’t fundamental to writing programs.
As the industry has grown a lot of practices around software engineering from FAANG have become more widespread (reviews, CI, linting, etc) but these were designed for professional team environments. They aren’t fundamental to writing programs.
This is probably because "add publishing with provenance" is precisely the kind of thing that would ping on my AI slop radar. There are people mass-opening crap issues like this. It's not per se nice to block them and you obviously don't deserve that but you can get type I error only so low before raising your type II.
You could at least evaluate the contribution to see if it is or is not actually slop. From my perspective in security, it's the exact kind of thing that I would expect a thoughtful, helpful community member to do - big project, not a lot of activity but still widely used, moderately sized security win, not super hard to do solo - hey, let's improve security for everyone! - not AI slop.
And, FWIW, cURL - who has been dealing with tons of faux-security AI slop - just recently posted about someone using AI to find 22 actual security issues in cURL, which was helpful. So even if it's AI, it's not necessarily even slop - you should evaluate the contribution on its own merits. Before AI, people opened garbage PRs to popular repos all the time that were unhelpful/noise, they continue to do so now, nothing has changed.
And, FWIW, cURL - who has been dealing with tons of faux-security AI slop - just recently posted about someone using AI to find 22 actual security issues in cURL, which was helpful. So even if it's AI, it's not necessarily even slop - you should evaluate the contribution on its own merits. Before AI, people opened garbage PRs to popular repos all the time that were unhelpful/noise, they continue to do so now, nothing has changed.
I tend to agree, sure. This doesn't make the PR worse or something.
On the matter of curl yeah I've seen they got actual help that way. Here is the problem. If you are an open-source maintainer there is some proportion of good contributors (most) and some proportion of low-effort spammers (few). AI is a force multiplier for sheer volume. So the spammers all pick it up because they do not care about quality. It can be used carefully to good effect, true, but now your mix of incoming volume goes from "lots of good contributions and a little to spam" to "lots of good contributions and lots of AI stuff" with the latter being mostly slop.
So open-source maintainers with limited time do what all humans do: they fall back on heuristics and adopt a bias against AI output, because now dealing with the spammers on a case-by-case basis takes way more time and just tossing AI stuff becomes easier. Like all heuristics it is imperfect, and I don't know if it's the best way, but I get why they do it.
On the matter of curl yeah I've seen they got actual help that way. Here is the problem. If you are an open-source maintainer there is some proportion of good contributors (most) and some proportion of low-effort spammers (few). AI is a force multiplier for sheer volume. So the spammers all pick it up because they do not care about quality. It can be used carefully to good effect, true, but now your mix of incoming volume goes from "lots of good contributions and a little to spam" to "lots of good contributions and lots of AI stuff" with the latter being mostly slop.
So open-source maintainers with limited time do what all humans do: they fall back on heuristics and adopt a bias against AI output, because now dealing with the spammers on a case-by-case basis takes way more time and just tossing AI stuff becomes easier. Like all heuristics it is imperfect, and I don't know if it's the best way, but I get why they do it.
> You could at least evaluate the contribution to see if it is or is not actually slop
Even that takes time. So people resort to proxy signals and ban for "bad vibes".
Even that takes time. So people resort to proxy signals and ban for "bad vibes".
Seems really wacky that dude got blocked. That’s pretty extreme.
Blocking someone for being annoying? Sure, whatever.
Blocking someone for trying to make a contribution even if it was unwanted? Seems excessive and unhealthy to me.
Blocking someone for being annoying? Sure, whatever.
Blocking someone for trying to make a contribution even if it was unwanted? Seems excessive and unhealthy to me.
Github deals with a lot of bots/AI that open pointless/spam/bad PRs/issues/etc.
https://github.com/orgs/community/discussions/158850 https://www.reddit.com/r/developersIndia/comments/1akh9ll/a_...
etc etc etc
Github needs moderation, just like anything else with user-created content.
I am not in the tiniest bit surprised that sometimes moderation makes a mistake, whether human error or automated error.
https://github.com/orgs/community/discussions/158850 https://www.reddit.com/r/developersIndia/comments/1akh9ll/a_...
etc etc etc
Github needs moderation, just like anything else with user-created content.
I am not in the tiniest bit surprised that sometimes moderation makes a mistake, whether human error or automated error.
As an aside, since it seems the other comments already address the core issue...
No one should be using Lodash in 2025, it mutates your collections, use `ramda` (https://ramdajs.com/) instead.
Unfortunately, a lot of the early core existing packages have dependencies in lodash, or another packages that does so too.
No one should be using Lodash in 2025, it mutates your collections, use `ramda` (https://ramdajs.com/) instead.
Unfortunately, a lot of the early core existing packages have dependencies in lodash, or another packages that does so too.
Ehh what. I would give some merit to arguments like "no one should use lodash in 2025 because you can do most of it with built-ins nowadays" or maybe because it doesn't tree-shake well or maybe even because it doesn't seem to have much active development now.
But stating matter-of-factly that no one should use it because some of its well-documented functions are mutating ones and not functional-style, and should instead use one particular FP library out of the many out there, is not very cool.
But stating matter-of-factly that no one should use it because some of its well-documented functions are mutating ones and not functional-style, and should instead use one particular FP library out of the many out there, is not very cool.
Without naming, there seems to be >1 VC-funded companies building "open-source" products, with paid-enterprise or other more sinister business models, where they claim to be open to contributions and have a full CONTRIBUTING.md, and where there's an active community of devs trying to contribute good PRs to solve open issues in the issue tracker.
But the issue tracker is so overwhelmed by slop, non-Latin scripts, and people who think their personal problems (or AI model problems) are the product's problems, that the employees have all but ghosted the issue tracker and PRs; it takes days or weeks for the maintainers (employees) to triage/respond/despam the Github issues list. And if the employees _do_ leave an initial comment on a community PR that multiple users on the issue tracker are begging to be merged, and the PR author makes the requested changes or solves the roadblock, then the team never responds, or takes months to respond. Meanwhile main branch marches on - PRs from the internal paid dev team do get merged often.
I have to imagine that there's a layer of internal politics (maybe VC funding related? dunno) at these companies that shifts more and more communication onto internal nonpublic platforms, to the point where the open-source community rarely gets updates beyond patch notes. It certainly can feel strange when you're on the receiving end of a ghosting. One has to remember that "open-source" does not necessarily mean "community".
But the issue tracker is so overwhelmed by slop, non-Latin scripts, and people who think their personal problems (or AI model problems) are the product's problems, that the employees have all but ghosted the issue tracker and PRs; it takes days or weeks for the maintainers (employees) to triage/respond/despam the Github issues list. And if the employees _do_ leave an initial comment on a community PR that multiple users on the issue tracker are begging to be merged, and the PR author makes the requested changes or solves the roadblock, then the team never responds, or takes months to respond. Meanwhile main branch marches on - PRs from the internal paid dev team do get merged often.
I have to imagine that there's a layer of internal politics (maybe VC funding related? dunno) at these companies that shifts more and more communication onto internal nonpublic platforms, to the point where the open-source community rarely gets updates beyond patch notes. It certainly can feel strange when you're on the receiving end of a ghosting. One has to remember that "open-source" does not necessarily mean "community".
> One has to remember that "open-source" does not necessarily mean "community".
> But the issue tracker is so overwhelmed by slop, non-Latin scripts, and people who think their personal problems (or AI model problems) are the product's problems
The internet used to have a community feel. But that is very easily destroyed by this kind of "dark forest" behavior; everyone learns that opening yourself to the world is opening yourself to attack.
> But the issue tracker is so overwhelmed by slop, non-Latin scripts, and people who think their personal problems (or AI model problems) are the product's problems
The internet used to have a community feel. But that is very easily destroyed by this kind of "dark forest" behavior; everyone learns that opening yourself to the world is opening yourself to attack.
a nice 4 part series on the SBOM, CycloneDX additions to Raku may be found here … https://dev.to/lizmat/series/32933
Sounds like they feel you're making useless work for them. Not saying they reacted well of course, but if they haven't published in five years then you have to imagine that improving their publishing flow could not be any lower of a priority. Obviously whatever is shipped five years ago was secure or someone would have noticed my now.
I also think attestation is bullshit. It's what I would call "security theater" like paying $5 for a blue check mark.
Whether a package has this particular check mark has almost nothing to do with whether its security practices are sufficient to keep you safe. At that point the attestation check mark actually harms security by welcoming complacency where there is still not sufficient operational safely to justify complacency.
I also think attestation is bullshit. It's what I would call "security theater" like paying $5 for a blue check mark.
Whether a package has this particular check mark has almost nothing to do with whether its security practices are sufficient to keep you safe. At that point the attestation check mark actually harms security by welcoming complacency where there is still not sufficient operational safely to justify complacency.
> In an attempt to reach out to clear up any misunderstandings, I opened a Github issue on my forked repo, tagged the lodash org and primary maintainer, and explained the situation. I gave context as to why I had opened the PR, and what I wanted to achieve. Two weeks later, no response. As a last-ditch effort, I sent an email directly to the same primary maintainer, using an email I found in git commit history
Dude cannot take a no. The lesson here is don't be annoying if you want people to work with you.
Dude cannot take a no. The lesson here is don't be annoying if you want people to work with you.
Dude didn't get a no. And was blocked before doing anything you're calling annoying here.
Block is a no
Blocking is a "no" and also a "I don't even respect you enough to deliver my answer to you or acknowledge your question". About as tactful as ghosting.
A lot of people think it was an anti-bot measure, and if that's true it was not a no to the human contributor.
I agree that banning people without prior communication is rude, but looking at OP's PR[^1], I tend to concur with lodash maintainers this time. The PR gets no description, no explanation, and no prior discussion or RFCs. It adds a totally new GitHub Actions pipeline, while lodash isn't even using GitHub Actions now. It contains various fixup commits that should be squashed. One commit has a super long subject that should be split up. OP here went straight to the top level to propose a brand new release workflow, but the lodash maintainers obviously didn't consider them to be ready for such contributions.
These are common mistakes every contributor would make in the beginning, and I don't think the maintainers meant it personal. As many other comments have pointed out, by choosing an easier task, getting familiar with the workflow, and building trust, OP can get their patch landed.
[^0]: https://www.mozilla.org/en-US/about/governance/policies/comm...
[^1]: https://github.com/lodash/lodash/pull/6014