7 ms·

> It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. You don't know that. There is nothin

by sshine 3y ago

> It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. You don't know that. There is nothing wrong with being motivated by getting credit. And there is nothing wrong with fixing FOSS problems you're affected by. The value of FOSS is fixing a problem once for everyone. > this attitude doesn’t qualify for contributor status. Since when was attitude a qualifier for contributor status? Linus Torvalds himself had questionable attitude at times. The simple fact is: He did contribute, he just didn't get credited. How much would a Co-authored-by: ... have hurt for doing all the analysis, even if the patch itself got completely rewritten?

arghwhat 3y ago
> The simple fact is: He did contribute, he just didn't get credited. The credit they deserves is identifying the issue - not for writing a patch that didn't pass the bar (especially on security-report where maintainer gives critical priority, speedy review, extra focus on correctness, etc.). Had this been done on a non-security mailing list, their patch would probably have gotten in after a few iterations. EDIT: The original reporter was credited as "reported-by" in the patch, so removed the section saying there should be a standard for that.
- birdyrooster 3y ago
  If I submit a patch and a maintainer (or anyone else) reads it and writes their own based on it, then they have edited my work. If they don’t attribute me at all, then they are plagiarizing. Maybe there is no law to protect me, but it’s social contract.
  - arghwhat 3y ago
    If it was taken verbatim, sure - while perfectly fine under the license, that would be a dick move. But you should also note that the commit contains an additional essay or two's worth of analysis and justification, and includes test sign-off from other people. Even if you disregard the difference in code, the difference in commits is huge. And as mentioned elsewhere, this issue was submitted to security@, triggering a machine optimized solely for resolving issues quickly and correctly for the safety of the user-base, and not one suited for training new contributors. If this was submitted normally, it's quite likely that this would have gotten merged after an iteration or two - which could easily have taken a week or more.
    - bluGill 3y ago
      Just because the patch was urgent is not an excuse for not giving proper credit. Co-author appears to be the minimum credit.
  - guenthert 3y ago
    There are typically multiple ways to write code to address a given issue. They might differ in aesthetics (including clarity of intend), but also performance, maintainability, extensibility and robustness. It's not uncommon that those who wrote the code to be fixed rewrite the patch in order to improve on aforementioned properties while avoiding lengthy back-and-forth when asking for improvement of the patch. They are often in a better position to do so due to familiarity with the code, it's history and (unwritten) development path. That is by no means plagiarism. If not communicated clearly, can however lead to disappointment of those who submitted the patch. An 'inspired-by' comment would have been nice.
    - fleshdaddy 3y ago
      Yeah it just seems like a bad strategy on the maintainers part. Seems like one of those perfect places to teach a new contributor style guides and make them more useful in the future. To me approaching it this way comes off as disinterest in welcoming new contributors, which maybe now they’re not needed, but being so unwelcoming could one day leave us with no one capable of maintaining these projects.
    - foldr 3y ago
      It is plagiarism by definition if you don’t give credit to the person who wrote the original patch. Paraphrasing a source without citing it is certainly considered plagiarism in non-programming contexts (even if you think that you improved the prose style).
      - jacquesm 3y ago
        A patch, by definition is a modification of an existing piece of code, in this case a very small one. Now, it is possible that copyright protection would apply to such a small piece of code in that context but plagiarism usually does not involve a perfect record (the mailing list where the patch was submitted) that states exactly where the original work was submitted, what was done to it to make it ready for inclusion as well as an admonishment that the patch was not usable because it wasn't properly signed off. Plagiarism means that the kernel maintainer included the code and pretended that it was their original creation and nothing of the sort happened so I don't think that word should be used in this context. Nobody doubts the OP wrote the code, nobody is saying that they did not and nobody passes it off as their own.
  - PH95VuimJjqBqy 3y ago
    The maintainer is responsible for quality and correctness. I don't know the specifics of this patch, but it's absolutely not strange for a maintainer to make changes with these goals in mind. Hell, maintainers are usually more aware of broader concerns than the contributor.
    - Arnavion 3y ago
      I don't know the specifics of the patch either since OP has not linked their patch nor the final kernel commit. I don't understand why being a private list would be a problem since they can just post their patch on their website. Maybe they're waiting for the fix to hit mainline first. But when someone submits a patch to any of my OSS projects and I want to make modifications to it before I merge it, I either keep the original author as the Author and make myself as Co-Authored-By, or make myself the Author and keep the original author as Co-Authored-By, depending on how much change I had to make to the original patch. In either case I also have the original author review my version to get their approval of my version. The only case where I would not credit the original author at all (or only as Reported-By) is if my version had absolutely nothing to do with their patch, say they fixed the symptom in file X and I fixed the cause in file Y. Edit: https://news.ycombinator.com/item?id=37674872 https://news.ycombinator.com/item?id=37674872 found the patches. If it was my project I'd consider these in the Author/Co-Authored-By category because they're basically the same patch.
