Tuwunel’s theme is empathy in communication defined by the works of Edith Stein.
What does “empathy in communication” have to do with a software project? Are they going to ban people who don’t display empathy? If so, isn’t that anti-empathetic? I’m kind of confused what this is intended to convey.
I’m all for empathy, don’t get me wrong, but ideally software projects are more focused on technical correctness than feels.
What does “empathy in communication” have to do with a software project?
Not having read Stein’s work, I can only mostly guess it’s related to the emphasis on the “communication” part as it applis to effective communication of duties, milestones, failure modes and reactions in a project. Torvalds’s tirades for example were awesome and most of the time well-deserved for the idiot trying to accidentally the kernel, but are quite more of a bummer and a momentum-killer when looked at at a project-wide scope.
I’m all for empathy, don’t get me wrong, but ideally software projects are more focused on technical correctness than feels
(Not) sorry to say, that age has long sailed. Remote teambuilding, capitalism and AI have made it that we now need to actually care and be watchful why or how something is being made to work, on the technical sense. Just look at the situation with Mozilla or Signal (offering systems that can be described as free, but are being offered so in a rather adversarial manner).
Torvalds’s tirades for example were awesome and most of the time well-deserved for the idiot trying to accidentally the kernel, but are quite more of a bummer and a momentum-killer when looked at at a project-wide scope.
Sure, and the problem was the profanities and personal insults. He has toned down both and I think the project is much better for it, but I wouldn’t call his communication style “empathetic,” merely technical. If there’s an issue, he’s clear about it, minus the profanities and personal insults.
we now need to actually care and be watchful why or how something is being made to work
And I very passionately oppose that. I don’t care if the lead maintainer is a Nazi or a communist, I care that they keep their beliefs to themselves and focus on technical issues in the project. For example, I strongly disagree with the Lemmy devs politically, yet I use Lemmy, have contributed patches, and will probably contribute more patches at some point if something pisses me off enough. The same is true for other projects. I disagree with Brendan Eich’s views on same-sex marriage, but that has zero impact on whether I’d use the Brave browser or Brave search engine.
If our standard for interacting w/ a project is “I agree with the developers on this unrelated thing,” then we’re not going to get anywhere. We should focus on technical soundness, and leave the individual contributors to their own views on other stuff.
That said, I draw the line at a lack of inclusiveness. If a project is actively discouraging others to join the project on purely unrelated grounds (i.e. excluding people based on gender identity, nationality, etc), then I’d prefer to avoid that project. But not being aggressively inclusive isn’t the same as being exclusive; as long as contributions are welcomed regardless of source, it doesn’t really matter to me what the personal opinions of someone involved in a project are.
Identity politics is stupid. I don’t care if the lead dev is trans, obese, or Russian, I care that their technical contributions are sound and they’re reasonably respectful to contributors.
Hopefully no one is asking developers to be virtuous (even tho, to be fair, if we are going to be asking that we should also expect the code to be wholly bugs-free!), but how many times they actually “keep their beliefs to themselves and focus on technical issues in the project”? On whichever side. It’s just not a thing that can reasonably be avoided all the time between humans.
But the reality of these times is that behaviour outside the field of programming is representative and/or predictive of behaviour in the field of programming, when it comes to literally working with other people. And this is not only about the act of commiting changes or filing PRs, it’s about the why of programming and the ways of delivery as well. Someone who strongly associates with barbaric beliefs is less likely to want to spend their spare time working in peace for all, and more likely to be wanting to work on software that at least in some way carries or represents those beliefs, for example in capturing and using user data, or in aiding systems used by the military to kill children of “non-citizens”. So being “absolutely” uncaring does not really make sense.
Someone who strongly associates with barbaric beliefs is less likely to want to spend their spare time working in peace for all, and more likely to be wanting to work on software that at least in some way carries or represents those beliefs, for example in capturing and using user data, or in aiding systems used by the military to kill children of “non-citizens”. So being “absolutely” uncaring does not really make sense.
Let’s look at Linux, for example, which is perhaps the most successful FOSS project in the world. It takes contributions from people of a wide range of motivations, such as:
hardware vendors who just want their stuff to work
intelligence agencies, who want stable systems to spy on people
hacking groups that want low level control to facilitate exploits
militaries that want reliable guidance systems to bomb women and children abroad
freedom fighters who need top security to protect themselves from repressive governments
free software advocates who believe computing should be accessible to all
ad agencies that need a scalable solution to push their dark patterns more efficiently
IT pros building a career on maintaining complex systems
And so on. The net result is a solid, general purpose kernel and a rich ecosystem of supported software. All Linux did was focus on technical details and largely ignore the source.
In the words of Linus Torvalds:
With enough eyeballs, all bugs are shallow.
Does it really matter who those eyeballs belong to? Yes, we should be careful about malicious intent (e.g. xz scandal), but that’s a technical problem, not a political or cultural one.
At the end of the day, everyone is free to associate or not associate with any groups they want. If you’re a maintainer, that means you get to decide which contributions you accept and who you let into your communication channels.
I use software maintained by people I really don’t like, such as:
GrapheneOS - lead dev is a giant pain to deal with
Lemmy - both lead devs have extreme political views that I strongly disagree with and find dangerous
Brave - CEO’s political views are distasteful, to put it mildly
Tor - pretty sure it’s largely maintained by spooks and militaries (at least it started that way)
React web framework - developed and maintained by Meta, whom I actively avoid and refuse to do business with
I’ve also contributed patches to some of those as well. Why? Because the technical merits of those protects is pretty much all that matters. If the maintainers go off the deepend and piss people off, I or someone else can fork it. That happened with various OpenOffice (LibreOffice), ownCloud (NextCloud and OpenCloud), and now Redis (Valley), though those had more to do with licensing changes than technical project direction.
That’s why I’m concerned when projects put non-technical concerns (say, a COC) above technical concerns. Yes, civility is expected, and enforcement of that is a lot easier when the project focuses primarily if not exclusively on technical concerns.
Looks interesting.
This part confuses me though:
What does “empathy in communication” have to do with a software project? Are they going to ban people who don’t display empathy? If so, isn’t that anti-empathetic? I’m kind of confused what this is intended to convey.
I’m all for empathy, don’t get me wrong, but ideally software projects are more focused on technical correctness than feels.
Not having read Stein’s work, I can only mostly guess it’s related to the emphasis on the “communication” part as it applis to effective communication of duties, milestones, failure modes and reactions in a project. Torvalds’s tirades for example were awesome and most of the time well-deserved for the idiot trying to accidentally the kernel, but are quite more of a bummer and a momentum-killer when looked at at a project-wide scope.
(Not) sorry to say, that age has long sailed. Remote teambuilding, capitalism and AI have made it that we now need to actually care and be watchful why or how something is being made to work, on the technical sense. Just look at the situation with Mozilla or Signal (offering systems that can be described as free, but are being offered so in a rather adversarial manner).
Sure, and the problem was the profanities and personal insults. He has toned down both and I think the project is much better for it, but I wouldn’t call his communication style “empathetic,” merely technical. If there’s an issue, he’s clear about it, minus the profanities and personal insults.
And I very passionately oppose that. I don’t care if the lead maintainer is a Nazi or a communist, I care that they keep their beliefs to themselves and focus on technical issues in the project. For example, I strongly disagree with the Lemmy devs politically, yet I use Lemmy, have contributed patches, and will probably contribute more patches at some point if something pisses me off enough. The same is true for other projects. I disagree with Brendan Eich’s views on same-sex marriage, but that has zero impact on whether I’d use the Brave browser or Brave search engine.
If our standard for interacting w/ a project is “I agree with the developers on this unrelated thing,” then we’re not going to get anywhere. We should focus on technical soundness, and leave the individual contributors to their own views on other stuff.
That said, I draw the line at a lack of inclusiveness. If a project is actively discouraging others to join the project on purely unrelated grounds (i.e. excluding people based on gender identity, nationality, etc), then I’d prefer to avoid that project. But not being aggressively inclusive isn’t the same as being exclusive; as long as contributions are welcomed regardless of source, it doesn’t really matter to me what the personal opinions of someone involved in a project are.
Identity politics is stupid. I don’t care if the lead dev is trans, obese, or Russian, I care that their technical contributions are sound and they’re reasonably respectful to contributors.
Hopefully no one is asking developers to be virtuous (even tho, to be fair, if we are going to be asking that we should also expect the code to be wholly bugs-free!), but how many times they actually “keep their beliefs to themselves and focus on technical issues in the project”? On whichever side. It’s just not a thing that can reasonably be avoided all the time between humans.
But the reality of these times is that behaviour outside the field of programming is representative and/or predictive of behaviour in the field of programming, when it comes to literally working with other people. And this is not only about the act of commiting changes or filing PRs, it’s about the why of programming and the ways of delivery as well. Someone who strongly associates with barbaric beliefs is less likely to want to spend their spare time working in peace for all, and more likely to be wanting to work on software that at least in some way carries or represents those beliefs, for example in capturing and using user data, or in aiding systems used by the military to kill children of “non-citizens”. So being “absolutely” uncaring does not really make sense.
Let’s look at Linux, for example, which is perhaps the most successful FOSS project in the world. It takes contributions from people of a wide range of motivations, such as:
And so on. The net result is a solid, general purpose kernel and a rich ecosystem of supported software. All Linux did was focus on technical details and largely ignore the source.
In the words of Linus Torvalds:
Does it really matter who those eyeballs belong to? Yes, we should be careful about malicious intent (e.g. xz scandal), but that’s a technical problem, not a political or cultural one.
At the end of the day, everyone is free to associate or not associate with any groups they want. If you’re a maintainer, that means you get to decide which contributions you accept and who you let into your communication channels.
I use software maintained by people I really don’t like, such as:
I’ve also contributed patches to some of those as well. Why? Because the technical merits of those protects is pretty much all that matters. If the maintainers go off the deepend and piss people off, I or someone else can fork it. That happened with various OpenOffice (LibreOffice), ownCloud (NextCloud and OpenCloud), and now Redis (Valley), though those had more to do with licensing changes than technical project direction.
That’s why I’m concerned when projects put non-technical concerns (say, a COC) above technical concerns. Yes, civility is expected, and enforcement of that is a lot easier when the project focuses primarily if not exclusively on technical concerns.