The problem is that the road between creating a piece of software that does something well, and then creating simplification layers on top of it is typically much longer than just “edit a config file” and “here’s a readme”.
You need extra documentation, config gating and workflow, warnings, UI/UX work etc.
I know there are Linux elitists but kind of expecting that much extra work for what is still at it’s core mostly volunteer software seems like it’s own form of elitism.
The thing is, simple can mean two things, and they are quite often at odds with each other.
It can mean simple to understand, or simple to use.
For example, a piece of software that’s just a binary, a config file and a man page describing the config file and the software’s behavior is generally quite easy to understand. Like, you can fit the idea of the program entirely into your mind and “comprehend” it, though it may not be easy to use for a novice.
By contrast, a piece of software that contains additional layers for easy of use, like a GUI to edit options, may be simple to use, but not necessarily simple to understand. The additional layers add more complexity that does not contribute to core functionality of the program, it can become unclear what gets changed where when you click on buttons, the config file is likely not documented, human readable or editable, or it may even be a completely opaque configuration database (the registry), … So making the software more simple to use, often makes it harder to comprehend.
I, and I think many other nerds, like software that is simple in the “comprehensible” sense, we want to be able to wrap our head around it completely and we don’t mind putting in a little bit of effort to achieve that comprehension, whereas other people prefer to hit the ground running.
Absolutely agreed, I find it extremely telling that most people who say that have never personally contributed nor donated. Its ok to have expectations but its not ok to make demands from volunteers, thats why so many devs get burnt out and leave.
The problem is that the road between creating a piece of software that does something well, and then creating simplification layers on top of it is typically much longer than just “edit a config file” and “here’s a readme”.
You need extra documentation, config gating and workflow, warnings, UI/UX work etc.
I know there are Linux elitists but kind of expecting that much extra work for what is still at it’s core mostly volunteer software seems like it’s own form of elitism.
The thing is, simple can mean two things, and they are quite often at odds with each other.
It can mean simple to understand, or simple to use.
For example, a piece of software that’s just a binary, a config file and a man page describing the config file and the software’s behavior is generally quite easy to understand. Like, you can fit the idea of the program entirely into your mind and “comprehend” it, though it may not be easy to use for a novice.
By contrast, a piece of software that contains additional layers for easy of use, like a GUI to edit options, may be simple to use, but not necessarily simple to understand. The additional layers add more complexity that does not contribute to core functionality of the program, it can become unclear what gets changed where when you click on buttons, the config file is likely not documented, human readable or editable, or it may even be a completely opaque configuration database (the registry), … So making the software more simple to use, often makes it harder to comprehend.
I, and I think many other nerds, like software that is simple in the “comprehensible” sense, we want to be able to wrap our head around it completely and we don’t mind putting in a little bit of effort to achieve that comprehension, whereas other people prefer to hit the ground running.
Absolutely agreed, I find it extremely telling that most people who say that have never personally contributed nor donated. Its ok to have expectations but its not ok to make demands from volunteers, thats why so many devs get burnt out and leave.