> Because their opinion gets any legitimacy only by what you paid for it, either by money or work.
I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.
Developers should consider random opinions, just not if they conflict with the direction of the software. If a number of users have similar grievances, that is an indicator that something needs to be fixed, or maybe the direction of the software should be changed slightly.
That's if the developer intends the software to be widely-used, of course
>I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.
It's not about qualifications. It's about the willingness to hear them. I'd rather write my OWN project, MY way, that a better project in some other's terms. That's why people start their own projects after all.
So, the might be qualified, but the open source project creator could not care less about their advice, valid or not.
He might have his own opinions and long term ideas about the project. He didn't start to write software to be a slave to other people's ideas.
If he _wants_ other people's opinions, he'll ask for them.
And if he, like DHH, even posts a lengthy blog post telling them to shove them, then it's clear that he doesn't want them in this particular case.
>That's if the developer intends the software to be widely-used, of course
Developers can also intend for their software to be "widely-used" but only if it's _in their own terms_.
E.g RoR is widely used just fine, for example, despite being "opinionated".
So, "wanting your software to be widely used" does not necessarily imply that you "should consider random opinions".
It's contradictory that you would do whatever you like regardless of anyone else's opinions, ever and expect your software to be used by a large number of people.
Obviously you aren't obligated to accomodate anyone when you are doing your own project, even if you are doing your own project and then making it available publicly. But acting like a tiny dictator on a power trip is not the correct behavior if your purpose is to make a tool for public consumption.
If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.
>It's contradictory that you would do whatever you like regardless of anyone else's opinions, ever and expect your software to be used by a large number of people.
Who said you expect or want "a large number of people" in the first place?
You might put your project out there just for the potential valuable contributors to help with the code, not for the end users.
And one can imagine someone creating something unique with no regard for what people are saying, and still expecting them to embrace it. Because he thinks his vision is perfect or better than what exists. Kind of like Ford's quote "If I had asked people what they wanted, I would have given them faster horses".
But the problem with all the above is the absolutism. You don't have to "_never_ listen" as you imply. A project leader might listen to user opinions sometimes, and don't care at all about their opinions on other aspects of his program that he feels adamant about.
E.g it's not like DHH _never_ listens and does whatever he likes "regardless of anyone else's opinions". He only does that for FEW aspects of the project.
>If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.
Yes. A lot of projects are like that and people should understand that and respect your decision, instead of bitching about it.
You are the one that stated absolutely you shouldn't listen to random opinions, with rhetoric such as "If he _wants_ other people's opinions, he'll ask for them" and "developers can also intend for their software to be "widely-used" but only if it's _in their own terms_."
I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.
Developers should consider random opinions, just not if they conflict with the direction of the software. If a number of users have similar grievances, that is an indicator that something needs to be fixed, or maybe the direction of the software should be changed slightly.
That's if the developer intends the software to be widely-used, of course