[barrkel]

The mistake you're making is thinking that the public tools are the best tools.

There are reasons that make them the best for many, if not most, companies: more investment, more mindshare, easier to hire employees with prior experience, and so on.

But there are also costs in having a wobbly stack of glued together stuff, especially if the parts aren't quite right for your goal.

Sometimes the best tool is more focused, more vertically integrated, in a different language or for a different operating system because those choices integrate better with the rest of your stuff.

The constraints of the company are also part of the problem domain. Using the wrong tools can be quite expensive, and the public tools may all be just a bit wrong in a way that compounds.

[kelnos]

Where I work, the majority of our tools were built in-house, mainly because we started (2008) before there were good open source or even paid options for most of it all. As good options started to appear, we found that we couldn't adopt them, because there was a mismatch in concepts/fundamentals between what we'd built and what was out there. We've evaluated a lot of things, and for many of them, we end up realizing that integrating them with our systems would require a hard fork, and so we'd lose most of the benefit of using it.

Frankly, it sucks. Our tools are mostly very good, but it took us a long time to get there, and the internal fights over getting funding to really invest in our internal platform have been exhausting for all involved. I get that it's not zero work or zero time to use something off the shelf, but as someone who has been playing in the grass on the other side of that particular fence, it takes a lot of work to keep that grass green.