28 ms·

I got robbed of my first kernel contribution

• tumetab1 3y ago
  Reading now with the updates, I think the issue was overcome, glad to see such cases :)
• tasubotadas 3y ago
  The problem was fixed. The goal was reached. Not everything in life is about getting a golden star in your grade book.
  • vore 3y ago
    Is it so wrong for people to want to feel appreciated for their work? So they have a good experience and want to contribute again?
    • devoutsalsa 3y ago
      Low expectations is a helpful part of living a peaceful life. Everything nice that happens is a bonus, but I’d recommend not staking your happiness on what others do and don’t do.
      • krzyk 3y ago
        Low expectations is recipe for a very sad life
        • devoutsalsa 3y ago
          If you can be happy with nothing, you win life!
        • peoplefromibiza 3y ago
          compared to ...? the secret of a happy life is trying to be happy, whatever that means to you, and making it, the secret of a sad life is trying to be happy and failing at it. regardless of the expectations.
        • baq 3y ago
          Exactly the opposite, actually.
          • marcinzm 3y ago
            Humans aren't machines. In my experience it's very hard to actually have universally low expectations and be content with them in the long run. Usually people who say that either have low expectations in only certain areas (ie: material wealth, etc.) or are bottling up resentment (ie: the classic midlife crisis).
            • baq 3y ago
              That's the point! It's very hard to have small expectations especially if you see your friends, colleagues or generally other people to 'be better' or 'have more', but if you can not care about this, you'll be happy. It is against human nature, though.
          • bowsamic 3y ago
            I'm literally in extensive therapy because of the huge emotional and psychic damage that having low expectations for everything has caused. Literally immense self-sabotage. Huge feelings of hopelessness and inability to do basic work without feeling suicidal because I expect the worse. So no, it isn't always the opposite. For many of us, our pessimistic attitude has been extremely damaging. Someone else here said > You have control over the inputs but not the outcomes :) I can't speak for others, but for me personally, having low expectations has caused me to become lackadaisical or even destructive with my inputs. What is the point if it will just go wrong? EDIT: I can't reply because /u/dang has blocked my account again > That... isn't what I mean by low expectations? For me, it means to be grateful for what you've got, to question feelings of envy and to not feel that you deserve something. That's called "gratitude", not "low expectations" "Low expectations" means you expect low, i.e. bad. It's pessimism.
            • deleted 3y ago
              [deleted]
            • 3y ago
      • aiunboxed 3y ago
        You have control over the inputs but not the outcomes :)
      • vore 3y ago
        Yes, but you can also do things for other people to make their day better. Saying that happiness comes from within doesn’t mean you shouldn’t try help others feel happy.
        • danw1979 3y ago
          The best leaders never take credit themselves. It doesn’t matter if it’s a paid job or as a volunteer on an OSS project, if you lead, you give all the credit to those who work under your direction.
          • marcinzm 3y ago
            Then you're just shifting the same unhappiness the person who wrote this blog feels to the leaders. That sort of flies when the leaders get a ton of money or other benefits but this is an OSS maintainer. Going for extremes tends to lead to worse outcomes than aiming for a good middle ground.
            • ZephyrBlu 3y ago
              It doesn't create unhappiness when you're a leader because that's part of the deal. There is no need to try and take explicit credit when you get implicit credit simply from the visibility of leading the project.
              • marcinzm 3y ago
                >It doesn't create unhappiness when you're a leader because that's part of the deal. Having spoken to a lot of low level leaders I'd disagree. It does create unhappiness because in the end they are no less human. That unhappiness may be worth it for the other benefits and the happiness they gain from them but saying they don't experience unhappiness is dismissing their very human emotions. But often the unhappiness dominates, they burn out and then get replaced by some narcissist/sociopath. That person is fully happy and rises up the ranks.
                • 3y ago
      • mfru 3y ago
        This is a very sad way to live life. Expect the worst and be happy when things are better than your basically non-existent expectations? No thanks.
        • deleted 3y ago
          [deleted]
    • tasubotadas 3y ago
      No. That's normal. But life is not fair and it's not going to happen always. Not being able to accept that shows immaturity.
      • marcinzm 3y ago
        >But life is not fair and it's not going to happen always. The world would be a much much much much much much shittier place if everyone accepted things and never pushed back. >Not being able to accept that shows immaturity. I find not being able to accept that other's have a different but equally valid approach to life shows immaturity.
      • vore 3y ago
        Why can’t we try and change things we feel are unfair? Sure, we can’t change everything and we don’t always get what we want, but surely we can try, like asking someone to improve their behavior?
      • ZephyrBlu 3y ago
        Either you're high status enough to not care about these things, or you get walked all over. For most people fighting for recognition on important or valuable things is worthwhile.
        • derangedHorse 3y ago
          My thoughts exactly.
    • Zetobal 3y ago
      I mean the maintainers fix really does look better... op can and is credited with finding the bug because and that literally is all he did in concern of the code that ended up in the kernel. If you look at the initial commit and the linked stackoverflow answer I understand that the maintainer was hesitant to merge and wrote a clean implementation of it. Not even going into the "laying words into someones mouth" shit he did. He found a bug (even that is questionable because it got reported prior), copy&paste-developed a fix and is angry that it doesn't get merged and now throws a hissy fit that he got attributed with the exact thing he did. Looking at his employer makes this even funnier.
    • peoplefromibiza 3y ago
      > Is it so wrong for people to want to feel appreciated for their work? Is it so wrong to not be awarded a medal everytime someone does something? The title says "I got robbed", the reality is the solution has been discarded for something the maintainer, who's going to maintain that code, liked better. The handling wasn't great, sure, but the real appreciation comes from within, from knowing you found a solution to the problem, not from others. It is like going to the doctor with the solution and being upset if the doctor replaces it with something he can trust
      • vore 3y ago
        It’s hard for me not to empathize with the author when they: - diagnosed a longstanding bug - contributed an initial patch - actively reached out to the maintainer, who said they would reach out in private - contributed additional versions that were reviewed just to have the maintainer take over the contribution wholesale. How would you feel when you put in all that work and receive basically no recognition for it? Maybe you are truly ascetic and have no need for it, but most people appreciate being credited and being encouraged to contribute again.
        • peoplefromibiza 3y ago
          > How would you feel when you put in all that work and receive basically no recognition for it? I would feel that nothing bad happened and that my code was actually reviewed by a kernel maintainer, that acknowledged the problem, and found a solution based on mine, which is in itself a big ego boost. But probably it's just because I have been programming for over 25 years, because I like solving problems, and I don't do it for the recognition, which is basically a false coin. The recognition at work is the salary, the recognition when I volunteer is that I contribute to help people when I can, not that the people I help are grateful to me. Sometimes they are ungrateful too, but that's not why I do it, so I don't care. In my opinion it is childish otherwise, you do things you think they are right because you think they are right, not for some prize. Never let your sense of morals prevent you from doing what is right. > ---------------- - diagnosed a longstanding bug - contributed an initial patch - actively reached out to the maintainer, who said they would reach out in private - contributed additional versions that were reviewed That's basically what I used to do when my car had a problem and I brought it to the mechanic, because I grew up in my uncle's body shop. but the mechanic does it professionally and of course he wants to do all the process again, so he can be sure what the real problem is. At that point he probably found a solution which is slightly better than mine or that solves the root of the problem, not just the symptom. So now I just go there and tell him what is that I feel it's wrong (e.g. the motor keeps stalling) and I let him fix it. If I wanted to become a real contributor, I would start from the bottom, as everyone does: changing oil (here's a bug you can fix)
  • throwawaysleep 3y ago
    Great! So I can hand you all my work and you will do it, I will take credit, and you will be happy?
  • trustingtrust 3y ago
    My thoughts too. A bug existed, the maintainer looked at a contribution and as the maintainer picked the best solution which happened to be his own solution. That’s how the kernel community works. The community picks what’s best for the kernel. Not what looks good on your resume.
    • rootlocus 3y ago
      Someone spent 5 days debugging and giving the explicit details of the problem and a proposed solution. They should be given some credit, even if the exact lines of code that fix the problem weren't the ones proposed. The maintainer could've just given the feedback required for the contributor to submit the desired patch. Or some metadata on the commit could've offered attribution to the contributor. From the article, this was 90% the work of the contributor and 10% (maybe?) the work of the maintainer. Considering that being mentioned as a contributor to the kernel is a Big Thing, completely neglecting to give any mention is poor taste.
  • hmottestad 3y ago
    That’s quite harsh. And also a very simplistic tautology. This post is literally about not getting credit for one’s work. If you don’t believe that the author deserved recognition for their work then you should say that outright.
  • cryptonym 3y ago
    There is a data field to store that information: who contributed a change. Writing your name instead of the actual author seems wrong and I wouldn't blame him to feel unrecognised. I agree it's probably not a big thing but remains a valid feeling in that situation.
  • yard2010 3y ago
    Everything in life is about golden star stickers
  • dotancohen 3y ago
    > Not everything in life is about getting a golden star in your grade book. No, but being a kernel contributor could affect his job prospects in the future. One of the prides that I can discuss in job interviews are my contributions to upstream software stacks (mostly PHP frameworks such as Laravel and Magento). I have had a patch rewritten by a maintainer that arguably made the patch worse - that left a very sore feeling for me and I think that it was the very last patch that I sent to that particular project (Wordpress, which I am glad to be rid of).
    • yencabulator 3y ago
      I sure hope nobody's getting a job based on a single patch.
      • dotancohen 3y ago
        A Wordpress patch, no. But an accepted Linux Kernel patch is a prestigious hurdle, albeit minor, and could easily put the OP over other applicants without.
  • kklisura 3y ago
    I agree, although I do understand that some people might have a problem with it. Last year I spent the whole friday night debugging an issue in a lib I've been using at work. I found an issue, wrote tests to demonstrate it, fixed the issue, write more tests and opened a PR. Maintainer months later closed an issue and I saw it has been fixed within one of his owns PRs. It did sting a bit, but I remembered I learned A LOT while debugging it and I fixed an issue that was bugging us on work.
    • thedoctor79 3y ago
      Maybe the connection to this topic won't be obvious, but I used to read Animal Farm and think that the Donkey was supeior to the Horse. Nowadays I don't think that anymore. The Horse was never alone for a day in his life. The Donkey survived the Horse but was left alone. So I now think "I will work harder" is the right approach most of the time.
  • jbombadil 3y ago
    Sure, this problem was fixed. But with this attitude and lack of recognition, the next bug that this person could have fixed, won't be.
