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

@riley@toot.site Oh yeah, so do I... I've actually been working on an alternative implementation of Nix (on-and-off) that *should* be both faster and more hackable - with a bit of luck that'll allow for experimenting with better UX!

@riley@toot.site Oh no :(

@riley@toot.site Like, there was a bunch of frustrated discussion a while ago about flakes being widely used already despite still being technically experimental (and therefore having breaking changes), I'm just hoping here that the problem isn't even worse

@riley@toot.site Wait, that's only the case when flakes are enabled, right? Or always?

@riley@toot.site Wait, which change was that?

@riley@toot.site The flakes stuff?

@kaasiand So close :D

@skaryzgik My main takeaways from this would probably boil down to:

1. Make cultural and social expectations *explicit*; be clear about what your values and goals are as a community, instead of expecting word-of-mouth to do the job. And I don't just mean "don't be a bigot", but also eg. the anti-capitalist values that are necessary to maintain a healthy public commons.

This also includes 'community consensus' values - for example, deliberately leaving space for living standards designed by the community, and carefully ensuring that any central steering organization doesn't interfere with those, and preferably *adopts* them.

2. Do not ever accept for-profit organizations as "full" members of the community. By definition, they will always place their own interests above those of the community, and they should be treated accordingly - as threats to defend against, not as contributors.

They might *use* the tech, but it should be clear that they're not really wanted in the community, and their needs and interests should be actively deprioritized compared to those of individuals and grassroots non-commercial organizations.

Any funding from them should be very carefully considered - money rarely comes without strings, even if they're not always written down, so this is something to be extremely cautious with.

3. *Particularly* dangerous - this is what killed npm - is the sentiment of "oh yeah, I know they're a business, but they just need to put food on the table, they're good people, it's not like it's Google".

Sounds reasonable on the face of it, but corporations exist independently from their founders, and will almost never follow their founders' ethics. In practice, npm was a VC-funded corporation that acted in the interests of its shareholders, and this meant that VCs controlled the fate of the public commons.

The same is true even for small for-profit companies. *Never* let the fate of your community rest on what is legally a for-profit company, no matter how nice and friendly the owners seem. If you must formally incorporate, at least make it a non-profit that is controlled solely by individuals, not by for-profit actors.

Granting control over any critical part of your ecosystem to a for-profit organization is not only unnecessary, it's also playing with fire.

4. Take concerns about the health of the ecosystem seriously, and make it an integral part of your culture to evaluate such concerns seriously whenever they are expressed. Don't default to "I'm sure it'll be fine" or "but can you *prove* that there is a problem".

Very often, a small handful of people will spot problems early, before they become obvious. Take those people seriously. They may not necessarily be *right*, but they're not crying wolf for no reason.

@evelyn@misskey.bubbletea.dev Yeah, the mismanagement of npm was definitely a big factor in it all. Not everybody at npm were twitter liberals, but many of the vocal policy-deciding folks definitely seemed to be, and had no real understanding of the implications of their decisions.

@emilis I think that's only half the problem, though - it wasn't *just* an Eternal September-style overrun. There also just genuinely wasn't much documentation on the culture, nor structure to it! The only reason I learned about this at all, was because I literally met one of the early adopters (substack) at a tiny "revolutionary tech" conference.

So I feel like this *could* maybe have been prevented, if there was enough of an established and *documented* culture, instead of relying on word-of-mouth via two dozen early adopters - that probably would also have prevented the hype cycle, though, but that'd probably be a good thing really.

@IceWolf I'm not optimistic, unfortunately. The thing is that the problem extends beyond just npm - the collaborative, consensus-based culture has rotted away at every level (despite attempts for several years to change that), including the language core team itself. It's incredibly difficult to wrest away that control from a now-established hierarchical power structure, especially one this big and influential.

I still tried to work on changing it for many years because of the large existing ecosystem, the large public commons to save - but that public commons has been rapidly falling apart over the past several years, and I now feel like it's gotten so bad that it's genuinely easier to start from scratch with a new language + community that establishes the right culture upfront :/

On Twitter, the bias seems to be slightly different! An *even stronger* bias towards the third option, but the first option is no longer the least popular.

At least in the 'a' poll, they have hidden nbsp's; Mastodon wouldn't let me toot identical options :)

@welshpixie Yep!

@welshpixie

Room IDs are purely a (permanent) identifier, they have the original server's domain added to it to avoid naming conflicts, but because rooms are decentralized and don't exist on a specific server, a client can't just take that domain and run with it - the server might not exist anymore even if the room still does.

Room aliases *can* be used because you can have multiple of them (on different domains!) pointing at the same room ID, and while a room alias will stop working when the server in question goes down, that won't affect the room *itself*, which will work fine. It's only relevant for being able to join.

matrix.to links include both the room ID and *multiple* servers that are in that room, making it more likely that after a long time, the link will still work to join the room, because at least one of the servers in the link will still be alive.

Ultimately all this is just about *joining* a room; once you've joined, your homeserver is federating with the room, and it will continue working forever, no matter what happens to any other server.

@welshpixie That won't work, unfortunately - it's just a room ID, which (despite appearances) doesn't tell you what server to talk to to join it.

There are roughly two ways to share a Matrix room:
1. Sharing a room alias, which can be created in the room settings, and starts with #
2. Share a matrix.to link, usually your client will have a 'share' button to get one

Can't help but feel like there's some positional bias in the polls...