5 ms·

> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we kno

by jf 2y ago

> One of the things which gets very frustrating from the maintainer's perspective is development teams that are only interested in their pet feature, and we know, through very bitter experience, that 95+% of the time, once the code is accepted, the engineers which contribute the code will disappear, never to be seen again. This was painful for me to read as someone who has seen how corporations think about “Open Source” - he isn’t wrong at all

Diggsey 2y ago
He's not wrong, but he hasn't addressed the problem: Some maintainers are rejecting changes as a way to block a project they disagree with - ie. there is no path forward for the contributor. I wouldn't assume this normally, but they're not hiding this fact, it's self proclaimed. On the other hand, Linus has been largely in favour of the R4L project, and gave the green light for it to go ahead. The Linux kernel maintainers need to figure out among themselves whether they want to allow Rust to be introduced or not, and if so under what constraints. If they can't come to an agreement, they're wasting everyone's time. Once that happens, either the project is canned, or people can stop arguing over if these changes should be upstreamed, and start arguing over how instead, and that's a lot more productive.
- llm_trw 2y ago
  It's not the maintainers job to make your project happen. It's yours. If you need someone to do free work but you can't convince them then you either get their boss to tell them to do it, you take over their job, or - the one thing that no one under 30 ever seems to do - fork and do the work yourself without anyone stopping you.
  - Diggsey 2y ago
    Noone's asking the maintainers to make the project happen. It is the maintainers job to determine whether a project should be pursued at all. If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer! That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent decision regarding R4L.
    - llm_trw 2y ago
      >Noone's asking the maintainers to make the project happen. If you're asking them to accept your code then yes, you' are asking them to support your project forever. If you weren't sending them patches then they couldn't block you. Since you are they can. Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.
      - jemmyw 2y ago
        Yes but the parent has addressed this and you're just talking past them like they didn't comment. If the maintainers don't want it to happen then they need to come to an agreement that it won't happen. If they do want it to happen then they need to stop blocking it for non-technical reasons. If they can't actually decide then that's "no" or up to the project lead to enforce the decision at the risk of losing maintainers.
        muamoe 2y ago
        Wow, the entitlement here is absolutely amazing. You are not entitled to any work, or explanation, or "agreement". Show me where it says maintainers owe you any of this at all.
        harimau777 2y ago
        I think that being open to working with others is implicit in deciding to maintain a widely used project like Linux. There's tons of open source tools which are explicit "this is something you are free to use but I created it for my own purposes and don't intend to support it"; however, that isn't how Linux presents itself. That is to say, if you are building an tool as a collaborative open source project, then that implies that you intend to collaborate.
        unethical_ban 2y ago
        Basic communication/decisionmaking by the maintainers about a major feature in the kernel is something that I would expect devs to be entitled to.
  - 43920 2y ago
    Reducing this to age is overly simplistic. When Linux was younger and simpler, it may've been easier to fork, but today it's a massive system with huge inertia behind it. Even if you are right in principle regarding your changes, it's extremely hard to overcome that inertia. In the related submission on this topic [1], the author makes this argument in a lot more detail, that it's essentially impossible to make a Linux fork sustainable without massive investment that no one can realistically obtain. [1] https://news.ycombinator.com/item?id=43036904 https://news.ycombinator.com/item?id=43036904
  - liveoneggs 2y ago
    I agree with you completely. If rust is so great why not make a new kernel with it and compete? or fork and start rewriting subsystems? I do also understand the frustration when an open source project strings you along (me: can I join your club?), ask for this and that (them: sure if you pay your dues), ensuring your cover every "important" person's pet use case (them: and also buy us lunch), then publicly snark about the whole thing (them: this new guy know about no mustard on the lunch!) and kill your failing motivation (me: oh, sorry). That's why the fork is so appealing. If it's good enough for long enough you get to join the club.
    - llm_trw 2y ago
      What I don't get is the complaints from the Rust people. If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden. Then they can write every driver they can imagine to their hearts' content. The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.
      - MyOutfitIsVague 2y ago
        The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel. It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
        llm_trw 2y ago
        What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.
        dralley 2y ago
        "if you match upstream" Talk about aggressively missing the point.
- layer8 2y ago
  IIRC Linus has been in favor conditioned on the agreement of the respective subsystem maintainers. Meaning, he’s not deciding over their heads. And introduction of Rust can be handled differently from subsystem to subsystem.
harimau777 2y ago
That doesn't exactly strike me as a bad thing? Isn't that sort of the point of open source? Lots of people working on the things that interest them and through a diversity of interests arriving at a useful project?