• jjgreen 3y ago
  I've experienced similar (not in the kernel, but a high profile OS project), making an initial contribution is interpreted as an offer to become the personal secretary for one of the project full timers. I politely backed away.
  • inglor 3y ago
    New contributors often have the opposite problem where after an initial contribution they're looking for areas to get involved with and time with a maintainer is valued. Usually the missing part is maintainers willing to do this. (Unless you mean literally personal secretary and dealing with their personal life or setting meetings up and stuff, I assumed you meant tell you what bugs are worth looking at etc)
    • jjgreen 3y ago
      Personal secretary was sarcasm, "personal coding assistant" would be more accurate.
  • scaramanga 3y ago
    If only these drive-by contributors would be around to maintain the stuff like secretaries that would be a dream. As it is, I think you may have the roles reversed: the maintainers are not there to merge your patch and look after it in perpetuity. The entire purpose of these responses is to repel the drive-by contributor who invariably generates clerical work for the full-time maintainer. It's just a sad fact about the nature of this work that it's often done by volunteers who are massively overloaded, and "contributions" are often so minuscule or low quality that they are actually just additional time-demands on already-overworked maintainers. There is a good book about this: https://www.amazon.com/Working-Public-Making-Maintenance-Software/dp/0578675862 https://www.amazon.com/Working-Public-Making-Maintenance-Sof...
    • jjgreen 3y ago
      The entire purpose of these responses is to repel the drive-by contributor It works! I'd rarely file a bugfix to a high-profile project now I know how contemptuous some of the maintainers are.
• inglor 3y ago
  The linux kernel isn't a reward and while I empathize with the OP I would absolutely prefer a better solution to maintain than one from the community. So the maintainer was well within their rights. That said, it's so easy to just give people who contributed to the fix attribution, in Node.js we make a point of trying to give credit in release notes and add `Co-Authored-By:` to PRs where we took _some_ work people did in PRs and adapted it. When you maintain something for a while, credit often stops being important to you (you _are_ the maintainer of the area after all) so it's hard to remember that for new contributors it's often very important. Totally a loss for OP and that part of linux that the maintainer wasn't more attentive to the fact sharing credit (especially when deserved like in this case) was important to OP.
  • secondcoming 3y ago
    It seems he did get credit in the ‘Reported-By’ tag.
    • rootlocus 3y ago
      That doesn't give credit for 5 days of debugging. It gives credit for raising the issue, which was already done, six years prior.
      • hmottestad 3y ago
        Best way to get help with an issue is to post the wrong solution. I remember hearing that somewhere.
        • fragmede 3y ago
          Cunningham's Law.
        • PinkRidingHood 3y ago
          You could've demonstrated it by calling it the wrong name
      • 3y ago
• i_am_a_peasant 3y ago
  Oh man at least you got a Reported-by. When I found a kernel panic on FreeBSD my report was taken by a guy on IRC and was told "just don't worry about it i'll send it to the maintainers".
  • darkhelmet 3y ago
    That sort of thing still happens with FreeBSD, even recently. Find a kernel bug, spend days tracking it down and fixing it, contact a maintainer for feedback before submitting it, and then they slightly reformat it and commit as their own work.
    • i_am_a_peasant 3y ago
      Yeap, happened to me on FreeBSD, happened to me on NetBSD. With Linux it was better, I once had a Tested-by: given as well as a Reported-by: when I encountered some cgroup crashes. The maintainer wrote a much more pertinent patch that I did, as I was not all that familiar with the subtle ways cgroups couple with a lot of other subsystems. I didn't care really about getting credit, whatever info he required of me I straight away gave, reproducer, .config, he was very polite, and I found the amount of credit I got for that fair. On the other hand once I asked for a certain block layer patch to be included in Linux stable and Jens Axboe yelled at me asking me to stop spamming him. Boy that guy's a d*k.. I get it, you're briliant, io_uring is a great thing and we all love it, except for your weird naming conventions with the tail and head pointers for the circular buffers. But by the gods will I strive my best to be as not-like-you as possible if I become a big name on an open source project.
• V__ 3y ago
  > Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix. What a great way to make sure someone will never help you again and disincentivize others from doing the same.
  • deleted 3y ago
    [deleted]
  • blackkettle 3y ago
    Especially after OP notes that the issue had been reported on and subsequently ignored for 6 years. Pretty lame behavior by the maintainer IMO.
  • mellosouls 3y ago
    The actual wording: > I haven't actually reproduced the crash with gdbserver, but I have a > test case which shows the bug, so I've been able to confirm it and > test a fix. > > Thanks for your patch, but I wanted to fix it differently. Can you try > the patch below and make sure it fixes the bug for you? https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/244387.html https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24... -- Also, not mentioned was another reviewers comment: I can't see the benefit of such macros if they are only for PPC32. : #ifdefs should be avoided as much as possible. : etc : Michael's patch seems easier to understand. https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/244531.html https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
    • jzb 3y ago
      This is when I lose all sympathy for the OP. All of it. Misrepresenting the actual statement this way is garbage. There's a world of difference in the two statements. I do understand why people clamor to get a patch into the kernel. It's a big deal. Feeling like you've come close and fallen short has to sting. But, part of having a patch accepted is being able to work with maintainers. Clear fail here. There's a definite air of entitlement in claiming that you're "robbed" of a patch and misrepresenting other people's words and actions.
• jiofj 3y ago
  [flagged]
  • progx 3y ago
    The difference between him and you: he has expertise.
    • jiofj 3y ago
      [flagged]
• firtoz 3y ago
  Open or closed source, sometimes the maintainers or engineers will go with different approaches or fixes. I don't think we have an agreed upon standard of thanking or crediting contributors, everyone does it in their own way. A lot of work is thankless, though. And sometimes people get angry for something you change, even if it's an improvement for most others. Sometimes people are thankful, but mostly silently. Stoicism may be useful.
  • politelemon 3y ago
    > Open or closed source, sometimes the maintainers or engineers will go with different approaches or fixes. I think you're highlighting a really important point. A maintainer who has a wider view of a system will more often than not know what a good, consistent fix should look like for that system. It may not be the approach that someone with a laser-like focus on a single, specific problem may have. In some cases it might even be that a fix for a particular issue is not desirable due to other effects it has, and that's OK. That said, a little understanding from both sides would go a long way: the person who did the initial work, in knowing that the maintainers have been at it for longer, and the maintainer for thanking the person for bringing it to their attention and pushing towards a resolution.
