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.

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.

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.

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.

> 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.

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.

If OSS project maintainers don't want to work with you then just fork it and move on. No need for drama.

a nice 4 part series on the SBOM, CycloneDX additions to Raku may be found here … https://dev.to/lizmat/series/32933

My only theory is maybe they thought the author was a bot? It seems very odd to block someone over one PR.

A reminder to all, that it is hacktober.

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.

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.

Most OSS projects have a scale of expectation for external contributors depending on what they propose, either implied or written (like in [^0]). A hypothetical but likely scale would be from typo/docs fixes (lowest), bugfixes, new features, to CI/CD and release workflow (highest). Generally, the wider audience your patch might influence, the more you are expected to know about the project itself, its workflow, collaboration, best practices, code quality and maturity, etc. in the first place.

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

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".

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".

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.

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.