Thanks for sharing such a personal story, Repair Cafés are a great idea, especially nowadays when “old tech” is still perfectly usable.

Curious: what were the biggest challenges you faced when setting one up?

Same here. Vibecoding my own tools is fine, because I’m the one who pays for the bugs. A kernel patch is different: thousands of people pay for them, so understanding every line is the minimum.

Anyone who sends code to public software should follow a simple code of ethics. A low barrier to entry is great, it’s how most of us started. But the bar for responsibility should rise with how many people run your code, and right now it doesn’t.

It’s an unfortunate news, burnout in open source was real even before AI. Now it has just exploded.

Reviewing code has always been a bottleneck. AI made sending a patch nearly free, but reviewing one costs the same as ever, and it lands on a few volunteers.

For code that millions run, someone has to understand every line, so the sender should do that work, not the maintainer. Otherwise you’re just moving the cost onto the people who can least afford it.

There should be a simple rule: if you can’t explain your patch line by line, don’t send it. And maintainers should feel free to reject any patch by default when the sender can’t explain it.

Excellent advice, you don’t need anything complex, just install git and you’re good to go.

Think of a commit as a save point before the boss fight. One rule is enough to start: commit every time something works, and always before trying something risky. Write the message as if for yourself in six months.

The server can wait until you have something worth losing. Just remember git on one disk isn’t a backup: copy the folder somewhere else now and then.

I get the appeal of a self-hosted tool, but my suggestion is to do the important ones in person.

When I ran a Linux group years ago, the decisions that mattered were settled around a table. For a big decision, the dialogue and the discussion that lead to a common agreement are the real work, and in my experience no software does that part for you.

For small stuff, a simple poll (or no poll at all) is fine: the core team decides and shares it as information. Save people’s attention for the decisions that need it.