Speaking for myself, reasons why I don’t immediately share my own tooling:

Perhaps I want to hold it to my own standard for tooling, not the team’s.

Perhaps I want to write it in a language that the team doesn’t really embrace.

I might not think it’s worth anyone’s time to code review changes I make to my own tools.

I might want to do something dumb like bake an API key into the tool.

Maybe the project already has a similar tool, and I don’t want to explain why I am wrapping/ignoring it.

In short: sometimes the cost to collaborate on idiosyncratic tools is just higher than I’m willing to pay.

Sadly, I do the same at times.

I just want to hack together something that works for my use case. If I can share that with the wider team, that is superb. But I really don't enjoy my hacky utils being subject to tedious code review scrutiny they don't deserve.

To be clear, I _do_ add utils that I think will be useful to the common repo, subject to review, and mostly they will be merged. But if it gets painful, I just retract the PR and keep it locally.

Have you ever tried to submit a PR of your Makefile to the maintainers of, say, an open source npm package? If you have, what compelling story were you able to tell about that Makefile that got the maintainers to merge your PR? And after they successfully merged it, did you continue putting up PR after PR for each successive round of tweaks to that Makefile?

What an extraordinary amount of unnecessary effort that would be. My workflow does not belong to the repo, it belongs to me. The only thing that belongs in the repo is all the shared workflows (or the elements they comprise.)