
Ask HN: Why don't companies open-source the source code of their old products? - blubbi2
I&#x27;m not talking about products like the first iPhone, I&#x27;m talking about products (like gameboys) that are still cool and interesting, but completely irrelevant for the company that invented them.<p>Why don&#x27;t these companies open-source their old products?
======
crazygringo
It may sound trite, but the real reason is -- why _would_ they?

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.

~~~
pdog
A potentially big upside is the preservation of our culture for future
generations.

~~~
amenod
Companies mostly care about making money, not being beneficial to human race.
(not passing judgement, just observing)

~~~
fredsanford
It's funny you say this...

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

~~~
chops
Companies _are_ usually improving the community in some way (that's why they
make money in the first place). Grocers sell food to the community, hardware
stores sell tools and supplies for making things, even the dreaded oil
companies have sold the primary source of fuel for a century (and made money
hand-over-fist for it). Random acts of kindness (e.g. open sourcing projects
for no reason other than "We could"), while cool, are tangential to the
purpose and specialty of the company.

~~~
amenod
This is how it should be - sadly both ends (doing good and making money) are
not always aligned with each other. From my personal observation I would say
that they are less and less aligned the bigger the company is.

------
jbri
A number of reasons come to mind:

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

~~~
pestaa
I would be seriously shocked if #1 was a valid reason. Products for which the
source is completely lost after they are shipped? Can it happen _before_ the
release? Why there were no backups?

~~~
to3m
This has happened to a product I worked on. There were 2 companies working on
it, and when we were done there were 2 backups that I made after we'd finished
it.

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?
    

This product was a one-off, and not key to company B, so nobody chased this up
(not that they could do much anyway because the backup drive was presumed lost
forever). We only found out about the loss of backup #1 when company A asked
us for our backup, because they needed the code for a project they were
thinking of doing...

------
danbmil99
At On2, we open-sourced Theora (initally called VP3) partly because I (the CTO
at the time) worried that if the company failed, all our IP would be locked up
forever due to complex legal obligations to investors and customers.

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.

------
xradionut
To OP:

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

~~~
hobs
Imagine, all of this is standard.

------
samarudge
I don't work for a big company, so this is purely speculation, but there could
be many reasons why it's not done.

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

~~~
kabdib
Dependencies on commercial software (e.g., that package for the sound system,
purchased as source and modified, without which the product won't even
compile).

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.

------
ChuckMcM
If you're talking about games then the answer is licensing. There are a
zillion licenses around the audio stack, the video stack, perhaps the game art
or the game characters etc etc. None of that licensing allows you to release
the source code (and thus the source material) to the public.

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

------
djt
-legal problems (licensing, liability)

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

~~~
djt
Also, for individuals there is a lot of positives in that prospective
employers can see their work. From a company there may be way less incentives.

------
chiph
Software products usually have some 3rd party components in there, and they
can't release the code for them because they don't own the copyright. This is
the #1 reason why OS/2 can't be open-sourced.

------
abritishguy
Probably because projects which were not designed to be open source rely on
too many internal systems to be worth open sourcing.

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.

~~~
packetslave
Exactly this. I haven't looked at the Reader architecture myself, but take a
hypothetical "Hey, let's open-source Reader" project at Google:

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.

------
dschiptsov
Because it is not how open source movement works.

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.

------
wunna
These are all very good reasons posted below, but I believe that the most
important reason is corporate mindset . The powers that be - mostly old-hands-
view software as physical "property" and unwilling to let go. Sharing it is
seen as sacrilege! Also is seen as providing competitors a peek under the
kimono and giving them an advantage.

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_

------
frozenport
Software is written scratch, while the products like the GameBoy are made from
dozens of closed source components. Sharp owns the IP on the CPU. What could
they open source in a GameBoy?

------
mozboz
Why would they? There's plenty of downside and not much upside?

------
tokenrove
In the case of something like the Gameboy, Nintendo still profits from selling
old software for that platform, emulated on their newer consoles.

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.

------
fortmac
I hope I dont sound like a goofy idealist but... All of these issues (rightly)
point out that the major barrier to open-sourcing is cost. Doesn't this seem
like a very effective use of kickstarter? However, I can see just negotiating
with a vendor of legacy software could be a lot of work and require a good bit
of technical know-how for a volunteer on kickstarter.

------
joeblau
I agree with this. I think that even products that aren't core to a business
could be open-sourced. Twitter is a great example of open-sourcing code that
is not critical to their core business. I think it's a great way to give back
as well as helping your company get notoriety.

------
Zigurd
There is only one success story I can think of where open source revived a
faltering product: Eclipse.

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

------
eksith
There are quite a lot of reasons, but these come to mind first:

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

------
swah
Hardware too! We should have the original hardware for our childhood game
consoles running in FPGAs! One FPGA with NES, SNES, Master System, Sega
Genesis, Atari...

------
adrianlmm
Because someone else could update that old product and start competing with
the newer version.

------
mikemoka
Google Reader may come to mind..

------
X4
Why don't you start a web-service to help companies opensource products?

~~~
jakobbuis
because it doesn't solve any of the problems mentioned in this thread? The
essential parts are a stable community and 'buildability', none of which are
solved by a webservice. Unless you have a great idea for this, than let's talk
;)

~~~
X4
I think I have some ideas ;) What's your mail?

------
methodin
Embarrassment

------
amerika
They're morons not to.

Word of mouth in appreciation of a good deed or good product is the most
compelling sales pitch you'll ever hear.

