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.
This is not only good for your customers, but also puts some positive pressure on your competitors. Now they have to compete with an open source tool, so whatever they do, they'll have to provide a service which is at least as good as that. In other words, they'll have to compete more on quality and less on price, which is usually a good thing.
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.
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).
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.
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.
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).
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.
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'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:
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?
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.
If the value isn't there, then tightening the belt is just a cop-out. Even if the service could stagnate with a steady trickle of profit, it's not worth it to the founders who have their eyes on a bigger prize. The consumers who do derive considerable value are better served by an open-source implementation that can be iterated upon and developed further anyways.
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.
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"?
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.
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."
1. dump the code into a zip and release it under a free licence
2. step 1 + answer to emails
3a. step 2 + provide a hangout for interested developers
3b. step 2 + actively work on the code base
4. steps 3a and 3b
5. step 4 + actively sell the project to devs
For example, id Software is on level 1 (or 2?) by releasing old engine sources. That is already much better than throwing the code away. Most open source projects themself are only at 3b, because they are hobby projects and don't care about users.
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.)
Disclosure: I'm one of the maintainers of the new Copycopter.
When the announcement that Copycopter was to be shut down both Crowdtap and Iora Health reached out to Thoughtbot about keeping the service alive. Dan Croak facilitated communication between us and began the thankless job of putting the application in a state that we could deploy and maintain the codebase.
I believe this transition was a ton more than just opening a repository on Github. Dan engaged interested members of the community and has helped us get to the point in which we can carry the service forward. It was handled very well from my point of view.
I have seen quite a few code bases, where the original author who didn't want to continue the project, just released the source code somewhere (as zlib, public domain, GPL or what ever) but nothing more.
If there was interest by some other developers, there was always some new open source project/community building itself up around the released code. And if not immediately, maybe a few years later.
E.g., some examples (where I was partly also involved in):
oh wow, I worked on puzzle pits for a while trying to get it to compile.
I ended up figuring out that the original binary ran perfectly fine in dosbox (which I played for a bit) and that the original code was pretty much useless and it would be easier to do a complete rewrite of the game to get it to work with a modern system. Not to mention this doesn't even use a recent standard version of C. So I ended up losing all motivation because of this and because of being a 1 man team.
It was a fun project though, it was this project that introduced me to the hacks that made dos games possible :)
This is very true, but I think a company that is open sourcing it's source code is the ideal breading ground for an open source project. A lot of the marketing did already happen. This is especially true, if the main clientele of the company are developers.
For other ideas, maybe a new team will actually pick up the idea and continue to work on it as a company. I am currently working a startup project and we found a company, that was working on the same idea for 3 years and ultimately gave up. We emailed them and are hoping that they can share some lessons, but imagine we they open sourced their code. That might have really given us a jump start. But then again, as a developer I prefer writing by own code from scratch, to working on someone else's (by definition) crappy (most likely) PHP code base.
Technically they are just doing open sourcing for the most basic part. They are not starting a project, they are simply donating the code to those who want to start a project with it (read the post).
Being open-sourced doesn't prevent any codebase turning into some kind of abandonware. Certainly for me I have used a lot of software that turned out to be abandoned no matter they are open-sourced or not. But here is the problem, if it's a service, it's worse than abandoned. You simply can't use it. If it is just some desktop software, I can stick with an ancient version until I fill sick maintaining the running environment. For a service, that is it.
So to my own end, open-sourcing it, is at least, better than simply vaporize the service (which many of Google's services have been like that for the past months.)
This is so important and yet most people don't realize it. A tremendous amount of effort goes into maintaining an open-source project. No software is "bug-free" for instance; and you have to continuously seave user feedback for bugs and fix them quickly.
This is a worrying trend. Most of the projects on github have become 'orphans'. I see no docs and worse - no activity for years even on some pretty interesting ones. Contrast that to Apache projects and their communities.
@patricksroberts I think @nirvana meant this in a more general sense.
The Quake devs just took the program, dumped the sources online, voila. Open source community built itself.
It really depends on what you're making. If the software is popular, there's little need to help form the community, facilitate the process, and so on. It might help, but just dumping the sources online is way better than nothing.
I think the attitude here is simply, “if people want it and can get value from it, here it is”. Which is fine. Not every code dump needs to become a living project with an active community. It's nice that they put it out there to allow for the possibility.
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.
