[2024-09-29 note: This was previously posted on Cohost, on 2024-03-31 at https://cohost.org/ireneista/post/5349137-xz-and-community but the irenes.space URL is the permanent one.]
so these thoughts are only partially formed, but... well, we just managed to get them out in conversation elsewhere so we thought perhaps we'd share them here. it's a bit rougher than many things we write about, so let us know how much sense it makes...
so. a few years ago somebody we respect told us we were wrong to use the word "community" for things as large and amorphous as, say, "the FOSS community". they told us that it only counts as a community if the people are invested in each other, if people KNOW each other and care about each other.
we've taken that to heart, and worked hard to be clear when we're identifying a group that is actually a community, vs. one that isn't. because as much as we might wish the free software movement to be a community, that doesn't happen by saying the word and hoping it'll conjure community into existence. it happens by people doing the work of learning to talk to and care about each other.
when we talk about, say, the queer techie community, we feel entirely safe in using that word. that's because every time we walk into a room with ten random queer techies, we already know three of them. the social connections are dense enough, and at the personal level they are meaningful enough - real friendships, people who'd fight together for survival if we had to, because of our common history.
it may sound idealistic or impossible, but essentially... regarding threats such as what we saw with xz yesterday, our proposal to mitigate them is to focus not just on the material need for code review, but on making that social graph more tightly connected, so that individual maintainers can have not just the financial or operational support they need, but the EMOTIONAL support.
if this sounds like a weird tangent, keep in mind that part of the story that came to a head yesterday was that the attacker used sockpuppets to essentially bully the project owner into adding a malicious maintainer. see the documentation collected at [1].
the bullying and manipulation tactics worked because those behaviors are rampant in the larger FOSS social space.
FOSS as a whole may be too large to change - it includes people who are doing this stuff for vastly different reasons, including profit. we think that's too broad an umbrella, we don't know how to rally that whole crowd. if you do, great, please go for it, but personally we're trying to rally under the banner of free software, which is a smaller umbrella of people who are doing this for fundamentally ideological reasons.
what those reasons are differs substantially, but... we're very proactive-death-of-the-author about this. the FSF has failed to provide ideological leadership due to RMS's top-down style, but many of the ideals are good ones and it's the job of the current generation to renew the movement if we want our children to be able to enjoy its fruits the way we did.
if we form a nucleus of people who are invested in each other and let that investment also mean checking in on each others' projects and stuff from time to time, well... communities are the terrain that movements happen on top of. we would never, ever make a community subordinate to a movement, community has to be its own thing, for no purpose but itself. but we do think that building community is a very powerful action to take, in the long run.
none of the supply chain security proposals we've heard seem like they would have actually prevented the xz attack. for all its idealism and for all the problems it glosses over, we do think our proposal could have.
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor