The great SciFi author, Arthur C. Clarke, once wrote that any sufficiently advanced technology would be indistinguishable from magic. This remark can be considered from many angles, but in respect of open-source versus proprietary machines, it has a somewhat surprising application to current technology, even amongst current technologists.
When faced with a proprietary, sealed, black-box of some kind, engineers respond in different ways, but one reasonably constant reaction is a concern, or fear, of lack of understanding of the operation of the internals. This reaction is the root of "FUD", it is the seed of doubt which can be, with care and attention, grown into full-scale Fear, the fear of magic, the fear of the unknown. The Uncertainty resulting from not knowing exactly what is in the black box can be enough to encourage wildly inaccurate risk assessments by typically even-tempered, cautious people.
Why does this reaction occur? Simply, most engineers are control and function obsessed, they do not like to estimate how likely something is to happen, rather, they want to *know*. They want to know exactly how everything works, what makes it tick, what goes on inside the box. This is precisely how engineers should behave, indeed, it is this set of characteristics which has enabled engineers to build ships, trains, cars, bridges, rockets, the telecommunications network, satellites, televisions, radios and so on. One cannot combine components together unless one has a reasonable understanding of how they function, and how they will behave as one changes their environment.
So: enter stage-right the black box, the proprietary object, the locked-down machine. If this machine is going to stand alone, or has been deliberately designed to operate fully independently in its environment, then this is no problem. For example, a microcontrolled toaster is unlikely to be problematic, so long as the power supply is compatible, and the slots are the right size for bread, there is unlikely to be a problem. How about a television or radio? Again, so long as the TV can handle PAL and/or DVB, or the radio can manage AM and FM or Digital Radio, then it will work just fine if the power plug is the right kind. These boxes are not typically in the middle of complex, larger machines, they are usually the last in the chain, the customer premises equipment. But what if the box is designed for the middle of a network, say? Perhaps it's a multiplexing box, or a router, and perhaps it has some really useful feature, but the system designer doesn't quite, 100%, understand how it works?
Again, initial deployment will be fine, so long as the proprietary function, well, functions, then all will be well. The problems occur later, when one of two key events occurs. Either there is a change requirement, some adjustment to the overall system is needed, or, an alternative supplier is required. At this point, the proprietaryness suddenly becomes an enormous issue. Changing out a toaster or television working to accepted standards is no great issue - beyond selecting the features required by the customer against a price, all will be well. When a box in the middle of a network or system is considered, though, the problem becomes many times more complex, as the interactions between this box and many others need to be considered. This is the point at which the good engineers are separated from the also-rans, because they are the ones who can envisage what the outcome of different changes will be. Unfortunately, even for the very best engineers, predicting the behaviour of a proprietary, locked-down box is next to impossible, particularly if an alternative is to be sought.
Anyone who has looked at the challenges associated with automatic testing of complex machines will know that these tests are always limited by the number of conditions which can be measured, the problem rises exponentially - each new condition must be multiplied by all of the others. This is enough to give the greatest minds pause for thought, and probably a need for a beer.
Why? Well, inside that proprietary box is something which is, to a point, magic. Prodding it from the outside is most unlikely to ever reveal all its secrets, so a really good engineer will always be concerned that they've forgotten something, or missed something, or not considered a condition.
The result? The consulting engineer might well be very unwilling to consider the change-out of a proprietary device without truly exhaustive investigation - that investigation will add cost to the change out, and will serve to make alternatives seem less viable, more expensive, less suitable to a business.
The solution is really very simple, but like many simple solutions, not necessarily trivial! Engineers like simple things, for the reasons described above - they make their brains hurt less when performing design work, analysis, maintenance, repair, and so on. So, our non-trivial but simple solution goes like this: Start replacing the proprietary magic boxes with open boxes, running on standard hardware, using open-source software, adhering to all possible standards. The accountants will surely point to interesting facts, like "this open box costs more than the proprietary one". Well, it (usually) doesn't, in fact, but one has to consider exit-cost as part of the overall cost, which most companies do not, thus they arrive at the wrong answer.
There are other answers, of course, which straddle the ends of the spectrum, and handle such significant problems as "there is no open solution to this problem available". Naturally, you could write you own, or pay someone to write it for you, but sometimes even this is not practical for some reason. In this case, then the key is to be sure to have several different types of black-box being used for the same thing, that way, at least a company or organisation is not dependent on just one or perhaps two suppliers. This is a hugely underestimated risk, in that once a supplier realises that a large customer has really got nowhere else to go, it's amazing how much the price can rise...
That's the price of magic!