Some time during the 80s my dad bought a nice big japanese car. I think this was the first car he bought that had a modern injection and ignition system, so that when one day it wouldn't start and he popped the bonnet, there wasn't really a lot he could do about it. I remember him staring at the engine and not recognizing anything that he could actually tinker with to diagnose what had gone wrong. The only thing left to do was to take it to the garage and pay someone an obscene amount of money to hook up a computer to it.
All modern cars are like that now. Simply knowing how the engine works isn't really enough. You need to know how the onboard computers work, the sensor arrays, the electromechanical parts etc. in order to figure out why an engine that looks perfectly okay won't start. Some cars even hide most of the engine behind covers. You are not supposed to access the engine. Usually you can top up the fluids, but even something as fundamental as the spark plugs are often not your business.
Ordinary commercial software has some of the same properties. For the most part you are not supposed to tinker with it. It either works or it doesn't. And when it doesn't you file a bug report and then you wait. And wait. And wait. And if you are lucky, or you have thrown enough money at the vendor in the shape of a support agreement (which is not unlike an insurance -- in all the bad ways as well), you might get your problem fixed.
But there is very little you can do about speeding up the process. You are helpless.
The reason I, as a developer, like open source software is because I can pop the bonnet and have a look. I may not always have the perfect fix for what is wrong, but most of the time I can isolate problems, diagnose them and at least get a quick workaround in place while I, or someone else, comes up with a more permanent solution. Actually, quite often, a good permanent solution can be found and it is then easy to contribute it back to the open source community.
People who advocate open source usually get lost talking about improved security, lower total cost of ownership and other theoretical properties that they think they can measure, compare and understand in isolation. I can't really say that I have ever understood this reductionist approach.
I mostly care about what I can do to make something work, and once it works, keep it that way and know why it works. My nightmare scenario is to get a telephone call at 0300 in the morning and have no idea what to do in order to get a system up and running again. Or even where to begin diagnosing.
I also care about time-lines and progress. About how systems can be made better, more reliable, accommodate new requirements that keep appearing on the horizon -- as is invariably the case in any line of business worth being in. If your systems are key to your business and you are not continually working to improve them you have, for all practical purposes, started preparation for going out of business.
The problem with software is that, most of the time, those who make the decisions in large enterprises are often not the same people who have to fix the problems. Or even those who have the vision of where the company needs to be 12-18-24 months from now.
In fact, in many enterprises it is seen as suspect to have your own "mechanics" on staff. People who understand budgets and manage the finances tend to think of large computer systems as off-the-shelf solutions. Even when they are not. You set a price and a deadline, you take delivery of the systems and then you simply feed the computers power and occasionally slap them on the butt when they need to burp. Simple.
There is no simple set of metrics why open source is a good idea. Understanding why open source is important has more to do with building a durable culture than columns of numbers on a piece of paper.