5 ms·

> A lot of these maintainers are already overworked and don't have time to tutor every single person that wants to put kernel contributor on their resume. This

> A lot of these maintainers are already overworked and don't have time to tutor every single person that wants to put kernel contributor on their resume. This seems like a very cynical view of what happened here, and completely unfounded. Obviously these big open-source projects need gatekeepers, but if the gatekeepers often make aspiring contributors feel violated and humiliated rather than offering feedback to get their initial contributions across the finish line, general interest and enthusiasm for contributing are going to dry up. Maybe that's by design, but it doesn't feel sustainable in the long term.

fsdjkflsjfsoij 3y ago
> feel violated and humiliated A lot of contributors are going to feel like this if their patch doesn't get accepted immediately and the maintainer in this case was extremely respectful even though the offered patch had multiple major issues. Contributors shouldn't feel entitled to free tutoring.
- caconym_ 3y ago
  > multiple major issues Seems debatable and debated, reading through the rest of this thread. Regardless, I'll reiterate my point more straightforwardly: it's the maintainers' prerogative to treat aspiring contributors however they like, but actions have consequences, and some of those consequences may be deleterious to a project's health.
  - fsdjkflsjfsoij 3y ago
    > Seems debatable and debated, reading through the rest of this thread. Most of the people commenting in this thread haven't looked at the code and anyone saying the two patches are equivalent can be safely ignored. Out of the issues kazinator pointed out, 1 and 2 are definitely major issues and 3 is debatable although it is definitely suboptimal. > some of those consequences may be deleterious to a project's health Of course, but I think it might not be in the way the "everyone can be a valued contributor" crowd thinks.
    - caconym_ 3y ago
      > the "everyone can be a valued contributor" crowd Of course! Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay, if not those whose merit has already been proven?
      - fsdjkflsjfsoij 3y ago
        > Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay This is unironically a very serious problem and why most of the best open source projects are basically corporate FAANG projects that are really only open source for optics.
        caconym_ 3y ago
        On its face, you won't catch me arguing with that. It's a hard problem, for sure.
    - ariel-miculas 3y ago
      See https://news.ycombinator.com/item?id=37692883 https://news.ycombinator.com/item?id=37692883
hnfong 3y ago
It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating. Talking about utilitarian consequences, Linus had been way worse and while I fully agree from a moral perspective that his most extreme behaviors were bad, from a purely utilitarian perspective that didn't prevent Linux from being one of the most successful OSS projects out there.
- caconym_ 3y ago
  > It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating. Isn't this a little bit disingenuous? Do you really think the author of OP's blog post is upset simply because a Linux kernel maintainer has far more domain expertise than him and is in principle capable of writing a "better" patch? That would be pretty irrational, I agree!
  - zassy 3y ago
    The real disingenuous part is where OP lied about the maintainer saying his patch was better. It would be pretty bad if he said that, but he never did.
    - caconym_ 3y ago
      I agree that Miculas (the submitter of the original patch) should not have chosen formatting typically associated with direct quotations, but now you're the one putting words in his mouth: he didn't say Ellerman said his (Ellerman's) version was better, he (Miculas) said Ellerman said he liked his (Ellerman's) version better. Ellerman's actual words were "I wanted to fix it differently", so while I don't think Miculas' paraphrasing was entirely appropriate (why paraphrase at all?), I also don't think it was a misrepresentation of what Ellerman actually said.
- kazinator 3y ago
  Because it could be seen as communicating: "my ten minutes of coding around the array access problem is more perfect than your hours of investigation to root cause the issue plus your ten minutes of coding".
that_guy_iain 3y ago
> This seems like a very cynical view of what happened here, and completely unfounded. It is not unfounded at all. The author clearly stated the reason they wanted their commit to be accepted was should they could be contributor.
- caconym_ 3y ago
  Do you think there is any reason somebody might want to be credited for work they did other than having the ability to put it on their resume?
  - that_guy_iain 3y ago
    He had the credit amongst those who were paying attention. It wasn't like this was done in secret. Others chimed in to agree that the maintainers commit was better. So the only credit he didn't get was a commit credit which is important to be a "Linux Contributor" which clearly explictly wrote was the reason they asked for their commit to be used or to work on another patch. I think it would be odd to disbelieve the author.
    - caconym_ 3y ago
      [flagged]
      - that_guy_iain 3y ago
        [flagged]
        caconym_ 3y ago
        You need to work on your reading comprehension. This will be my last reply to you.
        dang 3y ago
        Personal attacks will get you banned here, regardless of how wrong someone else is or you feel they are. Please don't post like this to HN. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
xw3099 3y ago
> Maybe that's by design, but it doesn't feel sustainable in the long term. That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version... One might also consider the rarity of maintainers who can write high quality code and donate large amounts of time. To find and retain someone like that one might also be required to allow them to be curt with random people on the internet from time to time. I can see how drive by contributions could get old fast from their point of view.
- caconym_ 3y ago
  > That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version... Indeed, and while we're speaking in broad generalities, surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term... > I can see how drive by contributions could get old fast from their point of view. Indeed. But (again addressing generalities) my issue here is that the contribution in question doesn't read as "drive by" to me.
  - xw3099 3y ago
    > surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term... If the rate of submissions falls then it certainly makes sense to adjust. Until then, don't fix what isn't broken.
    - caconym_ 3y ago
      Frankly, if you treat effortful but green contributors the same way you treat grindset morons and LinkedIn jockeys, I would put money on the submission rate from the latter continuing to increase long after most of the former have decided your project isn't worth their time. This is a bit of a moot point, though, since I don't think it's very common for Linux kernel maintainers to behave this way. Correct me if I'm wrong.

