Slashdot Mirror
What's So Precious About Bad Software?
David Gerard invites to read Carla Schroeder from Enterprise Networking Planet, who gets down to the real reason why companies want to keep their code proprietary, with examples. Quoting: "We are drowned in tides of twaddle about precious IP, Trade Sekkrits, Sooper Original Algorithms that must not be exposed to eyes of mere mortals, and all manner of silly excuses. But what's the real reason for closed, proprietary code? Embarrassment."
As a scientist, I write a lot of code to do things that other people have already done. I sometimes think about "releasing" it -- informally, without a license, just on a webpage or something. But it really is embaressment that holds me back -- it's poorly documented, full of hacks, and basically inelegant.
I remember as an undergraduate suggesting to my advisor that I release my (actually rather pretty) code that I wrote to do general relativistic raytracing around neutron stars. His response? "People will not understand your code, they will misuse it, and then they will blame you when it gets them in trouble." You might expect someone who's doing raytracing around compact objects to not be so silly as to do something like that, but I think you'd be mistaken: I know I treat the few publicly available codes in my field (e.g., camb) with great disrespect, bitch all the time, and generally am part of the large community that makes it far more trouble than it's worth for the poor people who worked so hard on it.
Protect your liberties. Donate to the ACLU
Some of the proprietary code that I've seen is like a beater car:
-Held together with duct tape and bondo
-Only works by the hand of God
-Looking at it is an example of several works in progress from several different people
Yes. Companies that do that have a right to be embarrassed.
Then again, I've seen the other side of the spectrum where the proprietary code is "SOOPER" efficient and works better than any out of the box solution. Isn't that why you do things in-house to begin with?
The game.
I think #2 would be the major reason here. It's not just to hide "bad code". Why would you put all kinds of money and resources into your work, just to have someone else take it and profit off it after just a few tweaks? It's like asking, "Why doesn't Coca-Cola release their secret recipe?" Is it because it's bad?
More improtantly, what's there to motivate them to do that? It's extra work for development, extra work for support, longer time to market, more risk of malfunction compared to just writing the code naturally. And what's the benefit? If I were managing a programming that wanted to do that, I'd ask him what the benefit is for this extra work and complexity, and if he didn't have an answer, I'd tell him to focus on what's important and get this product out the door without goofing off.
Then there's the Not Invented Here effect. Need B-trees? Don't buy a third party implementation, 'cause that costs money, and don't use an open source one, 'cause it's encumbered with GPL, just write your own b-tree library. Of course, it's not as pretty and bug free as the other implimentations, but it's OURS; and yeah, it would be embarassing to let other people see how crufty it is. I think this is one of the secrets of Java's popularity, most everything is built in already.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Most companies who protect their code don't need to worry too much about it. It would take their competitors as much time to steal their code as it would to write new code. Analyzing a "foreign" project and then integrating it into another usually takes a lot of time. And then, the result would probably not be as good as new code. There might be some "ahh... so that's how they do that!" moments, but probably not worth the effort of stealing and analyzing the software. The main reason I would protect code would be to prevent lawsuits. Someone could analyze the code, find flaws, stage losses, and sue. Even this is pretty unlikely in a medium-to-small sized company.
Well, we invested a lot of money and resources to get the product written so that we could make money from it.
If we publish it and another companies takes it and uses it to make a competing product we will make less money.
Do we need another reason?
Another thing to consider is the fundamentally different mentalities the two camps (open source vs closed source) have. For closed source, all that matters is shipping a working product. So what if it breaks if you have more than 4GB of RAM or your directory naming convention must be exactly so. The open source approach on the other hand tends to be we wont call our product done till the code is perfectly optimized for all systems from a VAX to a Blue Gene. Also, one must consider that individuals and companies are at different ends of the spectrum when it comes to reasons why they have not released code. For individuals, there is personal criticism from programmers about their code. But, one has to keep in mind that not all individuals are programmers. If a recent physics PhD chooses to release the code he used to process output of his high energy particle physics simulations for his thesis, he would be heaped with scorn for spaghetti code despite the fact the code accomplished its primary purpose (get enough data to get the guy his degree) and did it in a reasonable time frame. For companies, there is simply a strong sense of possessiveness. They are loath to give away anything; including code for products they dont use or support anymore.
Legally obligatory sig : My opinions are my own... etc etc
The proposition here is "upper management knows the code is a mess and is embarrassed by it, so they insist on keeping the code closed."
Who here thinks upper management knows what code looks like, at all? Not bad code, not good code, but code, period. Does anyone really believe that the executives who make policy decisions about whether to release code are in any way qualified to comment on code aesthetics?
Hell, I think most programmers are unqualified to comment on code aesthetics. For a lot of people, programming is just the daily grind. People who actually put their heart and soul into crafting a piece of mathematical art are very rare. So if management can't recognize good code and an awful lot of the IT department is apathetic to good code, how is it possible that the decisionmakers know enough to be embarrassed by the code?
And if we can realize this in just ten seconds of thinking, why didn't Schroeder think of it herself?
As near as I can tell, the reason why companies like closed source is very simple: it preserves the asymmetry of information necessary for their bottom line. A free market depends on both parties knowing the product being bought and sold. When you buy a new car, you can read Consumer Reports, you can read Car and Driver, you can read any of a dozen specialist automotive rags that will tell you in excruciating detail what a certain car's dual overhead cam configuration means in context of their competitor's choice for a single overhead cam. The buyer has complete access to information, and that puts the buyer in a position of strength.
Asymmetric information, where the seller knows far more than the buyer, puts the buyer in a position of weakness. If the product is a black box, then you can't really get an informed independent critique; you have to instead rely on the claims of the people selling the product. Which is great, as long as you're the seller.
Last week at XP West Michigan, the speaker advanced the theory that a company with an older codebase is invariably a competitive disadvantage and that anyone who builds a new system that does the same thing will eat their lunch. He went so far as to claim that this mechanism would result in Microsoft's doom. And I partially agree because "technical debt" in a codebase behaves just like this.
I think that an existing codebase may occasionally NOT be a mess or a competitive drag on a company. I'm not claiming this is frequent, but that it is possible.
Now, let's suppose I'm a young, hungry company who wants to eat a big, established company's lunch. If I know his codebase is chock full of "technical debt," I'll know he's at a disadvantage because everything he does to respond to me will have to carry along the burden of that technical debt. This means I have a better chance of beating him than if he's got clean code. BUT if I don't know if his codebase is crufty or not, that'll sew doubt into my analysis. That doubt will give me pause and provide a barrier to entry into that market.
You'll note that I made no mention of IP heretofore.
Thus, the company with a codebase that is ashamed of its codebase will be keep the extent of its cruftiness secret, to discourage competitors. Conversely, if a company knows its codebase rocks may consider IP to keep things mum, but if it buys into the line of thinking above, it may show off its codebase to warn off potential competitors.