• underdeserver 3y ago
  Hard to judge this situation without hearing the other side. I don't know if the PowerPC maintainer saw significant issues with this guy's code. One thing I do know is that putting in a lot of work up front, without any communication, sending a patch and then getting all worked up if it's not accepted is not generally a good strategy.
  • i_am_a_peasant 3y ago
    That and being a kernel developer is for the most part not all that glamorous. For me whenever I ended up sending a kernel patch it was because I uncovered some bug while working on a larger userspace project.
  • fjfaase 3y ago
    I think that OP had not so much a problem with the PowerPC maintainer coming up with his own solution (which is basically the same, except maybe fitting the coding style better), but the fact that all his efforts for finding the root cause of the bug were not recognized. The PowerPC maintainer could have send him a message like: "Thank you for the patch. Thank you for diving into this bug and finding the root cause. I will attribute your effort. I have taken the liberty to come up with a solution that better matches the coding standards. I hope you do not mind. I will submit the following patch." and I think the OP would be perfectly happy.
    • deleted 3y ago
      [deleted]
    • jacquesm 3y ago
      > but the fact that all his efforts for finding the root cause of the bug were not recognized. But they were! That's exactly what 'Reported-by' is for.
      • underdeserver 3y ago
        Not exactly. Reported-by is for reporting the symptom; the root cause analysis is separate (and often requires much more work).
• micw 3y ago
  Comparing both patches, I see a clear difference. While the contribution from the linked article changes the behaviour of both branches of the if...else, the final contribution changes only the parth in the "if" branch. I guess, the maintainer had some reason to change the code. Nevertheless, giving credits to the original patch author would be appropriate since the actual fix was almost 100% copied.
  • deleted 3y ago
    [deleted]
  • deleted 3y ago
    [deleted]
  • ariel-miculas 3y ago
    I'm the author of the post. Unfortunately, I cannot link to the original patch I sent (it was very different) because I only sent it to the Linux kernel security mailing list. I wish I had saved it somewhere so I could show it.
    • toyg 3y ago
      If your mail client doesn't have a "sent" folder, you need a better mail client :) (Totally with you though: maintainer was a douche. People are the worst.)
    • angio 3y ago
      Should be in your "Sent" folder right?
      • ariel-miculas 3y ago
        Thanks, I actually have it in the sent folder of my personal email, I forgot about this. How can I share the email thread with you?
        • ariel-miculas 3y ago
• pm90 3y ago
  I can see both sides of the issue. The kernel maintainer is within their rights to implement their fix and accept it; they probably work with this codebase a lot and have to deal with issues that crop up. If the added code doesn’t match up in some way, they should be free to fix that. But this issue could have been handled better. The kernel maintainers should have better attribution mechanisms. At least share authorship in the commit so the patch sender gets credit and is incentivized to contribute more. Its so easy to do that and it can create so much goodwill for little cost.
  • rocqua 3y ago
    A solution mentioned a few times here is to take the patch as suggested by the maintainer, but to give a 'co-author' credit to the person who did all the debugging. This gives the best code quality (or at least style match) and still credits the hard work done by the author.
• finnjohnsen2 3y ago
  GitHub supports Co-Authored-By[1] It is probably something the kernel guys (and similar projects) should use generously in examples such as your own to encourage involvement [1] https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors https://docs.github.com/en/pull-requests/committing-changes-...
  • throw_a_grenade 3y ago
    Kernel people don't care about GitHub, and rightly so. Here's the relevant documentation of commit tags: 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...
    • reyqn 3y ago
      > A Suggested-by: tag indicates that the patch idea is suggested by the person named and ensures credit to the person for the idea. Please note that this tag should not be added without the reporter's permission, especially if the idea was not posted in a public forum. That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future. Seems like this would have been a good idea
      • hnfong 3y ago
        > Please note that this tag should not be added without the reporter's permission Given that the OP was upset for not being recognized as a kernel contributor, I wonder whether they'd settle for this. If not, then that would explain why Suggested-by was not used here.
• micw 3y ago
  One thing that wonders me. The patch contains a fix but obviously no unit test that verifies it. Is that the standard of linux kernel development? In the company I work for, the patch would certainly be rejected because of that.
  • romland 3y ago
    Not too long ago, this was actually discussed on HN here: https://news.ycombinator.com/item?id=33742130 https://news.ycombinator.com/item?id=33742130
  • toyg 3y ago
    Tbf the maintainer said the behaviour showed up in one of the existing tests, so effectively they already had it.
  • pjmlp 3y ago
    Units tests just like extreme programming, it was something that came and went, and only a few companies keep on doing. On most of project deliveries we have gone back to only integration testing.
  • hnfong 3y ago
    How do you unit test a #ifdef CONFIG_PPC32 ? I'm unfamiliar with how the Linux kernel does their tests, but presumably it would require a diverse set of hardware, and a lot of code would have to be in the form of integration tests...
  • yencabulator 3y ago
    A very large portion of the Linux kernel code can't even run in userspace. It's not your average software project. Here's one integration test project: https://linux-test-project.github.io/ https://linux-test-project.github.io/ -- typically (non-platform) subsystem maintainers write their own stress tests. But stress tests are merely probabilistic.
• staticelf 3y ago
  Seems like a great way of making people feel unwelcomed by the community. If I were to lay down work on an open source project and not get contribution I would never do any work for that project again. It is important for many to feel appreciated for their work.
  • peoplefromibiza 3y ago
    > Seems like a great way of making people feel unwelcomed by the community. seems like a great way to select those people who understand that a fix most of the times requires not simply solving the bug > If I were to lay down work on an open source project and not get contribution I would never do any work for that project again and that's okay there are people that would do it for the project, not for themselves
• shortcake27 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. > 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
• lyind 3y ago
  The goal shouldn't be recognition but getting the bug fixed. A working system for all is reward in itself. That said, attribution of work is a major theme in academia and business, where professors or department leads traditionally get credited for their student's or subordinates hard work.
  • rand_r 3y ago
    Receiving credit is important to the vast majority of people, and giving credit where it’s due is a leadership quality and ethical standard today. The rules of the game are established and not following them should be frowned upon.
  • derangedHorse 3y ago
    I hope you never receive credit for anything you do then. If "a working system for all is reward in itself" you shouldn't mind allowing someone else who doesn't think this way to take credit for your work.
  • d3w4s9 3y ago
    A simple example: if I found a bug in the Linux kernel, fixed it and get the code merged, I would 100% put it on my resume and LinkedIn which could be a big plus when looking for my next job.
• acatton 3y ago
  "robbed" is not a hyperbole here, it's a blatant lie. The blog author found a bug and submitted a patch, the kernel maintainer fixed the bug differently with his own patch. No copyright was infringed. Where is the theft? Open Source maintainers don't owe you to accept your patches.
  • oytis 3y ago
    Well, arguably "Reported-By" is indeed an understatement if the author also pinpointed the exact mechanism of the problem and proposed a solution - even if it was rejected. But it's also not maintainer's job to ensure everyone feels properly appreciated, Linux kernel community is very different from corporate environment in good and bad ways.
    • acatton 3y ago
      Pinpointing the bug is part of a good bug report. I often spend hours investigating bugs I am just reporting. This is because I want to make it reproducible for the maintainer. Sometimes making it reproducible narrow down the issue so much that it can be found in the code in a few minutes. "Reported-By" is often not a small feat.
      • planede 3y ago
        "pinpointing" can mean different things. Indeed a good bug report includes a good description of minimal reproducer, hopefully deterministic. I would also call this "pinpointing". But the author went further and identified the incorrect parts of the code as well and produced a patch that resolved the issue. I would sure love if most the bug reports I receive would be of this quality, it would save me a lot of work...
      • derangedHorse 3y ago
        It is when you'll now get grouped in with those who just say "X doesn't work"
  • roel_v 3y ago
    He was robbed of the label/title/achievement 'kernel contributor'. In the same way that the loser of a sports match due to a bad ref call is 'robbed' of something. Which I think is a fair description, given the facts as presented here.
• jabradoodle 3y ago
  Some really bad takes here. If OPs story holds up, their employerer paid them to work on OS software and they spent time and expertise debugging and fixing an issue. Not receiving credit here diminished the likelihood their employer will contribute employee time (money) in the future. Also, I don't see the criticism of the OP wanting credit for their work. This is totally normal and expected.
  • crote 3y ago
    Why? Are there really employers out there who pay people to work on OS software solely for the credit? They way I understand it, the main thing your employer cares about is getting the bug fixed / feature implemented.
    • TideAd 3y ago
      It's more like: they'll want evidence it was you who accomplished that. Not for the sake of their product but for the sake of people management.
    • jabradoodle 3y ago
      In the worse case management thinks the dev didn't do anything at all and are less likely to assign similar work in the future. In my experience, yes, companies love any way of gaining prestige and contributing to OS is one of them. For some devs it's a strong positive signal when a company they interview for contributes to OS. There are also performance reviews to be done, where it's a positive to be able to say you/ a dev you manage achieved x.
• jamesu 3y ago
  One time I submitted a patch to implement a feature in an Open Source project, it got completely ignored for 6 months until someone else implemented the same feature which the project went with. Felt a little frustrating, but I've learned sometimes these kind of things happen in large projects.
