Ctrl Zee

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.

Totally agree with the conflict-avoidance answer. A small reframing: making mistakes is perfectly normal. A lie is usually an attempt to skip owning one.

What makes you a mature person is:

• Acknowledge it to yourself: nobody is perfect.
• Plan the recovery: there’s a fix for everything but death. An honest apology is often most of it.
• Own the fix: you dropped the bricks, so you pick them up. Don’t wait for someone else to do it.
• Learn from it: making a mistake is fine, repeating it isn’t.

A lie turns one mistake into two, and the second one is harder to undo.

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.

Practice :) A tiny deliverable after each chapter or tutorial, something simple you can finish in a few days. Accept that it will “fail” sometimes, that’s part of it.

The best bit: the doubts you hit while practicing tell you exactly what to learn next.

That’s how you get out of tutorial hell: you stop following the course and start following your own questions.

Not exactly a floppy, but close: more than 20 years ago a very dear person gave me an Iomega Zip drive and a couple of disks. Game changer. My hard drive was 40 MB, so for the first time my backup was bigger than my computer. Same speed, too, so not much of a sacrifice.

Later came the tiny Clik! disks: great as a music player, and perfect for carrying data around when 100 MB was a HUGE amount of memory. Through all my university years the Zip was my go-to. I just learned to pray every time I heard a click that wasn’t the brand name. :D

Good point @bold_omi.

I was playing with Linux back in the kernel 2.0 days. The tech was mostly ready for us geeks, but not for everyone else. Switching meant new habits, and “it’s free and open” was never a strong enough reason for most people.

People use big tech products for convenience: already installed, works out of the box, compatible with everything their friends use. Microsoft knew that playbook very well.

No matter how much we argue and explain, if it isn’t more convenient, most people won’t switch.

The silver lining: building small alternatives has never been cheaper

I see a lot of useful replies here.

I prefer to answer to 4 simple questions, helps me have a clear idea without overcomplicating:

• What success looks like. Be concrete: “in a year I want X”. If you can’t say it, probably it’s not the right time for the decision.
• The risks. What could go wrong, and how bad would it be? Money, time, people affected.
• The known issues. The problems you can already see today and are choosing to accept.
• The way back. If it goes wrong, how do I undo it, what would it cost, and when will I check? Put a date on it, like “in 3 months I review this”.

The fourth point helps you to determine how “big” the decision is. If it’s easy to reverse, decide fast. If it isn’t, slow down, sleep on it, and talk to someone who has already done it.

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.