6 ms·

What's the solution to such high bus factors in Linux drivers? How do we encourage more devs to contribute?

trelane 2y ago
Buying hardware (laptops and peripherals) from vendors that explicitly support Linux would probably be a good first step for many folks.
- lolinder 2y ago
  That would help people use Linux, but I'm not sure it would make a difference in maintainer bus factor. If I only buy hardware from vendors that already have Linux support then my driver needs are presumably met for me, no? I'm unlikely to write drivers for hardware I don't even own.
  - trelane 2y ago
    > I'm not sure it would make a difference in maintainer bus factor 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.
    - deleted 2y ago
      [deleted]
  - diggan 2y ago
    > That would help people use Linux, but I'm not sure it would make a difference in maintainer bus factor 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.
janice1999 2y ago
The Linux Foundation using money from their sponsors to pay more full time developers.
- betaby 2y ago
  Not going to happen. Linux as in 'The Linux Foundation' as a corporation doesn't care. Read the report to see yourself https://www.linuxfoundation.org/hubfs/Reports/lf_ar24_121524a.pdf?hsLang=en https://www.linuxfoundation.org/hubfs/Reports/lf_ar24_121524... ... and realize how sad the thing are. The Linux kernel expenses are minuscule compared with the 'various'.
  - aeve890 2y ago
    Wow you weren't joking. ~7MM out of ~300MM.
baq 2y ago
At this point it’s probably WSL2 only, which is sad. A few government grants for open source hardware and drivers would help, but it goes without saying it isn’t happening at this time.
- jen20 2y ago
  The EU are far more likely to step up here than anyone else.
eviks 2y ago
Among many other things, one could start by doing less to discourage more devs from contributing https://news.ycombinator.com/item?id=41387924 https://news.ycombinator.com/item?id=41387924
- ImPostingOnHN 2y ago
  I don't see any comments by FirmwareBurner at your link, much less ones "discouraging more devs from contributing". Am I missing something?
  - eviks 2y ago
    Yes, you are missing the non-personalized meaning of "you"
    - ImPostingOnHN 2y ago
      You mistakenly said "you" instead of "we", so you'll understand the confusion. 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!
      - eviks 2y ago
        It's not a mistake, I'm not Linus & co, so there is no, as they say, I in "we". And you're also mistaken about applying the same implication semantics to semantically different words.
        ImPostingOnHN 2y ago
        If you're using the term "Linus & co" to refer to people who are discouraging devs from contributing, then FirmwareBurner is not "Linus & co" either, yet you included them in your accusation, saying FirmwareBurner was among those discouraging devs from contributing. 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).
mschuster91 2y ago
> How do we encourage more devs to contribute? 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.
- jamwaffles 2y ago
  Completely agree. I'd be tempted to put up some Rust code if the contribution pipeline wasn't such utter crap (yes yes it was good for it's time, but that was decades ago). 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.
  - diggan 2y ago
    > if the contribution pipeline wasn't such utter crap 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).
    - 2y ago
Retr0id 2y ago
I, for one, find the email-based workflow pretty intimidating. 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)
- aloisdg 2y ago
  forgejo is quite nice nowadays
- dartos 2y ago
  I’m pretty sure that’s intentional. Your OS kernel is NOT a code base where you want a lot of people making “drive-by PRs”
  - Retr0id 2y ago
    It is intentional, and I think it's a mistake. Plenty of changes aren't suitable for drive-by contributions, but many are.
    - epcoa 2y ago
      I’ve done dozens of what might be considered “drive by PRs” over the decades (hardly a regular). It’s attaching a patch to an email after finding the correct list (that might be the hardest part). It’s hard to accept the process itself is much more onerous than a forge. Regardless of venue, in every high profile project there are particular idioms and procedures that must be learned and followed. Few outside of side projects truly want totally "drive-by" contributions with no regards to the project standards, even if they're hosted on github. On the other hand the lk process might be less marketed - but there have been sites like kernelnewbies for decades as well. 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.
  - Palomides 2y ago

