This is fine for what it is... but at its core, it is a categorized list of github repositories, and the category happens to be failed startups.
I would drop the whole "graveyard" theme, and expand the categorization concept... then this could be less of a novelty, and more of a new wrapper around github for discovery of relevant codebases to whatever your current project may be.
I disagree, I think that this is precisely targeted at encouraging failed startups to open source their software for others, which has been rare in the past.
People can then tell their (former) CEO, "See this site, everyone is using the graveyard".
Encouraging that behavior is utterly different than just indexing the few that did so in the past.
I see no particular point whatsoever in insisting that it would be better as a vague indistinct generic gitub wrapper -- although if you have an idea for improving search of such, go for it.
I definitely like the idea of preserving the source code of abandoned projects though. Ultimately, I'd like some equivalent of the "legal deposit" principle that applies to books and other printed works - some kind of scheme where source code, not just object code, for proprietary products eventually makes its way into the public domain. I'm not sure how this scheme would work, but I'd like it to happen.
I worked for a company where one of the clients required that all the source code be periodically archived and shipped to them so that if we went out of business they could potentially run it themselves. Practically, they wouldn't be able to because of the sheer complexity of all the different services. It was a minor pain to do this for them but the contract was worth it.
Having said that, I am a big fan of open sourcing projects of they fail. Why not? What do you have to lose?
- failed startups don't just stop, they go into administration and get auctioned off, which means someone else owns the IP.
- proprietary source usually contains licensed copies of other people's source, and sorting out who owns what and what's safe to release requires a surprising amount of time and money.
My previous place had a tonne of interesting IP, all of which is now owned by a VC company who will never, ever do anything with it. I'd have liked to open source it if we could have, but it was a total nonstarter. shurg
I've never worked for a company where we shipped the code directly to the client; that seems a bit risky for the company producing the code.
I did work for a startup though where all of the code was backed up and sent offsite to an escrow service. It was part of our standard contract that if the company ceased operations all clients would have received copies of the code. This was a pretty big deal to quite a few clients as one of the biggest risks for a larger client investing in using software from a small company is lost sunk costs if the startup fails. If the client has this type of agreement in place it is much less risky. If the startup fails then a heavily entrenched client would request to receive the code and more often than not hire one or more of the now unemployed software developers either as employees or consultants to either maintain the software or train someone else to.
@frazras actually from this context since I believe it is a fairly common problem, the closed casket paid service makes a lot of sense. What would be ideal is if it could essentially be turned into a GitHub/BitBucket (private) style service that is dead simple to use, but also acted as an escrow service. You would need a means of tracking clients, but not allowing them access unless terms of contract were met that allows access. Then it would also need to lock down the codebase in some manner; don't allow repo deletes, do backup snapshots, something like this so you can guarantee the startup doesn't breach contract.
Eight months later, I still think it was absolutely the right move. Don't get me wrong, I wish the project could have lived on. But I sleep much better at night knowing I didn't open myself up to any additional liability or feeling inadequate for not having the time to spend helping others do something worthwhile with the code.
I was involved in a project which had some potential to become a startup, but for various reasons we decided against going into business - we ended up GPLing the proof-of-concept application we'd been working on and put it up on GitHub: https://github.com/tsujamin/digi-approval
Because most of the time it's useless to open source projects that don't compile and run. Though perhaps I am sure there might be someone who might care enough and move in and make it run. I think something like that happened with Tesseract, Google stepped in to make something than was not running, viable.
Could be part of an escrow contract - e.g. if the company goes out of business, after x years, the escrow agent will release the code into the public domain.
I've been through this a few times as both the vendor and the client. There are normally a bunch of conditions that can trigger a release of the the source code to the client. These _could_ include business failure but also non-performance or acquisition.
I've never come across one where escrow agent will release source to the Public Domain but I guess it could happen.
Companies like Iron Mountain have escrow services for clients of SaaS providers. I think in these cases data escrow is significantly more important than source code escrow.
If a failed startup releases their source code and another team picks it up and solves whatever problem the original team had - time, resources, bugs, etc. and is successful, then there would be some kind of kickbaack (albeit small) to the original owners or developers.
Founder here: I fixed the server issues, I really never expected to make it to frontpage literally overnight. The aim was not necessarily to get someone to use the entire codebase. there are features that may be interesting to the user. The user may just me interested in the structure of the code and to familiarize themself with how code is written in a startup.
maybe you should have some projects that can be bought and maybe the founder of the failed startup can make some money out of it. If there is no buyer for the code for certain number of days, it would be open sourced?
I am a proponent of open source but graveyard, obituary, failed.. sounded too much negativity..
frazras later indicates that he has reservations on the release....
It might be gpl, but it may pull along enough other baggage
as to be pretty stupid to use the code.
maybe codebutuary might be renamed to submarinebituary.
There could even be unpaid vendors, issues as to the true
owner's actual intent and it's release to gpl, possibly a
spiteful act.
This needs much better definition and stated ownership,
by codebituary.com
Looks pretty awesome. If I have to criticize the "Add a Startup" button bothers me a bit, its placement is a bit off. It feels like it should be a bit lower and more in line with the rest of the page.
The potentially most valuable part of this site is the "reason for death". In fact, i'd find that useful even if the site source code was not open source. Simply open sourcing your lessons learned is valuable.
There is a category of start-ups that are like that "American Ninja Challenge". There's a line of obstacles that are visible, and seem easy enough... but are hard to swing across. It would be nice to see the ways people fell in the pit. So when you try to swing across, maybe you can make it :D
This may lead to show that code actually have some value, even if the business didn't work out.
If some failed projects go open source, while others manage to sell the code, then it may create a market and then makes it easier to borrow money, with code being the collateral.
Looks pretty awesome, but logo could use some improvements. e.g lose the cross or replace with stone or something else. Religion sign might put some people off.
I would drop the whole "graveyard" theme, and expand the categorization concept... then this could be less of a novelty, and more of a new wrapper around github for discovery of relevant codebases to whatever your current project may be.