14 ms·

I can’t empathise with the author. It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. > in

I can’t empathise with the author. It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. > instead he implemented his own version of the fix. I told him that I would really appreciate if he could accept a patch from me, so that I could receive credit for fixing this issue and become a kernel contributor. In other words, you asked a maintainer to accept an inferior fix just so you can put “kernel contributor” on your resume. > My company and I should have received proper credit for solving this issue, especially considering how much effort we put into it. No one asked you to do this. You aren’t owed anything when you do an unasked favour for someone else. Also, the only reason you put so much effort into this was to fix your own problem. Which, from my understanding, is now fixed. You seem to have no interest in fixing other problems (which you were given an opportunity to do). IMHO this attitude doesn’t qualify for contributor status.

ironmagma 3y ago
> a) they get credit I think this is the least we can do for people who contribute to OSS. Add to that that "contributing" could be as much as commenting on an issue. It's basically zero-cost and encourages help.
joshuaissac 3y ago
> You seem to have no interest in fixing other problems (which you were given an opportunity to do). Based on what happened the first time, fixing other problems may have led to the same outcome again.
- deleted 3y ago
  [deleted]
- shortcake27 3y ago
  If someone is more interested in receiving credit than fixing bugs, OSS might not be the best place to hang out.
  - bakugo 3y ago
    I'm sure the OSS ecosystem would be better for everyone if every project started removing the names of contributors from the commit log and replacing them all with the name of the primary maintainer. Everyone loves it when they dedicate time out of their life to improving something and it ends up under someone else's name, after all.
    - JodieBenitez 3y ago
      Yeah, it's baffling to me how many people here have little consideration for the recognition of work. I sincerely hope these people never ever attempt a management career.
      - cp9 3y ago
        this thread is *wild*, everyone is jumping down the OPs throat for the crime of doing a ton of work while receiving zero credit for it and having the gall to be upset about it
        jacquesm 3y ago
        He did a ton of work and got credited for it. The four line patch isn't a ton of work once you've done the RCA and besides it required work by the maintainer to get it to pass. And he changed the essence of the interaction with the maintainer, who isn't going to hang around to teach a newcomer how to properly submit a patch in a cycle of back-and-forths (of which there were already plenty) in a security issue.
        cp9 3y ago
        > The four line patch isn't a ton of work once you've done the RCA and besides it required work by the maintainer to get it to pass the debugging *is* the work! the work for which he went uncredited, that's the crux of the whole thing. he got a Reported-By which just means he ran into a bug and told someone about it, not that he root caused it, wrote a patch and bothered to submit it.
rootlocus 3y ago
> In other words, you asked a maintainer to accept an inferior fix just so you can put “kernel contributor” on your resume. He asked to accept "a patch" not "the patch". You left out the next sentence: "I was also open to working with him, addressing his feedback and sending subsequent versions of patches."
- arghwhat 3y ago
  The thing is, working with the contributor to guide them to write a specific patch entirely different from what they did is a lot of work, and quite frankly really awkward for both parties. And at that point, it is no longer the contributors patch. The maintainer authored it in its entirety, and the contributor slapped their name on it. It should also be noted that by sending to security@, you trigger a machine optimized for getting fix merged fast to protect the user base - not one optimized for teaching new contributors.
  - darkwater 3y ago
    > It should also be noted that by sending to security@, you trigger a machine optimized for getting fix merged fast to protect the user base - not one optimized for teaching new contributors. This is the crux of the issue, and that generated a mismatch of expectations vs reality. If it went through LKML I'm pretty sure someone would have guided him to have a patch accepted and fully authored by OP. As an external observer, however, I empathize and sympathize with OP.
  - throeaaysn 3y ago
    [dead]
  - jacquesm 3y ago
    This is exactly the problem. By doing this with a security issue you are essentially going to have to be happy to see the problem fixed, regardless of whether or not it has your name on it because the maintainer has more to do than to tutor you until you 'get it right'. There are other more suitable venues for this.
justinclift 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. Even if that's the case, aren't those supposed to be "ok" motivations? A lot of the point of giving people credit is to encourage further contributions. And people only fixing problems that affect them is a very common starting point for people becoming contributors.
- cutemonster 3y ago
  Definitely OK motivations. From what I've read, the majority of kernel contributors get paid by their employers, that is, they fix things that affect them. And, I'm guessing that getting credited for their work is important to them too, for career reasons if nothing else.
