On the other hand, having that expertise is not always possible, which is why purchasing then paying for support business models exist in the first place. It also tends to be that which is business-critical is also peripheral to the service or product you’re providing, which makes it unlikely you’ll want to spend time or effort improving those systems.

I’d counter your point that the provider is only out to make money with the fact that its business model is based on the service they’re providing, which means they have the incentive to improve and update their product consistently. Their sales department wouldn’t have customers long otherwise.

Proprietary software is supported only by the vendor, and the vendor doesn’t have the same interests as you. You want your system to work; the vendor merely wants to get money out of you in the most efficient way possible. (Note that I’m not putting making a value judgement here; the vendor is simply doing what is in its best interests, which is perfectly natural.) Thus, any support you get from the vendor is going to be negotiated: you will ask for things and threaten to withhold other things if you don’t get them, and the vendor will decide what it will and won’t give you.

In a non-critical system, this isn’t usually a big deal. If you can’t get a feature that you want or get a very annoying bug fixed, you live with it. In a business-critical system, however, problems like this can hurt a lot more, to the point where even very expensive workarounds become economical or, in the worst case, you need to change or abandon entire lines of business.

This is where open source giving you more options for support makes a difference. Not only can you look for new support vendors if your current one doesn’t satisfy you, but you also have the option of internalizing some of that support: doing it yourself. If something’s important enough to you, and you’re spending a fair amount of money on it anyway, it can be worthwhile to hire someone who is or can become a developer of that open-source software. That gives you the ultimate in support because you’re now not negotating with the vendor for features or bugfixes; you’re sinmply telling your developer what to work on. It also makes finding bugs considerably cheaper because it removes the gap between the person who understands the internals of the software and the person who understands the context within which the software is used: one person now has both of those sets of knowledge.

I think you’re correct mostly for abstract software such as code manipulation tools, standards-compliant servers (like J2EE), open source code libraries and etc. These are usually either easily extricated, switched, phased out or deprecated. Because you can still keep them in some cases, free means you don’t have to worry about continuing to pay for them after a switch.

There are at least a few pieces of software that would be worth the trouble of not being free (purchase or support) which include anything business critical such as point of sale software, intranets, servers. I would only feel comfortable though if I knew that I could switch with relative ease, but that it would cost me more to create it than to get support.