fsdjkflsjfsoij 3y ago

> feel violated and humiliated A lot of contributors are going to feel like this if their patch doesn't get accepted immediately and the maintainer in this case was extremely respectful even though the offered patch had multiple major issues. Contributors shouldn't feel entitled to free tutoring.

caconym_ 3y ago
> multiple major issues Seems debatable and debated, reading through the rest of this thread. Regardless, I'll reiterate my point more straightforwardly: it's the maintainers' prerogative to treat aspiring contributors however they like, but actions have consequences, and some of those consequences may be deleterious to a project's health.
- fsdjkflsjfsoij 3y ago
  > Seems debatable and debated, reading through the rest of this thread. Most of the people commenting in this thread haven't looked at the code and anyone saying the two patches are equivalent can be safely ignored. Out of the issues kazinator pointed out, 1 and 2 are definitely major issues and 3 is debatable although it is definitely suboptimal. > some of those consequences may be deleterious to a project's health Of course, but I think it might not be in the way the "everyone can be a valued contributor" crowd thinks.
  - caconym_ 3y ago
    > the "everyone can be a valued contributor" crowd Of course! Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay, if not those whose merit has already been proven?
    - fsdjkflsjfsoij 3y ago
      > Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay This is unironically a very serious problem and why most of the best open source projects are basically corporate FAANG projects that are really only open source for optics.
      - caconym_ 3y ago
        On its face, you won't catch me arguing with that. It's a hard problem, for sure.
  - ariel-miculas 3y ago
    See https://news.ycombinator.com/item?id=37692883 https://news.ycombinator.com/item?id=37692883

hnfong 3y ago

It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating. Talking about utilitarian consequences, Linus had been way worse and while I fully agree from a moral perspective that his most extreme behaviors were bad, from a purely utilitarian perspective that didn't prevent Linux from being one of the most successful OSS projects out there.

caconym_ 3y ago
> It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating. Isn't this a little bit disingenuous? Do you really think the author of OP's blog post is upset simply because a Linux kernel maintainer has far more domain expertise than him and is in principle capable of writing a "better" patch? That would be pretty irrational, I agree!
- zassy 3y ago
  The real disingenuous part is where OP lied about the maintainer saying his patch was better. It would be pretty bad if he said that, but he never did.
  - caconym_ 3y ago
    I agree that Miculas (the submitter of the original patch) should not have chosen formatting typically associated with direct quotations, but now you're the one putting words in his mouth: he didn't say Ellerman said his (Ellerman's) version was better, he (Miculas) said Ellerman said he liked his (Ellerman's) version better. Ellerman's actual words were "I wanted to fix it differently", so while I don't think Miculas' paraphrasing was entirely appropriate (why paraphrase at all?), I also don't think it was a misrepresentation of what Ellerman actually said.
kazinator 3y ago
Because it could be seen as communicating: "my ten minutes of coding around the array access problem is more perfect than your hours of investigation to root cause the issue plus your ten minutes of coding".

that_guy_iain 3y ago

> This seems like a very cynical view of what happened here, and completely unfounded. It is not unfounded at all. The author clearly stated the reason they wanted their commit to be accepted was should they could be contributor.

caconym_ 3y ago
Do you think there is any reason somebody might want to be credited for work they did other than having the ability to put it on their resume?
- that_guy_iain 3y ago
  He had the credit amongst those who were paying attention. It wasn't like this was done in secret. Others chimed in to agree that the maintainers commit was better. So the only credit he didn't get was a commit credit which is important to be a "Linux Contributor" which clearly explictly wrote was the reason they asked for their commit to be used or to work on another patch. I think it would be odd to disbelieve the author.
  - caconym_ 3y ago
    [flagged]
    - that_guy_iain 3y ago
      [flagged]
      - caconym_ 3y ago
        You need to work on your reading comprehension. This will be my last reply to you.
        dang 3y ago
        Personal attacks will get you banned here, regardless of how wrong someone else is or you feel they are. Please don't post like this to HN. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

xw3099 3y ago

> Maybe that's by design, but it doesn't feel sustainable in the long term. That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version... One might also consider the rarity of maintainers who can write high quality code and donate large amounts of time. To find and retain someone like that one might also be required to allow them to be curt with random people on the internet from time to time. I can see how drive by contributions could get old fast from their point of view.

caconym_ 3y ago
> That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version... Indeed, and while we're speaking in broad generalities, surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term... > I can see how drive by contributions could get old fast from their point of view. Indeed. But (again addressing generalities) my issue here is that the contribution in question doesn't read as "drive by" to me.
- xw3099 3y ago
  > surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term... If the rate of submissions falls then it certainly makes sense to adjust. Until then, don't fix what isn't broken.
  - caconym_ 3y ago
    Frankly, if you treat effortful but green contributors the same way you treat grindset morons and LinkedIn jockeys, I would put money on the submission rate from the latter continuing to increase long after most of the former have decided your project isn't worth their time. This is a bit of a moot point, though, since I don't think it's very common for Linux kernel maintainers to behave this way. Correct me if I'm wrong.