Live data from Hacker News

Failed Startup code graveyard

codebituary.com

11–20 of 35 posts

Re: Failed Startup code graveyard

#11
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.

Re: Failed Startup code graveyard

#15
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.

Re: Failed Startup code graveyard

#18
Sounds like a minefield.

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

jr

Re: Failed Startup code graveyard

#19
post #3

Site's not loading very well for me. 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, bu…

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 sou…

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.

Post reply on HN