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
Now, the stuff that isn't released to the public? That's 180dB noisy code. I can relate with what's being said here to a degree.
That said, I don't think sloppy code it the real reason source stays closed. Big business just thinks it'll make them more money in the long run.
1. What others don't know, won't hurt you. Any improperties in the code, any patents violated, any sarcastic remarks in the source - if you don't release source, they won't see it.
2. If you can't see it, you can't take it. Most companies would like to get paid, and the honor system is short on honor. One thing is corporate software - but are you really going to go into people's houses and see if they have a pirated version of Photoshop? Not going to happen, so they design up all sort of serial numbers and activation and whatnot that's incompatible with showing source - you'd just comment out those bits.
Live today, because you never know what tomorrow brings
In a nutshell, I think corps think that their software is soooo competitively important, that they don't want to release it - regardless of how bad it is.
I prefer Flambe as apposed flamebait.
A lot of software contains proprietary libraries or other pieces of software provided by 3rd parties, which they are not allowed to distribute. It can be a huge job to strip or re-write those libraries, like what Sun had to do with Solaris, and if it's old software, it just isn't worth their time.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
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.
God. My question is who would want to attribute their name to juvenile mis-spellings of common words like that. Really, there's no secret why commercial operators would keep their code secret, no need for speculation. It's a business! If you can do it, and your competitor can't, then you make money and win.
Three Squirrels
It's obvious why code is closed source; it's a security matter. You seem to be forgetting ignorance is strength.
(No, really, it was all sarcasm.)
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?
(see what happens in google, etc). These people think they have a team of very good programmers but it's a bunch of tired old-timers.
Google old timers are very rich.
Having worked for a large stupid company, this really rings true. We were a startup with a product that did X. A big famous large stupid company bought us and said, ok, we want this HUGE thing Y that does this and does this and does this and does this- and it has to be built on X (because it was "prestigious", although it did NOTHING similar) and totally integrated with it and the Y data types have to be completely intermingled with X data types so you can transfer objects from the context of X to the context of Y seamlessly. (I have to change details to protect the guilty, but imagine that X was a raytracer, and Y was a vote counting system.)
So we basically spent a year fucking up X into a conglomerate X-Y system, and ended up doing all sorts of horrible things to get it done on time ("fooling" old code, etc.) And I found out for myself how disheartening it is to be ordered to do something hopeless that makes no sense. Meanwhile we discovered that the sales guys had been running around for months promising a system that did X and Z, and that it would be ready next month. They called a meeting. (This is one thing they were good at- scheduling meetings.) They said we need to combine X, and this "Z" we've been promising, into one product. (Z would be a missile guidance system.) X was "prestigious", Z was the hot new thing, and Y was going out of style (denoted henceforth as "y", lower case). Only two customers used y, but they were IMPORTANT ACCOUNTS.
So there's a panic where everyone is trying to convert X-Y to X-y-Z (something nobody in their right mind would want), in the absence of any specifications at all. ("You guys are smart! Tell us what we want it to do!") And it's getting nowhere and bugs are starting to appear in X and people are using old versions like with XP and Vista. So much time passes that we could have written Y from scratch and Z from scratch without fucking up X at all. (I'm simplifying things somewhat, because I ran out of letters- there were a few more after Z.)
Right in the middle of it all, they pulled everyone into a meeting with patent lawyers and demanded that each of us produce a list of all the intellectual property in the application. The top 20 most patentable things.
What do you write? "System and method to cope with your incompetence?" I shudder to think that they might have filed a patent that prevented someone from doing something worthwhile, but I doubt they found anything they did that anyone would ever want to repeat.
So... we look at five projects that have every right to contain crappy code, and therefore conclude that companies keep code closed to hide crappy code? Pick crap and you will see crap. How about some successful projects: Microsoft Windows (kernel), Adobe Photoshop, VMware?
A witty [sig] proves nothing. --Voltaire
Exhibit A is Windows itself?
I don't need to read any further.
Right. Because, of course, Windows is perfect, so the article must be wrong.
You don't need to be a zealot to realise that Windows is probably pretty close to the classic definition of the codebase that's outgrown its original purpose by an order of magnitude or more and is now getting pretty hard to maintain. Why else did it take MS 6 years to release Vista, which isn't really much more of an upgrade over XP than XP was over 2K (which took them only 1.5 years)?
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
At my previous place of employment this reason for keeping software closed was actually named several times by different people.
May Peace Prevail On Earth
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.
Back at Aspen Technology, I was working with the IRMA card. They provided source code (In C)for their file transfer code for $100. I tried their code and found really dumbass bugs, such as:
int wait_x(int milsec)
But, when they didn't want it to wait, they would would call wait_x().
When I wrote a list of bugs, it was 3 pages, single spaced.
When at Microsystems Software, there were functions named, "we_are_fucked" and comments that
said, "I know this is crap, but Dick wanted this now. I'll fix this later."
That was 3 years after that programmer left.
Fight Spammers!
No, this isn't the reason things are kept proprietary. Stop and think for half a second:
If something is going to be designed and released Open Source, this is decided up front. It has legal implications, especially when you might be interfacing with external third-party libraries and making platform decisions. Then code is written.
Things are exactly the opposite: closed source leads to poor code. No one's going to see it. The product has to get out of the door fast. You hire crappy budget programmers. You don't enforce disciplines of good design and code. Marketing runs the show. There is no ability for the community to see, contribute, and fix. All of these things about the closed source process make crappy code easy. I've seen them all.
But of all of these, no, crappy code is not the reason people don't release their source. I've seen plenty of craptastic code released by companies, that of all things is hardly going to stop them. Especially when improving the code is one of the benefits of releasing it.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
McDonalds "secret sauce" amount to mixing ketchup with mayonaise.
So, Yes. Part of the reason for these kinds of secrets is that they are "bad" in a sense.
At the very least, it would be embarrassing to the companies in question to have stuff like this spelled out.
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.
Indeed. That's probably why the poster actually wrote:
It takes 5 seconds to start booting windows on my notebook, my PC is the same.it's still there, they just renamed it "Perl Contest" ;)
Tsunami -- You can't bring a good wave down!