Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@silvermoon82@tech.lgbt I have... strong feelings about this :) The main problem is that there's just currently no (credible) automated way to reliably assess the risk involved in dependencies, and it's unlikely that one can ever exist because of the nature of the problem. The best you can do there is pretty much "spotting known problems to look at", and that scope will be very limited.

*Ideally*, you would manually review every dependency. This is actually viable in practice in JS, *if* (and only if) you strictly stick to single-responsibility dependencies that have a very well-defined scope, but even then it's still a very time-consuming process, and there should really be good tooling for doing this collaboratively across the community, to spread the work.

But... there isn't. :|

I explicitly don't trust for-profit corporations to build such tooling, because "for-profit" and "public commons" don't go together and it'll invariably end in doing free labour for a commercial party rather than a genuine community project. But there's also very little ongoing work in this area in general.

The 'immediate' advice I generally give for JS nowadays is to stick strictly with single-responsibility dependencies regardless of how high it makes the dependency count go up. Because that way many of your dependencies will simply not *need* maintenance, and swapping out a dependency in the worst case is super cheap. It's also much easier to audit them manually because all code is 'local' instead of coupled to other parts of the stack.

(I wrote a bit more about the counterintuitive nature of JS deps over on the birdsite a while ago, if you're interested: https://twitter.com/joepie91/status/1065193459349446656)

@f0x Thanks! Will have a look

@silvermoon82@tech.lgbt Ahh, yeah. I guess they changed their pitch up quite a bit since I last looked at them - previously they were very much trying to be "the solution to funding OSS, pay once to pay everybody", which I really didn't like because they were essentially positioning themselves as a monopolistic OSS funding gatekeeper, intentional or not.

The current presentation does seem a lot better and a lot more measured. I have no idea how accurate their metrics are, though, and I do hope that it isn't just prioritizing Tidelift-affiliated packages...

@silvermoon82@tech.lgbt (I should note that my dayjob is basically "dependency auditing" and I've seen a loooot of bad software supply chain services, so that's where a lot of the skepticism comes from :p)

@silvermoon82@tech.lgbt Which vendor is this? I'm generally extremely suspicious of such vendors, because they tend to use simple (and very wrong) metrics that mostly just end up reinforcing harmful maintenance practices, but upstream support (also financially) does sound a bit better than usual.

@silvermoon82@tech.lgbt I'd argue that that'd be more 1.5 :p

@ckie we're all banned on this blessed day