On Developer - User Relations

There's a problem in the Linux user community that nobody seems willing to address - the pink elephant in the back of the room that nobody sees yet everybody smells. Here's the problem, in a nutshell: if you're not a developer, we don't want you. This isn't universally true, of course; and it's generally not the first reaction of any person you ask for technical support. The problem is this: when you have a real issue, the probability that you'll hit someone who is willing to provide a patch or script that can fix your problem versus someone who tells you how to fix the problem is astronomically low. It goes deeper than that, too: the average response to an end user with an update issue who doesn't want to code? "Wait for the next release." That's unacceptable, particularly when somebody COULD be coding a quick solution that effectively delivers the desired result in the interim.

Here's the issue, at its core: end users don't WANT to code. In the average day, if they have to see the URLs in a browser's address bar, that's enough CLI interaction for them. So why do we insist on forcing end users into the coding mindset?

There's something to be said for the heritage of Linux versus, let's say, the heritage of Windows. Historically, the more informed among software developers have sought to develop on the platform with the most technical freedom. This practice originated on System V, and has carried over to function-alikes such as Linux and BSD. Windows, as it exists today, is a concept based on the WIMP model introduced first by Xerox and made economically viable by Apple. At its core, it attacks an issue of apathy and ignorance - user-friendliness. Many of the people who use a WIMP interface neither know nor care how their system works "under the hood", they simply want to do what they're used to doing with it. Linux, on the other hand, has a long tradition among people who want to get their tasks done as quickly and efficiently as possible, so it should be seen as a failing of that model when users seeking an easy experience are met with the most grossly inefficient solution from their stance.

The simplest answer to this problem is to educate the populace, but it is hardly the most practical; many users are so entrenched in the anti-coding mindset that they don't realize that Windows, Macintosh, their TVs, microwaves, iPods, clock radios, many of the features on modern automobiles, any form of airline flights or scheduling, and so much more would be practically impossible without it. In the meantime, the easiest solution is this: don't push updates until they're ready. If you're of a mindset that you truly want to solve a problem for somebody else, get your hands dirty - if only in something as menial as BASH.

For all the good the Ubuntu Code of Conduct does, it lacks what I feel is one crucial if not obvious rule:
"If a real answer exists, mention it. DO NOT push updates until they're ready."