Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

261–270 of 353 posts

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

#261
post #65

Earlier quoted context omitted.

You dont need to wonder. Any long term maintainer of even semi popular open source projects will tell you that engaging with the peanut gallery is completely counter productive. Engage with people that have earned it in your eyes, whether by contributing to your project via code, assets, bug triage, writing a good and effortful bug report, whatever. Just ignore what the larger internet has to say about you and your c…

What form should this ignoring take, in your eyes? I’ve never maintained an open source project but I’d imagine this is the hard part, how to politely decline the peanut gallery’s feedback. Do you disable GH issues? Leave them open and ignore them? Decline with some boilerplate language? How do you stop people from being mad that you’re ignoring them? (IME these types of people are likely to take things personally an…

One example of a useful technique

https://serenityos.org/ apparently only makes source code available. There are no binary images of the OS to install

I think Andreas said this functions like a little test -- if you're not willing to build it from source, then you might not be a good contributor. Or you might not be seriously interested in the project's goals.

---

Likewise, my shell project provides source tarballs only, right now - https://www.oilshell.org/release/0.21.0/

It is packaged in a number of places, which I appreciate. That means some other people are willing to do some work.

And they provide good feedback.

I would like it to be more widely available, but yeah I definitely see that you need to "gate" peanut gallery feedback a bit, because it takes up a lot of time.

Of course, it's a tricky balance, because you also want feedback from casual users, to make the project better.

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

#262
At first I thought it was paranoid to suggest that people on the linked thread might be complicit in the attack but then I read this message:

  > You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?
It genuinely looks like we’re seeing a demonstration of supply chain psyops in retrospect. Amazing how sophisticated and patient this attack was.

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

#263

And this is why, for my build system coming out in two days, you need to pay to have me respond to bug reports.

That would stop a nation state or other nefarious actor because? This isn't spam that works in volume

It means I can ignore loud but non-paying users.

I also don't take outside contributions.

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

#264

Earlier quoted context omitted.

Say no, politely, with your reasons. If they continue to argue: 1) Unwatch the issue/block emails realted to the issue (setup tooling for this) 2) If they continue to harass just block them, they are a waste of your precious time and energy And yes they will go cry on reddit or HN or their own blogs and call you names. Ignore it. Be happy in the knowledge of the thousands or millions of people whose lives you have im…

This is certainly a good idea for the individual who is running a FOSS project.. But I think the projects with maintainers who bend over backwards for people are more often the ones that end up chosen and kept as dependencies when there are for example hundreds of compression libraries to choose from. The distribution game is kind of stacked for the most likely to burn out to be the most likely to be important in the…

It makes sense that this could have been an easy mistake to make in the past. Responsive people seem more interested and engaged. But I wonder if it would be best seen as imprudent now? If highly responsive maintainers are susceptible to burnout, then maybe people should consider those other algorithms.

Especially considering the responsiveness here is responsiveness to the peanut gallery.

It would probably be good for the maintainers too. If being responsive is seen as a way to have a bigger impact, people might be inclined to become more responsive and burn out.

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

#265

> This thread is a microcosm of the interactions in Open Source projects. Consumers make demands (some polite, some not-so-polite) of one maintainer (rarely two) that does everything. > Make no mistake. This is the way it works. > It needs to change. How?

Deny by default anything from a State that's hostile to American interests.

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

#266
post #86

Earlier quoted context omitted.

> 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.

Linux development is distributed (largely, between commercial entities), not really "open". If you aren't intimately familiar with the culture, you're likely to be ignored unless your issue also affects somebody who is.

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

#267
post #154

Earlier quoted context omitted.

A few minutes reflection on “who can I trust” would lead one to discard the extremely egalitarian ethos built up around open source software. But casting out meritless ankle-biters will immediately lead to being attacked as an unreconstructed egotist who needs to be hung from the neareat Code Of Conduct

I have never seen a code of conduct that would prevent a polite rejection of whatever new suggestion or help to a project.

I have never seen a Code of Conduct that emphasized that the overriding goal of all social interactions under the domain of project is to deliver a quality product

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

#268
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…

With a personal repo I maintain, I once had someone look me up on linked in, and then file a support ticket with my employer demanding I reply to his issue on github. He was asking for handholding following a clearly documented process and ignored all the warnings.

Needless to say, I did not assist him in any way and closed the issue as wontfix.

I've also had people demand that I expand the narrow scope of my project to cover a whole class of devices with completely different APIs, instead of the sole focus on the series from the same manufacturer of devices I own and use. Closed as wontfix as well with a clear statement that I will not be expanding the scope, but am more than happy to link to their project covering it.

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

#269

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.

As much as I support the privacy of maintainers I do feel like this is necessary to raise the bar for these types of social engineering attacks. However that would've likely done little to impede this attack if it is backed by organized crime or by a state as is being speculated. It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air.

It is trivially easy for those types of actors to simply use a stolen identity or create an entirely plausible one out of thin air.

Can you provide a historical example of when something like that has happened?

It sounds like hyperbole to say that it is 'easy' (even for a state) to impersonate a real-life identity or create one for a professional developer with a multi-year work history.

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

#270
post #58

Earlier quoted context omitted.

This ignores the very fact that peer pressure works and puts the entire blame on the victim. No, people react differently when pressured vs when not pressured. That's the entire reason why peer pressure works.

Peer pressure happens when someone like a teenager wants or has to be around some other peers (teenagers) but has to follow the whims of the peers in order to continue to be around them or to not be harassed by them. The peanut gallery of non-contributors are only peers in the sense that they pretend to speak on behalf of some OSS community. And the fact that they are spokespersons is by default suspect. The attacker…

If you think peer pressure is most relevant to teenagers, you really need to sit down and rethink peer pressure.
Post reply on HN