• oytis 3y ago
  Linux kernel maintainers might be not good as people managers, but it's also not their job - their focus is the code itself. The sure way to get your name in linux git history if that's you goal is contributing regularly.
  • toyg 3y ago
    > Linux kernel maintainers might be not good as people managers, but it's also not their job It's absolutely part of their job. Maintaining a healthy pool of contributors is in the job spec, and to do that you need a degree of people-managing skills - expressed either by tools or by the maintainer. Torvalds makes headlines when he flames, but he definitely always had a penchant for collaboration and delegation, or Linux would not have become what it did. He effectively encoded his philosophy in git, so now most of the people-management is done by tools, but it wasn't like this for a very long time.
• bowsamic 3y ago
  Oof, what a bizarre, self-centred post. It makes it seem like they are more interested in having "kernel contributor" on their CV than actually improving the kernel. This is the worst kind of OSS contributor, the one that jumps in, makes a small change, then leaves, and expects recognition for it. If you really care, stick around and keep helping. Almost no one does.
  • derangedHorse 3y ago
    Why would I help improve something I'm not getting credit for? Especially while others are? It would feel like I'm helping an ungrateful community
    • bowsamic 3y ago
      Because you actually just want to improve it?
      • charonn0 3y ago
        If that were the only consideration, the kernel could be placed into the public domain.
        • bowsamic 3y ago
          Is attribution the only reason for the GPL??
          • deleted 3y ago
            [deleted]
• deleted 3y ago
  [deleted]
• andrewstuart 3y ago
  I sympathise with author but it's not enough justification to give up entirely on such work. You encountered one jerk - there is undoubtedly many, many jerks working in that field.
  • deleted 3y ago
    [deleted]
  • agos 3y ago
    "don't give up, there's so many jerks you still have to meet!" not exactly encouraging
• blinkingled 3y ago
  We can all make our existence so much better by being more empathetic to other people's positions. In this case the maintainer could've just communicated how he would like to see the bug fixed and let the original reporter fix it that way and retain credit. But he just went and did it himself and then made things further worse by using insensitive language. He could've easily added a line to the patch acknowledging the original fix and the effort that went into it. Getting the better technical solution in is in most cases not orthogonal to being better humans. But as it stands, beyond people who get paid for it kernel development is best suited for hobbyists who just have fun figuring things out without any expectation of Internet points.
• barrkel 3y ago
  Having someone else implement the fix and take ownership of the code is a positive in the long term, unless you're committed to the project - in which case you ought to be fine with looking at and fixing other bugs. In a company context, you'd expect the reviewer to coach someone being onboarded towards a solution the reviewer prefers, but that's because you know the person is going to be around for a while, and they're going to need to take ownership. If you aren't in it for the long haul, you shouldn't expect your code contributions to stick.
• ptico 3y ago
  What’s wrong with most comments? If you’re in front of keyboard, and someone is saying what to type. Does this makes you an author of this code? Definitely no. If you’re in front of keyboard, someone is saying what to type and you creatively rework what you hear. Does this makes you an author of this code? Like, you know, ChatGPT can make an existing code better, but this doesn’t mean ChatGPT wrote it. So mostly no See, the programming job is not about typing characters to the code editor. It’s even not about choosing between different idioms or applying common algorithms or patterns. It’s about solving problems. That’s where like 90% of efforts going You might say OP is not a true OSS developer because of solving own problems. But most OSS contributors are solving their problems, what a surprise. This is why OSS still exists. You might say OP is a glory hunter. But in fact, he spent few days solving the problem and then the authorship was just stolen by rewriting the solution. It’s normal to demand a proper authorship of the work you’ve done
  • turtlebits 3y ago
    It doesn't matter how much time was spent. Maybe maintainer could have solved it in hours/minutes if a bug report was filed. What ultimately remains is that the maintainer is responsible for the code, which often times is a much larger burden than submitting a fix. Take what credit you received, appreciate the learning experience and move on.
    • foldr 3y ago
      A bug report for this issue had already been filed, and years had passed without it being fixed.
• juxtapose 3y ago
  I'm not sure if this counts for "robbery", but similar stories happen every day in the FOSS community, usually for very boring reasons, e.g. copyright assignments, or in the author's case, security concerns, presumably. My first contribution to Emacs is a very similar experience as the author's. I took time to debug a long-standing issue in Emacs, I wrote a patch, I asked other users to test my patch, and I addressed comments on emacs-devel, but eventually it got completely rewritten by a maintainer without any credit for my efforts.
  • ariel-miculas 3y ago
    I used this word to emphasise my strong feelings about the situation.
• ThinkBeat 3y ago
  The maintainer has a lot more experience writing kernel code than you do and has a better grasp of how this update will impact other parts of the code. Is his version better? Presumably, it is in the kernel source now? It would be interesting to see them side by side. If he just took your implementation, stuck his name on it and pushed it, that would clearly be an asshole move. If he read your description, looked at your implementation and wrote a much better one, then that is beneficial for the codebase and Linux. In which case proper credit was given. Writing kernel code is hard. Very few people get their first contribution into the kernel. which sucks for the ego of someone making a contribution, but it makes the codebase better. In a generous light, the maintainer recognized that you were interested in helping the kernel and he saw you had some talent, so he offered you a new task as a step to learn more and building your skills as a kernel developer. He could have communicated it in a more verbose and polite manner for sure.
• not_your_vase 3y ago
  While on a personal level I can empathize with the author, it is not because I'm such a perfect person. Based on the timeline this experience has been eating him since more than a year, and it bursted out of him just today. Publishing this 16 months ago would have been seen as a knee-jerk reaction. Now, 16 months after it has happened, it is just petty. Get over it. Open source is like that. Count your blessings - most people would be happy if their worst experience would be only twice as bad as this.
• Nfthero 3y ago
  [flagged]
• ariel-miculas 3y ago
  Author here, I've forwarded the original email thread for those curious about additional context: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg221962.html https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...
• bhouston 3y ago
  This sucks. You went above and beyond and then got undermined by a senior Linux contributor. I think that many people have low social skills in software development. And this is an example of that. I suspect the intentions were not malicious just that the senior contributor doesn’t care about your feelings or values, your work or ensuring you get credit for your efforts. I think your main recourse is writing articles like this as there is nothing else. Maybe next time try not to involve this particular OSS contributor?
  • deleted 3y ago
    [deleted]
• FridgeSeal 3y ago
  Seeing some of the responses in this thread, I hope some of you never manage people, especially anyone junior/mid. If you have a (eager) junior on your team and they contribute a helpful, but sub-par quality PR for some issue, the worst possible way to handle the interaction is admonish them for not being good enough, throw their code in the bin and then rewrite it yourself. You’ve destroyed morale, wasted their time and yours, ensured that they haven’t learnt anything - and thus won’t be able to improve or meaningful contribute next time and you’ve likely dissuaded them from asking for help or volunteering for anything next time. Even if they waded into a hectic past of the codebase, there’s better ways to handle this interaction.
  • mellosouls 3y ago
    Seeing some of the responses in this thread : the worst possible way to handle the interaction is admonish them for not being good enough, throw their code in the bin and then rewrite it yourself. You should perhaps read through again, that's not what appears to have happened, or at least it's possibly an emotional retelling of one side of the story.
    • Cyph0n 3y ago
      No, that is exactly what happened: A new kernel contributor spent 5 days investigating an issue only to have their fix slightly adjusted and committed by a tenured maintainer. See comparison: https://news.ycombinator.com/item?id=37673443 https://news.ycombinator.com/item?id=37673443 How should have this been handled? Easy: something called “code review”. The maintainer could have simply reviewed the patch and suggested what changes need to be made for it to be accepted. And if the maintainer really wants some credit for some odd reason, they can get the Reported-By tag. Win-win! But what ended up happening is a loss of (at least) one potential long-term contributor. I for one definitely thought more highly of kernel maintainers.
      • mellosouls 3y ago
        No, that is exactly what happened No. It's not as simple as represented in the OP, though perhaps your suggestion would have been a useful approach to consider. See the details of the discussion in the email thread.
• incomingpain 3y ago
  This happened to me with metasploit. Their assertion was that my 0day code was so poor they had to rewrite but it wasn't that significantly different. Yes, admittedly my ruby skill is poor, but the fundamental gist of the code was still there. I expect they are to this day still distributing my 0day without any credit.
• runxel 3y ago
  Amazing how the hostility is perpetuating all through HN here as well. I have seen (and sadly self experienced!) this kind of story way too often. And let me tell you this: This guy is now burned by this bad interaction and is successfully shooed away. And some folks wonder why "nerds" and "geeks" are seen as socially inapt... I don't even think that Mr. Ellerman had any malicious intents. But it just shows again, that the so called people skills are nothing to be neglected when choosing leading figures. To paraphrase George Carlin: "It's a big club. And you're not in it!"