Buying hardware (laptops and peripherals) from vendors that explicitly support Linux would probably be a good first step for many folks.

lolinder 2y ago
That would help people use Linux, but I'm not sure it would make a difference in maintainer bus factor. If I only buy hardware from vendors that already have Linux support then my driver needs are presumably met for me, no? I'm unlikely to write drivers for hardware I don't even own.
- trelane 2y ago
  > I'm not sure it would make a difference in maintainer bus factor 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.
  - deleted 2y ago
    [deleted]
- diggan 2y ago
  > That would help people use Linux, but I'm not sure it would make a difference in maintainer bus factor 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.

janice1999 2y ago

The Linux Foundation using money from their sponsors to pay more full time developers.

betaby 2y ago
Not going to happen. Linux as in 'The Linux Foundation' as a corporation doesn't care. Read the report to see yourself https://www.linuxfoundation.org/hubfs/Reports/lf_ar24_121524a.pdf?hsLang=en https://www.linuxfoundation.org/hubfs/Reports/lf_ar24_121524... ... and realize how sad the thing are. The Linux kernel expenses are minuscule compared with the 'various'.
- aeve890 2y ago
  Wow you weren't joking. ~7MM out of ~300MM.

baq 2y ago

At this point it’s probably WSL2 only, which is sad. A few government grants for open source hardware and drivers would help, but it goes without saying it isn’t happening at this time.

jen20 2y ago
The EU are far more likely to step up here than anyone else.

eviks 2y ago

Among many other things, one could start by doing less to discourage more devs from contributing https://news.ycombinator.com/item?id=41387924 https://news.ycombinator.com/item?id=41387924

ImPostingOnHN 2y ago
I don't see any comments by FirmwareBurner at your link, much less ones "discouraging more devs from contributing". Am I missing something?
- eviks 2y ago
  Yes, you are missing the non-personalized meaning of "you"
  - ImPostingOnHN 2y ago
    You mistakenly said "you" instead of "we", so you'll understand the confusion. 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!
    - eviks 2y ago
      It's not a mistake, I'm not Linus & co, so there is no, as they say, I in "we". And you're also mistaken about applying the same implication semantics to semantically different words.
      - ImPostingOnHN 2y ago
        If you're using the term "Linus & co" to refer to people who are discouraging devs from contributing, then FirmwareBurner is not "Linus & co" either, yet you included them in your accusation, saying FirmwareBurner was among those discouraging devs from contributing. 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).

mschuster91 2y ago

> How do we encourage more devs to contribute? 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.

jamwaffles 2y ago
Completely agree. I'd be tempted to put up some Rust code if the contribution pipeline wasn't such utter crap (yes yes it was good for it's time, but that was decades ago). 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.
- diggan 2y ago
  > if the contribution pipeline wasn't such utter crap 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).
  - 2y ago

Retr0id 2y ago

I, for one, find the email-based workflow pretty intimidating. 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)

aloisdg 2y ago
forgejo is quite nice nowadays
dartos 2y ago
I’m pretty sure that’s intentional. Your OS kernel is NOT a code base where you want a lot of people making “drive-by PRs”
- Retr0id 2y ago
  It is intentional, and I think it's a mistake. Plenty of changes aren't suitable for drive-by contributions, but many are.
  - epcoa 2y ago
    I’ve done dozens of what might be considered “drive by PRs” over the decades (hardly a regular). It’s attaching a patch to an email after finding the correct list (that might be the hardest part). It’s hard to accept the process itself is much more onerous than a forge. Regardless of venue, in every high profile project there are particular idioms and procedures that must be learned and followed. Few outside of side projects truly want totally "drive-by" contributions with no regards to the project standards, even if they're hosted on github. On the other hand the lk process might be less marketed - but there have been sites like kernelnewbies for decades as well. 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.
- Palomides 2y ago