Quite often the company's product is the open source project. It's just that instead of selling licenses, they're selling support contracts. You could get the software free, but for a fee you get to call the engineer that built it in the middle of the night for help keeping it running. And as a bonus, you get to leverage their ability to drive the roadmap when you have feature requests.

So really the debate here is not "do you hire an engineer full time or not?" it's "do you allow the output of that engineer to be open source or not?"

There's also a perk for the engineer: they work on stuff they can publicly point to as their portfolio full-time. Want to see me code? I don't necessarily have to have a bunch of side-projects on Github. Go check out the JIRA for these huge features I worked on!

1.) The task usually needs to be done, but is not business advantage. E.g. you wont sell more because of it. The developer asks the company whether the thing can be released and company does not care so it says ok.

2.) The developer has high status in the company and thus can do what he wish (up to the point). The company ends up tolerating it.

In addition to the other answers you've gotten, it's often the case that: (a) Developing what you need as a modest extension to existing OSS is cheaper than doing it all by yourself; and (b) Contributing those changes back to the community means that you've shed the burden of having to keep your local patch's changes in sync with the OSS version going forward.

("Hey, we wanted to use MAAS to maintain our cluster, but it doesn't support our particular power controller, so let's send the patch upstream...")

It's generally a technology somewhat related to your job.

For example, web hosts like GoDaddy do a fair amount of contribution to WordPress because they host a lot of WordPress sites and their customers will keep renewing their web hosting if WordPress is excellent and secure.