- shortcake27 3y ago
  My point (which I didn’t convey properly) is that the combination of the two isn’t all that productive, ie “I’ll only work on problems that affect me and only if you give me credit”. I get that true altruism probably doesn’t exist, but I’ve contributed to dozens of projects where I haven’t received credit, and I didn’t care because I helped fix problems that affected thousands of people, which I felt was more important than whatever label was placed on me (or not).
  - alexsmarsh 3y ago
    [flagged]
  - justinclift 3y ago
    > I’ve contributed to dozens of projects where I haven’t received credit, and I didn’t care because ... This seems a bit weird to me. Not the contribution-without-credit thing on your part, but the trying to denigrate the article authors contribution because their motivations were different from yours. Even though their motivations were just as valid as yours. :)
  - emerongi 3y ago
    It seems it was quite productive, no? An important bug was fixed. Next time, it probably won't. Which may very well be a fine trade-off if giving credit is a lot of work that nobody wants to do - just expect less contributions with that approach.
orra 3y ago
> It seems like they’re only interested in OSS when a) they get credit That's incredibly reasonable. Not crediting them is plagiarism. Moreover, even most permissive open source licenses require attribution.
- lamontcg 3y ago
  > Not crediting them is plagiarism. not if it is a substantially different fix.
  - orra 3y ago
    Making changes for the sake of it doesn't stop plagiarism being plagiarism. More charitably, “substantially different” is not a high enough bar when you literally just read the other author's patch. Besides, even if your method is genuinely original, it's only fair to credit the work you're building on. If you're writing an academic paper and come up with a whole new mathematical approach algorithm, you still reference the previous best algorithm.
    - lamontcg 3y ago
      > More charitably, “substantially different” is not a high enough bar when you literally just read the other author's patch. Yeah it really is. If they rejected the approach and rewrote it from scratch that is sufficient. Doing a cleanroom reimplmentation with someone who had never seen the original patch is a good affirmative defense to protect against all possible lawsuits, but it isn't required. > If you're writing an academic paper and come up with a whole new mathematical approach algorithm, you still reference the previous best algorithm. This isn't an academic paper, and the proposed fix wasn't published, and it sounds like the maintainer thought the proposed algorithm was "poor" not "previous best". You can consider it "rude" but under no circumstances is this illegal in any way.
korijn 3y ago
I want to add that the author's attitude can be considered prohibitive to their professional and personal growth. They are taking quite a strong position (blogging about it emphasizes how much this matters to them) which could have the unintended side effect of discouraging peers and managers from honestly giving them feedback on the situation. Edit: I've reworded this to be less black and white. The down-voting here does exemplify the argument that negative feedback is not appreciated.
- hmottestad 3y ago
  Are you sure that it prohibits their professional and personal growth? It seems like a rather significant thing to state based on a single blog post. Do you know this person from before?
  - korijn 3y ago
    Fair enough. I've attempted to reword this to be more considerate of the possibilities.
  - catiopatio 3y ago
    As a long-time OSS contributor and an active maintainer on a different OSS operating system, I can definitively state that the answer is: yes, it’s absolutely limiting. They received a reported-by credit, which was more than sufficient — especially on a tiny patch that got rewritten. The important work was identifying and reporting the issue, and they got credit for that. By turning around and writing an angry blog post, they turned a non-issue into some seriously unpleasant drama. Nobody is going to particularly want to deal with them again.
  - jacquesm 3y ago
    This patch is miniscule, and does not deserve 'Kernel contributor' status, which seems to be what the OP is after, and which I don't think is warranted for this sort of thing.
    - hmottestad 3y ago
ghosty141 3y ago
> you asked a maintainer to accept an inferior fix Why is the fix by the author inferior? By all we know it could even be better. Not taking sides, just pointing out that your response seems kinda biased against the author. > Also, the only reason you put so much effort into this was to fix your own problem Isn't this the case with most problems? Fix the problems that impact you first, then other ones. That's completely normal.
- sshine 3y ago
  > Why is the fix by the author inferior? It very often happens in FOSS that a contribution is well-intentioned, but doesn't match all qualities of the project, and asking them to fix it vs. rewriting wastes a lot of time. I've seen this pattern several times before: First-time contributor delivers patch, reviewer thinks "The idea is great, but it's faster if I just rewrite it rather than give feedback." Consequence is, first-time contributor will not contribute to this project again. FOSS maintainers can learn some pedagogy here. I tried having a patch rejected only to see the maintainer rewrite my patch that introduced bugs.
  - derangedHorse 3y ago
    That's a stupid approach to maintaining a project. A maintainer should want to make their project the best it can be, and the best way to do that is encouraging contributors to keep contributing. If they can't do that, their work deserves to die and yield way for better managed repos/forks. I have a similar experience with a bug fix I submitted and the decision to delay my fix to literally change the whole architecture of the project left a bad taste in my mouth. After that I stopped contributing to the project and just kept my fixes to myself. It's especially annoying when the maintainer asks for help and pulls this. Architecture changes after proposing small fixes to projects has been a somewhat common occurrence for me.
    - catiopatio 3y ago
      Linux seems to be doing just fine. Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially. Regardless, this individual received a reported-by credit. That’s more than adequate.
