Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

81–90 of 353 posts

Re: Xz: A microcosm of the interactions in open source projects

#81
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

The points you make aren't unreasonable.

It is necessary to establish clear boundaries of what can and can't be provided by the maintainers. If not done at an earlier stage of the project, the support burden becomes too much to bear at which point the maintainer transfers ownership, and the project suffers from catastrophic consequences such as the xz backdoor we're talking about here, or other cases where the project mostly stalls and serves as an ego-boosting platform for the new maintainer, as was the case with PhantomJS[6] before it was shut down.

This can also happen in your life, where a "friend" sees that you possess a certain skill, and then gradually tries to push an inordinate amount of their personal work related to this field onto you.

Personally, I think it's best to use an approach with extremely clear communication as to what the maintainer can and cannot provide. This can be seen, for example, in yt-dlp[1], where the consumer is clearly informed upfront that not providing detailed information as requested will lead them to block said consumer; or sqlite where their position regarding contributed patches[2] and support[3] is similarly made clear.

Having a shouty BDFL like Torvalds can also help improve code quality[4] and questionable contributions[5], though it is better that the shouty BDFL makes statements that are professional and do not show as much aggression; so for example, "Mauro, shut the fuck up"[7] would become "Mauro, your response is completely unbecoming for a Linux kernel maintainer, and is not in line with the promise of not breaking userspace."

[1] https://github.com/yt-dlp/yt-dlp/issues/new?assignees=&label...

[2] https://www.sqlite.org/copyright.html

[3] https://www.sqlite.org/support.html

[4] https://www.theregister.com/2024/01/29/linux_6_8_rc2/

[5] https://cse.umn.edu/cs/linux-incident

[6] https://github.com/ariya/phantomjs/issues/14541

[7] https://lkml.org/lkml/2012/12/23/75

Re: Xz: A microcosm of the interactions in open source projects

#82
post #61
post #38

Earlier quoted context omitted.

This is why OSS can be more secure. How much software has the build scripts, the code, all of it, locked away and hidden behind propriety software? Instead of lots of eyes, just 2 DEVs? Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to eve…

I think there are huge factors that push things both for and against open source here. Yes, you get more eyes and people like Andres Freund. However, if this had been a mole in a company, he wouldn't be able to hide behind a possibly anonymous fake persona and (likely) be immune from any consequences/fallout from this attack. It would be harder to gain entry in the first place, he would have needed a real identity. B…

And yet industrial espionage in companies is quite common, by both competition and, if you’re big and important enough, state (yours or enemy). The means are different, though.

Re: Xz: A microcosm of the interactions in open source projects

#83
post #8

Earlier quoted context omitted.

That assumes the maintainer wants to be paid. There are plenty of us who maintain FLOSS projects that do it for other reasons and any monetary exchange would burden us, since it might pressure one that this is now a job and you have to execute on tasks - there are enough headaches handling other things as it is.

Agreed - I already have a job where people come asking. If developing OSS came with obligations, I’d do something else instead.

That’s of course a fine approach for you. I think a big part of the problem in this case is not with the maintainer, but with the critical software that took a dependency on this hobby project (in the maintainer’s own words).

Re: Xz: A microcosm of the interactions in open source projects

#84

I'm starting to feel that one of the lessons here is that individuals invited into trusted positions should be identifiable. Jia Tan is not a real person. We don't know who they are, so there is no way to hold them accountable.

While all of this is of course quite serious, we also need to remember that these types of things are actually fairly rare. Last major one was that JS event-stream thing, and that was in 2018 (5 and a half years ago).

I don't think this is really a structural problem requiring these kind of sweeping changes; it's just an occasional rare incident.

Re: Xz: A microcosm of the interactions in open source projects

#85
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

>There's a natural belief that unless someone is egregiously out of line, all discussion around a project from users is allowed, even encouraged.

I mean sure, but how do you intend to stop people? You can't stop them from setting up a forum somewhere.

This is why github discussions is useful though. A feature request in a ticket is something that needs to be handled. A feature request in a discussion is just some users talking about stuff they think would be cool.

Re: Xz: A microcosm of the interactions in open source projects

#86
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

> Even writing it down here I'm worried I sound like I'm trying to curate a closed community of ego-boosting yes men. There's this weird trend that's been happening for some time now that tries to make non-fully-open groups look wrong, but honestly, has anything ever actually been done by such open groups? As far as I can tell, "closed community" is a necessary (but not sufficient) condition for any kind of quality c…

I think the linux kernel developement is quite open. But Linus is famous for telling people directly in not so nice words, that they are not helping.

I don't think insults are the solution, but giving a clear no, is a skill many people struggle with. And if some cannot cope with that, blocking individuals also works.

Re: Xz: A microcosm of the interactions in open source projects

#87
post #11

Earlier quoted context omitted.

Huh? So anyone who asks/says something in OSS, should just throw money into the ring to have an opinion?

No. But if the maintainer is burning out and doesn't have free time available for it, paying them so they can take time off to actually work on the thing is a nice way of fixing issues.

I don’t understand this view of “If I give someone unsolicited money, they will do what I want”.

Re: Xz: A microcosm of the interactions in open source projects

#88
post #31

I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…

[deleted]

Re: Xz: A microcosm of the interactions in open source projects

#89

So the first step of this huge mess was: a social engineering attack. Attacking a tired, burnt-out open source project developer and peer pressuring him into giving more control of the repo to the attacker.

Occams razor says that those commentators were not in on it; that pressure is common on all projects, there is no need to think that they were part of an attack.

In fact, Occam’s razor says that the malicious code was injected by a compromised account and not a malicious actor who spent years steadily getting into position to attack?

Re: Xz: A microcosm of the interactions in open source projects

#90
post #52

I'm starting to feel that one of the lessons here is that individuals invited into trusted positions should be identifiable. Jia Tan is not a real person. We don't know who they are, so there is no way to hold them accountable.

No. https://geekfeminism.fandom.com/wiki/Who_is_harmed_by_a_%22R... >

I despise real name policies on social networks, but it's a very different thing to be anonymous while in a position of public trust.
Post reply on HN