Hacker News new | past | comments | ask | show | jobs | submit login

The solution I've come up with is a pledge to release the source code if the product dies.[1] We've done this at Floobits, and it makes our users' lives less stressful.[2]

1. http://geoff.greer.fm/2012/09/19/a-responsible-product-sunse...

2. https://floobits.com/pledge




Nice to see someone else viewing pledges as a potential solution.

Something I think would make this even better, is if the pledges were standardised, so they followed some mutually agreeable guidelines. I had a go at doing this here:

https://github.com/jamesisaac/pledges

I have it in place on my app (https://nachapp.com), and plan it include some/all of the pledges on future products I launch. Haven't yet come in contact with any other founders who are up for including it on their product... but if you like the idea and want to help improve the draft (even if it's just for the "long-term service" pledge), feel free to get in touch.


What good is a pledge? Once the product dies, there's presumably little incentive to abide by it.


I have worked at startups that people could believe would fail. We used source code escrow services that release the code to customers if we went out of business. Any of them would have been free to open-source.


Up-voted and seconding. I have worked at startups that have done the same thing. I think this is not an uncommon practice.


Any recommendations as to reputable code escrow services? I'd imagine there are some misbehaving players out there.


Never heard of a bad actor. I think you just choose a law firm, insurance company, big 4 accounting firm. That sort of company.

They just need to safeguard the code drops and execute the transfer at the proper time. Like reading a will.


Little incentive? Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar. The internet has a long memory, and people would not trust you in the future.


How about the pain-in-the-butt that is organizing, packaging, and releasing an organic network & development environment when you have other bigger things on your plate? I'm sure there are a few companies here and there with everything already nicely packaged. Yet, most places I've worked, it would be a herculean effort to pull the tangled jungle that is the internal network & development environment into one halfway-functional package.

It's less than ideal, but it is usually extremely low on the list of priorities as well as virtually untestable, unless the business model involves a large number of functionally identical VLAN's.

Also, names of people are usually not very strongly attached to products.


Who said anything about organizing or packaging? Just put the code up on Github with a reasonable license and walk away. Running and maintaining is of course still a problem, but you can hardly expect a company that is out of business to do that.


You may have the code, but there might still be a huge pile of problems. Such as:

How many application variables are hard-coded to your company's specific network and server configuration?

Have you fully documented the configuration of every related server, checked that in, and kept it up to date?

Are the required versions of every dependency well documented?

Does it use any third-party packages that you have modified, but never checked into your source control?

Is any part of it dependent on some massively expensive piece of software or data set that you happen to have easy access to for some reason?


I completely agree that open sourcing the project does not guarantee that the project will continue to function. I also think that after a company goes out of business they have no responsibility to keep their project functioning. Once they open source it, anyone is free to put in the work to keep it going and I can't think of a better guarantee a company could reasonably give.


"Just put the code up" isn't always that easy.


Not to be a dick, but

"One thing we do want to make clear: Svpply is not going away. We’ll continue to bring our users new products each day"

https://news.ycombinator.com/item?id=7939934

And as dotBen posted, from their blog:

"One thing we do want to make clear: Svpply is not going away. We’ll continue to bring our users new products each day"

And if you follow the comments you'll see that some believe that these promises aren't even meant to be long term. So, simply, we would be stupid to bank on it.

Congratulations to the team, though! It shows a great and determined effort, something I greatly admire. And hopefully a means of maintaining trust will emerge.


> Even assuming sociopathic tendencies, it doesn't make sense to renege on the pledge and be branded a money-grubbing liar.

But that's just the same incentive for a company to continue providing the same level of service after being acquired.


In general it could be taken as a legally binding statement so if they are bought out and shut down there would be an avenue to pursue with the new owners.

The couple of small companies that I have worked for that had such a pledge took it seriously. They would hand source for every release over to an escrow company ensuring availability after company death.


Yes, the legal route sounds at least plausible. I don't know if there's any precedent or how reliable such a contract could be made.


It's not plausible because insolvent / bankrupt companies have the option to walk away from onerous contracts if it is in the interests of the debtors not to honour them. In this case, the idea of open sourcing the software UPON bankrupcy could destroy any remaining value left in the business (value of IP) which would otherwise be realisable to distribute to debtors.


Why not just open source it from the beginning? :)

https://github.com/inboxapp/inbox/blob/master/LICENSE


I know some folks at Basho where they do just that with Riak, a high-availability distributed database. It's not an unworkable strategy, and clients know the product's not going to vanish out from under them.

https://github.com/basho


I prefer something enforceable in court.


Putting the source in escrow is a much better -- and more enforceable -- option than a mere pledge. This places the ability to release into the hands of a third party who is obligated to do so in the event that the conditions are met.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: