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."

kinda true

[sdedeo]

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 [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:

[rolfwind]

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.

Thank you for your honesty, but it sounds like it's up to you to change that attitude now that you know better than to perpetuate it in that field.

Re:

[sdedeo]

Well, it's partly a joke, I mean, I don't actually send hatemail. But it's true that the authors spend a lot of time fielding "customer support". They are dedicated to their code, and put a lot of work into it, and it's not something that I personally have the time (or the code skills) for. You should see most of the code scientists write, it is horrific, cobbled-together stuff, meant for an audience of one. Perhaps I should take a CS class again (the last time was in high school) -- I duplicate efforts eve

Re:kinda true

[irtza]

I agree with your sentiments as well; however, I got over that sense of embarassment. I am not a computer scientist by profession. I write code to accomplish a task I wanted to do. The code is largely funcional, but may break around end cases or often has poor exception handling. Every now and then, I'll go back and clean some code up. I decided that there may be people who are willing to take this code and fix it up, or maybe somebody who can't program is looking for something quick and dirty to do what I have already done. For this reason, I released a substantial number of my programs as a single package on sourceforge. Some functionality is redundant to other projects, some is not.

Heck, I just realized I could recruit people here ;) if they are willing to help.

Re:

[sdedeo]

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.

It might be something to do with the bizarre psychological fact that p

Re:

[irtza]

intersting thoughts. I am in medicine; however, only a small fraction of the programs are related to medicine. I have in there general utilities that I have used for mass conversion of file formats (usually one text file format to another), or to allow me to get access to datasets others have published.

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:

[sdedeo]

Interesting. Releasing code unrelated to the core field seems fine (I may have done that myself, including little "bug fixes".) It's when you come to release code that does something related to your core competency that things become problematic -- people could use it to (unfairly) judge your work.

Re:

[j-pimp]

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:

[BronsCon]

I would have moderated parent as insightful, but I prefer to comment and elaborate. There may be an advantage to releasing your sloppy code. Someone might come along, clean it up and show you what was wrong with it. Sure, that code isn't going to get you any job offers. The next program you write after learning how to make pretty code might, though.

Re:

[MidnightBrewer]

But that's not realistic. Pretty code takes time, and companies hire you to meet deadlines with a product that works, not make perfect code. The whole point of this conversation is that one of the lesser-known reasons to keep things hidden is to keep your ugly mistakes from coming to light.

Re:

[tchuladdiass]

I'm in the exact same position. I released a simple interpreted language on Sourceforge and get a few downloads a week, and only a couple support / feature requests, and no traffic on the mailing list.
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:

[slashdotmsiriv]

"People will not understand your code, they will misuse it, and then they will blame you when it gets them in trouble." Thank $DEITY Linus et al. do not share the same view with your advisor ...

Re:kinda true

[letxa2000]

But what's the real reason for closed, proprietary code? Embarrassment."

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

[Kadin2048]

Code is kept "secret" because the companies, rightly or wrongly, think it gives them a competitive advantage.

I'm not saying this is never true, in fact I think it's probably the case more often than not. But at least in some cases, I've known/seen companies who have indicated a willingness to open-source their code -- meaning that they've thought about the competitive aspects and realize that it's not going to hurt, and might help, them -- suddenly drag their feet at the last minute, or spend months or years "preparing" to open-source their code. I think this is directly related to embarrassment over the poor state of their codebase.

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 ... suddenly they clam up and come up with excuses. This is most apparent when the code being considered is abandonware or otherwise dead, and the only effect it could possibly have is to hurt a competitor; companies (and individuals) are paranoid of the damage to their reputation that messy code could have, particularly if lots of insecurities or design flaws are exposed.

Re:kinda true

[mcrbids]

I've known/seen companies who have indicated a willingness to open-source their code -- meaning that they've thought about the competitive aspects and realize that it's not going to hurt, and might help, them -- suddenly drag their feet at the last minute, or spend months or years "preparing" to open-source their code. I think this is directly related to embarrassment over the poor state of their codebase.

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

[DudeTheMath]

In the field my employer works in, namely, financial software, we are mostly competing with our customers. What we do isn't necessarily hard, but is complex. We've put years of experience into the software. Any of our customers is trying to decide whether to do these calculations in-house or farm it out to us. If our source code was readily available, we'd get a lot of "Thanks, but we've got what we need now!" instead of sales. It's not proprietary algorithms, it's not trade secrets, it's simply the thousands of programmer-hours that have made an intricate piece of software what appears obvious in hindsight. We do occasionally release the source under an NDA for a customer with an odd platform we can't provide some kind of object module for, but that's certainly the exception. We aren't embarrassed by the state of our code; we just want to make sure we're paid for the work.

