What's the solution to such high bus factors in Linux drivers? How do we encourage more devs to contribute?
... and realize how sad the thing are. The Linux kernel expenses are minuscule compared with the 'various'.
If they want to ship working hardware, it would help for sure.
> I'm unlikely to write drivers for hardware I don't even own.
Oh, I see. You're assuming the users will write the driver. See, the point of this proposal is that the vendors should write the drivers and kernel infrastructure.
You know what's harder than writing a driver? Writing a driver for hardware that you don't have documentation or chip/board vendor support for because you're some random person instead of their direct customer and potential revenue stream.
Another perspective is that every maintainer of Linux drivers starts as a Linux user, so driving up Linux users will indirectly lead to more maintainers eventually, even if only a small bump.
Then if a Linux user starts out with a computer that is 100% Linux-compatible, they might at one point switch out the RAM or GPU or whatever to a new component, find it isn't compatible/as compatible and armed with their new knowledge, might attempt to contribute to existing driver/write a driver for it.
By allowing more accessible and higher-quality tooling than email threads. It's amazing that the development workflow has chugged on for so long, but most people (outside of finance, here be dragons) work with modern tools in their day jobs... they're not gonna take their time and try to work with the limitations of arcane processes. Unfortunately, the "old guard" is firmly entrenched and has zero interest in moving with the times. Just look at the recent Rust/Apple SoC support drama.
In the end it's conflicting viewpoints and, let's be frank, a lack of money - the Linux kernel maintainers are overworked as it is, and each new piece of less-than-perfect code is likely to cause the maintainers a ton of work. More money would at least IMHO allow for getting new drivers up to speed.
But I won't be putting up any code either way until the culture moves on from little kings calling things they don't like (and that don't really affect them) "cancer". I'm not holding my breath.
I've started wondering what's next after Linux because it doesn't feel sustainable long term any more. There's a small trickle of fresh blood but not enough to keep the kernel project healthy IMO.
I think the filter they have is working as intended, as demonstrated by this sentence. I'd agree the pipeline isn't the best, but it's not crap either, it evidently worked decades ago, and it also evidently works today, even though you seem to think it doesn't.
So in this case, they'd probably prefer contributors that can see the good and bad parts of a process, instead of a knee-jerk reaction to it calling it "crap", and prefer those contributors to be more amendable to existing workflows than many seem to want to be, as they've found their workflow to work (even if they aren't perfect).
Given that the arcane state of tooling around the Linux kernel is a constant complaint in any "why do you not want to work on the Linux kernel" thread, the process evidently does not work, for it excludes many MANY MANY people from working on the Linux kernel.
At the moment, the kernel development process is mostly gatekeeping to keep moderation effort at bay - anyone running any major FOSS project on Github is all too aware of that - but in the end IMHO they're throwing the baby out with the bathwater, and by the time the lack of new people becomes too evident to ignore it will be too late.
If I encounter a minor issue in most pieces of software, I can submit a drive-by github PR in minutes. I wouldn't know where to start with Linux, and the "activation energy" is just too high for me to bother. (I'm not saying they should use GitHub specifically, but some kind of git forge with a web UI would be great)
Your OS kernel is NOT a code base where you want a lot of people making “drive-by PRs”
Plenty of changes aren't suitable for drive-by contributions, but many are.
Where the process really looks different to me is for large, extensive work, not the drive bys. Whether it should change is another debate, but I think the intentionality of gatekeeping narrative via process is oversold.
with a such a hostile pipeline, it's no surprise there aren't more kernel devs
A few government grants for open source hardware and drivers would help, but it goes without saying it isn’t happening at this time.
Am I missing something?
Using "you", personalized or not, implies that the person you're speaking to is one of the ones doing the action.
If the person you're speaking to isn't doing the action, "you" is inappropriate in that context, but "we" is appropriate because we're all on team human at least (you included).
To illustrate this point, I'm not the only one running into your confusing wording and replying to you about it here.
edit: "you" was edited to "one", which makes more sense to me at least, thanks for responding to feedback positively!
And you're also mistaken about applying the same implication semantics to semantically different words.
If there is no "I" in the people you're accusing of wrongdoing, then there is no FirmwareBurner in it, either. That's the mistake. It's the one you fixed.
When you're referring to a group of people, "you" is only appropriate to use when the person you're speaking to is a member of that group. I don't see any group here, of which they're a member and you aren't.
But hey, on the plus side, we're all in the same group when it comes to being human, so "we" is totally fine, too (I personally prefer language that brings us together).