I don't know, I used to feel that way but over the last few years I've changed my mind. The reason is because I got a hosting company as a client and I've seen some shit.

I've written the tools they use for automated VPS creation/deployment. The wrench in the works is that this company offers the ability to install/configure a lot of different pieces of software and software combinations, not just the usual to get enough going for the customer to log into the VPS. Slowly over the last few years I've started to realize my trust and hope in software that isn't written by me has plummeted as a direct result of this experience. I'm talking about software with a configuration web API where only half the confurable options will actually configure via the given web API and instead you find yourself tracking down and diving into the individual files and updating those instead (and figuring out how to restart their services such that they don't overwrite your changes and accept them). It's just not acceptable, and they charge money for that implementation. I've been told that one of the major features in their new version is that their own web app will start calling the web API so their implementations will actually work in this version. Am I the only one who finds that a ridiculous feature?

long story short, I think there's an assumption in your post that the people writing the software give a shit about correctness and ease of use, when in reality a lot of software only cares about getting money in their pocket. If that means shipping with a web API that's broken and announcing the proper functioning of said API as a feature for the next version, then so be it.

What ends up happening is that you, as a developer, have to deal with the bad decisions made by other people and at some point you start preferring to just write it yourself. To give you an example, PoSH SSH (Powershell SSH). Version 1.6 had no timeout functionality, so it was possible for an SSH session to never end. 1.7 added a timeout functionality, only the default timeout was set to 60 seconds, you can only change the timeout on a session basis, and it's not possible to get back the old 1.6 behavior of having no timeout (sending a timeout of 0 just immediately returns with a timeout error). The best you can do is set the timeout to Int.Max.

The thing is, most of the differences are a bit of a pain, but nothing more, except for the decision to change the default behavior in 1.7 to be different than 1.6. This guarantees that anyone who upgrades gets rocked by this change. And for no good reason. If someone wants a shorter timeout in 1.7, they can make that adjustment while they're writing new code. It's just a bad decision made out of convenience and probably some emotional feeling of "goodness" that results from the default behavior being "right" or "correct" with the new timeout behavior.

Another issue in 1.7 is that if the connection goes away, it will hang until the timout gets hit. I went diving into the code to see what was going on, and in their busy wait loop they never actually check if the session breaks unexpectedly, so if it does break it sits in that loop until the timeout is hit. I discovered this because my automated tools were SSHing into some linux VPS's and issueing a restart command. But because the timeout is on a session basis rather than command basis, it isn't as simple as just adjusting the timeout. I had to actually start maintaining my own version (I did report the issue to PoSSH SSH, but I don't think it's been fixed).

In general, the quality of the PoSH SSH library is such that I'm actually in the middle of changing from PoSSH SSH to the putty tools for my SSH/SCP needs. It's actually more consistent for me to escape and parse the cmd input/output than it is for me to use PoSH SSH, and that's damning.

I'm not asking for 9 9's of availability from these libraries, but my personal goal when I write code is for it to work consistently, and to be loud in its failures so we know that more work is needed to work consistently. But PoSH SSH's design is such that it's easier to meet those goals using external CLI tools than to use the Powershell library.

This turned into a bit of a rant, but this is something that's been on my mind more and more over the past few years as I find myself dealing with such a myriad of different pieces of software with this client.