I know I'm a tiny fish in the game, but because of the behaviors of Red Hat employees, I am disenclined to purchase products they make, and even use Linux as a whole. People ask my advice, I give it, but don't have control over pursestrings, or anything like that. However, the behavior of Red Hat employees, like Poettering, Sievers, and Drepper before them makes me believe that Red Hat is not an organization that does a good job of creating leaders. The aforementioned people are poor stewards of projects, showing poor technical decision making and poor communications ability, and it reflects poorly on the organization as a whole.
Poettering, being a high profile employee of Red Hat, is one of the faces of the company. Because of this, I would argue that Red Hat has a duty to step in from time to time to tell him that what he is doing is harmful in the long term. If they don't do it soon, I can almost guarantee there will be a lot fewer support contracts for Red Hat in the months and years to come; they just don't create dependable developers.
What you're doing is a bullshit power move in attempting to threaten someone's job because you don't like their attitude. One discussion where someone was an arrogant douche might be outweighed by the sum total of all their contributions.
If all Poettering did was community outreach, you would have a much stronger case that he's bad in all aspects of his job and should be fired. Trying to pressure Red Hat by saying it 'reflects poorly on you' is basically saying 'you should get rid of this guy even if you think the good outweighs the bad, because I don't like him.'
No, this is a decision on the fact that he has made many many discussions where he was an arrogant douche. This is a decision made where he's made many many technical flaws, such as including the fundamentally broken efivarsfs in systemd, in choosing poor defaults for other portions of systemd, like pointing the default ntp server against a source which says not to use it as such, like in making the easily-corrupted journal an inexorable part of systemd. He has a long track record of making questionable decisions and then getting downright petulant when criticized. He's being paid in part to be a leader of a few high profile projects when he shows a lack of leadership ability. That's why I feel he should be gotten rid of.
Perhaps you're right that he should be gotten rid of, but redirecting criticism of him toward Red Hat is precisely not the way to achieve that. Red Hat won't care if you criticize them as a company. Why should they? However, effective community leadership/stewardship is part of the job description for someone like Poettering. If a person's conduct is poor, criticism should remain focused on them individually. If there's enough such criticism, then the project's own community should act to resolve the situation. It's both less optimal and less likely for an employer or sponsor to take action, but even then it would only be due to criticism of the individual and not themselves. One of the nice things about open source is that it's resistant to such political "get you in trouble with your boss" backstabbing. Address the individual directly and honestly, or forget it.
Since HN won't let me respond to uuoc directly, I'll respond here. I wasn't saying criticism should only be directed to its target. That's not the kind of "redirection" people seemed to be suggesting. What I'm saying is that the criticism should remain about that person, not displaced onto some third party. Believe it or not, it's possible to see how someone's behavior is affecting a project, without relying on that person to convey such information themselves. We've all done it here, after all. Anybody who thinks it's reasonable to blame individual behavior on someone's employer should consider whether they'd be comfortable with the idea when it's their behavior and their employer involved. I doubt it.
> However, effective community leadership/stewardship is part of the job description for someone like Poettering.
If this is true, then this is exactly _why_ the criticism should be directed towards Redhat. Because in his arrogant world view, he can do no wrong, so he will not report to his bosses that he has ineffective community leadership/stewardship. The only way his bosses will know of his ineffective leadership/stewardship is if the criticism is directed towards Redhet, and therefore, his bosses.
I.e., the criticism has to go around the roadblock, Poettering being that roadblock.
Three employees among thousands, representing two projects out of hundreds. Why generalize from that sample? Why ignore all those contributions to the Linux kernel or Fedora, OpenStack or Kubernetes, gcc or coreutils? Some pretty good leaders in there. And if "creating leaders" is supposed to be how we judge companies, what should we make of much larger companies where few employees engage with the community at all? I don't even mean unpopular companies like Microsoft or Oracle. What about Google, for example, or Apple? When it comes to community leadership, they're net negatives; existing leaders go in, and are never heard from again. When every single developer at a billion-dollar-a-year software company is engaged with some open-source community or other (often several), there will be a few losers. That's a poor reason to insult thousands of others.
The way i see it is not so much the individuals, but that so much of the traffic between them happens within the corporate realm that by the time it hits the public repositories they have all agreed on some iron clad world view.
The whole thing reminds me of how priests and monks would debate the number of angles that could dance on the head of a pin.
Poettering, being a high profile employee of Red Hat, is one of the faces of the company. Because of this, I would argue that Red Hat has a duty to step in from time to time to tell him that what he is doing is harmful in the long term. If they don't do it soon, I can almost guarantee there will be a lot fewer support contracts for Red Hat in the months and years to come; they just don't create dependable developers.