yosef123 3y ago
It doesn't matter what the intent behind the fix is, even if it is 100% for personal gain. In my opinion, it should be treated fairly, like any other commit and given credit where credit is due.
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.
bayindirh 3y ago
Unless you have copious amounts of free time, you can only fix the problems affecting you in your day job, and contribute them back. The developer could have accepted that allegedly inferior fix, give the credit, and patch it with their own version in a single commit. I'd have done that, for example, all the while trying to communicate with the submitter of the patch about my intentions. Maybe he wanted the badge for his own honor, not to put it anywhere else. Some people are into that kind of thing, and he fixed a legitimate problem of his to earn this. I can understand them and respect them for that. > No one asked you to do this. Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion. > You seem to have no interest in fixing other problems (which you were given an opportunity to do) As I aforementioned, you need time to do this. It's not given that the author has free time to work on any problems they deem worthy. I'd love to fix tons of bugs, mine or not, but I can't do that because lack of time. Heck, I can't find an hour to finish implementing my own projects. How do we know that he has the whole day to do the research and fix other bugs?
- shortcake27 3y ago
  > Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion. Why is it not open for discussion? I can’t just fill in a pothole or cut my neighbours grass and expect credit and/or compensation. OSS isn’t common property. You can’t just do whatever you want and expect to receive credit. Yeah, their work needed a fix and they got a fix. That’s already a better than average outcome.
  - bayindirh 3y ago
    Free software is common property. This the rule 0. It's everyone's. This is why four freedoms exist, and The Kernel is GPLv2. i.e. Free Software. Compensation and credit are completely different things. Credit is not compensation. It's an answer to question "Who did this?". He didn't do whatever he want. He was experiencing a problem, he traced, researched it, debugged it, fixed it, and submitted a patch to The Kernel. If that was only something "whatever he wanted", the patch would be shot down. The bug is accepted/confirmed on The Kernel side, his patch is being reviewed and deemed "stylistically unacceptable", the reviewer/maintainer wrote his own version, and by pushing the fix w/o attributing him, he effectively claimed that he did all the work from discovery to patching, incl. everything in between. The maintainer didn't have to accept the patch per se. He could have just written "This bug is discovered, dissected and fixed by $THE_PERSON. Patch is implemented and committed by me. Thanks a lot, $THE_PERSON!". This is basic human decency. I have my name on many bug reports, either reporting them, or providing more information leading to solution of the bug. I have a couple of patches here and there, and I experienced something similar from another prominent project people interact with every day, but I said that "mneh, whatever". The author certainly didn't because the treatment he got is really bad, and good for him publicizing this, because these kind of people needs to be known. Well, there might be miscommunication and the story can be completely different, but starting the discussion from somewhere is healthy.
DSingularity 3y ago
If you can’t empathize that says a lot about you. At the very least the maintainer could have modified the submitted patch and thus granted co-authorship to the submitter. Who knows — maybe the maintainer is a narcissist who couldn’t accept patches for his own broken code.
- yencabulator 3y ago
  There was no Signed-off-by in the initial submission, using that code was literally not allowed. https://kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by https://kernel.org/doc/html/latest/process/submitting-patche...
armada651 3y ago
Proper attribution is actually important though from a licensing standpoint. Contributors publish their patches under the GPL, but they retain the copyright. If an OSS project ever needs to change the license they will need to seek permission from each contributor. You can't relicense a project if you have some code that's submitted without proper attribution to the actual copyright holder.
- yencabulator 3y ago
  The original patch, as submitted to the security email address, was not acceptable for use in the Linux kernel, as it was missing a Signed-off-by: line. The maintainer had written their own patch by the time the blog post author got around to sending their next email.
  - ariel-miculas 3y ago
    This is not true. I've sent subsequent patches to the PowerPC maintainer in private, there was no practical reason why he couldn't work with me instead of implementing his own version.
    - yencabulator 3y ago
      Someone said elsewhere on this forum that the time of the maintainer's commit is before any subsequent email from you. security@ is a fix-ASAP forum.