- light_hue_1 3y ago
  The patch absolutely passed the bar. The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.
  - sdflhasjd 3y ago
    I'd argue the differences are not just style changes and even "just style" changes are not trivial. The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
    - jabradoodle 3y ago
      After he did none of the hard part.
      - sangnoir 3y ago
        I'm sure other people did the "hard part" too for the Row hammer and Heartbleed bugs; which were even harder. All they got was credit in identifying the bugs; kernel-contributor-status is not a prize for doing hard work finding bugs.
        deleted 3y ago
        [deleted]
        jabradoodle 3y ago
        * OP didn't identify the bug, it had been reported years prior. OP identified the root cause and suggested a working fix. * What then is the hard part, if this is the "hard part" * What is kernel contributor status a "prize" for then, if not for contributing to the kernel? * Why all the focus on OP wanting recognition for the work, and 0 on the dev who merged the patch. Why not have all patches be merged by a committe/ someone who isn't the author.
jacquesm 3y ago
> There is nothing wrong with being motivated by getting credit. They did get the credit, just not for the code, and rightly so. If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel, more so if it is posted as a security issue which get special treatment and a whole pile of extra review to make sure that the fix doesn't introduce yet another problem. This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues, clearly some work went into this. But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up, especially if you want to do security work where the details really matter, so props for identifying the issue, but no medal for delivering something that didn't meet the bar for inclusion. And that last bit is where 'kernel contributor' comes in. The whole 'robbed' angle is an interesting one, it appears that there is a much higher perceived value than the one that is normally associated with getting an issue fixed (which is what most people would like to see). Perverse incentives are a thing and it is good to be aware of them. > The value of FOSS is fixing a problem once for everyone. No, the value of FOSS is the ability to read and modify the source code. > Linus Torvalds himself had questionable attitude at times. Whether Linus has had questionable attitude at times is immaterial: clearly he was a contributor and so is credited. This person did not contribute as of now. You see the same with YC and pretty much anything that people would like to have on their resume: the thing itself is less important than the CV mention. > have hurt for doing all the analysis, even if the patch itself got completely rewritten? That there are many more implications for being allowed to call yourself an author. The kernel contributors are doing very important work and their standards for inclusion are high. You don't make it into that circle without adopting their standards.
- disintegore 3y ago
  > They did get the credit, just not for the code, and rightly so. They received credit for reporting the issue, which is a fraction of what they did. They provided the entire solution, full stop. The maintainer only restated it.
layer8 3y ago
> There is nothing wrong with being motivated by getting credit. There is nothing wrong with it, but apparently they were also payed by their employer to do the work in the first place, so I don’t know why their personal motivation should be a major consideration here anyway.
- tremon 3y ago
  Perhaps being a recognized kernel contributor would have given them more leverage in their salary negotiations with their employer?
  - camgunz 3y ago
    Or future employers. All the wrangling about "this guy should be selfless and just be happy he made the world a better place" is bonkers. He lobbied his job to give him time to put in a bunch of highly technical work to improve the kernel. Would it really be so bad to acknowledge him as a contributor? How in the world is his work not a contribution?
    - zarathustreal 3y ago
      """ Solution taken from arch/powerpc/kernel/ptrace32.c --- arch/powerpc/kernel/ptrace/ptrace-fpu.c | 31 +++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) """ You really consider this a contribution? You genuinely want to call someone submitting this a kernel contributor and imply they know anything about the code? I mean, I get the social angle of trying to build each other up and do each other favors but in the long run we're doing more harm than we are good by warping the meaning of the title
      - camgunz 3y ago
        I consider it a great first contribution. Dude took initiative at his job to try to make his and his teammates' lives easier, investigated a super technical issue, found prior art and built on it, sought help on the list, and tried to shepherd it to get it merged. It was significant effort, and he in no way had to do it. He definitely didn't need to upstream it. The amount of energy wasted in this thread on the meaning of "contributor" could boil me water for tea. Bewildering, honestly.