Re:

[OakDragon]

Code is kept "secret" because the companies, rightly or wrongly, think it gives them a competitive advantage.

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:

[udippel]

I had an employer many moons ago who manufactures PC-add-on boards such as RAID controllers
[...]
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:

[rucs_hack]

I'm in exactly the same position. I'll be obtaining my phd in a few months, and I planned to release the full source code for my work, which amounts to over ten thousand lines of code (machine learning and EA's in my case). It all works, and what it does is pretty cool. However code written over three years, haxxed about, experimented with and cannibalized at times to make utilities does not in fact make a nice release candidate.

There ought to be an open source project to clean up research code and make it

Re:

[Original Replica]

It all works, and what it does is pretty cool. However code written over three years, haxxed about, experimented with and cannibalized at times to make utilities does not in fact make a nice release candidate.

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:

[rucs_hack]

the most likely event would be that I release the code, people look at it who are interested in the algorithms, they recoil in horror, and my reputation drops.

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

[Maurice]

Years ago I posted the source to a neural net implementation that I did while in school. It was a very simple one with just regular back propagation, and the code was documented with examples. Soon after that I started receiving all kinds of email asking for help with the code from people clearly trying to use it to do their Comp Sci homeworks or projects. I started out with courteous and helpful replies, but at some point people ask questions which really have nothing to do with the software (and more to do with whatever that person is working on) -- to the point where they are wasting your time and you have to cut them off. Then they get annoyed and start insulting you.

Re:

[ScrewMaster]

That's why you release the source with "THIS CODE IS UNSUPPORTED - USE AT YOUR OWN RISK" stamped all over it and then don't leave any way for anyone to contact you. If you left an email address or a phone number and anyone finds your code useful they're going to drive you nuts. I learned that lesson a long time ago. The world is full of inconsiderate people who don't understand that their problems are not at the top of your to-do list.

Re:kinda true

[ratboy666]

Way back... way, way back...

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:

[rapidweather]

OK, I have some bad software I want you to look over:
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:

[sdedeo]

I actually kinda agree. The problem is sort of cat-and-bell -- right now, only a few do it, and are penalized, whereas if it were required we'd all get used to seeing crappy code.

Re:

[budgenator]

Considering that one of the major foundations of scientific method is repeatability, so to me not releasing the source code is like getting your data through divne revelation.

Re:

[gerddie]

Exactly so. For that reason, whenever I review a paper about "that great new algorithm" without any source code available, I tend to write that without the source code a proper review is not possible within the requested time frame. Usually, I also add in the notes to the editor that the release of a working implementation - at least to the reviewers - should be a requirement for publication.
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

[illegibledotorg]

Sometimes people make fun of Perl because the code looks like 'line noise.' As a Perl programmer, I resent that. Any code released to the public with my name on it is pristine, well commented, easy to read, and nearly bug free.

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

[Dachannien]

There used to be an Obfuscated Perl Contest [wikipedia.org] (in the spirit of the International Obfuscated C Code Contest [ioccc.org]). I suspect that the reason they stopped holding the contest is because of the risk of someone inadvertently causing a universe-collapsing paradox with their contest entry.

Re:Can't help but agree

[Anonymous Coward]

> There used to be an Obfuscated Perl Contest

I've always wondered how they get the acronym "CPAN" from that. :-)

Nah

[markov_chain]

it's still there, they just renamed it "Perl Contest" ;)

Two reasons...

[Kjella]

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.

Re:Two reasons...

[ShatteredArm]

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?

Re:

[fymidos]

code is protected by copyright law, coca cola recipe is not.

Re:

[fyngyrz]

code is protected by copyright law

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:

[msuarezalvarez]

code is protected by copyright law

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:

[fyngyrz]

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-fre

Coca-Cola's secret recipie

[Jeremy_Bee]

Why doesn't Coca-Cola release their secret recipe? Is it because it's bad?

Coca-Cola's "secret recipe" is basically just to add massive amounts of sugar.
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:

[fyoder]

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:

[vertinox]

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?

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:

[ShatteredArm]

You can do it illegally without the source, but it will take a heck of a lot more work than it would if you have the source. Tweaking source code and selling it is a little bit easier than reverse engineering, or rebuilding from scratch.

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:

[SnoopJeDi]

all sort of serial numbers and activation and whatnot that's incompatible with showing source - you'd just comment out those bits.

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...

[Unoti]

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?

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:

[WNight]

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++.

Re:

[Chmcginn]

"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?"

That's the dumbest fucking thing I've ever heard. And games try to curb piracy with hardware (why mod-chips are needed), computer software doesn't have that luxury.

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.

[SanityInAnarchy]

At least with your example, it is complete and utter bullshit.

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...

[iknownuttin]

American Airlines and their Sabre booking software. AA had a tech edge back in the 70's with their software. Other airlines actually rented, not licensed, AA's software.

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...

[darkmeridian]

Sabre was crucial technology that kept AA at the head of the pack. The system was quick and assigned the quickest available flight to each passnger. Sabre began as a military system for assigning interceptors to incoming targets, but there was clearly an application to assigning passengers to planes. Sabre eventually got spun off into its own company. Travelocity is based on SABRE technology.

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

[AaronW]

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.

Re:Often companies can't release it for legal reas

[kisielk]

Well, if you think about it, the whole reason these companies are being held back by the 3rd party components is because the 3rd parties didn't open up their code in the first place. A bit of a catch-22.

Been there. Seen that. Got the T-shirt.

[thatskinnyguy]

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?

Re:Been there. Seen that. Got the T-shirt.

[dc29A]

It is much worse than that in my opinion. I had to recode many parts of this ancient yet very important financial application. You wouldn't believe the horrors in that code. Goto galore, single threaded server components, buffer overflows and whatnot. However, that was nothing compared to the plethora of security deficiencies. Database root user with blank password for one. Absolutely no auditing. Everything sensitive transmitted in clear text. Insane amount of business logic bugs. If this company releases this source code, it closes shop next day because people would realize how insecure their software is.

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:

[thatskinnyguy]

Just wondering, did any of those companies have any problems with corporate espionage? If not, they're damn lucky.

Re:

[durdur]

Yes, sometimes the Crown Jewels is something that's been optimized to within an inch of its life. I've seen some examples.

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:

[CaptDeuce]

Some of the proprietary code that I've seen...

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"

[rueger]

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.

Re:"Trade Sekkrits, Sooper Original Algorithms"

[Sique]

I wonder why SAP is still in the business of ERPs then. SAP's R/3 code is open (but not freely distributable). If you are interested in the inner workings of SAP's R/3, log in with developer priviledges (or just SAP*), fire up the R/3 builtin debugger and look how the code is actually working.

Yes. You can build a successful business with proprietary code and still show it to the world.

Re:

[Oligonicella]

You'll note he didn't say you couldn't compete doing what SAP is doing, only that a business that can keep a better process to themselves has an edge. What's your point?

Re:

[Sique]

Of course I note that. But I just doubt a little that it actually makes sense for the majority of software vendors to keep their source secret. Source code is protected by copyright law, and thus obfuscation by compilers doesn't add much of protection to it.

It isn't the code that has the most value

[Anonymous Brave Guy]

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

[styryx]

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.)