throwaw12 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. (a) so why it is okay for companies to sponsor events and use it as a marketing, but not okay for people doing same? (b) what's wrong if people want to help fixing problems when they get impacted? isn't it good that they are not demanding someone else to fix, but giving a help?
- shortcake27 3y ago
  The problem is the combination of the two. Ie, “I’ll only contribute on problems that affect me personally and then only if I get credit”. I’m not convinced this mentality is productive in the OSS community.
  - rand_r 3y ago
    Based on what? Discounting credit as motivation is a bit naive and motivation is the only way shit gets done.
praash 3y ago
It's as if people have work to do and can only spend their paid time in OSS fixing problems blocking their work. Having done all the debugging work and figuring out a way to fix it, it's a bit nasty of the maintainer to make a "better version" of it and rudely tell them to be "more useful. Basically it's the same as accepting the contribution and refactoring it afterwards. If the author "only wanted Linux street creds", without the context of a problem, they could have searched for an easy issue to fix and contribute on that. No, wait, now you'd consider that an act of selfless OSS contribution, fixing random problems not related to you!
throeaaysn 3y ago
[dead]
JodieBenitez 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. So what ? These are two perfectly valid motivations. The only thing that matters really is that in the end it benefits everyone.
deleted 3y ago
[deleted]
VagabundoP 3y ago
Nothing wrong with those motivations at all. The maintainer should be fostering new contributors who are doing all this work, who cares if they just want the label. Is the work good or not is all that matters. And, if getting your code into the Kernel is the only way you get that label then that's a shit system, all the testing and writing solutions "contributes" to the final code, its like the 90% you don't ever see.
derangedHorse 3y ago
Contributing for credit and fixing problems that affect them is what most of open source is about. Why would you ever want your hard work credited to someone else when it could benefit you? Sorry shortcake27, this is just a bad take lol
FrustratedMonky 3y ago
LOL. What is wrong with those reasons? Everybody does this: 1. Yes, I'd like some credit and status. -- Every human ever. 2. I have a problem, I would like to fix it -- Every programmer with a problem.
glitchc 3y ago
Sorry, you're way off base, in particular with the especially snarky last paragraph. If the effort up to the point of the patch was used, then the effort has value and an acknowledgement is necessary. Taking the work without attribution is tantamount to plaigiarism. Could you tell us which open source projects are yours so that we, as a community, can avoid contributing to them? We don't want to support this type of behaviour.
- shortcake27 3y ago
  [flagged]
- dang 3y ago
  Please don't cross into personal attack. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - glitchc 3y ago
    Sorry about that, dang.
    - dang 3y ago
      Thanks. It happens and we're all subject to these forces - that's why they're hard to manage. It's too much to expect that they won't sneak in unintentionally. The main thing is to re-read one's comments after posting them and then edit out anything you notice that breaks the site guidelines. It's much easier to notice these things after posting them. That's my experience anyhow, and it's why https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html includes the phrase "edit out". One tip, in case helpful: you can set 'delay' in your profile to give you time (up to 10 minutes) to look over and edit your posts before others see them.
nailer 3y ago
> It seems like they’re only interested in OSS when a) they get credit I have code in your OS, node and maybe your web framework. I am *absolutely* only interested in OSS when I get credit. Why would I remain interested in contributing if someone else takes credit?
- shortcake27 3y ago
  This has been one of the most polarising conversations I’ve been a part of on HN. Your comment made me think. I’ll preface this with an I also have code in your favourite web framework. There are many people like myself who don’t care about attribution, and don’t understand people who care more about attribution than the project itself. Then there are just as many people like you, who are only interested in contributing as long as credit is given. And you seem just as equally unable to empathise with my position. And I feel like this is causing such a heated environment, because neither of these groups are seeing eye to eye. Just a thought.
  - nailer 3y ago
    Tone is hard to read on the internet, but I'm not heated and I don't mind that you feel differently. > Then there are just as many people like you, who are only interested in contributing as long as credit is given. The "as long as credit is given" reads oddly to me. Attribution, for me is basically table stakes. Score of zero. I contribute, my contributions are attributed to me. I think you think of credit as a reward, but it's not. It's just decency to me. Someone taking credit, enjoying the fruits of my work, but not enough to attribute them to me, is minus one. It's not that I'm not being rewarded, but rather that I'm being stolen from.