• derangedHorse 3y ago
  I've contributed to an open source project after wasting hours of my time diagnosing a bug, diving into the code, and making a fix. The project was in an area I was trying to get a job in, and the contribution would have given me rapport with the FOSS-supporting companies I was applying for. Instead of taking my fix, the maintainer spent a month making drastic changes to the architecture to address my problem and fix. There was a major version increase and people left using the old version of the code either had to deal with breaking changes to adopt the newest version with the fix, or use my fork. The whole thing was non-sensical and I came away thinking the maintainer was an absolute idiot. No one likes their hard work going to waste so I don't know how a rewrite under someone else's name could ever be justified. Wanting to get credit for your work is only natural and sometimes career changes are hinging on being able to build your resume in this way. Even from just a reputation aspect to get more sway when attempting to tackle more ambitious changes. When credit is robbed from someone for no good reason, it's just wrong imo. It's crazy this even has to be explained.
• JokerDan 3y ago
  I really don't understand the toxicity here.. People saying that 'you shouldn't do things just for recognition/gold starts/reward/cv/etc are insane to me? Do they have jobs? If so, to make these kinds of comments imo they should be working completely for free. Salary is a form of recognition for contribution. Personally, adding a co-author (even if the final solution ends up different to the one proposed, but the solution is based around the findings of the original solution) is such a tiny thing to do. I think the author has a valid point to moan about this.. it isn't the first and won't be the last instance of somebody feeling their contribution to something is going unrecognised.
  • cp9 3y ago
    > I really don't understand the toxicity here.. People saying that 'you shouldn't do things just for recognition/gold starts/reward/cv/etc are insane to me? people are acting like we are code robots who never want recognition for a job well done. even if the patch itself was inferior, the debugging effort certainly was not
    • FireBeyond 3y ago
      "Perhaps then we should make all contributions anonymized, so that we can ensure people are contributing for what we think are the "right" reasons".
  • shortcake27 3y ago
    > to make these kinds of comments imo they should be working completely for free. Salary is a form of recognition for contribution. No, that’s a different scenario. Where employment is concerned, the employer and employee have an agreement where work is performed in exchange for compensation. If you walked into a company unannounced and started doing work no one asked you to do (which is a far more accurate analogy to what happened to the OP), very few people would argue you’re entitled to compensation.
    • jpc0 3y ago
      You will likely find though that someone will say "thanks for the work you've helped us with" I find the blog post a little in bad taste, but sometimes you need to stir things to get meaningful change. How many other first time contributors has this exact thing happened to who now will never contribute again but didn't speak up?
• superboum 3y ago
  The kernel documentation defines some tag conventions, one of them is "Suggested-by". Its definition: A Suggested-by: tag indicates that the patch idea is suggested by the person named and ensures credit to the person for the idea. Please note that this tag should not be added without the reporter's permission, especially if the idea was not posted in a public forum. That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future. It could have been more appropriate to the situation, I think it's convey better the idea that you have found a solution to a problem, but because you are not familiar with the project, the exact syntax of your patch has not been kept. Ref: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=HEAD https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  • jacquesm 3y ago
    That works, but probably it works better in the context of things that are not reported as security issues where speed and accuracy matter more than form, the kernel maintainers did the right thing by crediting the person as 'Reported-by', your 'Suggested-by' would make things a bit better but clearly isn't what the OP is looking for, they want to be labelled 'Kernel contributor' based on a miniscule patch.
    • shadowgovt 3y ago
      They should be listed as a kernel contributor based on a miniscule patch. Lines of code modified is a notoriously bad signal for estimating the significance of software engineering contributions. And at the end of the day, credit is damn near free to give out and volunteer projects ought to let it run like water.
      • deleted 3y ago
        [deleted]
      • jacquesm 3y ago
        That's true, but in this case the contribution really is miniscule and if you look at the actual exchange between the kernel maintainer and the OP it is at a minimum misrepresented in the blog post and on top of that the kernel maintainer put in a bunch of work as well including code changes. OP makes it seem as though something major is at stake here and I just don't see it, it's a four line bug fix for a very old issue on a non-mainstream platform. That doesn't get your name posted next to Torvalds and Cox, though I do support the 'Suggested-by' tag, that would be a nice middle ground. Finally: if you want 'Kernel contributor' on your CV then the last thing you want to do is to mail security patches to that particular mailing list, especially ones that still need work.
• deleted 3y ago
  [deleted]