Don't forget NIH syndrome

[$RANDOMLUSER]

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.

Re:

[thsths]

> just write your own b-tree library.

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

[fyngyrz]

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

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:

[fyngyrz]

This sort of leak is impossible to detect except by a human, and even humans have trouble with it when the list is mixed with live and dead objects and the bits of code which "forget" about objects in the list without removing them are scattered everywhere.

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:

[fyngyrz]

Wow, way to guarantee your software will have terrible usability.

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:

[AaronLawrence]

The problem with this idea is that it is really unlikely you actually have implemented everything that Microsoft did, albeit with bugs.

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:

[fyngyrz]

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

[edibobb]

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.

Obvious?

[dracocat]

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?

Re:

[Brandybuck]

Precisely. If it was more profitable for a company to open source their product, then they will do it. And many have. It is natural for businesses to seek out and exploit advantages, and that is a good thing. They are not charities. Even in a world without copyrights, companies aren't going to provide public access to their repositories.

Re:

[Ichijo]

If we publish it and another companies takes it and uses it to make a competing product we will make less money.

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?

[TheLink]

So what's the big deal about companies keeping all that bad code proprietary?

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

[Anonymous Coward]

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.

Look at the losers and you'll see ... losers

[kscguru]

This blogger did something quite insidious and quite stupid: she chose only examples that support her claim. Let's look at all her ugly/evil/l3me closed-source whipping boys:

Diebold

The poster child for make-a-buck quick. Diebold saw a "need" for electronic voting software, lobbied a few politicians to get sweetheart deals, and came up with substandard, shoddy software. Same moral as always: you get what you pay for, and the gov't paid for the lowest bidder.

Samsung's Linux rootkit

So Samsung wrote some truly crappy Linux drivers? Well, Samsung's printer driver looks like it was written by a college intern on his first assignment - which probably means it was written by a college intern on his first assignment. Do you really thing Samsung is going to assign their best developers to writing a Linux driver, especially when Linux folks will just reverse-engineer it anyway because they don't like something about it? No, Samsung is going to give the project to the lowest-level code monkey they can find. OF COURSE the code looks crappy.

