We *need* standard protocols like ActivityPub, but ultimately, users do not want a protocol. People do not want a formless ball of infinite potential. They want "Products". They want a clearly presented thing that they can put into their web browser or phone and it slots them into a legible user flow satisfying a specific user story. This is not because they are brainwashed by capitalism. It is because most people *have other shit to do* and don't want to bother with software that's unfinished.

This creates a big problem, because in general we ("we" meaning "humans") aren't good at creating Things with singular, consistent visions unless there's a specific single human in charge of the entire vision. And "we" don't have many social structures that allow for a creation like that unless that single human winds up with inordinate control over the final creation, leading to either corporate control or (in OSS) "BDFL" projects where a single overworked maintainer becomes a point of failure.

@mcc Sustainability sans-BDFL can sometimes be achieved if the original creator manages to articulate the vision of the productized project well enough that others can rally behind that vision and keep moving it forward. Like a genie wish, though, it can end up with the original BDFL coming back and saying "No! Wait! Not like that though!" and you get successor projects like deno.

@isaacs deno actually sounded kind of nice to me, except I was turned off by it using its own package repo lol

@mcc I'm flattered, but despite the alleged oss rivalry, Deno in practice uses the same npm registry as the rest of js, just usually served through unpkg or esm.sh. And trex looks pretty promising. As more of the node world makes esm a first class path, the difference and inconvenience will diminish quite a lot, I think.

@isaacs To be totally honest it's not even I specifically "like" npm, I just remember the horrorshow period when npm and bower coexisted and tons of stuff on github supported exactly one which was a problem if you wanted to use TWO libraries in a single project. I don't want to have to *think* about whether whatever library supports the toolchain I'm using.