One thing that always puzzled me on this code-hiding issue is...why bother? Not just from an open-source-is-good-for-progress point of view (although I'm a big subscriber to that too), but from the frustration that people regard source code as a 'product'. A program is much more than its source code; the product is the whole deal - manual, support, logo, pretty box, marketing concepts etc. The code is just *their* programmers' particular implementation of a bunch of solutions to the tasks proposed by the design spec.
I would suggest that > 90% of all the code ever written is single-use applications running on a single machine, designed to do a specific task for a specific company. If it was a different task, company, or even machine, it'd be written again. And again. And again. And that's the point. Programming is about programmers, not code. If asked to write some code that duplicated/improved some existing program, how many of us would ever bother to take a glance at how the internals worked? You may look at / attempt to copy other aspects - the user interface etc., but when it actually comes down to writing the thing, you start a New File and you write your own version. Sure - there may be sticky problems to overcome, but it's *highly* unlikely that the existing program is the only code out there that addresses the issue - true this-is-so-innovative-and-radical-it's-worth-hiding stuff is very rare, and generally patented so you couldn't "steal" it anyway.
When it comes down to it, it's about ignorance and ego. PHBs and marketing people find it had to understand unless presented with a suitable analogy - I generally use the car industry when I can (and it's amazing how far you can stretch it...). You can open the hood of your BMW and look around as much as you like. "Yup" you say..."it's an engine". If you know about engines, you can point out the bits to your friends - "Look - see how beautifully engineered that crankshaft is". You can, if you have the right tools and training, have a tinker about yourself - fix things, change things around...and if you were completely tooled up, you could even build one yourself. But you wouldn't. If you wanted a BMW, it'd be cheaper and easier to buy one. If you wanted something *better* on the other hand, and were capable of doing so,you'd already be one the same level as the Bavarian design team, and would know just as well as they do the problems you would encounter and how you'd solve them - before you even started cutting out any steel.
Ego comes into play when you really really believe that the kit-car you knocked up in the garage is going to be a serious contender in the car world...and your engine design is soooo innovative and clever that you're going to weld that hood down *tight*..."If you want to put water and oil in it - you come to *me*!".
I tend to treat source code as disposable - if bits of it are useful, they'll end up in a library somewhere - but a lot of that stuff is already in libraries, and most likely that's how I put the program together in the first place, because I was hired to solve a *real-world* situation - "We move bits of paper from here to here and carboard boxes from there to there - automate it". That, IMHO, constitutes the majority of 'programming' tasks - once the solution to the task is clear, the code 'writes itself'...or at least screams "this is how I'm going to be written". Once you've done a database schema, writing the queries and their presentation is more about the 'fiddly detail' than problem-solving.
*Phew* - sorry to go on, but this again, like demerphq, this is one of my hobby-horses :) And sorry for all the car stuff - mine got broken into tonight,so that was a little pre-bedtime exorcism :)