> We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution I would also consider

> We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution I would also consider self-hosted FOSS tools under the "build" category rather than "buy", so I would have no objection to using those versus re-building an available FOSS tool yourself. It's OSS, so you have the code, so you know what it's doing and how. It's self-hosted, so you aren't reliant on a vendor. It's (hopefully) free, so no vendor is trying to sell you on a module you don't need. > Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood. I think the key question here is, "who is using the internal tool?" To my mind, this is about teams building the tools THEY need, so it is nigh impossible to develop the tool but not understand it. You're not handing it off to another team, you built it because YOU need it. There can absolutely be abysmal documentation, but not having documentation and not looking at extant and extensive documentation is functionally equal, and the latter is by far the default state of tool use. Your comment sounds as though in your mind some team is being mandated to build a tool for another team, against that other team's wishes. Is that internal to the company? Sure. Is it self-rolled? Not if the people using it didn't make it them*selves*. In that case it's really just a vendor tool, but the vendor is much less invested in the tool.