Live data from Hacker News

Xz: A microcosm of the interactions in open source projects

robmensching.com

301–310 of 353 posts

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

#301

As a maintainer of a security-oriented open source library, the paranoia of "is this person trying to help or to exploit?" weighs down on me every time I have to read a PR (EDIT: even though the libraries are by no means as widely used), regardless of whether it's from a long-time contributor or someone new. I think accepting a slower pace of development is the only viable solution (as I'm not interested in making th…

> As a maintainer of a security-oriented open source library, the paranoia of "is this person trying to help or to exploit?" That's an excellent mind set when reviewing code, no matter security or not. But especially for security. How could this be wrong? What are the corner cases? How could anyboy break this? What do we need to test? That kind of scrutiny is crucial for keeping the quality of your code base high, no…

Yes but that's a huge amount of work, and is not the 'fun' part of coding. It's one thing to have to spend those cycles looking for errors or incompetence, and hopefully helping the contributor improve their skills so they can in turn help the project more in the future. It's quite another to spend even more energy being suspicious and looking for subterfuge from someone that has been one of your most helpful contributors.

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

#302
post #266
post #86

Earlier quoted context omitted.

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.

Being open for collaboration does not mean anyone and anything is welcomed. But I could just write to the kernel mailing list (I think, it used to be like this) - but yeah, since I am not a kernel hacker, I do not have anything meaningful to contribute, I would be ignored, or told to shut up - as it should be. I won't go there and say "hey you know, it would be really good if linux would support xyz ASAP". I have no right to do this and this would not be welcome - yet in many other open source projects, this is quite the norm. People come with this expectation. Some even might have donated 5$ and think now they own the place. Well, no.

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

#303

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…

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.

You're not wrong, and that's the first mistake: the individual running a FOSS project wants to see their project succeed and willingly bends over backwards to make it so.

The more you care about popularity, or even acceptance, the more vulnerable you are.

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

#304

> This is the way it works. It needs to change. Well, it’s on you to set your boundaries. "Feel free to submit a PR" works wonders.

Be careful what you wish for. Someone will eventually take you up on that challenge. The responsibility will lie with you when they do make that pull request. Is that something you actually want? I gotta ask because it seems there's lots of people out there who are saying that but don't actually want it to happen.

Look I get it, it's a great line, it instantly weeds out anyone who can't code, it even filters out those who can code but don't actually care enough about your project. If you choose that route though, you better be prepared for the day when the fabled PR finally arrives in your inbox. You told them to do it themselves if they wanted it so bad, they went and did it. Even though you know your code base and could probably have implemented it 10 times faster than they did, they labored over it to spare you the trouble instead of begging for the feature in your issue tracker. You asked to see the code, you got the code. Now the buck stops with you.

Seriously, if you say this, be ready to engage with whomever does show up with a patch. Unless they send you literal irredeemable garbage, the least they are entitled to is your sincere peer review. Nothing's worse than putting in effort into learning somebody else's project and writing the patch, only to not be given the time of day, or worse. I'd rather have a Linus Torvalds type take a big shit on the patch in public than be ignored like that. Someone who does that is at least treating you like a peer.

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

#305

Earlier quoted context omitted.

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…

Someone has to step up. Someone's got to care. Someone this. Someone that. Who if not you? When if not now? Be someone.

What are you people talking about? I wasn’t saying it’s not something I would do. I was just stating what is needed for a project to thrive after the person or people who started it leave: someone has to fill the void left by the departing person or people, and that void is ‘keeper and maintainer of the vision’.

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

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

This is fundamentally a problem of perspective. As the guy using software X you believe you are doing open source maintainers a favour by going there and telling them about a thing that is wrong or missing in your opinion.

But we all should realize that any interaction also comes with a cost. If you report a problem and don't manage to describe it well it doesn't help the maintainers one tiny bit, in fact it might just create work and a bad feeling.

So my approach is to "just" write stellar bug reports including ways of bisecting where the problem might come from.

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

#307

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

let's add passport (and visa) checks to github

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

#308

Earlier quoted context omitted.

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

How would that help with the problem of people being rude to unpaid OSS maintainers?

Rude is subjective and words are not violence.

I think the OSS worked as intended.

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

#309
post #296

Earlier quoted context omitted.

It is certainly the most obvious and kind of archetypal kind of peer pressure, which doesn’t mean that it’s exclusive to teenagers.

That's still thinking of it the wrong way. Peer pressure among adults is far more widespread and powerful than the limited peer pressure among teenagers.

What do you think like means?

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

#310

Earlier quoted context omitted.

How would that help with the problem of people being rude to unpaid OSS maintainers?

Rude is subjective and words are not violence. I think the OSS worked as intended.

>Rude is subjective

The person you replied to accepts the supposition that some users of open source software are rude when they interact with the developers, and asks how this could change. If you don't accept the premise that some users are rude then you can't pretend to answer the question.

>words are not violence

And? If your coworker reaches into your desk drawer while you're not looking and takes money out of your wallet that's also not violence, yet I imagine you would not think it's acceptable behavior just for that reason.

Post reply on HN