this post was submitted on 31 Mar 2024
582 points (97.5% liked)

Open Source

38012 readers
30 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
582
“the lesson I'm choosing to take from xz, as an oss maintainer, is that anyone trying to pressure or guilt me into doing something should immediately be told no, for security reasons” (crabby.fyi)
submitted 1 year ago by [email protected] to c/[email protected]
57 comments fedilink hide all child comments
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 112 points 1 year ago (3 children)

In some open source projects there is a lot of leeching and little contributions.

In 2020 the sole developer of Invidious stepped away from development because of burn out. https://omar.yt/posts/stepping-away-from-open-source

Also in 2020 developer Raymond Hill archived the uMatrix browser add-on https://news.ycombinator.com/item?id=24532973

I will never hand over development to whoever, I had my lesson in the past -- I wouldn't like that someone would turn the project into something I never intended it to become (monetization, feature bloat, etc.). At most I would archive the project and whoever is free to fork under a new name. For now I resisted doing this, so people will have to be patient for new stable release.

What would actually help is that people help to completely investigate existing issues instead of keep asking me to add yet more features. Turns out people willing to step in the code to investigate and pinpoint exactly where is an issue (or that there is no issue) is incredibly rare.

[–] [email protected] 29 points 1 year ago

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.

[–] [email protected] 21 points 1 year ago* (last edited 1 year ago)

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

[–] [email protected] 14 points 1 year ago

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.

[–] [email protected] 78 points 1 year ago (2 children)

Lol, you don't already operate this way in life?

Someone trying to guilt or pressure you has an agenda and isn't concerned with what's best for you.

[–] [email protected] 41 points 1 year ago

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

load more comments (1 replies)
[–] [email protected] 51 points 1 year ago (1 children)

Yes, you should totally do that. DO IT.

[–] [email protected] 41 points 1 year ago

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

[–] [email protected] 48 points 1 year ago (1 children)

Open source is such a wild west at times.

You have your gatekeepers like Linus Torvalds who will call you a fucking moron if you submit something that looks remotely off.

You have your committees that you can submit a MR, but it has to go through the council of experts before it gets merged.

But the vast majority, it's a one or two person project and this was a side project because you had an issue you wanted solved. No financial reward, no acknowledgement. And so when someone gives it a iota of attention, you fall head over heels and hope they are like-minded and want to support this dream too.

[–] [email protected] 7 points 1 year ago (1 children)

Theo is even more strict than Linus.

[–] [email protected] 31 points 1 year ago* (last edited 1 year ago) (1 children)

I've always taken this attitude towards pushy people and tbh this is more or less why. Being pushy like this is inherently suspicious as fuck.

[–] [email protected] 6 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] [email protected] 3 points 1 year ago

Yeah, that's fair, there are driven people, and people who are pushing for something, right, but in this case, look at the language used:

Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn't care to maintain anymore. It is sad to see for a repo like this. [src]

Tons of emotional button-pushing and pressure, but not on technical grounds. Just trying to make the dev feel crappy about themselves.

[–] [email protected] 25 points 1 year ago (1 children)

Anyone pushing you to do something you don't understand, or understand poorly. I could see an actual security researcher pushing for a code update to fix a vulnerability.

Heck, even as an occasional contributor I take some pride in seeing my fixes etc make it into the mainline codestream.

But yeah, you definitely need to be wary of somebody you only know from online pushing a change that doesn't make sense or you don't understand.

[–] [email protected] 8 points 1 year ago

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.

[–] [email protected] 19 points 1 year ago (2 children)

I've always been a fan of "pull requests welcome" when someone asks me for something.

[–] [email protected] 13 points 1 year ago (1 children)

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.

[–] [email protected] 3 points 1 year ago (1 children)

I can’t imagine just opening a giant PR without having extensive contact and coordination with the maintainer. Almost any amount of incremental safe steps would be preferable to a giant PR, even with extensive communication. I once introduced fully strict typescript into a vanilla js codebase and it took dozens of small PRs to do so. It was made more complicated by the fact that it was a library, but still. The communication made the entire process smooth and let everyone be confident the changes were correct along the way. If I’d done it all at once without any coordination, it would have been faster for me, but at the cost of the maintainer’s sanity and time.

[–] [email protected] 2 points 1 year ago

The point is that saying "pull requests welcome" is still work for the maintainer, because now you have to have these discussions with potential contributors, sometimes explain them why you don't want to maintain the feature, or explain them why this PR is not the way you want...

So either way it's work, it's important to keep in mind before saying "just send a PR".

[–] [email protected] 5 points 1 year ago

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

[–] [email protected] 14 points 1 year ago (1 children)

Honestly that should go for all transactions. someone calls you to fix an issue or pressure you into buying something. Just hang up and call the company back. one thing I have learned from many years of support is the person calling always has power over the person being called. So flip the dynamic. same goes for car sales just walk away. hell go look at cars when you don't want one and practice just walking away and see how much power you get.

[–] [email protected] 2 points 1 year ago

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.

[–] KillingTimeItself 12 points 1 year ago (3 children)

as a non developer myself, to my understanding, the vulnerabilities were implemented in test binaries?

If so, i question why those were shipped to the client. Unless they were built into the package itself on the mirror, in which case, still curious as to why that would be. I would think tests are entirely benign and do nothing. Seems like it would be incredibly bad practice to do otherwise?

Seems like an obvious vector to shutdown any potential fuckery. But what do i fucking know.

[–] [email protected] 23 points 1 year ago (1 children)

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.

[–] KillingTimeItself 1 points 1 year ago

hmm ok. Yeah idk, even from an organization aspect, i still wouldn't consider that to be ok. Test files that patch code on the fly is a recipe for a nightmare of maintenance. Which i suppose is the idea here considering that it's malicious code lol.

[–] [email protected] 20 points 1 year ago (1 children)

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.

load more comments (1 replies)
[–] [email protected] 17 points 1 year ago* (last edited 1 year ago) (1 children)

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/

[–] KillingTimeItself 1 points 1 year ago

i know it's rather involved, i've been tailing it from the sidelines, though like i said, i am not a developer, so in terms of code and maintaining code im blind there. But everything else i understand.

It's definitely an interesting situation to observe.

load more comments
view more: next ›