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
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.
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?
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
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.
> There used to be an Obfuscated Perl Contest
:-)
I've always wondered how they get the acronym "CPAN" from that.
We have our own memory management; we do it because it allows us to ensure that there are no memory leaks, anywhere, ever. We have our own linked list management because it is a fraction of the size of the alternatives and does exactly what we need. We have our own file dialogs (and treeview dialog logic) because the OS offerings were buggy for almost a decade. We have our own JPEG routines because we need to load all manner of proprietary and oddball JPEGs. We have our own tree structure code for our ray tracer, particle systems and so on because we can make really big trees and unless we control the memory allocation, the tree becomes too fragmented in memory for it to be handled efficiently. I could go on like this for quite a while. In short, though, there are some very good reasons to skip over the canned solutions. And that's assuming that the canned solutions work perfectly, as described.
When one of your operating platforms is Windows, you either learn to do for yourself or you end up with a buggy application, because Windows itself is prone to long term unfixed (and sometimes unfixable) problems. Write your own code and you can eliminate the problems. That's a pretty strong motivation.
Code in libc may be hard to beat when it comes to doing what that code does; but who is to say you need exactly what libc offers? Memory management is a good example. We require firewalled memory boundaries, cumulative usage tracking by routines and by blocks of routines, named memory groups, live overrun detection, dead pointer detection, real-time and post-run logging. And the code has to be really, really good... if there's a bug, we can't wait for the libc maintainer(s) to fix it. With these kinds of needs, pretty soon you end up writing code. It's pretty straightforward, really.
There's a competitive advantage, too. If a bug is found, your turnaround time can be measured in hours if it is in your own code. For every bug that turns out to be a consequence of an OS or otherwise "not your code" library, bugfixes are much more likely to take longer or simply be impossible. Example? We can process streams of image frames. MS's file dialog let you select many files at once. Seems like a natural fit, right? Click on one file, shift click on another, you've got a block, we should process them. Winner! Well, yeah. But.
If you selected more than about 100 files, MS's file dialog would fail to properly terminate the returned file names, and cut off the last one arbitrarily. Leading to all manner of things, not the least of which was not the behavior that the user was trying to achieve. But wait, there's more! Unless the customer, completely unintuitively, selected the last file first and the first file last, the files would be provided to us by the OS out of order. So? (I hear you thinking.) Just process them in the other order, right? Well, yeah, but the first file in the list we got would be mangled in the natural order. And besides, it wasn't the first one the user selected, just a mangled file name somewhere around number 100 or so. What a mess.
We complained to MS for years about these things without result, until I had simply had enough and wrote our own file dialog. End of problem. Now it just works. Plus, since I was writing it anyway, I did it so the file dialog offers tree views, thumbnails, properties, regular expressions, file management, clipboard tricks, you name it.
No, it wasn't perfect first time out the door, but within a few weeks of release, the customers had ferreted out the weak points and they were all fixed and the working application was back in the customer's hands. I haven't seen a bug report on the file dialog in years now. But if I do... I'll put that bitch down like a KKK'er at an MLK rally.
It isn't wasn
I've fallen off your lawn, and I can't get up.