Closed source, secrecy and trust
Most companies which produce source code don't release it in the wild. They are hiding it, protecting it against unauthorized access, obfuscate it, make you sign NDA and ask themselves how they can be sure that the code will never ever reach internet.
When asked why they aren't releasing source code publicly, people are usually ashamed, and then start to quote different reasons.
Our product is innovative. We don't want our ideas to be stolen.
What if somebody uses our product as if it was their own, effortlessly becoming an important competitor in no time?
We want our customers to be secured. Fool, don't you understand that releasing our source code would go against security best practices?
It is expensive to set up a platform in order to release source code. Who will pay for the bandwidth? The server maintenance?
etc.
In essence, they don't have valid reasons to not releasing source, or, rather, they have reasons, but won't admit them, sometimes even to themselves.
At Pelican Design & Development, despite the orientation towards openness since 2013, a large part of the corporate source code remains secret. Those are the true, secret reasons why:
The quality of the source code is too low. It is a case for legacy source, as well as projects created without quality in mind. Releasing such source may harm the image of the company and the authors. For example, I wouldn't appreciate being asked questions about my own old, crappy code during an interview.
The source code contains known security bugs. Solving them takes time, so meanwhile, the code remains hidden.
The source is stolen from somewhere or is used in a way which is not permitted by the license.
The source contains information which shouldn't be in the source, such as passwords or private keys.
As you can see, the real reasons are much less attractive than the ones from the first list above. Indeed, the ones from the first list don't make real sense for most companies:
Innovation
Seriously, stop using this word. If you're really innovative, you don't need to put this word in every sentence of your marketing jibber-jabber. If you're an ordinary company, I'm sorry, but you're not innovative. At best, you're up to date with technology. Often, the marketing term innovation is used by small companies to indicate that they discover, from times to times, what was already used by larger companies for decades. The appropriate expression would be reinvent the wheel, not innovate.
I'm tired if customers who make me sign NDA before telling their super innovative idea, such us “Let's create a website where people can post short messages about news” or “Any company would be excited by a website which will unify all their corporate applications and information in one place”.
A year ago, I had a customer who asked me to sign NDA in order to work on a secret project. A week ago, I launched Health app installed with Windows 8.1 in order to see what it is about. It appears that a part of it is very similar to my customers' project. With the difference of being done better. With better graphics. More intuitive. Faster. I'm pretty sure that this NDA-covered project was never released, or is released but not used by anyone.
If only one could talk about his projects to others, he would have a chance to learn lots of things. Such as that the project sucks. Or that it already exists.
As a side note, I work in a so-called “R&D department” in a company. There is no research, and there are no researchers. There is practically no development neither. Just programming and debugging.
Clones
Have you seen an open source project which one can seamlessly copy and use as his own in no time? Making a product from the code base of a competitor requires time. The larger is a product, the larger would be the effort. Not counting the fact that in most cases, the code base is unusable and won't even compile.
It's as easy as that: either your competitor makes an effort, creates additional value, and sells a better product than yours, or he achieves to sell the same stuff than you, but better.
In the first case, remember that you're the one who knows the code base the best, so you have undoubtedly this benefit over your competitors, being able to respond faster to new demand.
In the second case, you're simply a bad seller. Deal with it.
Security
If releasing the source code makes your product less secure, you're doing security wrong. Dude, go learn some basics of security, seriously.
Cost
Wait, I always thought that GitHub and Codeplex were free.
What actually costs money is to hire lawyers to write the NDA, to spend meetings discussing how to protect source code, to waste money on protection software, etc.
Implications
In other words, when somebody claims he has serious reasons to hide source code, he actually lies, and indirectly admits that he wastes money and time. Your money, if you're a customer. Your time, if you're a freelancer.
When you can't see source code, you can't be sure it's good. Presumption of innocence doesn't work here: if there is no proof that the code is good, assume it's bad, since by default, the code is always bad and it requires additional effort to make it good.
Secrecy on this level has one and one only implication: the lack of trust.
- I trust open source projects, because I can go and read the code myself, check if unit tests pass, add my own tests, check how recent is the code and whether the code was written by developers with enough reputation.
- I don't trust closed source projects, because I participated in too many to know how bad they are. I don't care about marketing crap about innovation, security and research. Buzzwords lie too much. Code doesn't. Show me real stuff. Show me your code.