ranting-moth 3y ago
[flagged]
phendrenad2 3y ago
> only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. This is why kernel maintenance should be left to companies like Google, Microsoft, and IBM. They don't care if they get credit and they put serious efforts toward problems that don't affect them.
unethical_ban 3y ago
>I can’t empathise with the author. It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. Most people want credit for their work. People enjoy recognition for the things they do, though not all people crave it. As for part b), isn't that exactly the attitude encouraged in snide style by OSS advocates whenever someone complains about the function or quality of an open source project? "If you don't like behavior x, you can fork it and fix it yourself <smiley face>" So someone does some work that many don't do, did it for free, and wants to see their name somewhere on the patch note. Sounds reasonable to me. If that gets more people (self) interested in maintaining one of the world's most important software projects, okay.

ironmagma 3y ago

> a) they get credit I think this is the least we can do for people who contribute to OSS. Add to that that "contributing" could be as much as commenting on an issue. It's basically zero-cost and encourages help.

joshuaissac 3y ago

> You seem to have no interest in fixing other problems (which you were given an opportunity to do). Based on what happened the first time, fixing other problems may have led to the same outcome again.

deleted 3y ago
[deleted]
shortcake27 3y ago
If someone is more interested in receiving credit than fixing bugs, OSS might not be the best place to hang out.
- bakugo 3y ago
  I'm sure the OSS ecosystem would be better for everyone if every project started removing the names of contributors from the commit log and replacing them all with the name of the primary maintainer. Everyone loves it when they dedicate time out of their life to improving something and it ends up under someone else's name, after all.
  - JodieBenitez 3y ago
    Yeah, it's baffling to me how many people here have little consideration for the recognition of work. I sincerely hope these people never ever attempt a management career.
    - cp9 3y ago
      this thread is *wild*, everyone is jumping down the OPs throat for the crime of doing a ton of work while receiving zero credit for it and having the gall to be upset about it
      - jacquesm 3y ago
        He did a ton of work and got credited for it. The four line patch isn't a ton of work once you've done the RCA and besides it required work by the maintainer to get it to pass. And he changed the essence of the interaction with the maintainer, who isn't going to hang around to teach a newcomer how to properly submit a patch in a cycle of back-and-forths (of which there were already plenty) in a security issue.
        cp9 3y ago
        > The four line patch isn't a ton of work once you've done the RCA and besides it required work by the maintainer to get it to pass the debugging *is* the work! the work for which he went uncredited, that's the crux of the whole thing. he got a Reported-By which just means he ran into a bug and told someone about it, not that he root caused it, wrote a patch and bothered to submit it.

rootlocus 3y ago

> In other words, you asked a maintainer to accept an inferior fix just so you can put “kernel contributor” on your resume. He asked to accept "a patch" not "the patch". You left out the next sentence: "I was also open to working with him, addressing his feedback and sending subsequent versions of patches."

arghwhat 3y ago
The thing is, working with the contributor to guide them to write a specific patch entirely different from what they did is a lot of work, and quite frankly really awkward for both parties. And at that point, it is no longer the contributors patch. The maintainer authored it in its entirety, and the contributor slapped their name on it. It should also be noted that by sending to security@, you trigger a machine optimized for getting fix merged fast to protect the user base - not one optimized for teaching new contributors.
- darkwater 3y ago
  > It should also be noted that by sending to security@, you trigger a machine optimized for getting fix merged fast to protect the user base - not one optimized for teaching new contributors. This is the crux of the issue, and that generated a mismatch of expectations vs reality. If it went through LKML I'm pretty sure someone would have guided him to have a patch accepted and fully authored by OP. As an external observer, however, I empathize and sympathize with OP.
- throeaaysn 3y ago
  [dead]
- jacquesm 3y ago
  This is exactly the problem. By doing this with a security issue you are essentially going to have to be happy to see the problem fixed, regardless of whether or not it has your name on it because the maintainer has more to do than to tutor you until you 'get it right'. There are other more suitable venues for this.

justinclift 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. Even if that's the case, aren't those supposed to be "ok" motivations? A lot of the point of giving people credit is to encourage further contributions. And people only fixing problems that affect them is a very common starting point for people becoming contributors.

cutemonster 3y ago
Definitely OK motivations. From what I've read, the majority of kernel contributors get paid by their employers, that is, they fix things that affect them. And, I'm guessing that getting credited for their work is important to them too, for career reasons if nothing else.
shortcake27 3y ago
My point (which I didn’t convey properly) is that the combination of the two isn’t all that productive, ie “I’ll only work on problems that affect me and only if you give me credit”. I get that true altruism probably doesn’t exist, but I’ve contributed to dozens of projects where I haven’t received credit, and I didn’t care because I helped fix problems that affected thousands of people, which I felt was more important than whatever label was placed on me (or not).
- alexsmarsh 3y ago
  [flagged]
