Not even close. One of my favorite examples to demonstrate the logical fallacy of this, is you have people who will claim they bought some stereo system in 1975 and it still works great today. Of course when you look at it, you can see that this was a very high end system in 1975 and cost a pretty penny when you adjust for inflation. Meanwhile landfills all over the country, world even, were filling up with cheap transistor radios that were pieces of junk that lasted maybe 1-2 years, if that.
There were plenty of examples, no matter where you looked, of people producing cheap junk. The idea that people produced perfect code every time or the whole notion of someone being pressured to get a product out the door before it was ready is a new phenomenon is simply not true. You can look at the Y2K example of where developers knowingly and intentionally introduced a catastrophic bug into their code. At the same time, computer programs in the 1960s and 70s were extremely limited in functionality and were generally used by people who were very highly trained, possibly even the developers themselves.
I write a number of macros for automating some of the more tedious parts of my job. As the developer of said macros, I know where all the pitfalls are and the specific input this function is expecting, so I don't need any protections against my doing something stupid. Now if I decide to share these macros with my coworkers, I have to try and account for all kinds of things that I never would have thought of. A couple weeks ago one of my coworkers was saying my macros weren't working for her and upon investigation, it turned out she was trying to enter in letters to an input box tied to a function expecting only numbers. The vagaries of VBA means that it had to be a string variable, even though it's storing an integer value because of the manipulations I need to be able to manipulate it like a string. So now I've had to add checks for letters in that field and that complicates the code. I also have to make sure no one enters more than 12 numbers in that same field because it's a 12-digit internal tracking number and be able to handle things gracefully if they do. That adds complexity to my code. I have to try and anticipate every single stupid thing my coworkers could possibly do with these macros and devise some method of dealing with it. Probably about 1/3 of the couple hundred lines of code that is my macro suite is nothing but trying to anticipate the unintended ways someone might try and use any given part of any macro.
But don't expect Linux to be any different from Windows. Unless you're a rather accomplished programmer, it's not exactly the land of freedom it's often made out to be. You're just trading a bunch of people at Microsoft making decisions about how you should use your computer for a group of random, often changing, group of people from various parts of the world deciding how you should use your computer. Look into some of the history of the GNOME project and how they've annoyed users by trying to force something on them. Not just the new conceptual interface with GNOME 3, but even before that, when GNOME decided to keep plugging along with CORBA and then developed something akin to the Windows registry instead of the old Unix style configuration files. Even the Linux kernel isn't nearly as open as it might seem. Linus basically has final say over what does and doesn't make it into the kernel, when a particular kernel version is released, etc. Not too long ago he very publicly stated he wouldn't accept any more patches from a particular developer. So sure, the source code is there, but what good does it do you unless you have the requisite programming skills to develop the feature you personally want and not to mention the time and resources required to maintain your own parallel branch of the program if your patches are not accepted upstream to become part of the next version? If you want to pick up programming in your golden years, I commend you for it, but until you've done that, you're just trading the whims of Microsoft for the whims of the developer(s) for any given Linux program you may use. Even if you have the source code and are a reasonably skilled programmer, getting your head around tens of thousands of lines of code is no small task. I have a hard enough time sometimes maintaining my macro suite which is probably in the 100-200 lines of code if you don't count the comment blocks I put at the beginning of functions to explain what they do.