tarsinge 3y ago
> There is nothing wrong with being motivated by getting credit. It's wrong if it's your top priority instead of improving the codebase. And even then not being wrong doesn't mean you are entitled to get it, your motivations are your own.
- flagrant_taco 3y ago
  I'm not sure why intentions would matter here, or how one would compare the value of different intentions. If someone adds value to the codebase and fixes, or helps to fix, a valid bug why should we care why they did it? Sure intentions may indicate the liklihood of the person contributing more in the future, but that's a health metric for the project and unrelated from the contribution itself.
  - zarathustreal 3y ago
    >why should we care why they did it? Because it's important to cultivate the right motivation among contributors. Allowing people with selfish motivations to thrive eventually destroys the project.
    - flagrant_taco 3y ago
      Assuming that you can control who thrives in a project seems like a death nail in and of itself. Contributions should stand on their own, why the person contributed them or who the person is should have no bearing on the FOSS project.
- programmarchy 3y ago
  Recognition of individual contributions is a core component to why Open Source even works in the first place. It would not work if an abstract, utopian ideal of "improving the codebase" was the primary driver. A bug fix contribution may be borne out of necessity, but ultimately codebase improvements are a side effect of the social phenomenon of people being highly motivated to be recognized by their peers. Notoriety is the currency of open source software. And that's a feature, not a bug.
UncleMeat 3y ago
> There is nothing wrong with being motivated by getting credit. While in this case there isn't a big problem, "motivated to commit to OSS projects for credit" causes loads of aggravation in general. Consider the gazillions of "fixed a typo in a comment" PRs that people get from folks trying to pad resumes.
- nikanj 3y ago
  Are you familiar with Hacktoberfest? Every October you get an absolute torrent of crappy PRs from people who saw a youtube video on "How to get a free T-shirt". See https://blog.domenic.me/hacktoberfest/ https://blog.domenic.me/hacktoberfest/
  - UncleMeat 3y ago
    Yes, Hacktoberfest is the most extreme example of this situation.
lfmunoz4 3y ago
> There is nothing wrong with being motivated by getting credit. Nothing wrong is too strong of a statement. Obvious to me, but wonder why not to others that it would be better if someone was motivated by something else other than credit, something like doing good, the challenge of the problem etc. Motivation solely for credit is egotistic and will lead to other problems with team and self-worth etc. We have a name for such people and generally despised, "clout chasers"
hnfong 3y ago
> > It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. > You don't know that. From TFA: > He said (paraphrasing): "Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix." I found this really perplexing and insulting. Instead of getting recognized for fixing the issue, he wanted to give me more work to do.

by sshine 3y ago

arghwhat 3y ago

> The simple fact is: He did contribute, he just didn't get credited. The credit they deserves is identifying the issue - not for writing a patch that didn't pass the bar (especially on security-report where maintainer gives critical priority, speedy review, extra focus on correctness, etc.). Had this been done on a non-security mailing list, their patch would probably have gotten in after a few iterations. EDIT: The original reporter was credited as "reported-by" in the patch, so removed the section saying there should be a standard for that.

birdyrooster 3y ago
If I submit a patch and a maintainer (or anyone else) reads it and writes their own based on it, then they have edited my work. If they don’t attribute me at all, then they are plagiarizing. Maybe there is no law to protect me, but it’s social contract.
- arghwhat 3y ago
  If it was taken verbatim, sure - while perfectly fine under the license, that would be a dick move. But you should also note that the commit contains an additional essay or two's worth of analysis and justification, and includes test sign-off from other people. Even if you disregard the difference in code, the difference in commits is huge. And as mentioned elsewhere, this issue was submitted to security@, triggering a machine optimized solely for resolving issues quickly and correctly for the safety of the user-base, and not one suited for training new contributors. If this was submitted normally, it's quite likely that this would have gotten merged after an iteration or two - which could easily have taken a week or more.
  - bluGill 3y ago
    Just because the patch was urgent is not an excuse for not giving proper credit. Co-author appears to be the minimum credit.
