I don’t intend to turn this blog into my personal rant space, but every now and then there are issues I think should be discussed in an open and forthright manner.
Developers of software, particularly but not exclusively of the open source variety, often have a completely different view of themselves than many of the users of their software have of them. Developers see themselves a good guys writing cool software, that in some cases they are making available totally free to users. They think that all the users should at least be grateful, and should have at least the desire (if not the intent) of showering the developers with praise and accolades, and maybe even the occasional gift.
That actually might be somewhat of a reality when a piece of software is new and unique, and solves a heretofore unsolved problem, or provides new functionality that people have been wanting. When a new piece of software comes out that makes life better for people, the developers may hear mostly praise, along with perhaps an occasional suggestion for improvement, but rarely are the comments negative or hostile, unless the software really sucks right out of the gate.
However, as software matures, it sometimes happens that people start to see the developers in an entirely different light. Instead of being the guys who produce this wonderful software, a growing number of users see them as minions of the devil, put on earth to make their life more difficult, and to slowly drain their soul and their life energy. This is particularly true after major version updates to software, particularly when the developers introduce changes that break the existing functionality of the software in some way.
This is a particular issue with software that runs under the Linux operating system, and firmware that runs on embedded devices such as satellite receivers. Windows or OS X users may not be affected to the same degree, and that is because it is much easier for them to revert to an older version. All you need is the installer file for the older version (typically an .exe file in Windows, or a .dmg or .app file in OS X) and you can go back to the last version that worked. But the entire design of Linux is such that under Linux you generally don’t have that option, particularly if you are just an ordinary user of Linux that doesn’t understand the intricacies of compiling software from scratch. And with firmware, many times once you’ve installed a specific version of the firmware, it changes something in the device such that you can’t go back and install any older version.
The problem in user-friendly versions of Linux, such as Ubuntu or Linux Mint, is that the software primarily comes from repositories. There are the official repositories for the operating system itself, but you can add repositories for specific pieces of software, or groups of software from one developer. Take the Kodi media player software as an example, if you go to their downloads page you see that if you are installing in Windows or OS X, you download an installer file and save it to your computer, and then run that to install Kodi. But, if you are a Linux user, they direct you to a page that instructs you to add their repository to your sources list. You then use the apt-get command to actually install Kodi, and whichever of Kodi’s PVR addons you might need.
The problem with doing that is that the repository typically only offers the latest version of the software. If you find that a new version is buggy, or breaks functionality, there is simply no readily apparent way to go back to an older version. If you are a true Linux guru, you may know whether your software keeps older versions of software, and if it does, where it stores them, and how to restore them. But the typical user of a distribution such as Ubuntu or Mint has no clue about any of that. And also, if you’ve just set up a new system and installed the latest version of software from a repository and it’s broken in some way, you definitely won’t have an older versions stored in some obscure corner of your system, and in that case there is rarely an easy way to go back and get an older version that’s not broken.
This also highlights one of the weaknesses of the Linux operating system itself, something that many Linux devotees will tell you is an advantage, except it really isn’t.
If you are running Windows and for some reason you want to run an older version of software, most of the time it will still work. When I was running Windows and found a version of software that did what I wanted it to, I would save the installer .exe file and if a later version broke something that I considered essential, I’d just go back to that older version. The reason I could do that is because that installer file would typically contain everything needed for the program to run. For example, if certain .dll files were needed, the installer would include those. Linux gurus will say this is bad because since each program installs a copy of the .dll files it needs, the exact same .dll could be installed several times by different software installers, wasting space on the hard drive. That may have been a valid issue back in the 1980’s but with drive sizes today measured in Gigabytes and Terrabytes, there is no longer a need to be concerned about space even if the same .dll is installed a hundred times or more.
In contrast, Linux takes the approach that any dependency (as they are called in Linux-land) should be installed only once and that all programs that require it should use it. Which is great except that dependency versions change. So let’s say you decide to upgrade Ubuntu to a newer version, and now you want to run an older version of a certain piece of software. Even IF you can find the source code for that older version, and even IF you know how to compile it, there’s still a fair chance you’re going to run into what some Linux users term “dependency hell”. The older version of the software was designed to run with older versions of the dependencies, and if they aren’t present in the newer operating system then the older software may not run. Without going into even more boring detail about this, the net effect is that installing an older version of a software package in Linux is considerably more difficult that it would be under any other operating system, and in some cases may be totally impossible for anyone other than a true Linux guru that’s willing to devote hours of his life trying to get the older version to run. Whereas, a Windows or OS X user could install that older version with a few mouse clicks, as long as they have saved the older installer file, or can locate it online at one of the sites that specializes in offering old versions of popular software.
Also, there’s one other thing about Linux that is a bit unique among operating systems, that must be noted here. In Windows or OS X, when a new version of a program is available, typically you have to download it and install it. There are various mechanisms for doing this but with the exception of the operating system itself, you typically only upgrade one program at a time. In contrast, Ubuntu has a Software Updater program that occasionally pops up and tells your that software updates are available, often including security updates, which you’d typically want to install as soon as possible. If you just click the button to accept the updates, as many users are in the habit of doing, it installs all of the available updates for software on your system. So unless you look to see what is being installed, you could get a major version update for a piece of software that you depend upon without even realizing it, just because you wanted the latest security fixes and didn’t bother to scroll down to see what else is being updated.
(I will add that it always amazes me that when people come up with list of reasons not to use Linux, the above points are rarely on the list. IMHO they should be at the top of such lists, since they are certainly more annoying in the long run than any complaints about the Linux GUI not being as pretty as it should be).
The reason I have spent so much time explaining this is because in the remainder of this article, I want to talk about why users sometimes hate software developers, particular after a software upgrade is released, and I know someone out there is going to be very incredulous and say, “Why don’t the people having problems just go back to running an older version?” To which my response would be, in many cases they would if they could, but the process of getting an older version installed and working may be far too daunting for typical users.
Also, the rest of this article assumes that when we talk about developers, we are talking about people who should care how their software is perceived. Sadly, this is sometimes simply not the case with firmware developers, who are often pressured by their employers to get something out there that just works well enough that they can sell the receiver or other device. Once that project is finished, or has gone through the first few firmware releases, the developers might be moved on to some other project, or even released from employment. The point is that such developers may not care in the slightest what users think or want; all they care about is what makes their employer happy enough to give them a paycheck. This article is not about those types of developers, even though as users of the firmware we may experience the exact same types of frustrations. But, that lack of caring is one reason I personally prefer open hardware and software over proprietary hardware and firmware, where such a choice is available.
So here is what typically happens with any major software project that fills a need. It starts out pretty good; the first versions are okay and have basic functionality, but could definitely stand improvement. Users are generally happy with the software, but offer suggestions for things they like to see changed, and bugs they’d like to see squashed. The developers work on those and come out with another version, and more users are happy. More versions follow at various intervals, each adding new features and banishing bugs from previous versions.
However at some point, the software reaches kind of a plateau. Most of the initial bugs are addressed and some of the most-wanted features, or maybe the new features that are easiest to implement, have been added. Most users are happy and in retrospect, many of them will later wish the developers had just stopped there and taken a long vacation. But by now, the developers (and many users) have come to believe that a new versions should be released every so often, and being developers, they just can’t resist the urge to try to “make things better.” Often, this is the point at which they will take a look at their original code, and want to try to clean it up or make it more elegant, or at least easier for new developers to understand, because at this point some of the original developers may have become bored with the project. All of these are laudable goals, but the problem is that when you start tampering with existing code, things break.
And there’s also the problem of “creeping featuritus”, where developers try to think up “cool” new features to add, and in the process of adding those, break the code that makes existing features work. And sadly, they often have a greater desire to work on the new code than to fix the bugs they have created.
Users don’t see the code, and they couldn’t care less if it’s a hot spaghetti mess, as long as it runs and doesn’t degrade performance of the program too much. What they DO care about VERY MUCH is BREAKAGE. When you have been using code that works perfectly for your needs, and then an upgrade gets pushed to your system and something you have come to depend on stops working, you don’t appreciate that the developers cleaned up the code, or added some esoteric new features that most users won’t care about. As a user, all you know is that they broke the damn program!
Now if you are a user and are sufficiently annoyed, you may go and try to report the bug in one of the forums associated with the software. And that is often the point at which the annoyance with the developers turns into full-on hatred. Developers, to put it mildly, are not known for their people skills, so if they bother to respond at all, they often respond in such a way as to make the annoyance worse. But sometimes, other users can inadvertently push you over the line as well.
A classic response from another user is something along these lines:
“It’s free software, what did you expect? You got what you paid for. If it were a commercial product you’d have a right to complain, but with free software, if you want it fixed then learn to code and fix it yourself, and be sure to submit your code back to the community. Take your whiny attitude to some other software project, it’s not welcome here.”
This encompasses two of my pet peeves about these types of communities. The first is the idea that criticism of any kind is unwelcome, and particularly if it’s free software. So let me address that first: NO software is truly free. Even if you don’t pay the developers money, you pay in time spent to learn and use the software, and those using free software often pay more in that regard because free software is often poorly documented. But also, if a piece of software is good enough, many users may purchase hardware specifically to run that software. I would daresay that hundreds of thousands, if not millions of computers and tablets have been sold specifically for the purpose of running home theater software. So the user may not have paid FOR the software, but he has paid, sometimes to the tune of hundreds of dollars, BECAUSE HE USES THAT SOFTWARE. So when such a user posts that something is broken after a software upgrade (maybe one the user didn’t even want) and some jerk responds that he’s being “whiny” or acting “entitled”, there is an understandable momentary urge to hunt down that poster and take a sledgehammer to his keyboard, and maybe his fingers too!
The second peeve is when the jerk expresses the idea that if someone doesn’t like something about the way software is written, they should learn to code and then give their code back to the community. When I read this, I always figure one of two things is going on. Either this is the ultimate “drop dead” response, or the jerk poster is REALLY hoping that someone else will fix the problem. The obvious problem is that not everyone can learn to code, and that if they don’t know anything at all about programming, it could take YEARS for them to become proficient at it. Programmers, particularly those that learned to code on a Commodore 64 at the age of 12, simply don’t seem to get it that not everyone is cut out to be a coder. I have occasionally replied to such people that next time they have a car problem, they should take a class in auto mechanics and fix their car themselves. But then some of them will smugly reply that they ride bikes!
Developers have their ways of responding annoyingly too. For example, here is what I consider a “drop dead” response from a developer, assuming he’s not been given any reason to believe that the user that posted the message has any technical skills:
“You didn’t send log files. Please read the FAQ.”
To which the user thinks, “What the hell’s a log file and where do I find it? How do I send it to you? Do I need to be concerned that it contains personal information that could cause my system to be attacked, or my identity to be stolen? And where is this FAQ you speak of?”
What’s really sad is when this type of response is posted and there is no obvious link to the FAQ on the page, or if you go to the FAQ it doesn’t tell you where the log files are, or whether they contain sensitive information. Another issue is that some developers want you to post logs in an open area where anyone can look in them. As a user, how do I know that there isn’t information in those logs that I don’t want readable by the entire world, such as information that might personally identify me, or usernames and passwords?
Because developers live in their own little bubble, they don’t realize that asking a user to send log files can be an emotionally draining experience. Developers deal with log files daily, but users almost never look at them. To many users, log files are mostly just a useless waste of space on the hard drive, if they are even aware that log files exist.
Some users might be old enough to be your grandparents; they’re certainly not going to learn coding so they can fix the problems some developer created. And if a relative helped them set up the system, then even thinking that they can find a log file, let alone get it to the developers by whatever means they want to receive it, might be quite an indulgence in fantasy.
Another typically developer response will be something along these lines:
“We had to make changes to the code because it was getting so unwieldy that even we were having trouble understanding it. We now see that some of the decisions we made were in retrospect were perhaps not the best thing to do, but at this point we can’t go back and undo them.”
What the user hears: “We broke it, we aren’t going to fix it, and we don’t give a flying f–k.”
But perhaps the most infuriating of all is the “let’s see how far we can string them along” thread. This is where a user creates a thread about an issue in the support forum, and several other people add to the thread saying they are having the same problem, but no solutions appear, Eventually a developer drops by long enough to ask for more information – maybe log files, maybe information on what hardware or other software or addons/plugins are being used. He may do this a few times, always asking for information, and then finally you get the dreaded response:
“I can’t seem to replicate this on my system, and if I can’t see it then I can’t fix it. Sorry.”
Sometimes after that you will see more posts, with people describing exactly what operating system, software, and addons or plugins they are using; and occasionally someone will even post a YouTube video demonstrating the issue, but the developer has gone silent. He might have been run over by a bus for all anyone knows. Maybe he’s still participating in other threads and maybe he isn’t, but he’s clearly ignoring you and all the people who along with you are experiencing the problem. This is especially galling when it’s a new problem that just popped up in a new version, because you are thinking that as a developer he should be able to look at what was changed between versions that might cause this problem.
Anyway, with many software packages, there comes a point at which you sort of wish that developers would just leave well enough alone. If you must rewrite the core code, start a new project and use it there, but don’t screw up the existing code that so many of your users have come to depend on, even if you hate it because it now looks to you like something a first year computer science student would turn out. Sure, your ego may suffer a little because that “crappy code” is still out there, but at least you aren’t making beta testers out of all your existing users when you write your new code and send it out without warning.
But please, above all else, if you DO break something in a new version and users start reporting it, please GIVE A DAMN. Many users see programmers as arrogant and condescending, and one of the reasons is because when they screw something up, they figure it’s their prerogative to take their good sweet time to fix it. Well it may be, but if there is anything to karma (a.k.a. the belief that, “as you sow, so shall you reap”) I’d hate to be them, because they are causing emotional pain and anguish to many of their users with their aloofness.
As just one example, there is no feeling like having spent $300-$500 or more on a decent HTPC system, only to have it stop working properly because the developers of the primary software used on that system decided to completely rewrite the PVR addons, after which the ability to move around within a program very broken. It took MANY weeks after that bug was first reported for it to finally be fixed, and during much of that period the developers most responsible for the PVR addons went “radio silent” and did not respond at all to user posts in their forum. IMHO, that certainly reflects badly on the developers involved with that project. Why did they rewrite an addon that had previously worked perfectly? And then, having been notified that there was an issue, why didn’t they make it at least something of a priority to fix what they broke, or if they couldn’t do it right away for some reason, at least respond to users to let them know when a fix might be expected? Viewed one way, in the grand scheme of things, not being able to skip commercials without risking losing your place in the recording completely is not a major thing. But, think about it – if you have a PVR from a cable company or a small-dish satellite provider and they suddenly removed the ability to skip commercials, wouldn’t you be pretty annoyed about it?
I’m not trying to hang all this on the developers involved in that one incident. I’ve seen this same thing happen in far too many other software projects, especially open source ones, but I’ve even seen it happen in firmware for hardware devices. I disagree with the notion that if you aren’t paying for the software, you should be grateful for whatever the developers give you. That’s like saying that if someone offers you a free meal, you should be grateful if you get rotten fruit and moldy bread, even if the bread is only a little moldy. Sorry, but I find it hard to feel as much gratitude as I used to when developers break things and don’t seem to care, but when they then act like they don’t give a damn or just go totally silent, then it’s even harder to respect them.
I am fully aware that this rant will be viewed by some as whiny and disrespectful, and whatever other negative terms they can think of. I often wonder about people who feel that way. Did their dads beat them senseless as a youngster for not expressing enough gratitude for their mother’s lousy cooking? Are they part of some religious cult that teaches that you should express gratitude for all things, even if that means someone might feel they are doing an okay job when they really aren’t? I wonder, if any of those people are employers and one of their employees is doing a totally unsatisfactory job, do they just keep praising that person for their good work and hope the employee will improve? I get it, developers are not employees and they aren’t working for users, but that doesn’t mean that we should just let it slide when they really mess up a program that used to work quite well. My thinking here is that if you broke it, and you are any kind of a decent person, you’ll fix it, preferably without making users wait for months or years. Users can (and should) still be grateful for the previous versions that have served them well, and they might be a lot more grateful if they had some easy way to revert back to one of those previous versions. But any major unfixed bug, particularly one introduced in a new version of the software, will negatively affect users’ opinions of both the software and the developers behind it.
EDIT: A few weeks after I posted this, I saw this very relevant post on Reddit from someone associated with the Kodi project: