I don't believe this is a money issue, almost all maintainers and big kernel contributors already work for big tech. Thing is, you can't just simply hire more maintainers as there are only so many senior kernel contributors around and most of those that aren't already maintainers probably don't want the role as it is now.
Sounds like a money thing. Being a kernel engineer is being handcuffed to one or a small number of companies and a particular community. Meanwhile going up the stack is easy, will pay the same or offer higher risk/reward financial choices and let's you work anywhere.
Stop the ridiculous email patching already. It has kept me from contributing and will continue to do so. The infrastructure you have to set up to deal with all the email lists efficiently is just not worth it.
I will gladly invest days in fixing stuff, but if it takes me more than 20 minutes to figure out submitting my code you better pay me for it or it won't happen.
(And no, just because you set up your system 20 years ago and are used to it doesn't mean it is an acceptable system.)
I'm a sponsored maintainer of some other open source project (under a different handle). In my experience, companies rarely sponsor for altruistic purposes. You need to be working on some project that brings value to the company. Where I work we were told to spend 1 hour a week on reviews/maintainence work. Personally, depending on the complexity of the patch it can be impossible to check the correctness of the patch in a one hour timeframe.
TBH with the linux kernel I agree with Linus's interpretation. Email based patching is probably what keeps new contributors away (and you need new contributors to become maintainers...). In my experience you get several types of contributors:
1. Drive-by contributors
2. Regular contributors
Drive by contributors tend to be people who either are students looking to make a name for themselves or people who consume your product for a living. Regular contributors are generally people who are actually paid to work on the software. Drive by contributors may become regular contributors if they use your work regularly. Being on a platform like github significantly lowers the barrier for entry for drive-by contributors. I myself frequently patch downstream oss stuff that we depend on every now and then in a drive-by fashion. I only patch stuff thats on github/gitlab cause setting up a new software for patching is time consuming for me. Additonally the github/gitlab UX for suggesting changes is so much better than the email ux as you can specify exactly what is wrong/disagreeable. CI also is super useful as I don;t actually need to run every test myself when reviewing stuff.