

Shutting down a product? Open source it. - Croaky
http://robots.thoughtbot.com/post/19388751626/copycopter-is-now-open-source

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

~~~
jiggy2011
If it's truly open source then there's nothing stopping another business from
coming in and offering a hosted version much in the same way that the original
did.

I suspect that the reason this doesn't have so much could be licensing of
other libraries etc used by the code.

~~~
viscanti
If it were that easy to run a business in that market, the original probably
wouldn't have went under. Companies go out of business for a number of
reasons, but I'd bet on the initial founders who had the vision to create the
product and have experience in that market over someone who saw free code
online and decided to have a go of it. The reason we almost never see it
happen (at least successfully) is that there's almost no barrier to entry
(anyone else could pick up the same code) and that it's not an easy market
(the original company went out of business).

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

~~~
dredmorbius
In a talent acquisition, disposition of source code assets would be up for
negotiation among principals prior to closing the deal.

No reason founders couldn't specify this as a condition. Or make it an
explicit term of their service agreement to customers/users well in advance of
this eventuality. Something like:

"In the event COMPANY concludes business operations or discontinues SERVICE
for any reason, including but not limited to sale or acquisition of COMPANY or
relevant assets, COMPANY will license SOFTWARE under the terms of
$FREE_SOFTWARE _LICENSE, in the preferred form of SOFTWARE for making
modifications to it, inclusive of any build, deployment, operations,
management, and documentation support."

Where the free software license would be specified, though generally I'd
expect this would include a license meeting the FSF's Free Software Definition
or the OSI's Open Source Definition and certification.

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

~~~
five18pm
_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)._

I think they were trying to joke about the shutdown. I don't think thoughtbot
would have been under any illusion that the events were related.

~~~
Croaky
Hahaha. Yes, I was joking. Sorry about that, apparently not funny! :)

~~~
halogen64
Swing and a miss

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

~~~
Croaky
Very cool.

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

~~~
Croaky
I've been in a Campfire room with the new maintainers for a few days. We've
been coordinating the transition for a couple of weeks. Looking forward to
knocking out a few more features and bugs in the next few days while they get
used to the codebase.

Everyone's busy so we'll see how much time is needed and able to be spent by
the new maintainers but we're happy to have found almost a dozen developers to
lead maintenance across the two companies (Crowdtap and Iora Health) and we
took the time to express a process and way of doing things to help make the
project more efficient:

<https://github.com/copycopter/style-guide>

~~~
compay
Glad to hear that. Thanks very much for sharing your work!

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

~~~
patricksroberts
Thoughtbot isn't actually a VC backed startup. They have always developed
products by building tools to fit needs in their consultancy work and
unfortunately not all the products were successful enough to keep going.

The reality for Copycopter is that it's a really useful item in the Rails
developers toolkit. It didn't find a wide enough audience within the community
which is what eventually doomed it as a SaaS. The cost of spending even 5-10
hours a week working on it burns more capital than I imagine it generated as a
SaaS. That's why I think it's a perfect fit of an OSS project.

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

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

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

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

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

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

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

~~~
batista
Actually, they should also be congratulated for causing AIM to shut down.

~~~
halogen64
+1 don't worry I'm patting myself on the back right now.

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

------
glennericksen
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"?

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

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

~~~
clarkevans
If you're a developer and joining a startup you can ask as a term of
employment for this to be an option you can exercise; this way, if the startup
doesn't make it, your work is free and open source software.

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

~~~
gurkendoktor
What you say is true for software that needs to be _improved_. But I use and
love some semi-abandonware and couldn't care less about improvements: TextMate
1, NewsFire, Lineform, AAA game ports to OS X, lots of iOS software that is
ever being updated once.

iOS currently makes for a good example __, because all it takes for some old
apps to use the Retina display is _to recompile the very same source with
newer dev tools_. Sometimes it just takes that, or a small fixes to make
software run on a new OS.

I'd pay more for software if the authors promised to open-source it the moment
they drop support.

( __Of course, the App Store has a problem similar to Ruby Gems - it is hard
to transfer control of the main repository.)

~~~
itsnotvalid
For textmate there is 2.0 alpha actively updated:
<http://blog.macromates.com/2011/textmate-2-0-alpha/>

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

