Indeed, if you benefit from Free Software you'd better engage with it. Maintainers should stop bending backwards to please free loaders.

This is indeed the best way to handle your open source dependencies. I got concerns about the ability to sell that to management though because of the extra steps. It's also probably why you want to have an OSPO in your company, it's a good way to lower the barrier for developers to contribute this way.

Interesting analysis of the crates ecosystem. It shows quite well some of the challenges and weaknesses. Nothing to worry about yet about the ecosystem health overall. Still, you should probably be careful when picking dependencies.

Nice overview of where we stand regarding supply chain security. Code reuse has never been so widespread and we still have fundamental issues leading to security problems.

This latest development in the Ruby community is rather concerning.

Unsurprisingly ends up with an advertisement for their own security tool. That said the vector used for the attack is interesting, with more npm like ecosystems available nowadays, should we expect to see more such attacks?

Nice automation for such updates. I'm discovering endoflife.date this looks very handy.

A good explanation of why you likely don't want a centralised package manager for your ecosystem.

Good idea to standardise this for vendors just like we do using CVEs for software components. This would definitely improve dealing with breaches.

Bad actors will go to great length to try to compromise your supply chain.

It's indeed surprising that this compromised npm account didn't lead to more damage. It's a good reminder that you better regularly audit what happens in your ecosystem.

Sometimes, it's indeed better to not pull an extra dependency.

Mind your typos... It seems clear a bad actor is hiding behind that one.

Not strictly about Rust, still is shows how to approach the conversation about your dependencies. It also gives good ideas on how to try to reduce them.

I'm not sure this dichotomy is enough for building a taxonomy of FOSS projects. But I guess it's a start and captures something often missing in other such attempts.

For studying it makes sense. But don't shun other's work away only because of trust or ego issues.

There's clearly a tension between security and ease of pulling dependencies. In a way, it's "too easy" with cargo and you very quickly end up having to trust a staggering amount of third party code.

Dependency resolution is harder than people generally expect. This is a difficult problem and is very sensitive to the context.

Indeed there is a tension between both approaches in package ecosystems.

This is a worthy questioning... We try to reuse, but maybe we do it too much? For sure some ecosystems quickly lead to hundreds of dependencies even for small features.