That last sentence rings true of most software engineers. Everyone wants to work on a glamorous new feature that's going to wow users or let them think about problems they want to think about. No-one wants to hunt down the difficult-to-repro bug in an old but critical section of someone else's code.

For anyone wondering, here is the difference between uMatrix and uBlock Origin: https://news.ycombinator.com/item?id=24533329

When I stepped away from my own (mildly successful) Free software project, I had the same concerns: it's about the reputation.

The project had earned a decent amount of trust when I was running it, and presumably people were installing new updates without going over the changes. If I handed off the project to someone new, I wasn't just handing over the work, but that trust as well.

So rather than handing over the project to someone new, I archived it and someone else (thankfully someone not-evil) forked it. Anyone installing the fork immediately understood that the relationship was new. They'd have to decide whether to trust this new maintainer or not.

For my money, this is the way. If you're burning out, remember that your reputation is tied to your project name, and that it has considerable value. If you don't want to continue, the disruption of a fork is better/safer than the smooth-but-risky hand-off.

Fuck you

Respectfully,

Linus Torvalds

Respectfully of course.

Like "Fuck you Nvidia"?

Respectfully

I'm more of a fan of responding in kind. Manners may cost nothing, but so does clear communication.

Easy to say... Not so easy to just do it, specially if you're burned down..

No. I won't not do that. For security reasons.

Theo is even more strict than Linus.

I think it can depend on how and why you're being pushy too. I've definitely had to have my fair share of passionate conversations and strongly advocating (yes, you could say pushing) for what I believe is best for the direction of a project with my fellow maintainers, especially when it comes to important things (like how to handle specific security issues etc since there's not always one way of handling it). Generally speaking though you're right.

Anyone pushing you to do something you don’t understand, or understand poorly.

This was taught to me in my bank teller training back in 19-dickety-two. Don’t let someone try to rush you or to obfuscate/over-complicate things.

Regardless of flipping the dynamic, that's a good way to avoid scammers. It's easy to spoof an incoming number, but near impossible to intercept an outgoing call. If your "bank" calls and starts asking funny questions, just hang up and call the real bank to check.

The problem is when people then open huge PRs and expect you to take time to review them, then eventually merge them.

Especially when it's something you don't want in your codebase because it introduce a big unnecessary "refactoring" or a feature that you don't want to have to maintain forever.

That doesn't apply as a solution here. After all Jia Tan did make pull requests, the pressure came later.

The compile process was modified to decrypt and unpack the "corrupted" test zip file, which was actually a code patch, and apply said code patch before assembly of the final binaries.

They were not shipped to the client. They were shipped to the build system, executed there after deobfuscation, and they inserted an additional, opaque program file into the build process.

It is way more complicated than that. Very good explanation, I could never do it justice.

Edit: I found an even better one https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

It's common to bundle test artefacts with the release tarballs. The reason is that when Linux distributions build the software from the tarballs, they often run the tests to ensure that they pass.