If You’re Going To Kill It, Open Source It | Hacker News Reader

If You’re Going To Kill It, Open Source It

blog.makezine.com

174 pointsptorrone38 comments

One reason that "just open source it" isn't as easy as it sounds is that there tend to be a lot of IP restrictions, patenting and licensing encumbrances, NDAs, etc. that would take effort to identify much less resolve. When companies, like Sun, open sources various software, it took considerable effort to nail down all the problems and remove the parts that weren't there's to open source--which in the case of a device like a camera might well make the whole thing useless.

Besides the legal side of things, the code might be being built with an company internal tool-chain, and comercial compilers, so it would be a bunch of work to even get it ready for a public release. All of this reinventing of the wheel probably limits nice fixes for common bugs over the years.

Compiler issues shouldn't hold you back. Release it anyway. If someone is interested enough, they will more than likely be willing to work with what they can get. Let the burden of correcting the code fall on them.

While that sounds good in theory, when customers are involved, you want to make sure that you have your best foot forward. So filling up forums with complaints is never a good thing.

Which suggests that working on open-source compilers tends to support the open-source ecosystem more than working on end-user apps.

I'm guessing that failed startups don't release their code because their investors see it as an asset to be liquidated to recover some of the investment. Can anybody with failed startup experience comment on this possibility?

Technically the source code is an asset - so the company may be limited in terms of what they can do.

For example, a company that closed while owing money could not just "distribute" their remaining assets by releasing them into the open-source domain. Investors, employees, shareholders even founders may have legitimate claims to maximizing the value of that asset.

Equally, if there are multiple parts to the asset, they may not necessarily be disposed of "together". As a simplistic example a robotics company may sell off the hardware separate to software. And the software itself might be separated into different lots.

So the _creators_ of the product are not necessarily the _disposers_ of the product. And the person buying the thing (for whatever reason) is unlikely to spend money and then just give it away.

For companies that remain existing after the discontinuation of the product, the problems are even more complex. Take for example Sony's robotic technology. Just because they've discontinued the consumer products does not mean their investment in the tech is wasted. I think it's safe to assume that at some point in the future Sony would be able to either sell, or leverage that investment.

At the end of the day it's about balancing the upside and the downside. The upside to Sony, HP etc is negligible (some hacker types are happy) whereas the potential downside (loss of IP rights, effort to release, on-going impact, legal liability, trademark issues etc) are substantial. Even the effort to determine the downside is significant.

Now of course, if you've got some unheard of webapp, that attracted 5 users before you killed it, it's trivial to open-source that. On the other hand that _is_ probably happening all the time, and nobody cares.

The AIBO used a proprietary commercial operating system and required a separate set of commercial compilers to produce valid code.

When I was working on it through a special arrangement with Sony Research, I made a bunch of perl scripts that could munge the assembly generated from gcc so that the assembler could generate code that worked properly on the robots, but there were still a large number of very expensive commercial licenses between it and being OS compatible.

I unfortunately can't go into much more detail than that, because I believe I'm still covered by an NDA I signed back in ~1997 :-)

That's interesting, and your Perl scripts sound like the sort of thing I would utterly fail at were I to attempt to create them. What about the hardware of the robots though? Would all of the various interesting parts be covered by patents, etc., and thus be unsuitable for opening up? (Sorry if my questions tread on NDA territory - that's one long-lived NDA.)

Not at all! It wasn't that bad -- the object files just needed to have sections that had particular size restrictions, names, etc. Nothing too tricky.

I don't recall the hardware being too separately encumbered. Sony Research provided all of the early adopters with significant technical specifications about the hardware itself, though admittedly much of it was documented in Japanese and this is ~10 years before google translate. I remember one other independent research group rewrote all of Sony's dynamic stability code and was able to increase walking speed significantly, and there was a lot of that level of information available.

IANAL, but NDAs are only enforcable when there is some actual liability on the table. Example, I'm sure the NDA for the Coca-Cola recipe is still in effect for the lifetime since they still use the formula and it would actually do financial harm if it was to be released.

In some places NDAs are invalid if they don't have an expiration term. Since Sony no longer makes the AIBO and I'm sure whatever proprietary tech it did have is out of date please, do tell.

A couple months ago I was looking for database schema comparison and syncing tools. I found a product that looked promising so I clicked over to the product pricing page and was really confused as all of the products were listed as $0. Turned out that it was, from what I understand, essentially a one man software company that wasn't very profitable so after a period of time the owner/developer, Matt Whitfield, decided to just start giving away his products for free and open source them.

http://www.atlantis-interactive.co.uk/blog/default.aspx

The schema compare tool ended up doing exactly what I needed and Matt even provided support. What was so impressive though was that the database tool suite was becoming competitive with products from Red Gate and now they are all free and OSS.

There are three reasons why organizations and people don't open source their failed projects.

* Intellectual property issues * Pride * Pride

