So when it's your choice what software to use, you can use your definition of better. The high horse comes when you try to tell other people to use your definition of better. Like the link we're discussing. The person is telling others, who've decided they like Slack better than the free alternatives, that they should stop using it. That's getting on a high horse.
You don't see a lot of pragmatists telling free software proponents that they should be using non-free software. Unfortunately, the reverse situation is very common.
I'd change your qualifier from "when it's your choice" to "when it's your choice and your choice doesn't adversely affect anyone else".
Here, I think, we're talking about free software projects sending wrong or mixed messages to their users & contributors. Which is the adverse effect alluded to -- it obliges your users to use non-free software.
This may discourage some of your potential users & contributors, and that may reduce the quality of your project. And that, in turn, may be something you as someone running a free software project had not considered, and, on reflection, do not want.
Slightly perturbed you're using the word pragmatist as a synonym for someone that uses or advocates non-free software.
Arguably anyone casting an opinion is 'on their high horse', especially if it's orthogonal to your own opinion.
"This may discourage some of your potential users & contributors, and that may reduce the quality of your project."
The exact same argument was made about not discouraging non-technical users who don't want to bother with the arcane-ness that is IRC, and the reply was that they don't matter.
> "This may discourage some of your potential users & contributors, and that may reduce the quality of your project."
> The exact same argument was made about not discouraging non-technical users who don't want to bother with the arcane-ness that is IRC, and the reply was that they don't matter.
Then they can email you if necessary. If there isn't a mail bot which takes email patches (or just emails) and converts them into IRC messages then that's something someone should be working on.
Your point is valid - and we basically agree that there are different types of barriers to entry.
However, as cyphar observes, there are always alternative methods for users & contributors to gain access - git repos (PR's), email - direct or lists, twitter, bug trackers, etc.
Slight aside -- I suspect there's some correlation between sophistication of question / contribution a user may be asking / making, and ability to navigate IRC. Either way, I don't see IRC's alleged complexity as being a barrier to any one who's serious, especially (as noted) in almost any project it won't be the exclusive method of communicating with members of the project.
Even more of an aside, I don't get this whole 'arcane-ness' (and similar) claims levelled against IRC -- is it genuinely that tricky? Most projects I've seen that includes IRC in their 'How to contact us' page provides links to IRC clients, clearly identifying their network & channel names, and even sometimes a link to a free web client that drops them straight into chat (so about the same level of convenience as Slack etc).
You don't see a lot of pragmatists telling free software proponents that they should be using non-free software. Unfortunately, the reverse situation is very common.