BIOSes

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 kernel. It's understaffed, and the code quality shows. You think BIOS vendors stick with BIOS because they want lock-in? Ha. How about they don't have enough people to create a replacement, they are too busy patching up last year's code with this year's features.

Netscape

Yup, the Netscape codebase is an ugly mess. You'd think they implemented features without planning months ahead, almost like they were competing with some other major web browser ... the Netscape mess is a result of competition. I know enough former Netscape engineers to know they don't write crappy code. But when your schedule gets cut from 1 year to 3 months to compete with Redmond, crap will result. Remember, Open Source has the luxury of not having schedule competition - if a company delivers a feature late, developers will find themselves out of a job.

StarOffice/OpenOffice

Isn't the revisionist history here fun? Do you really think Sun was proud of the StarOffice codebase? No, Sun released it because the Open Source community begged for it (and Sun was the most likely to give in), and Sun wanted an office suite competitor to have SOMETHING to start from. No one ever claimed StarOffice code was any good; the only claim here is that StarOffice was better than nothing. You think Sun's best engineers worked on StarOffice? No, they worked on Solaris and Java. (With apologies to anyone who did work on StarOffice.)

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:

[Wavicle]

BIOSes
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

[MillionthMonkey]

So Samsung wrote some truly crappy Linux drivers? Well, Samsung's printer driver looks like it was written by a college intern on his first assignment - which probably means it was written by a college intern on his first assignment. Do you really thing Samsung is going to assign their best developers to writing a Linux driver, especially when Linux folks will just reverse-engineer it anyway because they don't like something about it? No, Samsung is going to give the project to the lowest-level code monkey

Different Approaches

[quo_vadis]

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.

Riiiight

[DurendalMac]

As opposed to open-source, where everyone can see how shitty the code is. Gimme a break.

Soooo True

[SolitaryMan]

At my previous place of employment this reason for keeping software closed was actually named several times by different people.

NoMachine

[Cheesey]

NoMachine's Linux server and client, for one example, rely on an ancient version of libstdc++ that sends you wandering all over Google trying to locate a copy of it.

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

[Brandybuck]

I am a consulant that works with a lot of companies, and I get to see the source for lots of proprietary software. The idea that they are embarassed by their code is ludicrous. They keep it proprietary for real and perceived trade secrets, don't want brand dilution, don't want to support user modified software, etc.

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.

[rjh]

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.

Re:

[Epistax]

Our CEO refers to our code as "spaghetti code". I work for a multinational corporation with an engineering base of a few hundred in the US and a hundred or so in India, as well as a manufacturing base of around a thousand (I believe) in East Asia.

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.

[www.sorehands.com]

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.

So what else is new?

[Tim Ward]

I've know this for decades, for far longer than the open source movement has existed (and the main difference there is simply that they don't mind people seeing that their code is crap).

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".

[dpilot]

I can't release it because it belongs to my employer.

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

[MrSteveSD]

In certain vertical markets e.g. software bought by energy distributors or water companies, rival software companies don't want each other to see their products at all let alone the code. The idea is that if the rival sees some of the cool things in the product, they will just copy it. You usually can't even get to see the software at all unless you are clearly a potential customer.

Re:

[PPH]

In certain vertical markets e.g. software bought by energy distributors or water companies, rival software companies don't want each other to see their products at all let alone the code. The idea is that if the rival sees some of the cool things in the product, they will just copy it. You usually can't even get to see the software at all unless you are clearly a potential customer.

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:

[MrSteveSD]

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.

[oGMo]

No, this isn't the reason things are kept proprietary. Stop and think for half a second:

1. Design, Policies, Marketing
2. Development
3. Delivery

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

[technoCon]

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.

Re:

[canuck57]

(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:

[PPH]

Google old timers aren't very old though.

Re:

[julesh]

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

Re:

[ajs318]

Or, just make it law that software be distributed in Source Code form. Absence of source code does nothing to prevent unauthorised copying. It just makes it a lot harder for users to (1) know what is going, (2) fix problems and (3) adapt the software to their established workflow instead of the other way around.

Re:

[CastrTroy]

And every car should be shipped with a full schematic for each and every part of the car. As well as documenting the complete manufacturing process. Who cares if the competing car company then uses all that technology you took years to develop.

Re:

[segedunum]

I take exception to Moldy binaries being the vendors fault. Its the OS's damn fault. I can write a windows program that worked 15 or more years ago on windows and it still executes just fine today. With linux thats impossible because distributions don't care about backwards compatibility...

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:

[Tim Browse]

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.