- justinclift 3y ago
  > I’ve contributed to dozens of projects where I haven’t received credit, and I didn’t care because ... This seems a bit weird to me. Not the contribution-without-credit thing on your part, but the trying to denigrate the article authors contribution because their motivations were different from yours. Even though their motivations were just as valid as yours. :)
- emerongi 3y ago
  It seems it was quite productive, no? An important bug was fixed. Next time, it probably won't. Which may very well be a fine trade-off if giving credit is a lot of work that nobody wants to do - just expect less contributions with that approach.

orra 3y ago

> It seems like they’re only interested in OSS when a) they get credit That's incredibly reasonable. Not crediting them is plagiarism. Moreover, even most permissive open source licenses require attribution.

lamontcg 3y ago
> Not crediting them is plagiarism. not if it is a substantially different fix.
- orra 3y ago
  Making changes for the sake of it doesn't stop plagiarism being plagiarism. More charitably, “substantially different” is not a high enough bar when you literally just read the other author's patch. Besides, even if your method is genuinely original, it's only fair to credit the work you're building on. If you're writing an academic paper and come up with a whole new mathematical approach algorithm, you still reference the previous best algorithm.
  - lamontcg 3y ago
    > More charitably, “substantially different” is not a high enough bar when you literally just read the other author's patch. Yeah it really is. If they rejected the approach and rewrote it from scratch that is sufficient. Doing a cleanroom reimplmentation with someone who had never seen the original patch is a good affirmative defense to protect against all possible lawsuits, but it isn't required. > If you're writing an academic paper and come up with a whole new mathematical approach algorithm, you still reference the previous best algorithm. This isn't an academic paper, and the proposed fix wasn't published, and it sounds like the maintainer thought the proposed algorithm was "poor" not "previous best". You can consider it "rude" but under no circumstances is this illegal in any way.

korijn 3y ago

I want to add that the author's attitude can be considered prohibitive to their professional and personal growth. They are taking quite a strong position (blogging about it emphasizes how much this matters to them) which could have the unintended side effect of discouraging peers and managers from honestly giving them feedback on the situation. Edit: I've reworded this to be less black and white. The down-voting here does exemplify the argument that negative feedback is not appreciated.

hmottestad 3y ago
Are you sure that it prohibits their professional and personal growth? It seems like a rather significant thing to state based on a single blog post. Do you know this person from before?
- korijn 3y ago
  Fair enough. I've attempted to reword this to be more considerate of the possibilities.
- catiopatio 3y ago
  As a long-time OSS contributor and an active maintainer on a different OSS operating system, I can definitively state that the answer is: yes, it’s absolutely limiting. They received a reported-by credit, which was more than sufficient — especially on a tiny patch that got rewritten. The important work was identifying and reporting the issue, and they got credit for that. By turning around and writing an angry blog post, they turned a non-issue into some seriously unpleasant drama. Nobody is going to particularly want to deal with them again.
- jacquesm 3y ago
  This patch is miniscule, and does not deserve 'Kernel contributor' status, which seems to be what the OP is after, and which I don't think is warranted for this sort of thing.
  - hmottestad 3y ago

ghosty141 3y ago

> you asked a maintainer to accept an inferior fix Why is the fix by the author inferior? By all we know it could even be better. Not taking sides, just pointing out that your response seems kinda biased against the author. > Also, the only reason you put so much effort into this was to fix your own problem Isn't this the case with most problems? Fix the problems that impact you first, then other ones. That's completely normal.

sshine 3y ago
> Why is the fix by the author inferior? It very often happens in FOSS that a contribution is well-intentioned, but doesn't match all qualities of the project, and asking them to fix it vs. rewriting wastes a lot of time. I've seen this pattern several times before: First-time contributor delivers patch, reviewer thinks "The idea is great, but it's faster if I just rewrite it rather than give feedback." Consequence is, first-time contributor will not contribute to this project again. FOSS maintainers can learn some pedagogy here. I tried having a patch rejected only to see the maintainer rewrite my patch that introduced bugs.
- derangedHorse 3y ago
  That's a stupid approach to maintaining a project. A maintainer should want to make their project the best it can be, and the best way to do that is encouraging contributors to keep contributing. If they can't do that, their work deserves to die and yield way for better managed repos/forks. I have a similar experience with a bug fix I submitted and the decision to delay my fix to literally change the whole architecture of the project left a bad taste in my mouth. After that I stopped contributing to the project and just kept my fixes to myself. It's especially annoying when the maintainer asks for help and pulls this. Architecture changes after proposing small fixes to projects has been a somewhat common occurrence for me.
  - catiopatio 3y ago
    Linux seems to be doing just fine. Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially. Regardless, this individual received a reported-by credit. That’s more than adequate.