by jf 2y ago

Diggsey 2y ago

He's not wrong, but he hasn't addressed the problem: Some maintainers are rejecting changes as a way to block a project they disagree with - ie. there is no path forward for the contributor. I wouldn't assume this normally, but they're not hiding this fact, it's self proclaimed. On the other hand, Linus has been largely in favour of the R4L project, and gave the green light for it to go ahead. The Linux kernel maintainers need to figure out among themselves whether they want to allow Rust to be introduced or not, and if so under what constraints. If they can't come to an agreement, they're wasting everyone's time. Once that happens, either the project is canned, or people can stop arguing over if these changes should be upstreamed, and start arguing over how instead, and that's a lot more productive.

llm_trw 2y ago
It's not the maintainers job to make your project happen. It's yours. If you need someone to do free work but you can't convince them then you either get their boss to tell them to do it, you take over their job, or - the one thing that no one under 30 ever seems to do - fork and do the work yourself without anyone stopping you.
- Diggsey 2y ago
  Noone's asking the maintainers to make the project happen. It is the maintainers job to determine whether a project should be pursued at all. If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer! That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent decision regarding R4L.
  - llm_trw 2y ago
    >Noone's asking the maintainers to make the project happen. If you're asking them to accept your code then yes, you' are asking them to support your project forever. If you weren't sending them patches then they couldn't block you. Since you are they can. Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.
    - jemmyw 2y ago
      Yes but the parent has addressed this and you're just talking past them like they didn't comment. If the maintainers don't want it to happen then they need to come to an agreement that it won't happen. If they do want it to happen then they need to stop blocking it for non-technical reasons. If they can't actually decide then that's "no" or up to the project lead to enforce the decision at the risk of losing maintainers.
      - muamoe 2y ago
        Wow, the entitlement here is absolutely amazing. You are not entitled to any work, or explanation, or "agreement". Show me where it says maintainers owe you any of this at all.
        harimau777 2y ago
        I think that being open to working with others is implicit in deciding to maintain a widely used project like Linux. There's tons of open source tools which are explicit "this is something you are free to use but I created it for my own purposes and don't intend to support it"; however, that isn't how Linux presents itself. That is to say, if you are building an tool as a collaborative open source project, then that implies that you intend to collaborate.
        unethical_ban 2y ago
        Basic communication/decisionmaking by the maintainers about a major feature in the kernel is something that I would expect devs to be entitled to.
- 43920 2y ago
  Reducing this to age is overly simplistic. When Linux was younger and simpler, it may've been easier to fork, but today it's a massive system with huge inertia behind it. Even if you are right in principle regarding your changes, it's extremely hard to overcome that inertia. In the related submission on this topic [1], the author makes this argument in a lot more detail, that it's essentially impossible to make a Linux fork sustainable without massive investment that no one can realistically obtain. [1] https://news.ycombinator.com/item?id=43036904 https://news.ycombinator.com/item?id=43036904
- liveoneggs 2y ago
  I agree with you completely. If rust is so great why not make a new kernel with it and compete? or fork and start rewriting subsystems? I do also understand the frustration when an open source project strings you along (me: can I join your club?), ask for this and that (them: sure if you pay your dues), ensuring your cover every "important" person's pet use case (them: and also buy us lunch), then publicly snark about the whole thing (them: this new guy know about no mustard on the lunch!) and kill your failing motivation (me: oh, sorry). That's why the fork is so appealing. If it's good enough for long enough you get to join the club.
  - llm_trw 2y ago
    What I don't get is the complaints from the Rust people. If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden. Then they can write every driver they can imagine to their hearts' content. The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.
    - MyOutfitIsVague 2y ago
      The problem is that they might want their drivers to actually work on people's existing Linux systems without having to force them to use a forked kernel. It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
      - llm_trw 2y ago
        What extra effort? If you match upstream it's a drop in replacement and anyone who cares will use it. If they don't it's because they don't care.
        dralley 2y ago
        "if you match upstream" Talk about aggressively missing the point.
layer8 2y ago
IIRC Linus has been in favor conditioned on the agreement of the respective subsystem maintainers. Meaning, he’s not deciding over their heads. And introduction of Rust can be handled differently from subsystem to subsystem.

harimau777 2y ago

That doesn't exactly strike me as a bad thing? Isn't that sort of the point of open source? Lots of people working on the things that interest them and through a diversity of interests arriving at a useful project?