Why don't these companies open-source their old products?
The engineers are all busy working on new things. What product manager is going to say, hey, Fred, take off two weeks and take this random product from 1997 and see if it still builds at all, find the old dependencies, clean it up, talk to legal to see if we still own the rights to (x, y, z), and throw it up on GitHub -- just to expose some of our shoddy programming, last-minute hacks, vulgar comments cursing out other programmers, and maybe even some proprietary company information that we had no idea was in that code base.
There's no upside, but possibly plenty of unknown downside.
id Software games: John Carmack wants to get old code out there, partly so students/others have some real-world examples to peruse and hack on rather than only toy games from textbooks, and partly because he's proud of a lot of his clever hacks and eventually wants them to see the light of day.
Axiom (computer algebra system): Someone starts a proprietary software company based on academic research, and it fails. One of the original researchers has a personal interest in getting the code released, so the project can continue.
Blender: Company goes bankrupt, and the original programmers want it to be open-sourced so their work doesn't disappear. Raise $100k to buy it from the creditors in bankruptcy.
Back when the idea of a corporation was first formed (I do not remember the time frame) one of the requirements to complete the process of incorporation was to prove what you were going to do for the community around you.
I wonder how this idea got lost in the process...
I guess we'll see what they've done with it when the first computer program copyrights expire in around 50 years (assuming Disney doesn't buy anymore extensions).
Very few companies would be willing to just throw the code as is to the world. Usually they're going to want to go over that old code line by line to make sure it's fit for public consumption and doesn't contain intellectual property that they don't have a right to open source. All of that stuff costs money and engineering time and probably legal time as well.
They would also have to have some reason for doing it in the first place, something more than that it could be hypothetically interesting to hypothetical people. That's a leap of faith that few companies are willing to make, and the larger the company, the more people have to make that leap and sign on to it.
Having said that, I also wish that more companies would open source their old code (for academic reasons if nothing else). I just think the reason it doesn't happen more often is for really practical and predictable reasons, and not because those companies are totally oblivious to the idea or because they're evil or anything.
It could be a huge PR boost. EA games got some good mileage out of releasing their older titles like Tiberian Sun as freeware. Imagine if they unleashed them as open source, and thus made them into a learning tool (like a textbook) for future generations.
1. They might not have the source any more. There's a depressingly large amount of software that was created, that no-one has the source code to. It might have been lost in a server crash, it might have been stored on a medium which is now unreadable, or people might have just not cared about it after the product was shipped and who knows where it is now?
2. There might be legal reasons preventing them from releasing it. For example, be a software patent covering part of the code which they licensed for their commercial use, but which prevents them from releasing it as open-source. An example here would be Doom 3's shadow volume code - the open-source release didn't actually include the code that shipped with the game, instead it included a slower (yet not patent-encumbered) algorithm. Unless you built absolutely everything in-house and licensed nothing from anyone else, it can be tricky to work out whether you're actually allowed to release the source to your product.
3. It might reveal other things that should be private to the company. Often source code has overly-tight integration with things like your in-house version control, or your build system, or other things of that nature. Perhaps your debug build automatically uploads crash logs to your bug tracker, and includes credentials for doing that which were stripped out of the release build? In order to do an open-source release, you need to look through your entire code to figure out if there is anything sensitive there, and remove it (in a way that doesn't stop the product working).
And finally...
4. What benefit does it get them? Gathering up, scrubbing, testing, and releasing an open-source product takes a substantial amount of effort, and hence a substantial amount of money. And you'd be hard-pressed to see a return on that investment in anything except vague, largely-meaningless "community good will".
Maybe they thought it was being backed up but the backup script started failing silently 2 years ago.
Never mind that it was no longer possible to buy the tools that were used to build the products...
Backup #1 (USB HD, kept by development company A) was lost in a flood. Of course, this sort of thing is why you have 2+ backups...
Backup #2 (USB HD, kept by development company B, the one I worked for) was lent to the client after they wanted to take a copy of it themselves. Then fast forward 6 months, and:
US: Please would you return our backup drive of product XYZ?
THEM: [paraphrased] Who are you?
We lost all the history, but (after they escorted the guy from the building) we were able to restart with source trees pulled off dev workstations.
No surprise that I got an email from one of the VPs of the nearly-defunct company a few years later asking if I might know the master password to the source control database. So yeah, they had a backup, but it was useless because of course it had been encrypted to prevent theft but nobody thought of recording the password somewhere secure.
The other reason we did it -- the reason that convinced the CEO and board -- was that we figured as we developed better products (VP4, VP6 etc) it would be preferable for us business-wise if the N-1 product was free to everyone. Otherwise, inferior competitors would continue to profit by undercutting us on price. It's impossible to undercut free.
I guess I answered the opposite question -- why do companies EVER open source their old products? The culture of VC-backed and public companies is not especially conducive to making the decision to do so, even with old products.
One argument you will hear against doing so is simple: old, free products might compete with new, profitable ones. There is no real business incentive to take that risk.
How long have you been in development, specifically corporate development?
Imagine code with no modern tools or development process and a limited number of people that might understand how and why it was written. Code written under pressure or by overly clever geniuses. Code not under source control with no or little documentation. Code written for companies that don't exist or have changed hands numerous times. Archived to media that no one has computers or drives or OSes for...
* Documentation Time
If you've got a big project, it could take weeks, even months to properly document some software to a position where it could be used by someone outside of the company. Sure you have your internal documentation but it can often be incomplete, or make assumptions that the person reading it knows about other bits of the company.
* Deployment
Big projects will often use very specialized hardware, software and environments, to the point where it could be nearly impossible to deploy outside of the company. It could depend on internal services that can't be open sourced because there still used, or are an important part of the business. Take Google Reader, yes it would be nice if it was open sourced, but internally it probably uses services, databases, APIs specialized just for Google, it's probably been optimized to work on Google's hardware, with their webserver, with their OS build etc.
Reddit is another example of this, Reddit's code is open source, and while it can be deployed, it's not easy. This seems mostly because it's been built to work on a very specialized set of software versions, and in a very specific environment. Larger open source projects tend to be tested on a multitude of environments, with applications only deployed or built internally, there's no point because you can very accurately control your environment.
* Some of the code is still used
Some, or even big chunks of the code could still be being used in current software. If you've got a library that's particularly useful, you might keep using it. If it works there's no point re-writing it just for a new project.
* The code is very bad
We all know it happens, a project contains terrible code, bad bugs and maybe even security issues, they never bothered getting fixed because they were never noticed. Given the opportunity to look through the code people might pick up on these issues and it would look bad on the company.
* Open source is complicated
Open source seems to come along with a whole host of fun things to deal with, GitHub issues, ranty blog posts, forks, copyright, licenses can all get a bit complicated. Even if it's old software that isn't used anymore you probably need to do some degree of management before things get too out of hand. Even a single tweet can have a big impact on a company, or a products reputation, so particularly at larger companies they'd probably want it managed in some way.
Anyone else got anything to add?
People often underestimate the amount of effort that open sourcing (in a responsible manner) a large project requires.
Dependencies on specialized build tools; porting to something free would not be easy.
Exposure of security holes in existing deployments by revealing bad security practices.
A good example was when Netscape open sourced Navigator v4. People couldn't get it to build and it was missing some proprietary components. So even though the open source world was desperate for a web engine, nothing was really done with it. In the end it was decided to start over from scratch with Mozilla.
You can't really opensource a project if it includes, say, a movie playback component or 3d engine or audio code with royalty-based licencing; the code won't even compile with it, and it may be customized/integrated to an extent where it would be a lot of work to even identify which of your source code files are "contaminated" by licenced stuff that isn't yours to publish.
For non-games it can also be about licensing (or as others have mentioned providing evidence that you used code in an unlicensed way) or about support (nobody wants to answer questions about the code).
-proprietary technology (ie Google Reader hooks into Google backend extensively)
- Cost of getting it ready for open source (usually a large sunk cost already)
- They may still make money out of it in the future (ie selling old games with emulation)
The google feedback tool springs to mind, the google engineer that made it is working towards open sourcing it but because it want created with that in mind it is taking ages to remove its dependency on loads of internal Google stuff.
Reader probably uses the Googlebot crawl infrastructure to retrieve feeds. We're not going to open-source the crawler, so now we need to rip that out and replace it.
Let's say Reader used Megastore to store feed data (the Megastore paper says "hundreds of applications" use it, so this is not an unreasonable idea). Megastore is a nice chunk of intellectual property in and of itself, plus it's built on top of Bigtable.
Throw in Chubby for locking/coordination and some MapReduce jobs for bulk processing, and you're basically down to either rewriting the entire core of Reader or open-sourcing the "crown jewels" of Google's infrastructure. Not to mention any number of underlying libraries (e.g. core C++ libraries) that have hundreds of engineer-hours of investment.
The big idea about open source is that if you're making something useful for many other people and if it is sane, readable, manageable, then you will get lots of feedback, testing and even patches with bug fixes and improvements.
This is the story of nginx - when it was open sourced, people found it useful for themselves, and then they start using it, which leads to the extensive testing, fixes, patches, etc. Now it has several forks, including tengine.
The other story is the story of RedHat at times of RHEL4. They decided that they will maintain their own set of patches for kernel and glibc. Eventually kernel's src.rpm contained a hundred of patches. This was a mistake, because they should send those patches into main tree instead, and, if patches proven to be correct and useful, they would get feedback and testing and code reviews for free. As far as I remember, they did so with RHEL5.
There are another important stories about how community ceased to improve open source projects after they being acquired by big companies - no one wants to improve other people's property. MySQL and Xen were the most well-known examples.
So, there is no use to open source anything which no one need, except, may be some hobbyists and marginals.
It is the same reason that many pharmas don't release the data of their failed trials. How much better the world would have been had we had a commons of the failed drug trials. sigh
The more interesting question is in the cases of businesses that fail. Though I can't imagine this happening, it would be wonderful if the law specified that if a bankrupt company is liquidating its assets and cannot find a buyer for its source code, that it be open sourced.
I suppose the conclusions from that can be quite open:
a) It doesn't happen often enough to know how effective it would be
b) The product has to be useful enough to attract a community to maintain it, which might be a rare condition
There's a shockingly large number of projects out there that use "borrowed" code. This is in the sense that they may use code from open source projects (and didn't distribute the code back as stipulated in the license), code that they've inherited from other companies that may or may not have been part of a legal acquirement or through the much heard "Corporate Espionage", which sounds sexier than it really is.
Usually, it's just an intern or someone else who finds out the default password to source control and/or CVS server and sends out a few feelers to someone interested. Next thing you know, he plugs in a thumb drive and now he's a free agent with a plane ticket and fancier watch.
Early games especially were like this since being first often meant being successful at courting investors (this was before the video game crash of '83).
Source: I once did a freelance job ages ago where the dev team manager, who used to work at a gaming company, freely admitted that it happened quite a lot in the industry. Maybe it's still happening.
Then there are cases where the source is outright appalling in the number of hacks, re-hacks, back-hacks and any number of ducktape and hope holding libraries together. No one of sound mind would ever let anyone else see that mess. Let alone give the impression that some of that code survives in some form in modern software.
Can you imagine how many vulnerabilities exist? For all we know, it may be possible to do a lot more than install Linux on a Gamecube. http://www.gc-linux.org/wiki/Main_Page
Of course there are also the times where "works of art", as it were, are lost to history. As jbri said, there are times where large projects often are destroyed for silly reasons like crashes or even recycling.
I've bought several used hard SCSI drives back in the day on eBay that may have belonged to one such company (SCSI was expensive, yo!) I have no idea what the project was or what I may have in my hands, but it looked like a whole lot of assembly, a bunch of esoteric C (which might as well be assembly) and some proprietary language code, that resembles a cross between Pascal and Python to my untrained eye, and I don't think anyone outside knew how or where to compile.
Now did they copy this stuff before selling it off? Who knows. This was after the dot com crash, so I have no idea if even the original owners were involved in the sale since many of those companies' assets were liquidated in a very short period of time. And we know how delicate they can be when money is at stake.
Then there are issues with licensing (kinda related to the first point) and already mentioned by people here. Open source, as samarudge said, is complicated. If your legalese isn't kosher, you can expect to lose a buttload of cash in a lawsuit(s) even if you win. Especially with the threat of patent trolls around, you can bet fewer companies are willing to risk OS-ing their code.
Word of mouth in appreciation of a good deed or good product is the most compelling sales pitch you'll ever hear.