yosef123 3y ago

It doesn't matter what the intent behind the fix is, even if it is 100% for personal gain. In my opinion, it should be treated fairly, like any other commit and given credit where credit is due.

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.

bayindirh 3y ago

Unless you have copious amounts of free time, you can only fix the problems affecting you in your day job, and contribute them back. The developer could have accepted that allegedly inferior fix, give the credit, and patch it with their own version in a single commit. I'd have done that, for example, all the while trying to communicate with the submitter of the patch about my intentions. Maybe he wanted the badge for his own honor, not to put it anywhere else. Some people are into that kind of thing, and he fixed a legitimate problem of his to earn this. I can understand them and respect them for that. > No one asked you to do this. Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion. > You seem to have no interest in fixing other problems (which you were given an opportunity to do) As I aforementioned, you need time to do this. It's not given that the author has free time to work on any problems they deem worthy. I'd love to fix tons of bugs, mine or not, but I can't do that because lack of time. Heck, I can't find an hour to finish implementing my own projects. How do we know that he has the whole day to do the research and fix other bugs?

shortcake27 3y ago
> Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion. Why is it not open for discussion? I can’t just fill in a pothole or cut my neighbours grass and expect credit and/or compensation. OSS isn’t common property. You can’t just do whatever you want and expect to receive credit. Yeah, their work needed a fix and they got a fix. That’s already a better than average outcome.
- bayindirh 3y ago
  Free software is common property. This the rule 0. It's everyone's. This is why four freedoms exist, and The Kernel is GPLv2. i.e. Free Software. Compensation and credit are completely different things. Credit is not compensation. It's an answer to question "Who did this?". He didn't do whatever he want. He was experiencing a problem, he traced, researched it, debugged it, fixed it, and submitted a patch to The Kernel. If that was only something "whatever he wanted", the patch would be shot down. The bug is accepted/confirmed on The Kernel side, his patch is being reviewed and deemed "stylistically unacceptable", the reviewer/maintainer wrote his own version, and by pushing the fix w/o attributing him, he effectively claimed that he did all the work from discovery to patching, incl. everything in between. The maintainer didn't have to accept the patch per se. He could have just written "This bug is discovered, dissected and fixed by $THE_PERSON. Patch is implemented and committed by me. Thanks a lot, $THE_PERSON!". This is basic human decency. I have my name on many bug reports, either reporting them, or providing more information leading to solution of the bug. I have a couple of patches here and there, and I experienced something similar from another prominent project people interact with every day, but I said that "mneh, whatever". The author certainly didn't because the treatment he got is really bad, and good for him publicizing this, because these kind of people needs to be known. Well, there might be miscommunication and the story can be completely different, but starting the discussion from somewhere is healthy.

DSingularity 3y ago

If you can’t empathize that says a lot about you. At the very least the maintainer could have modified the submitted patch and thus granted co-authorship to the submitter. Who knows — maybe the maintainer is a narcissist who couldn’t accept patches for his own broken code.

yencabulator 3y ago
There was no Signed-off-by in the initial submission, using that code was literally not allowed. https://kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by https://kernel.org/doc/html/latest/process/submitting-patche...

armada651 3y ago

Proper attribution is actually important though from a licensing standpoint. Contributors publish their patches under the GPL, but they retain the copyright. If an OSS project ever needs to change the license they will need to seek permission from each contributor. You can't relicense a project if you have some code that's submitted without proper attribution to the actual copyright holder.

yencabulator 3y ago
The original patch, as submitted to the security email address, was not acceptable for use in the Linux kernel, as it was missing a Signed-off-by: line. The maintainer had written their own patch by the time the blog post author got around to sending their next email.
- ariel-miculas 3y ago
  This is not true. I've sent subsequent patches to the PowerPC maintainer in private, there was no practical reason why he couldn't work with me instead of implementing his own version.
  - yencabulator 3y ago
    Someone said elsewhere on this forum that the time of the maintainer's commit is before any subsequent email from you. security@ is a fix-ASAP forum.

throwaw12 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. (a) so why it is okay for companies to sponsor events and use it as a marketing, but not okay for people doing same? (b) what's wrong if people want to help fixing problems when they get impacted? isn't it good that they are not demanding someone else to fix, but giving a help?

shortcake27 3y ago
The problem is the combination of the two. Ie, “I’ll only contribute on problems that affect me personally and then only if I get credit”. I’m not convinced this mentality is productive in the OSS community.
- rand_r 3y ago
  Based on what? Discounting credit as motivation is a bit naive and motivation is the only way shit gets done.