• 0xbadcafebee 3y ago
  Without seeing the entire back-and-forth, it's not exactly clear what happened (we only have a a single sentence from their correspondence). In any case, he can still claim credit from the Reported-By line, same as if he was in the CREDITS file. He can still put it in his resume. Saying he was "robbed" is wrong; nobody said he was going to get his patch accepted, much less be given a specific amount of credit. If he had been promised something, and his work was taken without giving him what was promised, I could see that as being "robbed". But giving someone something in the hopes of something in return, that was never promised, and being mad when you don't get what you hoped for? That's sour grapes. It's like taking a girl out for dinner and saying you were "robbed" when you don't get any after. The bug got fixed, which is a much bigger deal. Often maintainers don't accept your fixes at all, so you're still subject to the bug. Lesson learned: maintainers can be dicks, don't expect anything from them. (I report bugs and user experience issues all the time, and I mostly get either ignored or told that it was expected in some way, so they don't have to accept any responsibility or fix the problem)
  • phendrenad2 3y ago
    > Lesson learned: maintainers can be dicks, don't expect anything from them Nah, that's too cynical for me. I prefer to believe that most people are good. Just stop giving power to dicks, and route around them. Find projects that aren't run by dicks, and contribute there.
• jdance 3y ago
  Without the work of the author this bug would still not be fixed. So credit for that work (which seemed quite involved) would be fair and natural, no? I am surprised and a bit sad at so many comments questioning the author
• noirscape 3y ago
  I've heard before from multiple voices that the LKML has a bit of an "old boys club" issue when it comes to accepting contributions. Basically from what I can tell, the kernel is so large that you have individual maintainers responsible for a specific tree. Those maintainers in turn basically run their own little fiefdom in terms of what contributions they accept and even how they accept them. Some demand the use of git send-mail like in the olden days, others use a more dedicated website for contributors to upload their patches to (forgot the domain). The problem is that a good chunk of those maintainers are apparently running roughshod in terms of basic decency or willingness to communicate with people submitting patches. Prospective contributors have been yelled at or had their patches rejected for bugs that weren't in code they introduced (but were in the git diff they exported into send-mail) or for fixing a bug that their code relied on while adding a new feature (because it "should've been a separate patch"). It's not all of them, but enough to be frustrating. As for reimplementing submitted patches rather than offering feedback on existing ones and refusing the proper credit - this doesn't surprise me in the slightest, nor does the offense being taken suprise me. This is pretty much the exact same situation that led to the disastrous ffmpeg and avconv forking situation (where the lead maintainer would often not bother giving feedback and reimplement entire PRs on his own, without care for the other person involved). Seeing that replicated is unlikely given its Linux, but bad maintenance does usually follow a few trends. There's a reason that when you get to more "niche" hardware combos like say, homebrewed videogame consoles, most projects don't bother upstreaming to begin with, even if their patches are otherwise quality work. Not everyone wants to deal with these sorts of LKML politics.
  • toyg 3y ago
    LKML has always been a pit. In 2001 already, it was assumed that posting on it as a new contributor would involve surviving a barrage of sneer and abuse. Part of it was just the culture around C communities since at least the early '90s, "l33t h4x0rz" and all that; part was Torvalds himself enjoying the occasional public humiliation a bit too much. It's probably much worse now that there is big money at stake. As for maintainers "taking and rewriting", that has happened since the beginning of free software, the tales of "XXX took my patch and rewrote it, without crediting me in any way" are legion. It's why "Reported-By" was belatedly added, because the phenomenon is so endemic that doing nothing looks bad. But it still happens every day in all sorts of projects, not just Linux.
• pierat 3y ago
  Wow, just reading the bulk of responses here is just embarrassing on the FLOSS communities. Person did the hard work and figured out a kernel bug. Was related to memory handling, so sent it to security list. Big ego on security list truncated the reporter's troubleshooting, proof, and patch, and basically ignored the contributions to a 'they reported it' badge. What's a little bit of empathy cost? The person wrote code that fixed the issue. Even if it wasn't accepted, it's still a reference patch. And people wonder why FLOSS ecosystems, well, suck. 'reported and initially patched by __' costs nothing, and is a hell of a lot of good will. But nope. If I do kernel sec patches like this, I'll just get a cool URL, a funny image, and publish it as an 0day. That way, I'll get credit AND a cve.
  • Ocerge 3y ago
    100% this. It has all the symptoms of an old boy's club, combined with smugness of socially inept nerds. It would have cost the maintainer basically nothing to handle this better, but the natural inclination of these types of people in their fiefdoms would never allow it.
• arbitrage 3y ago
  This has been my experience contributing to F/OSS, as well. Upstream maintainers loooooove stealing your code. They are exceptionally unpleasant to work with, overwhelmingly so. "Sorry, I like my version better" is almost verbatim the same ripoff-kissoff I've gotten before in one specific circumstance in the past.
• ohyes 3y ago
  It would have been more appropriate to just give credit to this guy even without accepting his full patch. Clearly no one was fixing this security issue unless he found it and submitted a fix. It’s unethical to not give credit, in particular if Michael read his patch, changed some stylistic things, and submitted it himself. I’m surprised everyone thinks the maintainer is in the right here. If someone scooped up your work and took full credit for it, despite it being a collaboration (and even if miculas code was absolute garbage it was still a collaboration), that wouldn’t feel right, and you wouldn’t want to work with them again.
  • Ajedi32 3y ago
    He was credited. The commit says "Reported-by: Ariel Miculas" which seems accurate to me.
    • mfru 3y ago
      "Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future." [1] Nothing about that says "I have debugged an issue and contributed actual code to fix it" in there. [1]: https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes https://docs.kernel.org/process/submitting-patches.html#usin...
      • jxramos 3y ago
        I agree, it obscures all the heavy lifting debugging and validating and certifying with strong confidence the fix works and continues to work, the guy even tested it on newer kernel releases. Someone who exudes that much perseverance should be welcomed with open arms. These are the kind of go getter get stuff done type of individuals every company longs for.
      • loeg 3y ago
        The thing non-kernel people (including this guy) don't seem to understand is that the debugging and investigation is much more valuable than the actual code fix. The author of the article and commenters here seem overfocused on the actual patch. But the valuable and hard part was identifying the issue. Reported-by gives credit for that. (Sure, in the same situation I would prefer to also be credited with authorship too. But I get it.)
• smoothgrammer 3y ago
  If an one source project wants contributors they should recognize it. If they don't then they should not accept new contributors. It's 100% unethical to take credit for someone else's work.
• hermannj314 3y ago
  Being kind to another human being because you want to encourage them to keep doing what they are doing, Favor trading, Compromise. This is called diplomacy. Anyway. This story is about the opposite of that. Diplomacy is a choice, usually a trade-off, in favoring a longer-term relationship. Failure to even want to be diplomatic shows the Linux maintainer thinks this person is worthless as a human being on a long-term basis wrt kernel maintenance. And that's fine, but don't be surprised when that contributor is offended and proves you right.
  • Chris2048 3y ago
    > Being kind to another human being > shows the Linux maintainer thinks this person is worthless as a human being bit of a contradiction. This highly speculative take on the maintainer isn't exactly kind.
  • hnfong 3y ago
    Writing a story 1.5 years after the fact to complain about not being credited for a 20 line patch that was subpar doesn't sound very compromisy nor displomaticy to me. I feel sad for the maintainer in question who suddenly is on the receiving end of a borderline defamatory blog post featured in the front page of HN for some minor "mistake" he made 1.5 years ago. Apparently according to some comments in this discussion what he did was pretty much standard procedure even. Where is "being kind" for him? Where is the "encourage them to keep doing what they are doing" for him? Not the misattribution of course, but like, to not feel discouraged after 20 thankless years of contributing to the kernel and 10 years of maintaining a kernel subsystem? Speculative statements like this are anything but kind: "Linux maintainer thinks this person is worthless as a human". Take your own medicine. Actually be empathic, not only to those wearing the protagonist hat, but to every single person, and perhaps especially those unfairly villainized.
• bloopernova 3y ago
  Bug discovered by Bob Initial fix by Bob Fix refactored by Chris How difficult would that be?
  • bjornlouser 3y ago
    It might prove difficult if Chris has been at IBM for over 20 years.
• ok123456 3y ago
  I make most of my open-source contributions quasi anonymously, and don't want attribution. Does that make me the odd one?
  • dpkirchner 3y ago
    No -- that's my preference as well. However, I could be considered a "late-career" developer that wouldn't benefit much from credit for small patches.
  • guggle 3y ago
    That's what I do too. At the end of the day, all I want is for my patch to be included so I don't have the problem anymore. I code for a living and I don't have to sell myself to recruiters in my field. But I fully understand why one would want to be credited, and that's just fair.
  • finnthehuman 3y ago
    Nah, I do that too. I’m a “backstage” kind of guy, including literal backstages. For example, the only video of mine ever put on YouTube isn’t on my account, someone asked if they could post it. It got 10k views, I feel like that’s pretty good just for a little messing around, but I’m still glad it’s not tied to me.
• jwildeboer 3y ago
  The correct title would be „Why I am offended instead of happy that a problem got solved“ ;)
  • isatty 3y ago
    I suppose this is sarcasm but if not, no, the title is correct. A lot of the early internet and very useful chunks of the kernel was built for credit and acknowledgment. Not granting that, especially when it wasn’t a horribly buggy patch with a one line description, is really scummy of the maintainer and he should’ve known better.
• WalterBright 3y ago
  One thing I like very much about using git and github is the provenance trail of every contribution.
• kazinator 3y ago
  The maintainer's patch is better. 1. It doesn't lose the fpidx < (PT_FPSCR - PT_FPR0) test from the 32 bit case. 2. In the put function, it doesn't lose the *data = child->thread.fp_state.fpscr; fallback assignment, which is taken when fpidx is out of bounds. 3. It avoids the pointless FPRINDEX macro which reduces to identity if TS_FPRWIDTH is 1. The original patch's commit message says "On PPC32 it's ok to assume that TS_FPRWIDTH is 1", but then includes this anyway: #define FPRNUMBER(i) (((i) - PT_FPR0) >> 1) #define FPRHALF(i) (((i) - PT_FPR0) & 1) #define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i) Sorry, just because you found this trivially fixable array mismatch doesn't mean your buggy patch has to be accepted the way it is. The maintainer should, however, acknowledge that Miculas didn't simply report the problem, but that Miculas investigated identified the root cause, and had his own version of almost the same simple fix. "Reported-By" lacks the precision to express that it was thoroughly investigated by that party, and root-caused.
  • bhouston 3y ago
    I agree that the maintainers work is better. But he could have just done this as a code review on the patch and ask for an update. That happens constantly for new contributors to a project and it is the proper way to do things - it teaches people and brings them up to speed. If you just redo their work, you are discouraging them from contributing while also not allowing for a teachable moment.
    • jacquesm 3y ago
      Not on a security related list though. That's entirely the wrong expectation.
      • varispeed 3y ago
        Security through obscurity? Oh...
      • Arnavion 3y ago
        linuxppc-dev is not a security list.
• mhkhung 3y ago
  It happens to OSS projects all the time and simply discourages further contributions. Last year I took on an issue that has been opened for years, did all the work creating a pull-request, updating test code, yada yada, even another one that fixes their build problem. The maintainer took the PR to fix their build problem and simply ignores the original issue. Any chance I will spend my time contributing to that project again? No way.
  • PaulKeeble 3y ago
    Its a common problem. I often go through a bunch of bug reports and merge requests to ascertain how a patch will likely be treated. I have walked away from fixing quite a lot of bugs in projects as they didn't appear to be very good to contribute to, the Linux kernel being one such example back in 2003. Some projects are just like that and you are best not engaging with them as its likely going to be a waste of time. Not that it matters now, since the AI revolution the open source licenses are widely breached and I haven't submitted any open source code since and wont do so again.
  • turtlebits 3y ago
    IME, code projects want bug reports/improvements as contributions, not your code. I see people taking it personal when their code isn't accepted/rewritten, but overlook that writing code a small part of what it takes to run a project.
    • caconym_ 3y ago
      Isn't there a switch somewhere on Github (or cloud repository provider of choice) to disable public pull requests? Maintainers who don't want code contributions should avail themselves of it.
  • da768 3y ago
    Some people have their whole "GitHub resumes" built off copy-pasted contributions. 1. Open PR 2. Get comments asking for changes, you only have time to fix it a few days later. 3. PR gets closed as fixed by another PR submitted by a frequent contributor. 4. Find said PR is your exact code with a variable name change (approved instantly through lower 'friend' review standards) 5. Look at that user's profile and notice almost every contributions were copy-pasted from other people.
