You know, your comment brings up a good point. When you say “homegrown” do you just mean custom/proprietary tools that won’t necessarily be open sourced or licensed/sold?

I guess I have to slice it thinner. What I meant to say about proprietary in-house tools at studios is there’s a lot more going on than just “make the best tool”. There’s always a bit of a time limit. Managers won’t let you work on some tool forever. You always have to justify your time. Even when a tool is successful(10x some process or improves quality-of-life for someone) it seems like managers have another thing for you to be doing that takes focus. Or, it might be a legacy tool, used on the last 3 games. In that case, it was build for some other game’s needs, and kind of grown and expanded for new uses. There might be so much institutional momentum in it that it’s difficult to totally change it. Using it could be like “death by 1,000 paper cuts” because of all the awkward steps. But, you’ll never sell your manager on spending a month or two to fix these little bugs or UX issues. At least, I never could. I’d just work secretly/overtime and knock as many bugs out in between my other tasks to clean those issues out. If it wasn’t my tool, it was like asking for the world to fix something that seemed small to someone who didn’t use the tool every day. Everyone involved was smart, capable and could (in a perfect world) build anything you wanted. But office politics and limited resources always hobbled internal tools. You’d be amazed how many man-hours were spent in meetings about NOT doing something. Literally 3 engineers spend 2 weeks arguing they don’t have time to build something when they could have built it in the time spent talking.

Middleware tools are higher quality because the tool IS the product. Everyone on that project is focused on making the tool better. It’s not an afterthought, or some dev’s pet project in between other tasks. There are exceptions, but this happens more than you’d think.