So look at the projects that stand for a higher degree of quality and hire the developers that author them so they can invest the time to battle test the code.

So look at the projects that stand for a higher degree of quality and hire the developers that author them so they can invest the time to battle test the code. Since we're talking from an economic perspective. Whoch is more cost (ie time and money) effective. Tasking an internal developer with no domain knowledge to build a module from scratch to cover similar functionality of an OSS project. Or hire an OSS dev who already has a deep understanding of the domain as well as working code to battle test the existing OSS implementation. If you're talking in terms of risk, the latter is an easy sell. The problem is, most companies are too concerned with building a stable of 'rockstars' that can support their pathological adherence to NIH (Not Invented Here) syndrome. I'd argue that the most successful companies already use this strategy. Select exceptional devs from the OSS community to build hogh quality tools as open source projects. The community battle tests the tools and accelerates the discovery of new and useful capability. Meanwhile, the company leverages the tools internally to compose their own proprietary platform in the form of domain-specific applications and services. The major disconnect is, most software based business want to have their cake and eat it too. It's not difficult to determine when an OSS project reaches enough success to transition from one-off to mass appeal. OSS is an ecosystem of brutal software darwinism. Projects that survive experience growth in usage and improvement over time. Projects that don't, stagnate and remain or eventually become irrelevant.