4 ms·

In the second paragraph of the article the author describes how some dependencies of the application were replaced by open-source libraries like SDL. There are

In the second paragraph of the article the author describes how some dependencies of the application were replaced by open-source libraries like SDL. There are also many more examples of this happening. So the assertion that "nobody" would do it is wrong. If the application is interesting, people will find find a way to run it on modern hardware. It's not an excuse not to open-source what you can of your code. This line of excuses is just weak. Either release the code or keep it proprietary, that's your decision as owner. Just spare us the silly excuses and trying to make it seem like your company would really really like to open-source if only it wasn't for that tiny detail of blah...

johannes1234321 6y ago
Getting rid of third party's code often isn't as easy as removing a folder and be done. Sometimes third party code is deeply integrated and was patched and can't be isolated or it might be the core component/core engine where the missing make aThe reminder almost useless. Also some vendors put their APIs behind an NDA, thus you not only have to remove the API, but also rework the calling code. (Just for open sourcing fighting whether the NDA is legally clair is quite some effort ...) This also becomes fun if you worked with external contractors, who committed all over the code and the agreement doesn't cover releasing the code. And then there are still all the other things in open sourcing (making sure comments are appropriate, naming is appropriate, ...) And then you have IP besides the source, in artwork where designers often have some rights, copyrights, trademarks ... And after all that the "fear" on your reputation, if one fears the code might seem of low quality, which might reflect bad. (Whether it's truly bad doesn't really matter, a few blog posts or youtube videos of somebody taking worst parts can harm reputation) It's all simpler, if you plan on doing that eventually from the start, but notable effort for any serious project after the fact.
- colonwqbang 6y ago
  It seems unwise to let control of your product degrade to the point where you cannot draw a line between code you own yourself and encumbered/external code. It should be possible to avoid with proper planning. Still, you're probably right that it is a common situation. Your other examples mostly seem to boil down to "we were not willing to commit the necessary resources to do it". Which is fine, of course.
  - johannes1234321 6y ago
    > Your other examples mostly seem to boil down to "we were not willing to commit the necessary resources to do it". Yes, of course. If I invest resources from the beginning for "I want to relicense and open all the code" then there is no problem. However for most companies the priority is "get this out before our competitor releases their product" and many things fall under and often neither developers nor managers have the legal knowledge (and don't care) And btw. I fully support this on a different level: For instance for devices like (home) routers I support a scheme where a company is required to publish the software once they cancel support, so one doesn't have to throw away fine working devices only since the vendor stops fixing security issues. But that won't happen quickly, as it goes through the supply chain: You need the device drivers for the chipsets etc.
ghaff 6y ago
I wrote no one "to a first approximation" which I stand by for most (but not all) software. I actually think it would be nice if more abandonware would be released but "it's too much effort" and "it exposes me to unknown risks, especially if I don't take the effort to do due diligence" are not silly excuses. I did eventually open source some code from a popular shareware utility years ago after people asked me to. (No one ever did anything with it of course.) It took me a while because I did use some third party code but eventually decided the company that wrote the code was long gone and no one would care. But a business with lawyers would not have allowed that. And even documenting what would be needed to replace the routines would have taken a fair bit of work.

johannes1234321 6y ago

Getting rid of third party's code often isn't as easy as removing a folder and be done. Sometimes third party code is deeply integrated and was patched and can't be isolated or it might be the core component/core engine where the missing make aThe reminder almost useless. Also some vendors put their APIs behind an NDA, thus you not only have to remove the API, but also rework the calling code. (Just for open sourcing fighting whether the NDA is legally clair is quite some effort ...) This also becomes fun if you worked with external contractors, who committed all over the code and the agreement doesn't cover releasing the code. And then there are still all the other things in open sourcing (making sure comments are appropriate, naming is appropriate, ...) And then you have IP besides the source, in artwork where designers often have some rights, copyrights, trademarks ... And after all that the "fear" on your reputation, if one fears the code might seem of low quality, which might reflect bad. (Whether it's truly bad doesn't really matter, a few blog posts or youtube videos of somebody taking worst parts can harm reputation) It's all simpler, if you plan on doing that eventually from the start, but notable effort for any serious project after the fact.

colonwqbang 6y ago
It seems unwise to let control of your product degrade to the point where you cannot draw a line between code you own yourself and encumbered/external code. It should be possible to avoid with proper planning. Still, you're probably right that it is a common situation. Your other examples mostly seem to boil down to "we were not willing to commit the necessary resources to do it". Which is fine, of course.
- johannes1234321 6y ago
  > Your other examples mostly seem to boil down to "we were not willing to commit the necessary resources to do it". Yes, of course. If I invest resources from the beginning for "I want to relicense and open all the code" then there is no problem. However for most companies the priority is "get this out before our competitor releases their product" and many things fall under and often neither developers nor managers have the legal knowledge (and don't care) And btw. I fully support this on a different level: For instance for devices like (home) routers I support a scheme where a company is required to publish the software once they cancel support, so one doesn't have to throw away fine working devices only since the vendor stops fixing security issues. But that won't happen quickly, as it goes through the supply chain: You need the device drivers for the chipsets etc.

ghaff 6y ago

I wrote no one "to a first approximation" which I stand by for most (but not all) software. I actually think it would be nice if more abandonware would be released but "it's too much effort" and "it exposes me to unknown risks, especially if I don't take the effort to do due diligence" are not silly excuses. I did eventually open source some code from a popular shareware utility years ago after people asked me to. (No one ever did anything with it of course.) It took me a while because I did use some third party code but eventually decided the company that wrote the code was long gone and no one would care. But a business with lawyers would not have allowed that. And even documenting what would be needed to replace the routines would have taken a fair bit of work.