A skightly different view, but when I started a lot of companies did give back. I have worked with, hired, managed and led at least a half dozen teams with the explicit mission to make an already existing open source project do what we want by contributing functionality upstream, or by forking the project. I actually wrote a “open source engineering management” curriculum back when I was still teaching.
Unfortunately these efforts often sttuggle in a similar way - some developer who is not affiliated with us starts creating friction, and blowing up internal schedules, sometimes seemingly on purpose. Management starts to ask why so many of our features are dependent on SkankTopia6969 approving PRs and awkward conversations ensue. And then the project slowly becomes the process of educating an increasingly detached internal hierarchy on the realities of open source development, and people inevitability start asking why this is even in-house tooling in the first place.
Despite that, I’ve fielded a bunch of products like this, though always at fairly small scale (like $10M/yr revenue). The only time I’ve really done it big league the project got canned during a technical reorg.
Hey, congratulations on discovering why statutory law and case law are both “the law,” and why criminal courts exist specifically engage in open ended fact finding.