What are the cases where keeping source code secret is justified?

When I worked as a freelancer, I encountered lots of cases where customers were protecting their ideas and source code of their projects (such as web applications) as much as possible, no matter how unimportant, uninteresting and unoriginal were the projects and the concepts behind.

I’ve already posted a question about keeping the ideas secret, and received many great answers. Now, my concern is more about source code secrecy.

According to my observations of:

The codebases I had to work on during my career,
My own willingness to keep some of my own source code secret, and:
A few articles like, for example, Open response to Simon Stuart by the popular Programmers.SE contributor Mason Wheeler,

I conclude that source code is kept secret mostly for those reasons:

Because the author is ashamed of the code of such a bad quality, or the company fears losing reputation if somebody sees such bad codebase, or that given the low quality of the codebase, it will not bring anything useful to anybody to open source it: even if somebody would be interested, he would hardly be able to run the solution (or, often, even compile).
Because parts of the code are stolen (mostly from open source projects covered by a license which restricts its usage in a given situation),
Because the code relies on security by obscurity and the author doesn’t care about Kerckhoffs’s principle.
Because the product is so breakable that showing the code would cause too much harm: if a closed-source app with all those security leaks would withstand a newbie hacker, the same open sourced app would have far smaller chances, because even the beginner hacker would just have to study the code to discover all the holes.

If it’s not clear what I’m talking about, here’s an example:
```
if (credentials.password === 'masterPassword12345')
{
    isLoggedIn = true
    currentUser = credentials.userName
}
else
{
    authenticate(credentials)
}
```
Because the author over-estimated the source code (and his own skills and expertise). Example: believing that a home-made cryptography-related algorithm (which was never reviewed by anybody) is better than any well-known one.
Because the author believes that the idea behind the code is great, and that it would be stolen.
Because of the “It’s not perfect enough” syndrome. In other words, the developer is willing to release the source code to public when the code is “good enough”, but day after day, there are still things to improve, so the code would never be released.

All of those reasons give a rather negative image of people who are against publishing the source code.

Are there valid cases to not release to the public the high-quality code which follows Kerckhoffs’s principle?

Some people and most companies have a strange perception about the value of code.

“We spent $100,000 on this project therefore the code must be worth that” and feel a need to protect it.

In reality most code is more like paint. You spend $100 on paint and $200 dollars to apply it to your walls. But now the paint is worth nothing, you cannot sell it, nobody wants it, and even if they did you cannot take it of your wall and put it on somebody else’s wall.

It may enhance the value of the building but you cannot realize this without selling the building.

You could “steal” Amazons code base (most of it is freely available from various open source projects) and set up an Ammassons web site but you would not take over much of Amazons business.

Code is a necessary part of any modern businesses infrastructure, but, it only has value as part of a process and culture, on its own its worth nothing.

I would add there are some situations where the code is vital to the business and would be valuable enough to any competitor that it should be kept secret:

To prevent malicious manipulation of your facilities — a good example would be Google’s “page rank” system which is constantly being “gamed” to give web sites an unjustifiably high rank.
Automated Trading Algorithms — an unscrupulous competitor could study the algorithm and fool your system into selling too low and buying too high.
A “faster/better” algorithim — if your software’ s unique selling point is a faster better algorithm for sorting/compressing/whatever then it probably pays to keep this a trade secret for as long as possible.

Because it was hard to write, and test. And design. And specify. And debug. And ISO 9000. And document. And version control. And get pointy-haired boss out of the way. And whatever makes the job of a software engineer worthwhile.

And you don’t want that your competitors just copy-paste your source code instead of putting as much time and money as you in their product.

The most obvious answer of all, I think, is that the software is, for many companies, a substantial part of the value that the corporate entity brings to customers. So, if anyone could simply modify and re-compile the code, or re-use valuable parts of it, then they could offer the same service or value. This would hurt the corporate entity’s competitive interests, and possibly cause them to lose money.

Money was spent to solve a problem, or a specific set of problems. If competition then get the answer for these problems for “free”, that puts the company that solved the problem at a financial disadvantage – especially if it would be possible for a larger company to “get to market” before the creating company because they have infrastructure in place, or if a competitor spends the money they WOULD HAVE spent on development on marketing.

What’s more, it’s sometimes possible to get an idea of a company’s policies and processes by looking at these things. Again, this information can be used as a stratgic advantage. This is often the bigger issue… the code reveals the company’s inner-workings.

You’re right, most companies don’t need to go to any great lengths to keep their code secret, because it’s of no use to anyone else. Many internal solutions are tightly linked to other applications and systems as sort of a custom ERP solution.

For some companies, the value of the software is a part of the value of their company. A crappy code base that works for their purposes has value and isn’t going to be of a concern to a non-technical buyer. No one wants to buy a company with strings attached. The buyer wants a cut-and-dry answer on who owns the code and are they free to do with it what they please? Who knows, the new company may want to take an internal application and sell it to others in the industry and leverage their purchase. This group will not value a bad code base as high as a solid application. Knowing the code was kept secret (although this could be an illusion) and there are no open source licenses to work around does add value to selling the business.

You don’t hand out the source-code because then when your client needs modifications to a software you built, they will have to go with you and you can charge premium.

Filed under: softwareengineering - @ 12:59

Thẻ: hacking, open-source, security

What are the cases where keeping source code secret is justified?

I’ve already posted a question about keeping the ideas secret, and received many great answers. Now, my concern is more about source code secrecy.

According to my observations of:

The codebases I had to work on during my career,
My own willingness to keep some of my own source code secret, and:
A few articles like, for example, Open response to Simon Stuart by the popular Programmers.SE contributor Mason Wheeler,

I conclude that source code is kept secret mostly for those reasons:

Because the author is ashamed of the code of such a bad quality, or the company fears losing reputation if somebody sees such bad codebase, or that given the low quality of the codebase, it will not bring anything useful to anybody to open source it: even if somebody would be interested, he would hardly be able to run the solution (or, often, even compile).
Because parts of the code are stolen (mostly from open source projects covered by a license which restricts its usage in a given situation),
Because the code relies on security by obscurity and the author doesn’t care about Kerckhoffs’s principle.
Because the product is so breakable that showing the code would cause too much harm: if a closed-source app with all those security leaks would withstand a newbie hacker, the same open sourced app would have far smaller chances, because even the beginner hacker would just have to study the code to discover all the holes.

If it’s not clear what I’m talking about, here’s an example:
```
if (credentials.password === 'masterPassword12345')
{
    isLoggedIn = true
    currentUser = credentials.userName
}
else
{
    authenticate(credentials)
}
```
Because the author over-estimated the source code (and his own skills and expertise). Example: believing that a home-made cryptography-related algorithm (which was never reviewed by anybody) is better than any well-known one.
Because the author believes that the idea behind the code is great, and that it would be stolen.
Because of the “It’s not perfect enough” syndrome. In other words, the developer is willing to release the source code to public when the code is “good enough”, but day after day, there are still things to improve, so the code would never be released.