3 ms·

Maybe, maybe not. Did they have investors? The code is an asset. Can they sell the code/IP for any significant amount of money? If so, they should do that and p

Maybe, maybe not. Did they have investors? The code is an asset. Can they sell the code/IP for any significant amount of money? If so, they should do that and pay back the investors/reduce their losses. Maybe there are no buyers, or the investors are on board with the open-source plan, who knows. But it's not always the right answer or even possible.

HeWhoLurksLate 8y ago
This is a very narrow view. The code is not just a company asset, it's a customer asset as well, and their needs ought to be considered as well. Have you ever had software you were using just stop working because remote servers failed or something of the sort? What about if they never fixed that problem? Software isn't exactly like buying groceries where you can go to a different grocer and get a different, equivalent solution. Instead, it's more like a bakery, where a baker has their own (in software terms, proprietary) recipe that they use. If that bakery goes away, their recipe might go too, and that would directly affect those who buy their bread, especially if it was a joint that sold to other businesses, as software normally is. If I were that baker, and I went bankrupt, I would probably give that recipe to my customers- after all, I can't profit off of it, but they still need it. Unless I'm extremely mistaken, they haven't been bought by anyone else and won't be resuming operations ever. If they had been bought out, that would be different- their storefront would still exist, albeit somewhere else, likely- and people would still be able to get your products. I am a believer in Right to Repair, and the overall principle here is similar- documentation of products is really helpful in fixing things, and if a company goes out of business, and has no recourse or any way to deliver support, it would be amazing for customers if they publicly released as much documentation as possible. To be clear, I don't think that using an old thing forever is a good idea, but it often takes a long time to find something else that fits the bill perfectly.

HeWhoLurksLate 8y ago

This is a very narrow view. The code is not just a company asset, it's a customer asset as well, and their needs ought to be considered as well. Have you ever had software you were using just stop working because remote servers failed or something of the sort? What about if they never fixed that problem? Software isn't exactly like buying groceries where you can go to a different grocer and get a different, equivalent solution. Instead, it's more like a bakery, where a baker has their own (in software terms, proprietary) recipe that they use. If that bakery goes away, their recipe might go too, and that would directly affect those who buy their bread, especially if it was a joint that sold to other businesses, as software normally is. If I were that baker, and I went bankrupt, I would probably give that recipe to my customers- after all, I can't profit off of it, but they still need it. Unless I'm extremely mistaken, they haven't been bought by anyone else and won't be resuming operations ever. If they had been bought out, that would be different- their storefront would still exist, albeit somewhere else, likely- and people would still be able to get your products. I am a believer in Right to Repair, and the overall principle here is similar- documentation of products is really helpful in fixing things, and if a company goes out of business, and has no recourse or any way to deliver support, it would be amazing for customers if they publicly released as much documentation as possible. To be clear, I don't think that using an old thing forever is a good idea, but it often takes a long time to find something else that fits the bill perfectly.