Shutting down a product? Open source it.

This particularly makes sense for SaaS offerings that are being discontinued. If your product is only available as a service then it is particularly painful when it disappears for those who depend on it. From a business standpoint, open-sourcing is a good way to maintain goodwill and shift the onus of administering the service to those who consume it without leaving them out to dry. All your consumers will have to make a decision on whether the cost of running their own service is worth it, which is a much healthier situation than a bunch of irate customers left with no recourse.

That's only an option if you're shuttering the product of your own will. If you're part of a talent acquisition (which is the case with Posterous and Milk), the purchasing company would have to make that call, so you should really address the blog post to them.

It's unlikely any of them would: they just paid a bunch of money and acquired the team plus source, and even if they don't use the acquired source, open-sourcing it is extra work and/or a liability. The team, on the other hand, may still have faint hopes that the company will do something with their product.

In the cases where it's clear that the team's energies will be focused elsewhere the team could try to include it in the terms of the acquisition, but were I in those shoes I'd probably not want to risk souring the upside or acquisition as a whole.

I completely agree in that projects/products which have come to the end of their life cycle should opt at the possibility of open sourcing. But it's not always as simple as that. Some times, the feat of open sourcing something might takes considerable time, both from refactoring, and convincing people who need to be convinced that they shouldn't let the product rot.

Also, I've not actually heard of Copycopter before, and I think it's a bit of a stretch to make the causative link between your announcement of shutting down, to also having AOL and Oink following suit. Correlation does not prove causation. (I've not actually heard of copycopter before).

Completely agree on the OS'ing aspect though. To make a point, when IndexTank got bought by LinkedIn, they Open Sourced it. I was then given the opportunity to look through the code, and it was then that I decided to migrate from IndexTank with immediate effect. Even though other parties were picking up the sources, I was able to make this decision will full disclosure. (And move to Solr).

I actually wrote this into a founders agreement. If we decide to give up on the product, the company shall release the source under a BSD license.

I realize it might not actually be that simple post-acquisition or some such, but at least at present it gives me the option of a consolation prize. I could take all the cool bits with me to use on the next project.

This is certainly much better than just letting the software die a silent, anonymous death. At work we were about to do a project localized to a language nobody at the office speaks, so we were looking forward to using CopyCopter to work with the translators. I'm very glad Thoughtbot had the decency to release the code, so that we still have the option to use it.

I do hope, however, that the developers there continue to play a role in the project. Just "dumping" a product into the open source world without continuing to contribute to it can kill a product almost as effectively as shuttering it with no source release.

I do appreciate what Copycopter has done by identifying the right business that can make it available as an open source product.

There is lot of news about SAAS businesses going under recently and this is definitely not a good trend.

One reason is they are under pressure to provide some kind of return to VCs even if it is by selling off the businesses. The merits of taking money or not is a different discussion altogether.

Why wouldn't these 'startups' try to tighten up the belt, build a profitable business by figuring out premium services and actually RUN these services profitably?

I agree that open sourcing it is one way, but is it the best way? Since the users depend on it, that would mean that they would pay for it right? I think that the obvious need here is to find a way so that it would make it possible for somebody to build a good enough service and then be able to just neglect it, the same way you can neglect desktop software.

Before there was an "app store", people would think the same way and just open source software they cannot find a way to build a business from but that has severely changed thanks to having something as convenient as the app store.

I can think of some ways that a platform like this would work, and I think that it could be built by using something like Cloudfoundry, though I have the feeling that somebody is building it already somewhere.

It could be a platform where you create an application, someone confirms that the application is good enough and does what it is intended, you push the application, and offer it to other users in the same ecosystem.

Then you create the platform so that other users can clone an instance of your application by charging them. If you burn out, you can just stop developing the application, and the users that relied on your application. Otherwise you can keep on developing the application and then charge for the updates etc... etc... etc...

I think someone should do it, at least an abstraction of it. I would be "too frightened" to do it, maybe you could raise VC capital and become part of the problem by saying that it is the app store for web apps or something.

It reminds me of what happened with Blender. Now it's a valid product with a lively development community.

My experience with open sourcing dead product is that unless there is an interested community which understands the virtues of the product and wants to keep it alive, there are practically no advantages to open sourcing it.

There are graveyards out there full of dead open source code. Will it ever be used? who knows. Without people a product is just dead code.

I am pretty sure that the main reason a lot of folded start-up companies, killed projects etc. do not just open source their code is 'code pride' in some form.

No one wants to publish a 'hack' to the scrutiny of a elite community of programmers, and for some companies just cleaning up the code to the standards the community expect would cost a lot of money.

My conspiracy theory is that the majority of SaaS startups that get bought don't open source it for shame of how horrible their code is. After all, the only goal of their financers was a quick exit. You don't need pretty code for quick exits. This kind of pressure seeps through to the coders fast enough.

This is where the pivot methods fall short: in the long run, it erodes good will to rely on new services. We should expect that at least funded start-up will provide reasonable "exit" service for customers, and VCs will take that responsibility as part of their bet on the industry at large.

So, these guys openly admit they indirectly caused AIM to shut down and everybody is just congratulating them about going open source?! They should be drawn and quartered for that!!

(no seriously guys, nice job on the open sourcing :) )

It is never as simple as throwing it over the wall. It's one thing to make code available for review, and another to release a package that recreates a functional product.

Companies may have elaborate infrastructures and sets of dependencies, and it may take a lot of time to come up with something that even builds correctly in isolation.

Open-source basically has to be planned early on: use freely-available tools, use common platforms, etc. and then open-sourcing it later may not be too difficult.

For a great dev shop to give something to the community, it is an insightful gesture that speaks to their concern for their users. Rather than shuttering and issuing a 'screw you', they made the business decision to stop actively maintaining, clink beers with their customers, and give it away. How do you not respond with "cheers"?

Rather, sell it: http://news.ycombinator.com/item?id=3716808

If you're shutting down due to insolvency, this may not be an option.

People talk about this as if it's an action you can take. The title even uses it as a verb: "open source" it. Is "open sourcing" even the decision of the developer, in reality?

Sure, the developer can decide to release the code as open source. That's fine. But to make an open source project requires a lot more commitment than that[1].

An open source project is kinda like a startup. You need your product (the code) you need your marketing (letting people know the code exists) you need your customer development (is the code useful for a lot of developers?) you need sales (dude, you really want to help with this code!) you need passionate early adopters (dude! you actually wrote unit tests for us? Tubular!) etc.

Compared to all that, putting the code up on github is the easiest part.

Really, starting an open source project is about building a community of people. Not people who use the code, but people who care enough about the code to maintain it and contribute to it.

If you don't do that, you've still got abandonware, its just that the code was open sourced before disappearing, never to be seen again.

Spending this effort to build a community may not be viable for projects being shut down- especially if they are failures. The people behind them may be burned out or soon to be unemployed or soon to be handcuffed by NDAs.

Maybe the open source community could use its own equivalent of the ASPCA-- the American Society for the Prevention of Cruelty to Abandoned Projects.

They could take them in, like pets, give them a home for a few months or maybe a year. IF the original developers are willing they can provide as much or as little support as they are emotionally or physically capable of. After a year, if the project has attracted enough interest it is spun out as its own open source project, and if not, it is "euthanized" by being marked as shut down and put in cold storage.

This, at the very least, would serve to bring light to these projects that could use some love. And since the organization would only handle a limited number of projects at a time, they could provide life support during that transitionary year, without burning themselves out trying to save every abandoned project, lost and starving on the side of the road.

[1] I speak theoretically, I'm in the process of making my first open source project and have been thinking about this a lot lately. My previous open source experience has been as a contributor.

Edit to add: this isn't meant as a commentary on Copycopter, just general thoughts on the topic of "don't shut it down, open source it."

While bequeathing code to the community instead of having it buried with you is a very good thing it comes with a caveat. In most cases, it's not a good idea to pick up the result in its entirety - all of the code, the brand, the users, etc. That's baggage. It's a burden, not a help. In most cases it's better to make an explicit fork, or even just cherry-pick the best ideas and bits of code for use in a clearly separate project. If users think the new thing is better than the old, they'll migrate. If they don't, they won't feel entitled to come bugging you for support - or, if they do, you'll have a good reason to turn them away and concentrate on making the new thing great. Obviously you have to comply with the original licenses if you copy code, but you'd have to do that anyway. This way is likely to be far better for your own sanity and ultimately for users as well.