Why do you care if a murderer wrote your filesystems?

I care about the security and correctness of the code. I only care about the author who wrote it if they are someone known for low-quality, insecure, or malicious code.

If Linus Torvalds is convicted of genocide and child abuse tomorrow I'm going to continue using Linux as usual.

That's fine for you. But other people can have objections to it as is their right to.

If you're part of a group and a chunk of them decide to leave, there's no point saying "why do you care about X? It doesn't affect the group."

It's their right to leave.

The other side is that who you associate with defines that group. So if it was a murderer that wrote a file system, then the software project gets defined by that.

It becomes hard to attract contributors when the project gets defined by the actions of one of its participants. Project leaders then have to make a decision since inaction is also a decision.

It is their right to leave, but is it their right to shame unrelated people who do not want to leave?

There is a point where the shaming and shunning stops being useful and becomes bullying.

We see this all the time in politics worth people liking "their team" too much and denigrating normal citizens just for their opinions and choices.

"It becomes hard to attract contributors when the project gets defined by the actions of one of its participants."

I'm unaware of anyone ever making a decision about contributing to a software project based on secret police level surveillance of current team members political or religious opinions. Even classified DoD stuff I've been involved in isn't that creepy.

Its important to focus discussion on extremes such as murders when the actual goal is to make sure Republicans are unemployable.

You're changing the contents of the article though; it's about "communities", not software products. It's much easier to separate code from persons; strip off the committer name / email and you're left with code which rarely contains anything behavioural besides maybe inappropriate jokes / puns which are usually easily fixed. Not so with communities, which are much more about people and interactions.

For context: https://en.wikipedia.org/wiki/Hans_Reiser

I read the article, thank you. It is completely fine to have a murderer write your filesystems. Accepting patches from someone who writes good code and treats everyone involved with respect is the right approach.

Devil's advocate on this - what if the general population of your customers don't want to support a company that pays the salary of a murderer? Then it affects your bottom line. Would you still be ok with it?

This is about FOSS projects, which are generally unpaid.

What about accepting non trivial patch from someone who smuggled backdoor for lulz to another project 3 years ago?

Fraud is very different from murder, and I understand why someone would be worried about accepting contributions from a known fraudster.

I would not give their contributions extra attention (you should be suspect of all changes, regardless of the author) and I would not ban them from contributing unless they became disruptive or subversive to the project.

They served their time; you don't need to punish them further. They are probably even less likely to commit fraud when their employer is aware of a previous fraud conviction.

The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor.

> They served their time; you don't need to punish them further.

It is not about punishing them, it is about reducing the risk of others. Having served time is, at best, no indication of whether a person will revert to their former behavior.

> The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor.

This is no reason for not using what information you do have.

Note: I see that you have edited your original post to address these points, but I think they still stand, as expanded on in the continuing discussion below. Your statement "they are probably even less likely to commit fraud when their employer is aware of a previous fraud" seems to be in agreement with what I have been saying.

It's a reason to be equally suspicious of all code changes regardless of the publicly known reputation of a contributor, as it always comes down to the code itself.

You are still arguing against using the available evidence. You never have the time and resources to fully validate anything of use, so you have to use your judgement as to how best to go about it. If you learn that a person responsible for some aspect of security has been found guilty of defrauding his church's charity drive, it would be prudent to take a second look at his code.

Absolutely. Then again, code review is never perfect and it is easy to miss hard to see cosequence of something subtle. Especially if I tentionally hidden. So, trust matters. If you have track record of doing such things, then accepting your pull request comes with higher risk.

This is a good example, I agree that such a person probably isn't welcome - with a few caviats:

- Small (and well scrutinized) patches from this person are fine

- At some point forgiveness is due, maybe 3 years is at that point depending on the severity of their backdoor