praash 3y ago

It's as if people have work to do and can only spend their paid time in OSS fixing problems blocking their work. Having done all the debugging work and figuring out a way to fix it, it's a bit nasty of the maintainer to make a "better version" of it and rudely tell them to be "more useful. Basically it's the same as accepting the contribution and refactoring it afterwards. If the author "only wanted Linux street creds", without the context of a problem, they could have searched for an easy issue to fix and contribute on that. No, wait, now you'd consider that an act of selfless OSS contribution, fixing random problems not related to you!

throeaaysn 3y ago

[dead]

JodieBenitez 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. So what ? These are two perfectly valid motivations. The only thing that matters really is that in the end it benefits everyone.

deleted 3y ago

[deleted]

VagabundoP 3y ago

Nothing wrong with those motivations at all. The maintainer should be fostering new contributors who are doing all this work, who cares if they just want the label. Is the work good or not is all that matters. And, if getting your code into the Kernel is the only way you get that label then that's a shit system, all the testing and writing solutions "contributes" to the final code, its like the 90% you don't ever see.

derangedHorse 3y ago

Contributing for credit and fixing problems that affect them is what most of open source is about. Why would you ever want your hard work credited to someone else when it could benefit you? Sorry shortcake27, this is just a bad take lol

FrustratedMonky 3y ago

LOL. What is wrong with those reasons? Everybody does this: 1. Yes, I'd like some credit and status. -- Every human ever. 2. I have a problem, I would like to fix it -- Every programmer with a problem.

glitchc 3y ago

Sorry, you're way off base, in particular with the especially snarky last paragraph. If the effort up to the point of the patch was used, then the effort has value and an acknowledgement is necessary. Taking the work without attribution is tantamount to plaigiarism. Could you tell us which open source projects are yours so that we, as a community, can avoid contributing to them? We don't want to support this type of behaviour.

shortcake27 3y ago
[flagged]
dang 3y ago
Please don't cross into personal attack. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- glitchc 3y ago
  Sorry about that, dang.
  - dang 3y ago
    Thanks. It happens and we're all subject to these forces - that's why they're hard to manage. It's too much to expect that they won't sneak in unintentionally. The main thing is to re-read one's comments after posting them and then edit out anything you notice that breaks the site guidelines. It's much easier to notice these things after posting them. That's my experience anyhow, and it's why https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html includes the phrase "edit out". One tip, in case helpful: you can set 'delay' in your profile to give you time (up to 10 minutes) to look over and edit your posts before others see them.

nailer 3y ago

> It seems like they’re only interested in OSS when a) they get credit I have code in your OS, node and maybe your web framework. I am *absolutely* only interested in OSS when I get credit. Why would I remain interested in contributing if someone else takes credit?

shortcake27 3y ago
This has been one of the most polarising conversations I’ve been a part of on HN. Your comment made me think. I’ll preface this with an I also have code in your favourite web framework. There are many people like myself who don’t care about attribution, and don’t understand people who care more about attribution than the project itself. Then there are just as many people like you, who are only interested in contributing as long as credit is given. And you seem just as equally unable to empathise with my position. And I feel like this is causing such a heated environment, because neither of these groups are seeing eye to eye. Just a thought.
- nailer 3y ago
  Tone is hard to read on the internet, but I'm not heated and I don't mind that you feel differently. > Then there are just as many people like you, who are only interested in contributing as long as credit is given. The "as long as credit is given" reads oddly to me. Attribution, for me is basically table stakes. Score of zero. I contribute, my contributions are attributed to me. I think you think of credit as a reward, but it's not. It's just decency to me. Someone taking credit, enjoying the fruits of my work, but not enough to attribute them to me, is minus one. It's not that I'm not being rewarded, but rather that I'm being stolen from.

ranting-moth 3y ago

[flagged]

phendrenad2 3y ago

> only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. This is why kernel maintenance should be left to companies like Google, Microsoft, and IBM. They don't care if they get credit and they put serious efforts toward problems that don't affect them.

unethical_ban 3y ago

>I can’t empathise with the author. It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them. Most people want credit for their work. People enjoy recognition for the things they do, though not all people crave it. As for part b), isn't that exactly the attitude encouraged in snide style by OSS advocates whenever someone complains about the function or quality of an open source project? "If you don't like behavior x, you can fork it and fix it yourself <smiley face>" So someone does some work that many don't do, did it for free, and wants to see their name somewhere on the patch note. Sounds reasonable to me. If that gets more people (self) interested in maintaining one of the world's most important software projects, okay.