• tpoacher 3y ago
  Imagine if this was an academic submitting to a journal to improve state of the art. This is the equivalent of a reviewer rejecting the paper, and then publishing the same paper in their own words, saying "I like my phrasing better". The author is right to be upset.
  • neonate 3y ago
    The maintainer never said "I like my version better". That was completely made up.
• snickerbockers 3y ago
  This is petty and childish. The primary purpose of open-source software is not to pad your resume, and besides only one minor bug fix isn't going to get you hired anywhere on its own. The maintainer probably should've been a little more generous with his attribution than just posting "reported by:" in the bug fix, but ultimately OP is just the guy who reported the bug not who fixed it. They aren't obligated to fix the bug the way some rando on the email thread wants it to be fixed because it's still their code. This isn't just the way open-source works, it's also the way most corporations work. It's also perfectly normal for a bug report to contain an example fix because the reporter knows how to make it go away but not necessarily how to make it go away the "right" way so I can easily understand how the maintainer saw this as a "reported-by". Calling them out on a blog post that you then submit to hackernews doesn't make you seem like a pleasant person to work with either.
• foooorsyth 3y ago
  Relevant Jonathan Blow: “The idea of a pull request is offensive”. https://youtu.be/XLVjSeusPYg?si=NbTzVx6QlB337zSs&t=25s https://youtu.be/XLVjSeusPYg?si=NbTzVx6QlB337zSs&t=25s
• andrelaszlo 3y ago
  I found a (relatively minor) bug in Git and tried contributing a patch for it. That time it was definitely partially my "fault" that it didn't get merged, since I was new to C and their contributor process. The feedback on my patch was kind of overwhelming (something like "instead of your one-liner, it's probably better to fix the root cause of the issue by refactoring this and that..."). Didn't get around to it, then saw it got fixed by a regular contributor quite some time later. It was a bit discouraging, but I didn't feel robbed (since circumstances were different!) - and I realize it's difficult for maintainers to also find the time to onboard new contributors.
• gumby 3y ago
  By the way as a side point: trapping on a data access is called a "watchpoint", while "breakpoint" is when the program counter reaches a certain value. cf another topic on the front page today: this can be done with hardware (as the author did) or (extremely slowly) in software when you don't have hardware support for it. Not that this comment addresses the author's unhappiness.
• JediPig 3y ago
  he is not the only one, or will be the last. Having your name on the main line of the kernel is really worth $$$. However here is a pro tip. FreeBSD, being a kernel commit, and having your name in it, you will be snatched up by various companies that use it, and not only puts a footnote that they do. Example, Apple, Playstation, Juniper, Oracle, etc. BSD pays off more.
• cranx 3y ago
  I think this is a common issue that happens in software development. Some people just like to make thousands of changes that don’t impact logic, but let them own the blame for that line of code. I guess it gives some a sense of power, control, and ownership.
• jmull 3y ago
  An open source maintainer isn't obligated to accept unasked for code. For all we know there were gaps or issues with the submitted code and not accepting it was the only reasonable response. Now, the maintainer could have made this guy more welcome... but I imagine it's quite a bit of work to get a new contributor up to speed to the point where they are consistently a net positive for the project. In any particular case you have to decide whether you want to take on that work or not, and I can hardly blame someone who isn't getting paid for opting out of that, even if the reason is just that they don't want to do it that day. > I was also open to working with him, addressing his feedback and sending subsequent versions of patches. That's good, but it's important to note that that's asking the other person to do a bunch of work that helps you, not them. You're asking for a favor here, probably the dearest and often scarcest resource of an open source maintainer -- their time. I suspect the author failed a little test when rejecting the other piece of kernel work... who needs someone who wants you to help them work on their problems but isn't willing to help you work on yours?
• ChrisMarshallNY 3y ago
  I really am sorry that this happened, but it is also a risk that we take, when we jump into the deep end of the pool. The Linux Kernel is the deep end, and the Linux Kernel Security team is the Marianas Trench. It took gumption to make a first attempt to that level. It sounds like it was damn well done, but I have found that people in that level of things are generally not particularly welcoming of folks just coming in and assuming equal status. It's an unhealthy ego thing, but it's also quite human. I encounter it all the time. I don't come across as an alpha nerd, and am often treated quite dismissively. It used to infuriate me, but nowadays, I just shrug, and say "your loss." I don't think I'm missed; even if my contribution would have made a great difference. Sometimes, I have had stuff I pioneered used without credit, but I put it out there for a reason. Most of the software I write is designed to help people in need, and if it gets to them; no matter the route, then it's good. I am not particularly interested in getting credit. There was a post, a day or so ago, about "I Will Not Read Your F%%king Script"[0], and it sort of spoke to the same kind of mindset. Basically, if we jump into the deep end, the rewards can be great, but we won't receive any help, or any pity. We will be treated as interlopers, and can look forward to being treated fairly barbarously. All that said, I encourage the author to keep it up, but I'd gently suggest not making it a front page HN issue. That probably won't help. [0] https://news.ycombinator.com/item?id=37628606 https://news.ycombinator.com/item?id=37628606
• phil21 3y ago
  I've only skimmed most of the comments, but getting old is seriously starting to hit me reading this. There seems to be a large "old school open source" and "new school Github open source" culture clash here. This sort of thing wouldn't even make for a 5 minute controversy on IRC back in the day. But I also can see valid points and the expectations developers who grew up in a different era now have. The olden days were certainly not perfect, but neither is the new age. Certainly going to be interesting times as torches get passed for these huge fundamental open source projects over the next decade or two!
  • jacquesm 3y ago
    Assuming computers will still be programmed by then. I think your observation is spot on by the way.
  • andrewmcwatters 3y ago
    It’s probably a good idea these things are pointed out these days.
  • Arnavion 3y ago
    Yes, this has happened to me a few times (in other codebases, not the kernel). If I were in the author's shoes I'd be upset about it (and rightfully so), but I wouldn't post publicly about it like this because no good will come from it.
• RunSet 3y ago
  I have had my bugfixes rejected for superficial reasons and then immediately re-enacted by the project owner so many times I no longer even bother contributing to public github repositories. Now I just fix my own copy and wish others luck doing likewise. Makes me wonder if maybe funding github is part of Microsoft's long vision for the death of open source.
  • remram 3y ago
    Sounds like you are the problem, I don't see what is Microsoft's hand in this.
    • RunSet 3y ago
      > Sounds like you are the problem, I don't see what is Microsoft's hand in this. Perhaps in your haste to conclude that I am the problem you overlooked my mentioning github, which Microsoft owns. It is a website where, among other things, many open source projects are hosted. If you replied to a comment by mistake then disregard.
      • remram 3y ago
        The fact that it's hosted there doesn't mean that your unhelpful attitude is their fault.
        • RunSet 3y ago
          I take your abrupt change of subject to mean that that you now observe Microsoft's hand in this.
      • inemesitaffia 3y ago
        You can use git without GitHub . An example of this is the Linux kernel
        • RunSet 3y ago
          Correct. I wrote about Github, not git.
• ftxbro 3y ago
  Does that mean if I've been contributing anonymously I've been robbed of every contribution?
• r053bud 3y ago
  I guess I have a slightly different approach to my contributions. I really couldn’t care less who gets credit, I just want the bug fixed! I’m an OpenBSD user and I trust the core development team way more than myself. If Theo responded “I like my version better”, who am I to argue with that! :)
• deleted 3y ago
  [deleted]
• sevagh 3y ago
  I can't think of a more black and white situation than this. If the OP, Ariel, did not do what they did, the kernel would not be fixed. Therefore, they contributed the fix.
• naikrovek 3y ago
  can't wait to see how these things go once Linus steps down and Linux continues without him. You think egos are big now...
• gorjusborg 3y ago
  To me, the blog entry just shows that the author is overly emotionally invested in getting a very particular form of recognition (but without identifying it). If you did the work, and your employer paid for it, surely they know you contributed the fix and appreciate the leveling up you had to do to accomplish it. So you know what you did, the person paying you knows, so where's the problem? The way it is being presented makes it seem like nefarious work stealing went on. The thread posted doesn't indicate that though, and again, the people who matter know. Your gold star is the growth you got along the way, not the 'authored by' note.
  • seabass-labrax 3y ago
    It's very difficult to 'prove' personal growth, even if it's tremendously valuable to yourself. Imagine if the author wanted to leave and seek another job: "I was a former contributor to the Linux kernel" counts for something. You don't want to have to follow that up with "but, well, I never got credit so I suppose you'll have to trust me :) :)".
    • gorjusborg 3y ago
      Yes, I understood that was what the author was looking for: 'bragging rights'. The reality is that if you or he had been on the other side, you'd know that as a maintainer, you have enough to balance without worrying about everyone else's resume.
      • seabass-labrax 3y ago
        One can't always correctly assume the motivations for a contribution, but 'bragging rights', as you put it, rank pretty highly in my experience. To lead a sustainable project, one has to be sensitive to these motivations and make satisfying them a sufficiently high priority. That doesn't have to mean a three-page press release every time someone joins your project, but it probably means publicly thanking a contributor for their first contribution. Every project is different, but as for myself I believe I have been successful in balancing my responsibilities as a maintainer appropriately whilst giving credit liberally. If this has helped someone fill their resume and land a dream job, even the better for it!