Don't underestimate the power of emotion, especially when it involves failure.

The last two go for communities, too. I've been a member of at least a couple great online communities where the owners lost interest but could not handle handing their baby to someone else - so they killed them instead.

They seemed utterly blind to the awesome communities that had formed, and unable to grasp how much harm shutting down caused to so many people.

There's another reason: support.

There are a lot of people who believe they're entitled to support for any code you release. Even if explicitly noted in a 72 point font that it's totally unsupported.

I'm sure its not too hard to just have everything from that email address forward to the trash if you're so inclined.

The difficulty isn't in ignoring support complaints yourself, it's in protecting your personal or corporate brand from the corrosive effects of all those complaints.

If someone googles your name and turns up a bunch of complaints in forums and blogs, that's a hard first impression to overcome no matter how you try to explain that you never promised those people anything.

There is a danger to open sourcing code that you won't be maintaining. Many employers now ask for your github account. If your coding habits change over the years, employers will look at your older, non-maintained work, and draw conclusions. Further, if you show a large number of abandoned projects, they may decide you "don't finish things."

Something similar bit me recently. I didn't have any of my TDD code samples available to send on short notice, so I sent an older project that, while it showed I could code, was not TDD, and not nearly up to my current abilities--I think it cost me the job. If that was what was in my github account, I may not even been asked for a recent sample. My recent work belongs to my employers, so that's a non-starter.

It would be amazing if Palm Inc. released the BeOS source code, after a few years without using it.

I think it could have changed the history of personal computers OS. Fortunately we still have Haiku OS, but it will take some time until get stable.

Sadly, BeOS was stuck on the "Palm Source" side, which was hoovered up by ACCESS, most likely never to be seen again. They were even jerky enough to poke and prod at Haiku over IP issues.

Just because the product was 'killed' certainly doesn't mean the technology or knowledge associated with the technology disappear. I'm sure IBM has put the software used for Deep Blue to use as a service in decision making software or other products, and that Sony has probably assimilated code from AIBO and QRIO into other products as well.

I did that late last year with one of my WebOS apps. I don't have the time to keep it updated and the rev went from ~$700 a month to ~$200 so I MIT'd it on GitHub then announced it on twitter. So far a few forks, but no one has really taken and ran with it.

I did this when Apple rejected my iPad application "DashApp" https://github.com/jjg/DashApp and I plan to do the same with any other commercial product that I produce once they can no longer contribute in a commercial way.

I can see how this is harder for big and complicated companies but I think this can be overcome through planning and cultural change. I think the net effect for both builders and consumers (and society in general) would be positive.

Perhaps it could be made part of patent/copyright law itself, therefore providing a level playing field and reducing the fear of losing competitive advantage.

The company discontinuing a software product may want people to buy another if its products instead, which they might not buy if they could get a community supported version of the killed product for free instead. E.g. Adobe ended up owning both GoLive and Dreamweaver, and killed the former. If Adobe had open sourced GoLive, that might have reduced subsequent Dreamweaver sales.

So... rather than make not enough to pay the bills, now you make nothing yet have a giant support burden.

because you release something as open source does not mean you are any way responsible for maintaining it

That won't stop people from expecting it and emailing you about it.

So create a filter that deletes and/or autoresponds to all inquiries to the project's support e-mail address.

Unfortunately "brands" don't work like that.

As Flip is owned by HP, negative Flip experiences impact on other HP divisions. People will inevitable translate "bad Flip support" to "bad HP support".

"Bad support" is when you promise some (explicitly or implicitly), but fail to provide.

It's not "bad support", it's "no support". The same state it is now already.

Nobody would complain about lack of support if you specifically state that there won't be any. After all, it's the dump of source code and blueprints, not some end-user products you see in a store.

But then they'll read all my embarrassing comments!

Ah, but we all know a bunch of those projects probably have no comments at all. Spaghetti!

Why not?

On its surface it appears as if the company can at least get some good will out of its loss. Assuming Open-Sourcing it will not affect their ability to write-off the loss, you would assume it would be a simple no-brainer.

1. Because releasing your code might expose you to lawsuits if you have used other companies IP.

2. Because you might have your own patents and IP in that product that you don't want to release.

3. Because 1 & 2 means you have to pay the money to have a lot of legal analysis.

4. Open sourcing n$ worth of work can make is more difficult to pick it up later if the situation changes.

some of my code is so bad that I would be embarrassed to release it to the world

I went through this too ... don't let this worry you ... put it out there, people don't care about the code as long as it works, and you might actually get some badass come in and clean up your code for you ... for free :)

The upside from a corporate standpoint is that this will be more technical debt that the OSS community has to deal with, which can help you compete with them.

That assumes that people would adopt a code dump that's net-negative in value. More likely, they'd salvage just the good parts.

Don't kill it, if open sourced there are hackers who will fix/improve where you failed.

Reply on news.ycombinator.com