Also, the doc, blog posts, feedback from the community, evangelization at conferences, thinking out the API design so it answers enough cases, not just yours, all take engineering time, that's not free.

We open sourced my team's project a few years ago ( https://nomulus.foo ) and it was a substantial amount of work. There's everything you're saying plus a fair amount of engineering to get the darn thing working externally; we were built/hosted within the Google monorepo which is obviously not externalizable. And you end up spending lots of time writing documentation that you hadn't ever gotten around to when it was just a project being worked on by a handful of engineers all sharing adjacent desks.

Not disagreeing but elaborating: The costs are higher when it's an already existing product of which parts the company doesn't fully own enough rights of for publishing. Even higher when it's not known which parts are fully owned by the company and which parts are of foreign origin. The costs are lower when it's meant to be open sourced from the start and it's been a project constraint since before the first line was written.

Of course. But compare that cost to (say) six full time engineers pumping out code for a couple of years. It's not the dominant cost by any means. Not to mention you're paying those other folks a salary regardless.

If it helps you attract better talent, well - there's a financial incentive there through increased efficiency which I'm sure on its own is more than equal to the review cost.

Why would you give your open source code a tighter security and engineering review than your in-house code? Are you hoping for security through obscurity? And quality through obscurity?

If you are going somewhere where you have to get changed in public, say the gym, do you make sure you are wearing your good underwear?

I'm pretty sure I didn't say anything like that?