3 ms·

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'

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.

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.