SemperFiDownUnda:
There are a few facts that I assumed we both understood. The first is that you cannot sell what you do not own.
RedHat, for example, owns very little of the code that makes up their distribution. They do not own the Linux kernel, the KDE or Gnome desktops, the Apache web server, the MySQL and PostgreSQL database servers, the GIMP image processor, or much else of the software that is bundled with their product. That code is owned by the various programmers, groups of programmers, and companies that created the programs. They do own the rights to rpm ("rpm" being the "RedHat package manager"

, but not much else -- and RedHat has GPLed rpm.
So RedHat is selling service, not product. They are selling the service of gathering up all those myriad pieces of code, making sure they all play well together, and writing them to a CD. They also sell the service of support for all that. This is the same model used by SuSE, Mandrake, and other commercial Linux distributors.
RedHat can't drive sales by adding features to the Linux kernel -- Linux Torvalds and his lieutenants decide what new features will be added to each kernel revision, not RedHat. RedHat can't drive sales by adding features to MySQL -- MySQL AB owns that code. Etc. Etc. Etc.
The second fact is that you can't drive sales through feature addition when you give the product away. MySQL and StarOffice fall into this group. They can add all the features they want, but if they also license the product under the GPL, users have a choice -- pay for support for the new features or use them for free. Again, MySQL AB and Sun are not selling any feature they don't also give away for free. They sell the service of supporting their respective software.
If I were so inclined, I could download the MySQL source code, modify it to create my own database server, and give away my new product. I must simply fulfill one requirement: I must distribute my new product under the GPL, since the license of the source code is GPL. Mandrake got their start as a Linux distributor by taking the RedHat distribution and adding features users wanted.
The third fact is that you can't sell what you only give away. Apache falls under this category. What would drive the Apache programmers to take the 3 years necessary to re-engineer Apache from the ground up to add new features and make the product work under a more flexible paradigm? Certainly not sales -- Apache is not sold, only given away. It's because there were things their users wanted to do with the product that either could not be done or could not be done efficiently.
So what I meant is that open-source products cannot arbitrarily add features, call it innovation, and scare users into upgrading under fear of removal of future support. Mi¢ro$oft is facing a growning problem with their software -- people are upgrading less often than before. And if Mi¢ro$oft can't increase their user base (which they cannot do indefinately -- the population of the planet is, after all, finite) or convince their users to upgrade regularly on Mi¢ro$oft's schedule, then Mi¢ro$oft's income based on sale of software must, by definition, decline over time. I think Mi¢ro$oft must have seen this, too. It would explain all the FUD they've been spreading about open source software for the last several years.
On the subject of software engineering problems with Mi¢ro$oft...
You're confusing implementation errors with design errors. No ethical programmer is going to intentionally design a buffer overflow into a program.
And that functionality (execution of code in the Outlook preview pane) doesn't look to be very useful to users. The fix was to re-engineeer the way Outlook uses the HTML rendering objects so that code could not execute in the preview pane. All versions of Outlook since that patch are now set up this way out of the factory, and I haven't heard any complaints from users.
So it doesn't sound to me like a case of "preferred functionality". It sounds to me like a case of "closing the barn door after the horse had gotten out".
The bug you'v pointed out was not a bug in Apache -- it was a bug in the OpenSSL libraries used by Apache, not in Apache itself. And it was a buffer overflow error, which is an implementation flaw, not a design flaw. Unless one wants to believe that the OpenSSL programmers deliberately put that exploitable overflow in the code. And I believe that the time between the discovery of the bug and a release of an updated version of OpenSSL to fix the bug was on the order of hours.
Want the best answers? Ask the best questions: TANSTAAFL!!