Reducing Kernel-Maintainer Burnout
lwn.netBig tech wouldn't exist without Linux. Why aren't they forced to contribute?
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.
Big tech would be using BSD instead if the lawsuit had been clarified before GNU/Linux took off.
How much did UNIX vendors, Apple, Sony and co have contributed to BSDs?
But now that they are heavily invested in Linux, it would be a good time to make them contribute.
I mean isn't this the exact same tactic they use with their as-a-service offerings all the time?
The preference for non-copyleft licenses and SaaS kind of makes their point.
It is no surprise that none of new FOSS OSes for IoT use the GPL, including Zephyr, ironically hosted by the Linux Foundation.
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.)
Presumably there are companies who sponsor the full-time work of the maintainers, is that insufficient to attract new/more maintainers?
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.