- guenthert 3y ago
  There are typically multiple ways to write code to address a given issue. They might differ in aesthetics (including clarity of intend), but also performance, maintainability, extensibility and robustness. It's not uncommon that those who wrote the code to be fixed rewrite the patch in order to improve on aforementioned properties while avoiding lengthy back-and-forth when asking for improvement of the patch. They are often in a better position to do so due to familiarity with the code, it's history and (unwritten) development path. That is by no means plagiarism. If not communicated clearly, can however lead to disappointment of those who submitted the patch. An 'inspired-by' comment would have been nice.
  - fleshdaddy 3y ago
    Yeah it just seems like a bad strategy on the maintainers part. Seems like one of those perfect places to teach a new contributor style guides and make them more useful in the future. To me approaching it this way comes off as disinterest in welcoming new contributors, which maybe now they’re not needed, but being so unwelcoming could one day leave us with no one capable of maintaining these projects.
  - foldr 3y ago
    It is plagiarism by definition if you don’t give credit to the person who wrote the original patch. Paraphrasing a source without citing it is certainly considered plagiarism in non-programming contexts (even if you think that you improved the prose style).
    - jacquesm 3y ago
      A patch, by definition is a modification of an existing piece of code, in this case a very small one. Now, it is possible that copyright protection would apply to such a small piece of code in that context but plagiarism usually does not involve a perfect record (the mailing list where the patch was submitted) that states exactly where the original work was submitted, what was done to it to make it ready for inclusion as well as an admonishment that the patch was not usable because it wasn't properly signed off. Plagiarism means that the kernel maintainer included the code and pretended that it was their original creation and nothing of the sort happened so I don't think that word should be used in this context. Nobody doubts the OP wrote the code, nobody is saying that they did not and nobody passes it off as their own.
- PH95VuimJjqBqy 3y ago
  The maintainer is responsible for quality and correctness. I don't know the specifics of this patch, but it's absolutely not strange for a maintainer to make changes with these goals in mind. Hell, maintainers are usually more aware of broader concerns than the contributor.
  - Arnavion 3y ago
    I don't know the specifics of the patch either since OP has not linked their patch nor the final kernel commit. I don't understand why being a private list would be a problem since they can just post their patch on their website. Maybe they're waiting for the fix to hit mainline first. But when someone submits a patch to any of my OSS projects and I want to make modifications to it before I merge it, I either keep the original author as the Author and make myself as Co-Authored-By, or make myself the Author and keep the original author as Co-Authored-By, depending on how much change I had to make to the original patch. In either case I also have the original author review my version to get their approval of my version. The only case where I would not credit the original author at all (or only as Reported-By) is if my version had absolutely nothing to do with their patch, say they fixed the symptom in file X and I fixed the cause in file Y. Edit: https://news.ycombinator.com/item?id=37674872 https://news.ycombinator.com/item?id=37674872 found the patches. If it was my project I'd consider these in the Author/Co-Authored-By category because they're basically the same patch.
light_hue_1 3y ago
The patch absolutely passed the bar. The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.
- sdflhasjd 3y ago
  I'd argue the differences are not just style changes and even "just style" changes are not trivial. The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
  - jabradoodle 3y ago
    After he did none of the hard part.
    - sangnoir 3y ago
      I'm sure other people did the "hard part" too for the Row hammer and Heartbleed bugs; which were even harder. All they got was credit in identifying the bugs; kernel-contributor-status is not a prize for doing hard work finding bugs.
      - deleted 3y ago
        [deleted]
      - jabradoodle 3y ago
        * OP didn't identify the bug, it had been reported years prior. OP identified the root cause and suggested a working fix. * What then is the hard part, if this is the "hard part" * What is kernel contributor status a "prize" for then, if not for contributing to the kernel? * Why all the focus on OP wanting recognition for the work, and 0 on the dev who merged the patch. Why not have all patches be merged by a committe/ someone who isn't the author.

jacquesm 3y ago

> There is nothing wrong with being motivated by getting credit. They did get the credit, just not for the code, and rightly so. If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel, more so if it is posted as a security issue which get special treatment and a whole pile of extra review to make sure that the fix doesn't introduce yet another problem. This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues, clearly some work went into this. But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up, especially if you want to do security work where the details really matter, so props for identifying the issue, but no medal for delivering something that didn't meet the bar for inclusion. And that last bit is where 'kernel contributor' comes in. The whole 'robbed' angle is an interesting one, it appears that there is a much higher perceived value than the one that is normally associated with getting an issue fixed (which is what most people would like to see). Perverse incentives are a thing and it is good to be aware of them. > The value of FOSS is fixing a problem once for everyone. No, the value of FOSS is the ability to read and modify the source code. > Linus Torvalds himself had questionable attitude at times. Whether Linus has had questionable attitude at times is immaterial: clearly he was a contributor and so is credited. This person did not contribute as of now. You see the same with YC and pretty much anything that people would like to have on their resume: the thing itself is less important than the CV mention. > have hurt for doing all the analysis, even if the patch itself got completely rewritten? That there are many more implications for being allowed to call yourself an author. The kernel contributors are doing very important work and their standards for inclusion are high. You don't make it into that circle without adopting their standards.

