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?
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
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.
Proprietary vendors don't have exclusivity on bad code, plenty of open source projects feature terrible code too. That said, anyone who ever worked on a crufty proprietary codebase knows there's a grain of truth here. Programmers know their kludges will remain unseen if it's in a proprietary app and product managers may be pushing for a feature ASAP when the elegant way would be to re-engineer part of the codebase. Finally, many coders in commercial shops (esp outsourced shops) are actually clueless and where contributors to open source projects are likely to have an active interest in the project, code monkeys are more likely to care only about their paycheck.
It's by no means a black and white situation. Browsing repos for a few PHP projects ought to destroy any illusion that all open source projects are well written.
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.
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
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.
I get your point, but modularizing your code is hardly ever a waste.
Technically it's usually a win for complexity alone - two smaller pieces are easier than one large one. But then there's the benefit that once all your heavy-lifting is nicely wrapped up, you can start coding the rest of your app in Python or something much nicer than C/C++.
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
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.So are music recordings. And we all know how well that's worked out, right?
Hmm, how? Have all artists starved to death, production and distribution companies collapsed, and is music no longer being created and played because the economic incentive has disappeared?
No, all the artists have not starved to death. However, that is a very poor metric for the state of the musical community.
The fact is, a lot of artists don't make it because the barriers to financial success — not to making a recording, mind you, but to financial independence so one can actually spend pressure-free creative time making music — are now much higher. That's why the radio is filled with utter pop trash; that's why bands *must* tour instead working in the studio, creating new music, that's why recordings are lowest common denominator compressed to the roof, so that every radio station and every moron DJ can have music that is "just as loud" as the other guy.
Sure, you have "music." But you don't have very many great studio bands (at least, unless they were already great studio bands, like Pink Floyd, Rush, Emerson Lake and Palmer, and so on.)
And what is really sad is the people who were raised on this utter crap... they don't even know any better.
In 1970, if ten thousand people had your recording, it meant that pretty close to ten thousand sales had been made. Today, it means that pretty close to ten thousand people with an Internet connection have copied it with no funds flowing back in your direction. That's not a good change, and that has primarily happened because technology enabled it, and copyright law and enforcement is as toothless as a 2-bit crack whore.
In 1970, you'd have made a few tens of thousands of dollars, you'd be at least encouraged, and you'd probably have a raft of new equipment or at least some studio hours paid for. Today, you'd have nothing. In the case where the music is good, but the audience is small, you're really screwed, because you're never going to make enough to survive. You know who makes enough to survive? Britney Fucking Spears, that's who. And the rest of her ilk. Because she's mainstream, and despite the copying, just as you imply, she does fine.
And by the way, I'm a studio musician and a recording engineer as well as a guy who owns tens of thousands of recordings and eleven different high end audio systems to play them on. I also own a literary agency where our authors totally depend on copyright still working (only what it really is, is book copying is still very annoying to end users) so they can sell books. I've been paying close attention to copyright and anti-copyright viewpoints for decades now. Copyright stops working the day technology enables the end user to walk around it less expensively than obtaining a legitimate copy of a work. As a law, it never meant anything. It just felt like it did, because the technology was a higher barrier to cross (for instance, in 1970, if you were copying high fidelity audio, you owned a reel to reel, because that was the only high fidelity medium available at the time.)
I've fallen off your lawn, and I can't get up.