At that point, they have a framework that fits their use case and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case... Not that your point isn't good... I'm just saying its a grey issue.
> and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case
That's what you think. What actually happens in many cases is that the developers get too busy with other work that is important to the business (e.g. working on the business value directly). At that point the internally-written framework has known bugs and issues, or maybe lack of documentation, but nobody has time budget to seriously solve them and so they keep using the internally-written framework with all its quirks. Once in a while a person who worked on the framework leaves, taking knowledge with him. The remaining people sometimes think "uh... this part so strange, why was it like this again?" but the guy who wrote it already left. And then once in a while someone new joins, thinks "this framework is shit" and ends up reinventing his own internal framework, with its own quirks, while not completely understanding the problems that the original framework was meant to solve. After a while the internal framework gets abandoned in favor of a standardized framework.
I've seen this happening too many times during my days as a consultant. An internal framework is fine if your business case changes slowly, and your team changes slowly, and the framework has been very well-maintained. Miss any of those things and the framework eventually becomes a liability.
So if you're a one-man company and you intend on staying that way, and your business case doesn't evolve quickly, fine. In all other cases though...