disintegore 3y ago
> They did get the credit, just not for the code, and rightly so. They received credit for reporting the issue, which is a fraction of what they did. They provided the entire solution, full stop. The maintainer only restated it.

layer8 3y ago

> There is nothing wrong with being motivated by getting credit. There is nothing wrong with it, but apparently they were also payed by their employer to do the work in the first place, so I don’t know why their personal motivation should be a major consideration here anyway.

tremon 3y ago
Perhaps being a recognized kernel contributor would have given them more leverage in their salary negotiations with their employer?
- camgunz 3y ago
  Or future employers. All the wrangling about "this guy should be selfless and just be happy he made the world a better place" is bonkers. He lobbied his job to give him time to put in a bunch of highly technical work to improve the kernel. Would it really be so bad to acknowledge him as a contributor? How in the world is his work not a contribution?
  - zarathustreal 3y ago
    """ Solution taken from arch/powerpc/kernel/ptrace32.c --- arch/powerpc/kernel/ptrace/ptrace-fpu.c | 31 +++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) """ You really consider this a contribution? You genuinely want to call someone submitting this a kernel contributor and imply they know anything about the code? I mean, I get the social angle of trying to build each other up and do each other favors but in the long run we're doing more harm than we are good by warping the meaning of the title
    - camgunz 3y ago
      I consider it a great first contribution. Dude took initiative at his job to try to make his and his teammates' lives easier, investigated a super technical issue, found prior art and built on it, sought help on the list, and tried to shepherd it to get it merged. It was significant effort, and he in no way had to do it. He definitely didn't need to upstream it. The amount of energy wasted in this thread on the meaning of "contributor" could boil me water for tea. Bewildering, honestly.

tarsinge 3y ago

> There is nothing wrong with being motivated by getting credit. It's wrong if it's your top priority instead of improving the codebase. And even then not being wrong doesn't mean you are entitled to get it, your motivations are your own.

flagrant_taco 3y ago
I'm not sure why intentions would matter here, or how one would compare the value of different intentions. If someone adds value to the codebase and fixes, or helps to fix, a valid bug why should we care why they did it? Sure intentions may indicate the liklihood of the person contributing more in the future, but that's a health metric for the project and unrelated from the contribution itself.
- zarathustreal 3y ago
  >why should we care why they did it? Because it's important to cultivate the right motivation among contributors. Allowing people with selfish motivations to thrive eventually destroys the project.
  - flagrant_taco 3y ago
    Assuming that you can control who thrives in a project seems like a death nail in and of itself. Contributions should stand on their own, why the person contributed them or who the person is should have no bearing on the FOSS project.
programmarchy 3y ago
Recognition of individual contributions is a core component to why Open Source even works in the first place. It would not work if an abstract, utopian ideal of "improving the codebase" was the primary driver. A bug fix contribution may be borne out of necessity, but ultimately codebase improvements are a side effect of the social phenomenon of people being highly motivated to be recognized by their peers. Notoriety is the currency of open source software. And that's a feature, not a bug.

UncleMeat 3y ago

> There is nothing wrong with being motivated by getting credit. While in this case there isn't a big problem, "motivated to commit to OSS projects for credit" causes loads of aggravation in general. Consider the gazillions of "fixed a typo in a comment" PRs that people get from folks trying to pad resumes.

nikanj 3y ago
Are you familiar with Hacktoberfest? Every October you get an absolute torrent of crappy PRs from people who saw a youtube video on "How to get a free T-shirt". See https://blog.domenic.me/hacktoberfest/ https://blog.domenic.me/hacktoberfest/
- UncleMeat 3y ago
  Yes, Hacktoberfest is the most extreme example of this situation.

lfmunoz4 3y ago

> There is nothing wrong with being motivated by getting credit. Nothing wrong is too strong of a statement. Obvious to me, but wonder why not to others that it would be better if someone was motivated by something else other than credit, something like doing good, the challenge of the problem etc. Motivation solely for credit is egotistic and will lead to other problems with team and self-worth etc. We have a name for such people and generally despised, "clout chasers"

hnfong 3y ago

> > It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. > You don't know that. From TFA: > He said (paraphrasing): "Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix." I found this really perplexing and insulting. Instead of getting recognized for fixing the issue, he wanted to give me more work to do.