• the_biot 3y ago
  This happened to me as well. Didn't get any response to my patch, resent it and got told it had "already been fixed". Sure enough, a worse (IMHO) fix was in, fixing this thing that had never worked in the kernel. They didn't even tell me. The Linux kernel gets away with this because it's the biggest/most important software project in the world. When I had a similar experience with another open source project, I lost the desire to ever contribute to that project again.
• deleted 3y ago
  [deleted]
• zoogeny 3y ago
  In the past I've worked on really difficult bugs that took days to debug only to find a super simple and trivial one-line fix at the end of that hard road. That is, 90% of the effort was understanding what was happening well enough to write that one line of code. It seems to me that 90% of the effort for this fix was contributed by the author of this post and the 10% effort of writing, testing and verifying the few-line fix was contributed by the maintainer. At the very least it seems the original author should have got a Co-Authored-By attribution, even if no lines of his original patch made it into the final commit.
• jcalvinowens 3y ago
  This is a normal part of contributing to the kernel. You send a patch because it's often the most succinct way to convey the problem. Your expectation should be that they won't use it. I can think of at least three times off the top of my head [1][2][3] this "happened" to me. It honestly never even occurred to me to be upset about it... because my primary goal was to fix the bug, and I was happy to have done so. My sincere advice to OP is to delete this blog post... they will regret it in the future. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2f0680d116 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28b783e47ad7 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2270bc5da349 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  • that_guy_iain 3y ago
    Naming the dude and throwing him under the bus is a super bad look. I was really shocked when I saw the other guy's name.
    • time0ut 3y ago
      I really feel bad for the maintainer. Its already hard enough of a job without this sort of stuff.
    • netipulk 3y ago
      Yup. Incredibly unprofessional and a pointless emotional outburst. I felt second hand embarrassment from reading the blog post.
• ebiggers 3y ago
  This is a great example of why so few people want to be a Linux kernel maintainer. Not only is it largely a thankless "job" where you get blamed for issues you didn't cause and are expected to do much of the work on your own time, but you can potentially get a misleading hit piece published about you and posted to Hacker News just for doing your job. IMO, what the maintainer did (taking authorship and crediting the original author/reporter via Reported-by, after rewriting the entire patch including the commit message) was in line with kernel conventions. The lines are a bit blurry, and I think keeping the original author/reporter as at least a Co-developer would also have been acceptable. Still, people sometimes complain if they are kept as the author or co-developer if their patch is rewritten, as they don't want to "own" that rewritten patch and take blame for any issues in it. So pick your poison. Ideally, more time would have been taken to work with the original author/reporter to get their patch in shape. Unfortunately, there isn't always time for that. In this case, the bug was reported to security@kernel.org as a security vulnerability, so that throws much of the usual process out the window; it needed to be fixed quickly. The maintainer went out of their way to get it fixed quickly, in a better way, and even added unit tests for it later. The original author/reporter was credited in both the fix commit and the pull request merge commit. Also note that the maintainer's commit is dated June 7 and was merged into mainline on June 9. So AFAICS, it predated the original author/reporter sending a revised patch; it postdated only the first patch.
  • timeon 3y ago
    I agree in general (also things have tendency to escalate to unnecessary drama through re-posts and comments on the social networks) but: > as a security vulnerability, so that throws much of the usual process out the window; it needed to be fixed quickly Was not the bug reported originally six years ago?
    • ebiggers 3y ago
      It may have been, but security impact is often not recognized right away. The older report was not sent to security@kernel.org and did not include a root cause analysis.
• avgcorrection 3y ago
  Ignoring the problem with lacking DCO (potential problem) the Linux project seems very flexible with fixing up commits (I mean patches). I mean some practices are pretty jank: <message> Reported-by: ... Signed-off-by: ... [<initials>: fixed a typo in the commit message] Signed-off-by: <initials> [<initials2>: fixed a leak, oh my!] Signed-off-by: <initials2> (Changelog in the changelog) Assuming proper signoff attribution (DCO), it's absolutely possible to clean up a patch, note that in the commit message, and then either give the original author full authorship or give one of you a co-author status. That seems like a more reasonable way to go if you don't have time to go multiple review rounds, trying to poke them towards the preferred solution.
• zamadatix 3y ago
  Shoutout to Chaitanya Kulkarni. I submitted my first kernel patch after digging into why a group of new NVMe drives were having trouble all coming up in the same boot and they went out of their way to help me clean it up, format it correctly, and still get submitted under my name. I was already happy someone was willing to help me get it fixed properly but they went the extra mile.
• infogulch 3y ago
  My conclusion: * It wouldn't have hurt to give Ariel more credit with a `Co-Authored-By` instead of `Reported-By`, especially considering that the 'report' came with a working code fix. If this form of credit is outside the typical Linux commit authoring norms, then maybe this is a good motivation to adjust them. * Ariel should have brought up the complaint about the Reported-By tag at the time instead of letting his frustration and disappointment fester for a year then writing a blog post about it. * The "(paraphrased)" maintainer response to asking for more credit feels off, and the formatting of the blog post is badly misleading. I'd much prefer a direct quote than a paraphrasing for something like this, where it's important to have raw data for third parties (like everyone in this thread) to come to a valid judgement on this aspect. * I can't tell if this was communicated in private or if the response is contained in one of the links mentioned in this thread. In general the whole timeline is rather difficult to follow which doesn't help. Between this and the recent rust drama, I think we're running face first into the biggest issue of text-only communication mediums: it's really hard to communicate intent and feelings through text. You can dismiss that as silly human foibles, but the human shit actually matters. In person communication has such a higher bandwidth it's insane, and if we're going to continue pretending that we can replace it entirely with text, we will have to commit to a much higher level of transparency and candor than we'd feel comfortable with in person, else it will be harder than necessary to maintain community over the long run.
  • jacquesm 3y ago
    I'm pretty sure if the OP would have just sent the maintainer an email that he thought he deserved more credit would have been all it took to get it fixed. He was also given an opportunity to get more credit for another issue and that would have cemented his commitment to becoming a regular contributor. Both sides could have done better, but this level of attack is unwarranted for what happened and if Michael Ellerman is capable of seeing that they could have handled the situation better then I'd hope the OP has the insight that they too could have handled this better, for instance by communicating with the maintainer directly. Your point about communications is well noted, I think a part of it stems from a combination of workload on the part of the maintainer(s) and unfamiliarity with the various processes and attitudes as well as the absence of even clearer rules on how kernel maintainers should deal with various levels of contributions.
• sacnoradhq 3y ago
  It doesn't matter how much better the ultimate fix was, it was plagiarism and credit theft. A professional patch review process would ask for changes rather than kicking someone off the keyboard and taking over. It's a shitty thing to do and discourages contributions, contrary to FOSS.
• oytis 3y ago
  Looks like this scenario is common enough that it deserved a mention in Linux contributor's guide [1]. > On very rare occasion, you may see something completely different: another developer posts a different solution to your problem. At that point, chances are that one of the two patches will not be merged, and “mine was here first” is not considered to be a compelling technical argument. If somebody else’s patch displaces yours and gets into the mainline, there is really only one way to respond: be pleased that your problem got solved and get on with your work. Having one’s work shoved aside in this manner can be hurtful and discouraging, but the community will remember your reaction long after they have forgotten whose patch actually got merged. I think that summarises it perfectly. [1] https://www.kernel.org/doc/html/v4.17/process/6.Followthrough.html https://www.kernel.org/doc/html/v4.17/process/6.Followthroug...
• lobocinza 3y ago
  Something similar but with way way less significance happened to me. It left a sour taste. But at the same time and more frequently I see people going an extra mile to ensure I receive proper authorship where I don't really care that much.
• alexeiz 3y ago
  There is so much complaining for a patch with just a few lines of code. > I spent a lot of time and effort doing root cause analysis, fixing the bug, testing and validating the fix, getting feedback from other engineers at my company, adapting the fix to the latest kernel version, and sending two different patches to Michael Ellerman, the PowerPC maintainer. Thank you for doing all the work for free. Meanwhile Michael Ellerman gets paid by IBM to use your work. I hope now you understand an important thing about open source: if you're doing the work for free, you're an idiot.