"When it adds value", or so it is said. Define when it value is added and you get the edge you need to cross when it becomes viable. Say you are working on a F

"When it adds value", or so it is said. Define when it value is added and you get the edge you need to cross when it becomes viable. Say you are working on a FOSS project to replace something and the one of the dependencies doesn't work out. If you have the project capacity, it might add more value to roll a replacement. Example: say you are writing a metrics collector, and you need something that can run inside a container because you want to deploy it as a sidecar. A dependency you use needs root network access for some reason, and you can't really bypass it using CAP_'s because it's hardcoded to look for UID 0. You can patch it if the code allows for it, but if it doesn't, you still need a fix so you might as well roll your own. On the other hand, say you are in a commercial setting, then value is probably not added by rolling your own until it's either freeing up resources or addressing a business need. Example: you are running a bunch of APIs behind a gateway, and the gateway exposes those APIs on a subdomain based on their name. But you kinda want them on the path of a single domain instead. You could do an ugly patch with a reverse proxy in front of it and rewrite all requests, but at that point you might as well implement a replacement gateway that does the same thing. While it might be a slightly bigger effort, it both frees up resources and gets a business requirement resolved. There really is no one-size-fits-all rule, even if you take licenses, quality, maintenance, sourcing, cost etc. into account it still won't cover all cases. Say you are a small company but your software is used on billions of devices. Rewriting a part of a kernel would give you a few cycles less CPU time required for a task that multiplied by billions saves a lot of computational power, but you, as a small company, don't have the resources to do so. Even if the license, quality and maintenance is right, you still wouldn't rewrite something like that.