As long as you are not using tools and internal IP on your project and it is not a competing product it is typically fine.
This idea that BigTech is hostile to side projects is misplaced. They would actually like it if you succeed because its a PR and branding win for their engineers.
The process, at least as Google, is to disclose your project to a committee and ask for permission to do it in advance - if they accept they give you IP release waiver and tell you what parts you can and cannot do in your project, for them to not consider it an invasion into Google's interests. My experience with this process was largely negative. Bunch of jerks erring on the employer's side. I can totally see why people with strong interest in their personal projects may not be willing to participate in this circus.
In practice, that meant every time I was reading some mailing list and would like to reply to something with a small patch, I would first need to contact my company, add that mailing list's project to the set of outside works, write a bit about the project and get approval. It would turn a 10 minute action into a multi-day administrative action involving managers - completely impractical.
The company just didn't have a way to model someone whose idea of outside works was to contribute to countless random projects in small ways every evening, without knowing in advance what those would be.
I tried to talk with the company about this problem, and they weren't interested enough to solve it, and didn't see it as a real problem. They thought I was making waves about something unimportant, and perhaps I was misjudging its importance. Perhaps it would all be fine. But I didn't want to accidentally produce things that the company later decided it had a claim on.
This was a significant factor in my relief when I was made redundant, as I felt free to finally pursue my interests instead of holding back. I didn't know how much it meant to me until then, but the relief made it obvious that this one issue had been seriously weighing me down throughout the employment, and that I should be more mindful of it in future.
If the company had found a good solution to this problem early on, I expect I would have been very much happier working there. Clarity is all that was needed, really.
That was before GitHub. I'm guessing companies are a lot more used to their employees doing small outside contributions like that now. I am still wary of doing so without a clear line. Fortunately, all my recent engagements have contracts that limit what the company is interested in, and exist in a context which recognises and even encourages that outside works will take place.
I've seen a similar contract, but with an explicit exception for open source work.
The flip-side to this is that, if you're in the middle of nowhere (and demand on-prem), it's harder to attract junior developers for the things that they typically cut their teeth on to move up. This often makes maintenance activities, smaller design and development work, and adding a few extra coders to a project more expensive than they otherwise would be because senior talent is more expensive.
So what's an engineer? Outside of software, an engineer is a professional - a member of a professional body, licenced to undertake specified design and construction work, and required to take regular training and re-licensing. It's like a physician; it's not some particular level of training or experience. Or skill - there are rotten physicians and excelent ones. But if they're not licensed, they're not a physician.
Can't we go back to calling programmers programmers?
Software engineering got its roots from electrical engineering and this isn't true for most electrical engineers. You only need to be licensed in a few subsets of electrical engineering (i.e. power production and distribution). All other areas don't require a license.
There is a difference between software engineers and programmers. I had it explained to me like this. If you spend more than 50% of your time programming, you can't call yourself a software engineer. A software engineer is supposed to spend most of their time designing and architecting a solution, testing assumptions, documenting the design process and conducting design reviews. This process is slow and tedious but if done correctly will save you a lot of headaches in the future.
My gas-fitter is professionally-licensed. My electrician is professionally-licensed. My accountant is professionally-licensed. They have to be. But I'd hire a developer with a stellar record over one with a professional licence, unless the post was Compliance Officer or something.
I just don't expect such a licensed "software engineer" to be doing hands-dirty software development; they'll be managing the show. Hands-dirty developers need to know stuff you don't learn on training courses.
The FAANGs in the US will hire basically anybody, provided that person passes their interview process and is willing to physically relocate to one of their offices, which are usually located in major cities that have high costs of living (e.g. Bay Area, New York, Seattle, Boston) and therefore high compensation.
But there are many, many competent people in the US who aren't willing to move to one of these major cities, who can't pass the FAANG hiring bar, or don't want to.
Those people may be willing to accept a lower-paying job because that suits them better.
It might also be worth considering if the role you're thinking of as "software engineer" is actually a "software engineer". Does an SMB really need a "software engineer"? Maybe what they need is a "software developer", which on average receives a lower salary.