What's So Precious About Bad Software? 278
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."
kinda true (Score:5, Insightful)
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 [camb.info]) 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.
Re: (Score:2)
Re: (Score:2)
Re:kinda true (Score:5, Insightful)
Heck, I just realized I could recruit people here
Re: (Score:3, Insightful)
It might be something to do with the bizarre psychological fact that p
Re: (Score:3, Interesting)
Some of the programs are for personal use - such as to automate the creaation of a photoalbum for web publishing.
I just don't see the problem with letting people know that I am not a good programmer. I have
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
I'm not sure what field you're in, but mine is small (at most 10,000 people, but actually much less.) Giving away code -- it carries with it responsibility, in the sense that if you do give away code people think you are saying "I am so cool that what I have done is better than whatever you haven't released." Sort of like, I don't know, the difference between keeping a diary and publishing a diary on livejournal. It generates problems.
I guess it really depends on the nature of the code. My pet open source project (see sig) has gotten hardly any feedback. I have a trickle of downloads, usually 2-8 a day, one anonymous bug report and some feedback from the author of UltraDefrag after I contributed documentation to his project. So the problem I've had with open sourcing my code is that no one cares. This is probably partially due to the fact that no one wants a SQL front end to MS Access databases and there are better frontends to SQLite.
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
Re: (Score:2)
Whenever I have an update I post to freshmeat.net, then I get a surge of downloads but thats about it. However I was getting some feedback from a particular user -- I didn't really grasp what he was asking for at first (and didn't see the need for those requests), but once I started looking into it I ended u
Re: (Score:2)
Re:kinda true (Score:5, Insightful)
Oh, please. That's got to be the goofiest premise I've seen in a long time.
Code is kept "secret" because the companies, rightly or wrongly, think it gives them a competitive advantage. Heck, some companies should be embarrassed about the appearance of their product, do you really think some suits care about how it looks on the inside? Does Coke keep its formula secret because it's embarrassed or because it wants to make its product harder to copy? Same goes for software.
Heck, many open source products are no beauty to peer into, either. The code is so nasty that the argument of "If you don't like it, you can fix or modify it yourself" is reduced to a smart-ass comment with no real validity. Modify that code? First you have to be able to understand the mess. Unless you've been responsible for the mess from the beginning, or have a lot of time to invest in figuring out the mess, good luck with that.
Re:kinda true (Score:5, Insightful)
I think there's a feeling that in order to open-source something, you have to have it all wrapped up in a neat little bundle, that you can't just take last Tuesday's CVS checkout and dump it onto a web server somewhere as a tarball, even if that's what the community really, really wants. (A dirty tarball today being better than a slick project and a wiki and everything in three years.)
I've actually seen this happen; you can get management on board with the OSS concept in the abstract, but when it comes to actually giving out their code, and they start feeling like it might make them look bad
Re:kinda true (Score:5, Interesting)
Yep, here I am. I'm a CTO of a rapidly-growing software company. Our big money maker is a product initially conceived as a "quick project" of a few months' duration and was given similar consideration on design and construction. But it worked! It solved a need at a level that was unanticipated, and now, 4 years later, is satisfying 20x the dataset and 100x the customers originally envisioned.
And it was not originally designed for this level of scale.
So, going from a single, solo software engineer, to several programmers, (and growing fast) and developing a rapidly growing suite of products in a rapidly growing company, the cash-cow project remains, alas, solely in my hands.
Does the product work well? Yes, at least, reasonably well. Users routinely rave about how much time it saves and how it's improved their professional lives. It works well for the problem it solves and the problem is not met effectively by any competitor.
But, the dirty secret is that it's simply inelegant. It's a bunch of not-well-structured code only organized by a sloppy ad-hoc naming convention and riddled with minor bugs that are fixed quickly and distributed well, but shouldn't exist in a better design in the first place.
And, once saddled with the code, Code Inertia takes place [kimbly.com] and it becomes an exercise in how to move to something more sane while doing the following:
1) Keep the customers happy through multiple upgrades that don't appear any different than original. Introduce features that are obvious just fast enough to make it all seem worthwhile!
2) Keep the additional costs of development inline with "maintenance level". This cuts the rate of improvement, and also increases the amount of inertia accumulated with #1, since #1 is written to the "old way".
3) Improve the codebase enough to provide meaningful results demonstrated to the august powers, (this means ROI) and
4) Clean up the kludge enough to allow for improved pace of future development. You want to get rid of all the uglies, but there are so many since a few of your original, naive assumptions about the problem were simply wrong.
It's a hard row to hoe, and there's a bit of a "loan" being made, where design decisions early on made to shortcut development woes carry a long-term burden, almost like an interest rate. Since the company has passed the million-dollar-a-year stage, arguing about those original decisions is pointless; the only thing to do now is to figure out how to take what you started with and make it do what you need it to do hereafter.
I've been working for over a year on a basic design decision change that will close out lots of badness and produce almost an order of magnitude better data integrity. Since starting the project, we've almost tripled in client base, and yet I won't be done for at least another year, if ever.
I suppose the argument is moot - if I hadn't come up with the original product in time, the whole business would have failed. The company, then on the rocks, would have closed, and it would all be for naught. But, with the compromises made, it can be amazing just how badly inertia sets in.
Moral? Write the best quality code you can within the budget you have. Always. Because you'll live with a significant percentage of whatever you create, and the future costs of change may well be orders of magnitude more than your initial cost of creation. And you'll never quite know what it is that you end up living with.
PS: While it might sound like I'm complaining, I'm not! I'm living the dr
Re:kinda true (Score:4, Interesting)
Re: (Score:3, Insightful)
I have to agree with you there, but I would word it a little differently. The code is secret because it may give the company a competitive advantage; releasing the code, however, guarantees that competitive advantage is gone.
As a hobbyist who enjoys old computers and software, here is a question the vintage computer community often hears: Why do companies refuse to release or open software that
Re: (Score:3, Informative)
[...]
because a bigger competitors could take that knowledge and turn it into a less expensive product
[...]
there were features designed into the hardware ASIC's that should have worked, but didn't.
[...]
the company was unwilling to disclose that there were embarrassing design flaws in their hardware, a perception that could have ruined them
Sounds like your bigger competitor could have been Adaptec. I guess they used the
Re: (Score:3, Interesting)
There ought to be an open source project to clean up research code and make it
Re: (Score:2)
Release it for free use under the name "Ridiculous Gobbledygook" and don't offer support except to someone who's main focus is programming and is trying to clean up the code. It would be nice to see these very specialized sloppy programs rewritten as a learning experience for programmers, I'm sure it
Re: (Score:3, Interesting)
If there was a place that *expected* shitty research code I wouldn't mind, but I have a current open source project that I wouldn't want tainted with the bad coder rep my research code would likely generate.
I've got a fully working temporal neural network sat in a deep directory that I'm sure someone would like, if I can tidy it up first. I've not fou
Re:kinda true (Score:5, Interesting)
Re: (Score:2)
Re:kinda true (Score:5, Interesting)
I developed a system that decoded phototypsetting codes, and imaged onto a laserprinter.
I wrote the software using Borland Turbo Pascal, 8087, so it required a math coprocessor. One of the sales reps aquired a 286 laptop that didn't have a socket for a coprocessor, and wanted to demo the software.
I used Borland Turbo C to do a quick hack to emulate the 8087. Worked fine, but I didn't want to support it. Still, it was (somewhat) useful, and I released it as a hack (emul87 on simtel).
Fast forward 8 or 9 years... I got a call from someone claiming to be a "consultant", who had a client using emul87. Apparently, it didn't work on a new machine! And if I didn't fix it RIGHT AWAY, I would be SUED!
Of course I told him to take a flying fuck at a rolling doughnut -- and he went away.
So, this stuff happens. Go figure.
Re: (Score:2)
This is an internet radio station selector for Rapidweather Remaster of Knoppix Linux. (See screenshots, below, there are some showing this working.)
You may get a copy here, be sure and chmod +x station* to get it working.
http://www.angelfire.com/ms/telegram/station_selector.tcl [angelfire.com]
This thing is a front end for XMMS, and works alright as long as the addresses of the internet radio stations are vaild. If they are not, then XMMS will lock up, and cause a runawa
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Especially in computer graphics it's really annoying - they put in some pictures and tell you that they look better.
Can't help but agree (Score:2, Interesting)
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.
Re:Can't help but agree (Score:4, Funny)
Re:Can't help but agree (Score:5, Funny)
I've always wondered how they get the acronym "CPAN" from that.
Nah (Score:4, Funny)
Two reasons... (Score:5, Interesting)
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.
Re:Two reasons... (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3, Informative)
So are music recordings. And we all know how well that's worked out, right?
As an earlier poster said, with precise insight: "The honor system is short on honor." We know this. There is no possible doubt about it. And with open source, it only takes one person to steal something in literally seconds that took many years to develop and hone. This is the reality that commercial developers have to live with.
Speaking as a closed-source, commercial software vendor, I
Re: (Score:3, Insightful)
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?
Re: (Score:3, Insightful)
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-fre
Coca-Cola's secret recipie (Score:3, Informative)
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.
Re: (Score:2)
There actually is an open source cola [wikipedia.org]
I suspect a large part of the reason for Coka-Cola keeping the recipe secret is marketing, the mysterious allure of secret recipes, secret herbs and spices, and how do they get the caramel into the Caramilk bar? Open sourcing it wouldn't lead to reduced sales from people making their own, as it's a pain in the butt, and their competitors (esp. Pepsi) are looking to do their own thing and are also engaged primarily in a marketing game.
I'm not sure a secret cola reci
Re: (Score:2)
In a perfect world, your code would be copyrighted, but everyone have the ability to see your code at the copyright office database. However, everyone else would have the same requirement so it wou
Re: (Score:2)
As far as how Coca-Cola recipes are or aren't protected, that's irrelevant. Even if you can't protect your recipe the same way, they'd want it protected for the same reason. And that's what this discussion is about: why they'd want to protect their source code.
Re: (Score:2)
What's stopping them from compiling the important our-eyes-only stuff into an executable and putting the rest of the magic in a library which is released?
I mean, games come with the same sort of copy protection, but almost every mainstream game has an SDK that allows you to modify the game code (which is housed in a linked library) without scratching the surface of anything in th
Re:Two reasons... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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++.
Re: (Score:2)
Um, you do realize that many games are PC-based, yes? And those are what he's obviously talking about... For example, in Unreal-engine based games, it's generally possible to modify th
#2 is bullshit. (Score:2)
Who buys Photoshop?
There was a Slashdot article awhile back about how casual piracy has gotten, even among non-technical people. Photoshop included, Windows included... In general, your copy-protection scheme is probably already zero-dayed, and will almost certainly be broken within the year.
You know why?
Because while it's not as easy, it's still very possible to comment out those bits in the assembly. It's a lot easier than most other modificati
It goes back too... (Score:5, Informative)
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.
Re:It goes back too... (Score:5, Informative)
Another reason for secrecy is that SABRE was used to manipulate rankings to favor American Airlines flights over others. This eventually got outlawed by the federal government as unfair competition.
Often companies can't release it for legal reasons (Score:5, Informative)
Re:Often companies can't release it for legal reas (Score:2)
Been there. Seen that. Got the T-shirt. (Score:4, Insightful)
-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?
Re:Been there. Seen that. Got the T-shirt. (Score:4, Insightful)
Another application I worked on, had vendors dictate features and managers (without any technical background) gave us encryption routines. Worse than hacks, retarded XOR and shift routines that a 2 year old could crack. These same managers have used really badly coded RadioactiveX components made for browsers as a "high performance" server component. And of course they wonder why their servers can't take any load.
Embarrassment is probably a good reason why companies withhold source code, but I think it's more the fear of losing business over extremely shitty and insecure software is their primary concern.
Re: (Score:2)
Re: (Score:2)
But even if it isn't, and is a pile of cruft, it may be a pile of cruft that took years to write and is not something a competitor can easily duplicate. So keeping it under wraps could still give you an advantage.
Re: (Score:2)
Code? I don't need to see no stinkin' code!
There's plenty of software out there are like Taun Tauns -- they smell bad enough on the outside. For instance, after finally getting into a BIOS setup screen (hold down which the F-what ke... damn, too late), do you really need to see the code to know what it smells like?
"Trade Sekkrits, Sooper Original Algorithms" (Score:3, Insightful)
Re:"Trade Sekkrits, Sooper Original Algorithms" (Score:4, Interesting)
Yes. You can build a successful business with proprietary code and still show it to the world.
Re: (Score:2)
Re: (Score:2)
It isn't the code that has the most value (Score:2)
Yes. You can build a successful business with proprietary code and still show it to the world.
Indeed. I'm always somewhat amused when you see these company acquisitions in the software development business where the PHBs in the acquiring company talk about how wonderful a job they've done. It's always about two things: the customary tip of the hat to the "great staff" they've got, and then the patting each other on the back over all the IP they now own.
What most PHBs don't get is that the people usually have far more value than the code. People who've spent a lot of time solving certain type of
Duh (Score:4, Funny)
(No, really, it was all sarcasm.)
Don't forget NIH syndrome (Score:4, Insightful)
Re: (Score:2)
It it were only happening with B-trees. I have seen projects that even ignored libc, and had their on memory management, special logging and tracing routines, and even time zone conversion.
Of course sometimes the API of libc is rather cumbersome, but the code is still hard to beat.
Re:Don't forget NIH syndrome (Score:5, Insightful)
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
Re: (Score:3, Interesting)
No, not impossible.
Our manager would catch this, or any variation of this, first time it happened. This is because on exit, after legitimate cleanup is done (meaning, we deallocate the things we have been keeping proper track of... memory for wi
Re: (Score:3, Interesting)
Why would you say that? I didn't remove the OS file dialogs. I just added some that actually worked the way Microsoft said they were supposed to, and had (a lot) more features in addition to the OS's version. If you really want to use a buggy OS dialog that gives you a list of names instead of a properly functioning one that presents thumbnails and names, why, you certainly still can. You can even block select files in the OS dialog. Ma
Re: (Score:3, Interesting)
Does it resize? Does it work on every language and codepage supported by Windows? Does it support the full set of Unicode characters? Can you sort in all the optional ways? Can it view in a detail list as well as thumbnails? Does it support every different font size? All the possible icon formats? Does it monitor the file system for changes and refresh itself? Does it handle
Re: (Score:3, Interesting)
I wrote you a nicely detailed answer using quoting and so forth, but slashdot won't let me post it; claims there are too few characters per line. Very irritating. The general answer is that we support what we need to support; some of what you are asking about isn't relevant for a special purpose dialog that displays thumbnails (detail listings... we do show image properties which are far more extensive and appropriate... screen readers... you can't screen read an image); some of it isn't relevant for a dia
Code Paranoia (Score:3, Insightful)
Obvious? (Score:5, Insightful)
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?
Re: (Score:2)
Re: (Score:2)
If you publish it under a license that requires licensees to credit your company for authorship, then that's free advertising.
So what's the big deal? (Score:2)
0) What are you going to learn from bad code that you can't already from "The Daily WTF".
1) There's good code and bad code whether it's open source or not. I've seen plenty of crappy code (PHP Nuke comes to mind). I've written some crappy code myself, but I like to think I've also written some good code - all closed source for now.
2) You don't usually have to see the source to know whether it's bad code or not.
3) Whether it's bad o
Intellectual bugs (Score:4, Interesting)
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.
Look at the losers and you'll see ... losers (Score:5, Informative)
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?
Re: (Score:2)
Did you know there are exactly two major BIOS vendors out there? That there are no more than a hundred or so professional BIOS developers in the world? Yet there are more copies of BIOS software out there than Windows; everybody expects BIOS to support new whiz-bang features (boot from USB, PXE boot, boot device ordering, processor errata, microcode updates). There simply aren't enough people to make BIOS code look good. BIOS programming is hard - harder than writing a ke
Samsung's Linux rootkit (Score:2)
Different Approaches (Score:5, Insightful)
Riiiight (Score:2)
Soooo True (Score:3, Interesting)
NoMachine (Score:2)
I didn't have trouble with that myself, but NoMachine's Windows client does annoy me beyond belief. It refuses to coexist with fullscreen Direct3D applications, so if you want to play a game and use a remote Linux system, you have to reconnect every time you task switch out of the game. I cannot understand this behaviour as the NoMachine softwar
Not the reason (Score:2)
I've seen proprietary code that was truly embarassing. But I've seen a lot more that was of very high quality and design. Funny thing, I've seen the same range with Open Source software as well!
Ridiculous article. (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
The code has been incrementally worked on for at least fifteen years, so yes it is more or less a jumble of sorts. Efforts have failed to make it cleaner, and have actually made it worse. The solution is obvious, and we're doing it now. My point is although o
I have seen some of this first hand. (Score:3, Interesting)
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.
So what else is new? (Score:2)
Someone asked me just this week for a copy of the code for my web site, so that they could set up something similar. I refused, because it is crap code and I don't want anyone else to see it. But at least I explained this reason honestly!
I own some "proprietary code". (Score:2)
But other than that, embarrassment is certainly part of the deal. I try to do a good job, but to be perfectly honest, I'm not really a programmer, and this code bridges the gap between my "real designation" and programming, simply because I'm one of the people who can stand in both worlds. Beyond that, it's a learning experience - there are some number of stupid things embedded in there. Every now and then when I have spare time, I try to remove some s
Secret UI Too (Score:2)
Re: (Score:2)
I've seen some of it, and its crap. The code might be pretty, well documented and elegant. But if a newcomer who actually new
Re: (Score:2)
I've seen some of it, and its crap. The code might be pretty, well documented and elegant. But if a newcomer who actually new the business ever got a peek at it, they could easily knock the incumbents out of the market ....
I used to work as a developer for such a company and there was a real lack of knowledge of the business area. The company was always too stingy to hire people who really knew the particular business sector, so we often just had to make educated guesses. The code could also get pretty bad because they liked to hire cheap people. After 6 months I had usually managed to train them up pretty well, but by that time they had already generated lots of crappy code.
This stuff is expensive! This is mainly due to the small customer base over which the cost of product improvements can be spread. Its not like you can count on the Halo 1/Halo 2 customer base to fund the next version.
Yes, it's expensive due to the low numbe
No. (Score:3, Insightful)
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.
doubt is a barrier to entry into a market (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
(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.
Re: (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I have games that were released for Linux seven or eight years ago that still work, Motif applications written over a decade ago that still work and there is COBOL code written twenty or thirty years ago that still work
Re: (Score:3, Insightful)
BS. Sweetheart, the only time Windows ever booted in 5 seconds for me was when I installed a Linux distribution to dual boot and the installer resized the NTFS partition to something much, much, much smaller. That's the only time that phenomenon has ever happened to me, so no, you are not getting 5 second boot times with Windows.
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.