npm was a mistake.

npm was a mistake. the concept of pulling live dependencies that are not collectively managed by a QA team but each individually managed by many thousands of people with wildly varying skill and availability is inherently doomed to constant incidents.

@0xabad1dea I struggle with this take because I very much succeeded at contributing to foss in the js ecosystem due to the low barrier to entry for contributors and maintainers, but a low barrier to entry is not my top priority when choosing dependencies for serious projects. Rejecting npm very much feels like pulling up the ladder after myself, but I do also want a higher standard of quality for my users.

@dougwade @0xabad1dea PyPi, Pub, etc have similar issues, but it is also at the core of what makes them useful (to me, at least, as a user, maintainer and contributor). If you are designing a production system (especially public facing), you should always freeze your package versions and review version updates. If you're dealing with critical or protected data then you are probably legally required to have an external audit.

It would be excellent to have some expert reviews of package updates and new submissions but it would be nice to not have it go the way of R/cran.

It's a trade-off...I will say that it is probably a much bigger problem now, as the sheer volume of packages combined with AI/vibe coding means this is going to cause plenty more incidents and increasing numbers of malicious packages.

@zeyus @0xabad1dea I think you very much understand my conflict. My needs as a user, a contributor, and a maintainer are all very different, and when you are designing a registry, you have to choose to privilege one of those roles over the others when making design decisions. It’s easy to say npm got it wrong; it’s harder to admit that there isn’t a single definitive right answer.

npm was a mistake. the concept of pulling live dependencies that are not collectively managed by a QA team but each individually managed by many thousands of people with wildly varying skill and availability is inherently doomed to constant incidents.

@dougwade @zeyus I think there is a most right answer but it involves a lot of funding and I don’t have the funding

I’m not saying “fuck hobbyists and beginners” I’m saying maybe the code of hobbyists and beginners shouldn’t be pushed to the default global namespace of downloadable libraries widely used by schools, hospitals, governments, businesses and charities until someone else has signed off on it having undergone basic quality and safety checks

does that sound like it’d cost money to pay experts for their time? yeah. do I personally have the money to front for this? unfortunately no.

@0xabad1dea Sure, but the amount of code written by hobbyists that is also part of some critical infrastructure is *massive*. Mostly because it works really well (most of the time).
I don't see any system of code review that would scale to that level.

@tribut "there's too much hobbyist code in critical infrastructure to actually enforce basic safety standards" is itself a civilization-ending problem

I’m not saying “fuck hobbyists and beginners” I’m saying maybe the code of hobbyists and beginners shouldn’t be pushed to the default global namespace of downloadable libraries widely used by schools, hospitals, governments, businesses and charities until someone else has signed off on it having undergone basic quality and safety checks

does that sound like it’d cost money to pay experts for their time? yeah. do I personally have the money to front for this? unfortunately no.

@0xabad1dea @tribut the twist ending here is that the non-hobbyist code is worse, because the people who don’t want to pay for the basic safety checks aren’t actually the hobbyists.

(The solution is strict liability here for the people billing for software and services, no liability for the hobbyists, not “no warranty expressed or implied” for hobbyists charging you nothing and “that, but also mandatory arbitration” for corporations raking in billions)

@glyph @0xabad1dea @tribut The EU is trying that, right? Does Geomys have strict liability for all of Go? Or does Google? Why would Google let Geomys maintain Go if the liability falls on them? Does a maintainer with a Patreon have strict liability? What about a maintainer who scored their first $10k support contract, which is not enough to pay both taxes and E&O insurance?

I understand the desire to stick it to the man, but the system needs to be viable, not just desirable.

@filippo @0xabad1dea @tribut this is my point. Nobody pays for go. So nobody would have liability for it. Google owns google ads, and if google ads fucks up, google should be liable for it. If google pays geomys for assurances about go and those assurances are not met and damages result to google ads customers, liability can flow upstream. I don’t think this is how they are doing it in the EU, but I don’t fully understand their approach.

@filippo @0xabad1dea @tribut I think questions about whether e.g. a patreon incurs liability, have to do with what representations are being made. My (tiny) Patreon is mostly interested in software as bizarre performance art and blogging about my gripes, not infrastructure indemnification. But I also do tidelift, and I signed some contracts saying ai will follow certain security policies for that (tiny) portfolio, and I take those obligations seriously, so it’s different.

@filippo @0xabad1dea @tribut give me right-wing oil-billionaire think-tank levels of money and me and my staff will write you the whole regulatory framework in a few months, no problem

@glyph @0xabad1dea @tribut So would strict liability be mandatory, or something that can be offered as part of a contractual relationship? Because I don't see how the latter opt-in version is different from the status quo. As you said, there are already entities that do that. If it's mandatory, then you need a better answer to all the previous questions, because the rules need to adjudicate when it's mandatory and when it's not, and who it falls on. Clients do pay Geomys for Go.

@filippo @glyph @0xabad1dea @tribut at the moment there's no liability at all for most software failures. that's that whole thing about "no warranty, not even the implied warranties of merchantability or fitness for a particular purpose." if clickthrough agreements are taken at face value, nobody even has a remedy if a program turns out to be something completely different from what was advertised.

@ireneista @filippo @0xabad1dea @tribut You are correct that there need to be rules to adjudicate where responsibility for specific things lie. And there needs to be a pretty complex process of determining what constitutes "negligence" so we know when punitive damages are allowed. Not a process unique to computing. Here's a 20-page regulatory report on types of pickles https://www.ams.usda.gov/sites/default/files/media/PicklesStandard.pdf

@ireneista @filippo @0xabad1dea @tribut The principle that I'm advocating for here is just the implied warranty of merchantability, which commercial software vendors routinely disclaim or attempt to disclaim in their EULAs, with zero consequences.