Slashdot Mirror
What's So Precious About Bad Software?
David Gerard invites to read Carla Schroeder from Enterprise Networking Planet, who gets down to the real reason why companies want to keep their code proprietary, with examples. Quoting: "We are drowned in tides of twaddle about precious IP, Trade Sekkrits, Sooper Original Algorithms that must not be exposed to eyes of mere mortals, and all manner of silly excuses. But what's the real reason for closed, proprietary code? Embarrassment."
As a scientist, I write a lot of code to do things that other people have already done. I sometimes think about "releasing" it -- informally, without a license, just on a webpage or something. But it really is embaressment that holds me back -- it's poorly documented, full of hacks, and basically inelegant.
I remember as an undergraduate suggesting to my advisor that I release my (actually rather pretty) code that I wrote to do general relativistic raytracing around neutron stars. His response? "People will not understand your code, they will misuse it, and then they will blame you when it gets them in trouble." You might expect someone who's doing raytracing around compact objects to not be so silly as to do something like that, but I think you'd be mistaken: I know I treat the few publicly available codes in my field (e.g., camb) with great disrespect, bitch all the time, and generally am part of the large community that makes it far more trouble than it's worth for the poor people who worked so hard on it.
Protect your liberties. Donate to the ACLU
i run any code through a few versions of indent to make it look like i'm organized
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.
As a former programmer working as a network administrator now for a medium size financial company, I can confirm that embarrassment is one of the major reasons why programmers do not let me see their code when it works badly on the network. It is a lot easier to say that the network is bad. Thank god we have ethereal/wireshark.
1. What others don't know, won't hurt you. Any improperties in the code, any patents violated, any sarcastic remarks in the source - if you don't release source, they won't see it.
2. If you can't see it, you can't take it. Most companies would like to get paid, and the honor system is short on honor. One thing is corporate software - but are you really going to go into people's houses and see if they have a pirated version of Photoshop? Not going to happen, so they design up all sort of serial numbers and activation and whatnot that's incompatible with showing source - you'd just comment out those bits.
Live today, because you never know what tomorrow brings
In a nutshell, I think corps think that their software is soooo competitively important, that they don't want to release it - regardless of how bad it is.
I prefer Flambe as apposed flamebait.
A lot of software contains proprietary libraries or other pieces of software provided by 3rd parties, which they are not allowed to distribute. It can be a huge job to strip or re-write those libraries, like what Sun had to do with Solaris, and if it's old software, it just isn't worth their time.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
850*77.1
Some of the proprietary code that I've seen is like a beater car:
-Held together with duct tape and bondo
-Only works by the hand of God
-Looking at it is an example of several works in progress from several different people
Yes. Companies that do that have a right to be embarrassed.
Then again, I've seen the other side of the spectrum where the proprietary code is "SOOPER" efficient and works better than any out of the box solution. Isn't that why you do things in-house to begin with?
The game.
You know, not all code looks or works so pretty on open source proejcts either cuz there's always people that write bad code. But guess what happens then...someone says "well that's crap" and fixes it. You can't fix a ton of code when you're just sitting on it.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
God. My question is who would want to attribute their name to juvenile mis-spellings of common words like that. Really, there's no secret why commercial operators would keep their code secret, no need for speculation. It's a business! If you can do it, and your competitor can't, then you make money and win.
Three Squirrels
It's obvious why code is closed source; it's a security matter. You seem to be forgetting ignorance is strength.
(No, really, it was all sarcasm.)
In order to get a copyright, you should provide compilable source code in a standard language. Not only would that allow the end user to actually do something with it if there is a severe bug or if the program is not supported any more, but it would be a lot easier to check for copyright infringement.
Then there's the Not Invented Here effect. Need B-trees? Don't buy a third party implementation, 'cause that costs money, and don't use an open source one, 'cause it's encumbered with GPL, just write your own b-tree library. Of course, it's not as pretty and bug free as the other implimentations, but it's OURS; and yeah, it would be embarassing to let other people see how crufty it is. I think this is one of the secrets of Java's popularity, most everything is built in already.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Most companies who protect their code don't need to worry too much about it. It would take their competitors as much time to steal their code as it would to write new code. Analyzing a "foreign" project and then integrating it into another usually takes a lot of time. And then, the result would probably not be as good as new code. There might be some "ahh... so that's how they do that!" moments, but probably not worth the effort of stealing and analyzing the software. The main reason I would protect code would be to prevent lawsuits. Someone could analyze the code, find flaws, stage losses, and sue. Even this is pretty unlikely in a medium-to-small sized company.
Proprietary vendors don't have exclusivity on bad code, plenty of open source projects feature terrible code too. That said, anyone who ever worked on a crufty proprietary codebase knows there's a grain of truth here. Programmers know their kludges will remain unseen if it's in a proprietary app and product managers may be pushing for a feature ASAP when the elegant way would be to re-engineer part of the codebase. Finally, many coders in commercial shops (esp outsourced shops) are actually clueless and where contributors to open source projects are likely to have an active interest in the project, code monkeys are more likely to care only about their paycheck.
It's by no means a black and white situation. Browsing repos for a few PHP projects ought to destroy any illusion that all open source projects are well written.
Some of the most used applications in the open source movement have some of the worst written code ever. It's hack on hack on hack. People writting wrappers for no other reasons then to hide what they don't understand or to create an interface they would want to work with which all leads to very inefficient code. Sometimes it's just best to start from scratch, use what you've learned from the previous experience and don't make the same mistake twice.
Oh and document your design decisions, don't just assume that design patterns are enough.
In one company I worked with we were having real performance issues with a billing application. We staged a meeting with the software supplier to try and resolve things. One of the main problems we had tuning the database was the use of obfuscated pl/sql code in the Oracle database. I could see what was executing, but couldn't even add hints to help things along.
I asked them if we could get access to the code to help in tuning efforts.
"That's our Crown Jewels. We can't just let anyone see that" came the reply.
"Well, your Crown Jewels appear to be made of brass" quipped one of our project managers.
It's always been my experience that software companies prefer to hide what's behind the scenes. Having worked in some, I understand why.
Where there's muck there's brass. And vice versa.
Well, we invested a lot of money and resources to get the product written so that we could make money from it.
If we publish it and another companies takes it and uses it to make a competing product we will make less money.
Do we need another reason?
(see what happens in google, etc). These people think they have a team of very good programmers but it's a bunch of tired old-timers.
Google old timers are very rich.
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 or good, why should companies take the effort of releasing something as OSS? If they just chuck the code out as is without docs that outsiders can understand or use, they'll get flamed. There are extra costs involved. So what's the benefit? You get praise? When there's lot more money to be made from that, than from the code, then sure the code gets released.
4) Whether you have a good hand or a bad hand in poker, you don't let other people see it unless you're letting them "see" what you want them to see for strategic reasons.
5) Most of the smart OSS people don't actually want to see the bad code. They just want the specs and APIs, but producing full specs isn't always easy or cheap. Sure having better specs may benefit the company in the long term, but most companies think short term, plus they might change the specs + APIs later for other reasons (some even valid), and then they'll get flamed for that.
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.
:)
.NET they might as well be:) It tends also to create a support nightmare (giving rope to your typical user base is generally not a good idea) and muddy upgrades. Instead of source code software needs good and well factored APIs to enable users to extend functionality while at the same time isolating fault and responsibility.
With linux thats impossible because distributions don't care about backwards compatibility they think that recompiling is the answer to everything so you end up supporting everyones version of linux only by coding to the lowest common denominator and telling people to install the damn compatibility library *OR* releasing AT LEAST A DOZEN different versions of your software targeting subtly different versioned runtime libraries and expect anyone to be smart enough to pick the right one. This is the OS's fault!! Other UNIX systems such as Solaris do not suffer from this problem.
WTF is with the 30-60 second Bios boot time? It takes 5 seconds to start booting windows on my notebook, my PC is the same. Only idiots who have not turned off the POST tests get to wait 30-60 seconds.
Samsungs rootkit is my favorite
Also the last I checked the major Diebold issues were related to hardware and *design* shortcommings rather than code quality?
I suspect the real reason companies don't release their source code is quite obvious... Its because their in business to make money and giving their competition their code is not good for business. (Although with Java and
All and all if these are the only examples Carla can spit out to support her position in her FA then its not very convincing. Sometimes I look at the crap done in open projects just to make myself feel better about my own crap... everythings crap!! Show me one thing you think is well written and I will find an infinite number of reasons to call it crap. You only learn and improve if you think in these terms.
The more public/popular projects tend to be fairly well designed however not always. IMHO code quality tends to have more of a relationship to the number of people using something and the level of local complexities at their cores.
Having worked for a large stupid company, this really rings true. We were a startup with a product that did X. A big famous large stupid company bought us and said, ok, we want this HUGE thing Y that does this and does this and does this and does this- and it has to be built on X (because it was "prestigious", although it did NOTHING similar) and totally integrated with it and the Y data types have to be completely intermingled with X data types so you can transfer objects from the context of X to the context of Y seamlessly. (I have to change details to protect the guilty, but imagine that X was a raytracer, and Y was a vote counting system.)
So we basically spent a year fucking up X into a conglomerate X-Y system, and ended up doing all sorts of horrible things to get it done on time ("fooling" old code, etc.) And I found out for myself how disheartening it is to be ordered to do something hopeless that makes no sense. Meanwhile we discovered that the sales guys had been running around for months promising a system that did X and Z, and that it would be ready next month. They called a meeting. (This is one thing they were good at- scheduling meetings.) They said we need to combine X, and this "Z" we've been promising, into one product. (Z would be a missile guidance system.) X was "prestigious", Z was the hot new thing, and Y was going out of style (denoted henceforth as "y", lower case). Only two customers used y, but they were IMPORTANT ACCOUNTS.
So there's a panic where everyone is trying to convert X-Y to X-y-Z (something nobody in their right mind would want), in the absence of any specifications at all. ("You guys are smart! Tell us what we want it to do!") And it's getting nowhere and bugs are starting to appear in X and people are using old versions like with XP and Vista. So much time passes that we could have written Y from scratch and Z from scratch without fucking up X at all. (I'm simplifying things somewhat, because I ran out of letters- there were a few more after Z.)
Right in the middle of it all, they pulled everyone into a meeting with patent lawyers and demanded that each of us produce a list of all the intellectual property in the application. The top 20 most patentable things.
What do you write? "System and method to cope with your incompetence?" I shudder to think that they might have filed a patent that prevented someone from doing something worthwhile, but I doubt they found anything they did that anyone would ever want to repeat.
So... we look at five projects that have every right to contain crappy code, and therefore conclude that companies keep code closed to hide crappy code? Pick crap and you will see crap. How about some successful projects: Microsoft Windows (kernel), Adobe Photoshop, VMware?
A witty [sig] proves nothing. --Voltaire
Exhibit A is Windows itself?
I don't need to read any further.
Right. Because, of course, Windows is perfect, so the article must be wrong.
You don't need to be a zealot to realise that Windows is probably pretty close to the classic definition of the codebase that's outgrown its original purpose by an order of magnitude or more and is now getting pretty hard to maintain. Why else did it take MS 6 years to release Vista, which isn't really much more of an upgrade over XP than XP was over 2K (which took them only 1.5 years)?
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 modifications you'd try to make. And you don't usually have to go that far -- for awhile, the simplest solution to Windows was to download the Corporate edition and use the same serial as everyone else.
The copy protection bullshit is mostly illegal -- really only enforced at the corporate level, where source code availability doesn't matter, because the BSA will track you down. At the corporate level, they make sure to have licenses for everything.
All this is assuming a model of selling/licensing the software anyway, which isn't always the case.
Don't thank God, thank a doctor!
Another thing to consider is the fundamentally different mentalities the two camps (open source vs closed source) have. For closed source, all that matters is shipping a working product. So what if it breaks if you have more than 4GB of RAM or your directory naming convention must be exactly so. The open source approach on the other hand tends to be we wont call our product done till the code is perfectly optimized for all systems from a VAX to a Blue Gene. Also, one must consider that individuals and companies are at different ends of the spectrum when it comes to reasons why they have not released code. For individuals, there is personal criticism from programmers about their code. But, one has to keep in mind that not all individuals are programmers. If a recent physics PhD chooses to release the code he used to process output of his high energy particle physics simulations for his thesis, he would be heaped with scorn for spaghetti code despite the fact the code accomplished its primary purpose (get enough data to get the guy his degree) and did it in a reasonable time frame. For companies, there is simply a strong sense of possessiveness. They are loath to give away anything; including code for products they dont use or support anymore.
Legally obligatory sig : My opinions are my own... etc etc
It's also the case, though, that when a company goes in and cleans up, unifies, and replaces all that third-party croft, they come out with an improved product. Sadly, it isn't the kind of 'improvement' (i.e. eye candy and more 'features' on a bullet list) that the people who hold the purse strings in a company often acknowledge.
Microsoft says legacy (serial/parallel) ports are bad. They don't obfuscate the hardware enough.
...shouldn't forget the authors of free software don't hide their code.
We can open it up and learn from them.
As opposed to open-source, where everyone can see how shitty the code is. Gimme a break.
At my previous place of employment this reason for keeping software closed was actually named several times by different people.
May Peace Prevail On Earth
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 software doesn't use 3D features at all. Thanks to the combined magic of closed source software, and support that's reserved for paying customers, I have no way to fix it.
>north
You're an immobile computer, remember?
"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."
That's like saying because I want my privacy that I have something to hide. I think we're all a little bit past 5th grade now.
...thief, thief, thief! Torvalds! We hates it, we hates it, we hates it for ever!"
Seriously, this thread remained serious for over 30 posts. That's just not right. I had to act.
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!
Don't blame me, I didn't vote for either of them!
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.
However, it didn't work reliably and the customer (a major oil company) had failed to secure the source code, so they contacted the engineer who wrote it and asked to buy it. He pretty much refused for a long time (despite it being completely site-specific and having no resale value).
The oil company were being badly hurt by this stuff as failures were bringing their plant to its knees regularly and would have paid any price to get what they wanted - except that the guy had a special condition which he ultimately revealed as "just so long as no-one laughs or comments on the code". He wanted that condition in writing.
On the same day my project manager told me this, I accidently found some editor back up files of the source which consisted of thousands of lines like [ I am not making this up, this is literally what it looked like, down to variable names ]:- You get the idea.
We told the company there was no point in buying the source as we would never be able to understand it or fix it.
Instead we got the hardware documentation, implemented tested and deployed a direct interface of our own (using the hardware manufacturers protocol and not the antsy hodge podge "middleware" invented by the engineer) in under 2 months.
Mean-time-between-failure went from 4 hours to 4 weeks and mean-time-to-repair (aka "down time") went from 30 minutes to 5 minutes. Not great, but for a lot less than what the source code was going to cost.
We even got paid a bonus, flowers for our wives and an expensive lunch. Good times.
The proposition here is "upper management knows the code is a mess and is embarrassed by it, so they insist on keeping the code closed."
Who here thinks upper management knows what code looks like, at all? Not bad code, not good code, but code, period. Does anyone really believe that the executives who make policy decisions about whether to release code are in any way qualified to comment on code aesthetics?
Hell, I think most programmers are unqualified to comment on code aesthetics. For a lot of people, programming is just the daily grind. People who actually put their heart and soul into crafting a piece of mathematical art are very rare. So if management can't recognize good code and an awful lot of the IT department is apathetic to good code, how is it possible that the decisionmakers know enough to be embarrassed by the code?
And if we can realize this in just ten seconds of thinking, why didn't Schroeder think of it herself?
As near as I can tell, the reason why companies like closed source is very simple: it preserves the asymmetry of information necessary for their bottom line. A free market depends on both parties knowing the product being bought and sold. When you buy a new car, you can read Consumer Reports, you can read Car and Driver, you can read any of a dozen specialist automotive rags that will tell you in excruciating detail what a certain car's dual overhead cam configuration means in context of their competitor's choice for a single overhead cam. The buyer has complete access to information, and that puts the buyer in a position of strength.
Asymmetric information, where the seller knows far more than the buyer, puts the buyer in a position of weakness. If the product is a black box, then you can't really get an informed independent critique; you have to instead rely on the claims of the people selling the product. Which is great, as long as you're the seller.
Back at Aspen Technology, I was working with the IRMA card. They provided source code (In C)for their file transfer code for $100. I tried their code and found really dumbass bugs, such as:
int wait_x(int milsec)
But, when they didn't want it to wait, they would would call wait_x().
When I wrote a list of bugs, it was 3 pages, single spaced.
When at Microsystems Software, there were functions named, "we_are_fucked" and comments that
said, "I know this is crap, but Dick wanted this now. I'll fix this later."
That was 3 years after that programmer left.
Fight Spammers!
The article assumes most proprietary code is bad. Proprietary working code is not bad. Proprietary working code is valuable and worth hiding from other companies who would copy and resell it.
The article is really an argument for those who want everything free and against those who believe you should be able to charge for a service or product. That is, non-capitalism versus capitalism.
I write lots of Perl code, and most of it looks as good as I can possibly make it, because that's the only sane way to make something maintainable. Ditto with adding comments for every sub/method, and making sure your error checking and logging are tight.
It makes no difference to me whether the code will be released publicly or not.
I understand the sentiment, but I think it's an attitude which hurts scientific progress. The data and your software for analyzing it should be part and parcel of the papers you write IMO.
There is very little 'intellectual property' contained in programs these days. Programmers are just glorified typists, using algorithms devleloped by the true guardians of intellectual property, scientists and engineers. Most of the algorithms implemented in programs are slow, and poorly done. This is especially true of java, since it shields the programmers from most of the complexity.
Companies taking credit for this, are taking credit for other peoples work. The engineer develops the algorithm and proves it, the programmer simply types it in, or converts it into another language.
There is nothing ground-breaking in code, just sloppiness on the part of programmers.
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 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 stupidity. But let's face it, the code works and it delivers working, qualified products, embedded stupidities or not. My desire and effort to remove "unlearned practices" is just that - my own - and largely on my own time, as I said, because the code "works," and I'm being paid to deliver something that works, not something that is elegant and pretty.
That said, the code is being used in its second production technology. The new version is much "prettier" and more elegant. Is it clean? No, though it's much better, there isn't enough time to really clean it. Have I backported the cleanups to the last technology? No. The old version is "qualified", and the effort would be only for my own vanity. Current plans are to port the code to a third technology. It'll be cleaner, and maybe at some point I wouldn't be embarrassed for it to be seen.
But remember... at the moment, delivering clean code is MY goal, delivering working code is my employer's. There is some congruence between the two, but not necessarily a lot. Sometimes we do ugly things to meet schedules.
The living have better things to do than to continue hating the dead.
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.
No, this isn't the reason things are kept proprietary. Stop and think for half a second:
If something is going to be designed and released Open Source, this is decided up front. It has legal implications, especially when you might be interfacing with external third-party libraries and making platform decisions. Then code is written.
Things are exactly the opposite: closed source leads to poor code. No one's going to see it. The product has to get out of the door fast. You hire crappy budget programmers. You don't enforce disciplines of good design and code. Marketing runs the show. There is no ability for the community to see, contribute, and fix. All of these things about the closed source process make crappy code easy. I've seen them all.
But of all of these, no, crappy code is not the reason people don't release their source. I've seen plenty of craptastic code released by companies, that of all things is hardly going to stop them. Especially when improving the code is one of the benefits of releasing it.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
McDonalds "secret sauce" amount to mixing ketchup with mayonaise.
So, Yes. Part of the reason for these kinds of secrets is that they are "bad" in a sense.
At the very least, it would be embarrassing to the companies in question to have stuff like this spelled out.
The problem with this thesis is that in order to be embarrassed you have to 1) know that you did something wrong,
and 2) care. The only people who might know that the code wasn't beautiful are the developers, and who listens to them? To the rest of the company, it doesn't matter if clicking on a button causes some message passing to happen in some elegant MVC architecture, or if it yanks a string tied to the tail of a gerbil on a wheel. As long as the pretty lights happen, then the product is flawless. I think what they're protecting is their customer's perception of the value of their IP. If they open sourced their code, the marketing department would have a much harder time selling their product because they couldn't fall back on the "our product has bigger juju" argument. Who would want to pay for a product that has no visible difference from a lower priced or free product unless the higher cost product had extra magic? Actually creating IP that's worth protecting is really hard, it's much easier to just claim that you have, and hide the truth in closed source.
Google old timers aren't very old though.
Have gnu, will travel.
This article is based on the assumption that all closed source software is poorly coded and that open sourcing a software project will ultimately result in clean code.
For large projects, good software engineering practices are part of what make good software. It typically follows this path:
* Requirements taken and formalized
* Architecture designed from requirements
* Software constructed (coded) from architecture and design
* Extensive testing done through each stage to ensure correctness
Bad software does not discriminate against open source and closed source.
I guess that, having no shame, Commander Taco was immune from the influence of embarrassment.
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.
Anyone who's worked for a large company (even companies with "good" software engineering practices) knows how awful the internal systems are compared to the stuff released to the public. There's not a single company in the world that has an internal engineering department that doesn't have a ton of shitty code. The scary thing, though, is the denial of the bulk of the employees. I'm pretty sure that this is because the people who wrote the original shitty code are now VPs and directors, and nobody wants to say bad things about their boss' code.
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.
That was the first rootkit I ever wrote after college... * sniff *...
Heeeeemmm... Perhaps in the code there is a comment by a former employee about bad financial practices ? And as nobody in the legal or the director department know how to code, they didn't remove it, incase the programmes don't work anymore.
(Sorry my bad French) Je fais parler les Guignols de l'Info. Le pied, quoi.
it's still there, they just renamed it "Perl Contest" ;)
Tsunami -- You can't bring a good wave down!
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 problem could solve it again if they had too, probably much faster and with a better solution since they'll learn from their mistakes. However, as anyone who's ever joined an established and moderately large project can tell you, just having the source code without the people who are experts in how and why it does what it does has very limited value, and almost none at all unless the documentation is unusually good. I suspect that most companies could open up most of their code bases with very little real damage, if there was any worthwhile business reason for them to do so.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
My ghod, talk about not seeing the forest for the trees :(
:(
Sure, internal code can be embarassing. Whee, is that a revelation to anyone that works in or with software engineering?
But that is NOT the reason AT ALL.
Why doesn't Adobe open source Photoshop?
Because then no one would buy it! You just DL a free compiled version from the net, or if you are a little elss savvy, from one of the 50 value added clones now all selling by people other than Adobe for $65 to the same peolpe that buy it now for $650.
DUH!
Companies don't just give away code they have been working on for years and has earned them and is still earning them millions of dollars. Virtually all of the large projects that have gone closed to open have done so because the original company went out of buisness or was bought by someone else and the bigger company didn't care about the source (re AMD/ATI for a recent (partial) example) Or the code really was now outdated and had no real profit potential anymore.
Embarassing or not, if code is earning a company money, it's extremely unlikely they are just going to give it away.
"Because it's embarassing" yeah, THAT'S the reason
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
Stafford Masie at CITI last year...
...Y'know, we're a Linux company, we do identity management, but we're a Linux company. Identity management, there's so much happening there to open source alot of the APIs, which we've already done, the only thing we haven't open-sourced in the identity world is kinda our directory, and I can tell you what, we probably won't, because again - the same reason alot of proprietary vendors wont take their big software and unwrap it, like I've always said- if you unwrap this baby its ugly, people will run away, ok, there's certain proprietary software that you never want anyone to look at...
--10scjed IANAL,AFAIK
There are a many different ways to measure software.
As programmers, we get very caught up in the concept of "code quality". We truly understand that there is good code and bad code. Shoot, there are websites ( http://worsethanfailure.com/ for example ) devoted to exposing bad code.
However, from the non-programmer's point of view, the value in software is that it solves a problem. If you give something that solves a problem away you are giving away value. Publishing a solution to a problem can often make it easier for someone else to solve the problem. Either of these reduces the value of your solution and therefore directly diminishes the financial value of your venture. Investors don't like this sort of thing.
These are the blatantly obvious reasons that people choose not to release source code.
There are only 6,863,795,529 types of people in the world.
And, in many cases, not even allowed to use. I've seen blatant theft more times than I care to count, mostly of open source code.
I'm sure a major reason why companies won't let outsiders look at the source is because of legal implications, and the risk of lawsuits. The average CTO has no idea what's in the source -- whether it's gems they can sell in the future, or crap that makes them look ridiculous, or it plainly belongs to someone else. So just to be on the safe side, it better be kept under lids, like Schroedinger's cat.
If I release my source that removes a massive barrier to entry for new competitors who would otherwise have to spend a lot of time and money developing the equivalent of our in-house systems. Why would I want to encourage new competitors? If we can say we're the only one in our space offering a particular service or feature why would I throw that competitive advantage away? I do understand there's usually a lot more to each offering than just the software - but it can be a major factor.
I believe our code base is way ahead of all our competitors - that is a competitive advantage and there's no way I'm going to give it away.
This logic clearly doesn't apply in many of the situations already discussed in this thread. But I haven't seen any mention of this particular dynamic which applies quite commonly.
In theory, there's no difference between theory and practice; in practice there is.
I work for a company that produces traffic managers for ISPs and the like. These allow our clients to block or restrict P2P traffic, streaming media etc. The company is the only company in Europe that can detect Skype. I don't consider that to be embarassing, actually I think it's something to be proud of (from a purely technical PoV, that is). Even more important, it's a competitive advantage for us, and it would be very unwise to give that away by publishing our method to detect Skype.
Nobody said that Windows is perfect but the biggest reason why Windows is hard to maintain is the compatibility with all these applications, and it's also a big part of why Windows is successful.
And yes, Windows is still successful: Vista's issues are only growing pain, I remember similar comments on XP: XP is a beast, W2000 is much better, it's using too much resources compared to W98, etc.
I'm not suprised that the obviousness of this escapes many of the OSS crowd, who tend to not have any grasp of what a business needs or how a commercial entity "thinks"
If you mod me down, I will become more powerful than you can imagine....
... I can see some of his complaints. His main gripe is that there is seriously bad software out there that is trying to keep people from seeing how bad it is with a variety of defenses like "copyright," "trade secret," and whatnot.
However, I would suggest that "badness" (horrible grammar, but the idea comes through) is in the eye of the beholder. I worked for one company that had licensed its source code to a customer, with the idea that they could make changes to "fix bugs." The customer proceeded to take the entire source code and write their own program, claiming that a "bug" is where a system doesn't do what the user wants it to do ("Minesweeper won't let me open Word documents! That's yet another bug in the program!") and convinced a judge that our software was so "bad" that they were justified in using our code to develop their system and to write utilities that let them migrate the data from our system to their new one.
Yes, the examples listed in the article were pretty egregious (and the Diebold debacle has convinced me to use absentee ballots instead of the machines our county has picked up), and the article is an opinion piece rather than a legal decision, but the point remains that "trade secret" protection shouldn't be thrown out because some use it to prevent embarrassment, because of the many worthy companies that it does help.
Strike while the irony is hot! -- The Freethinker
There may be more reasons, but those are the ones that I think are plausible.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
if your competition is able to prove the capability of their software to evolve to meet changing business requirements, the competition will get the business, not you.
(M$ Vista versus Linux on the server and OS X on the client, anyone? That's the real reason Vista sucks and Linux and OS X rock. And M$s customers are starting to be aware. [Microsoft, the Erie-Bucyrus of the software world.])
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Usually the people making the decision aren't even aware that there is such a thing as "good" and "bad" code. They'll assume that it works so it must be okay.
They most likely refuse to release because they don't have to. The default state is to not release. Unless you give a good reason to release they'll go with the default
... ATTACK!!!
You know, there is a difference between trolling and pointing out the flaws in your reasoning. Just saying.
if the people who are making decisions would be embarased by code quality issues.
I think the answer is more straightforward. It is easier to (a) value and (b) liquidate the value of your know-how if it is in the form of patents, copyrights, and secrets.
Suppose you want to sell a business that comes down to having better people than the competition. The buyers have to negotiate with those people, figure out how to manage them, and worry about them quitting or even defecting to the competition. On the other hand, if you are selling "IP", the buyers can quantify what they are buying more easily.
It comes down to whether you treat the software as a commodity or the people as a commodity. Wisdom says not to treat the people as a commodity, but sadly people are much harder to control than software.
There are exceptions to this rule, but generally IP in the form of trademarks and brands plays a big part in the valuation of open source businesses.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
The management who decides to keep code closed has no idea if the code is great, lousy, or mediocre. They simply think that for whatever reason they will profit more by keeping it closed.
The same thing can be said for much classified software and harware for that matter. Once it is classified, it becomes far easier for a company to keep it's intellectutal property secret (from competitors). This is an open and rife abuse of industrial security that is not ever going to go away.
I am very small, utmostly microscopic.
I agree that this is 'a' reason. But one out of many. Others include:
Protection of competitive advantages within the software.
Protection of competitive advantages of processes illustrated through the software.
Security (this is the biggest one in my opinion).
Costs - Support and compatibility costs
I make my living writing code, and it's a matter of pride that it be elegant. Helps future sales if you can show beautiful, well commented code to the software engineers in the prospective new customer's outfit. No one much will ever see it, that's not the point. Maintainers do like the clean code and they tell us so!
But: I do mainly embedded programming. A rather famous microchip maker's CPUs has the usual sorta broken dev system (which is mainly free, and I wish open sourced so I could fix it). Here's why it's not open.
Some of the debug code they put into the target is real well hidden, and their memory dump tools refuse to dump that part of memory to keep it so. We asked them about this, as we have an NDA with them already. Absolutely no go, and the guy sounded freaked we'd noticed. Well, there's no stopping someone who knows all the basics, doh, so we reverse engineered and recovered that code -- we had the tools as this app needed incircuit updating anyway, so we did our own burner/reader.
Patent violations galore!
In this crazy world of IP and patenting everything in sight, it's darn hard to avoid stepping on someone's patent on something stupid/obvious like "inserting a call to debug code where the breakpoint was set" or "comparing PC with a hardware register". Both of those patents currently exist!
And in M$ case, it's probably not only embarrasment, but much stealing from GPL open source (ugly or not) and similar issues.
Having devstudio, I once trolled through the source code for printf. Thoroughly obfuscated for some oddball reason, and split across multiple files, gheesh. MFC is moderately clean inside though, so it shows they CAN do alright. Most bad MFC based code is done because someone didn't realize a style bit could be set and solve their problem, or that they were trying to handle something in the wrong place. Paul DiLascia and I have had some good belly laughs on this one, and we've both been caught writing elaborate and completely unnecessary workarounds.
Most of M$ bugs are due to features that were inserted without thinking about interactions with say, security. Now they can't fix them (like remove activeX) without breaking everybodies apps including their own. COM/activeX are a main reason they don't like ODF as well -- It doesn't easily support running unsafe binary code along with your document...
I feel for them. When they break backwards compatibility as they must to actually fix Windows, well, what exactly will be the advantage over linux at that point? None.
I don't care if Adobe open sources Photoshop, as I use the Gimp. The adobe pdf reader is the only thing on this ubuntu system that crashes. I know for a fact that part of the lousy UI in the free reader is to get you to buy the paid for one, as I know one of the programmers there.
Don't run away scared that someone might sue you for code you released. BSD GPL and many other OSS licenses state "AS IS" for the code. No guarantee.
And someone will, if they think they can bully you, WILL try to sue you but remember they don't have any standing to sue. Ask them for the contract between you two.
Arseholes exist. If you live your life according to what they might do, they've already won.
That's nothing, I wrote my own language, three times. If only I was joking...
Now that you have all these libraries have you considered releasing them under an open source license? I know there is no direct incentive to do so, it is extra work to give away lots of original work for free, but what benefits society benefits you.
You might even get lucky and have some bugs reported, sometimes even fixed. If you are proud of your product then the best bug is the one that is fixed before your clients ever see it.
I spent some time working as a programming consultant for Accenture. I saw some pretty awful stuff, including a 1,200 line gem that simply flipped a table from the db so the rows became columns when displayed. Yeah, I'd want to keep that hidden too...
Another reason that companies don't release their code, is that they might realize that they don't own it all, or can't prove that they own all their source. Some programmer, long gone, might have copied substantial portions from a book or previous employer. By keeping it secrect, they limit their exposure to lawsuits.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
I think your explanation is the best and simplest I've read in years as to why FOSS doesn't work for non-commoditized software markets. You're not selling an algorithm, a specially patented method, a trade secret or anything like that. Instead you're selling the sum total of your experience in the field as expressed in a software package. I understand where you're coming from entirely.
However, the same argument could be asserted against all of FOSS for exactly the same reasons. Why should an efficient and well written network stack be free? That also represents years of experience. The same could be said for word processors, web browsers, web servers, ray tracers, 3D engines, etc.
I think the key difference is in the business model and the evolution of the information-driven economy. As certain practices become common knowledge and relatively easy to implement, someone out there is going to scratch the itch and produce an open source version of that functionality; especially if they don't have a model or interest around leveraging that implementation for profit.
Specialized interests and non-commoditized areas require too much effort to support with too little help from the public at large to be good candidates for FOSS implementations over the long haul. So, they stay proprietary because someone needs to get paid to keep it alive.
Which brings me to my main point, and I think this is something I've always understood, but this line of thinking finally puts a finer point on it for me: FOSS is not about undermining the free market for software. The market forces after all are what has ultimately led to FOSS. At some point, it becomes my best interest to be open with commoditized implementations; why should I bear that burden alone when everyone needs it and could help with the package too?
So, FOSS is for the commoditized software market. Proprietary is for the software markets of competitive advantage.
Based on that reasoning then, I would have to say that using FOSS is never a competitive advantage for an enterprise, but not using FOSS can be a competitive disadvantage for an enterprise because I may in fact be bearing costs that my competitors do not because they have leveraged FOSS; where I may have opted for a more expensive option.
And vice-versa, if I wish to produce specialized software that is about producing a competitive advantage to companies that they can not already obtain with FOSS (in which case, that would be the new market baseline in order to say efficient and would not actually represent a competitive advantage because its presence as FOSS package proves that is is in fact commoditized already), then it stands to reason that I would have to develop a proprietary product.
Open sourcing a package that represents true competitive advantage would only ensure that I would bear the full cost of developing an expensive package (and developing anything that represents real competitive advantages is necessarily hard by definition), while potentially deriving no benefit from having done so, because as a FOSS effort I have no effective way to force my users to pay me for that effort. Because such an implementation is inherently difficult, my customers probably would not be able to "repay" me by helping with continuing development and maintenance.
And that finally clarifies for me everything that's been happening in the industry over the last 10 years or so. FOSS is a great thing, and I think everyone should support it. However it can not and will not ever be the cause of any particular software company's fall from power because unless those company's stop developing products with competitive advantages built in to them, FOSS can not consistently actually advance the state of the art beyond the commoditized baseline over the long haul.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!