Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

241–250 of 353 posts

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

#241

Serious question, but what is your expectations for linux and all these libraries/dependencies after 20-40+ years when most of old school or current devs are retired? How can anyone guarantee reliable continuity by good actors in all these dependencies?

Steve Jobs said that someone needs to be the keeper and maintainer of the vision. I think that’s the key to the making of anything great over the long run: there needs to be a Benevolent Dictator For Life who has the vision, competence, energy, passion, and caring to consistently iterate the thing well. The best case scenario for a project that loses its BDFL(s) is to hold on maybe as decently as Apple has under Tim…

44% of active open source projects have only one maintainer. Out of all maintainers, 60% would describe themselves as unpaid hobbyist.

They already are BDFL for themselves or one other person. The problem is a chronic deficiency of maintainers, which is at the root of this attack.

Your comment implies there is a wide pool of peoplecwho want to do that, along with mythical "someone".

Here is a little story:

There was an important job to be done and Everybody was sure that Somebody would do it.

Anybody could have done it, but Nobody did it.

Somebody got angry about that because it was Everybody’s job.

Everybody thought that Anybody could do it, but Nobody realized that Everybody wouldn’t do it.

It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.

- Charles R. Swindoll

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

#242
> ”Progress will not happen until there is new maintainer. … The current maintainer lost interest or doesn’t care to maintain anymore. It is sad to see for a repo like this.”

While this might be a sockpuppet deliberately manipulating the maintainer, the tone of this post is all too common, and the real thing that pisses me off is actually that last sentence.

The use of the words "sad", "shame" and "pity" have been weaponized by a generation of people to dump negative emotions onto to overworked/understaffed people in issue trackers.

If you're using those words to express an opinion in an issue tracker, you're probably being a fucking asshole.

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

#243
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 projec…

That LKML episode always makes me feel pretty bad. Mauro Carvalho Chehab maintains the ZBar project now. I briefly worked with him when I sent some patches in for a feature I wanted. There were things I had to address that I hadn't even considered and he worked with me all the way, ended up learning quite a bit about DBus. He's an awesome maintainer and set the bar for me for what qualifies as a great experience in contributing to free and open source projects.

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

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

I have a tag for my issue tracker that's called “maybelater” which is my polite version of “wontfix” (which I also have); I use it for stuff that might be reasonable, but I have no intention of (ever?) working on.

If you're working on open source as a hobby (as I do), you should make this very clear to your users. You work on stuff you want to, at the pace you find enjoying. You don't take contributions you think will be hard to maintain. You make it clear you don't owe anyone anything. You also accept that, often, the best answer to an issue/contribution/disagreement is a fork.

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

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

My layperson’s opinion is that anything to do with gaming is particularly riddled with people that interact poorly with maintainers. Again, purely my opinion: gamer culture invites a particular sort of Dunning-Kruger-prone ‘power user’ type. Every gamer community carries with it a corpus of baseless, fictitious, technical information. “The developers didn’t do this because x”, “it’s ridiculous that they didn’t just y…

My favorite know-nothing gamer meme these days is "bad optimization". What they mean is that the performance is worse than what they would expect (?) on a given hardware configuration and game settings.

They haven't poked around with RenderDoc, they don't have the debug symbols to profile the CPU code, they have zero idea what kind of work the software needs to do, they simply know the lazy devs have failed to "optimize" their game.

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

#248
post #190
post #179

Earlier quoted context omitted.

Agreed, which is why IMO ssh in production is a terrible idea that reveals even worse problems. A server with ssh generally implies there is a shell, and cli tools, and an administration model that involves humans connecting to servers to manually update them in place like pets. Having a full workstation-optimized distro like ubuntu or debian with hundreds of packages constantly shifting and updating as a critical pr…

> Production servers should be hardened immutable appliance kernels with read only root filesystems that verify and run signed containers, or run a tiny shim init system in a couple hundred lines that spawns a single application specific binary you trust. And then you need to debug something. What do?

Debug it with a binary with debugging enabled on a debug dev system. Just like you would any other immutable firmware appliance.

You could also in some cases have a debug container you pull in on demand, say if the host OS is an appliance-style k8s runtime like TalosOS.

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

#249
post #190

Earlier quoted context omitted.

> Production servers should be hardened immutable appliance kernels with read only root filesystems that verify and run signed containers, or run a tiny shim init system in a couple hundred lines that spawns a single application specific binary you trust. And then you need to debug something. What do?

Have good logging and virtual machines that can replay those logs offline?

One of many viable methods depending on the application, yes.

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

#250

Earlier quoted context omitted.

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…

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 stack and in desperate need of help.

Post reply on HN