I got robbed of my first kernel contribution | Hacker News Reader

I got robbed of my first kernel contribution

ariel-miculas.github.io

702 pointskkapelon692 comments

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.

He was credited. The commit says "Reported-by: Ariel Miculas" which seems accurate to me.

"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#usin...

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.

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.)

Reporting a bug is a lot less credit than debugging and fixing a bug. He did the latter, even if his exact fix didn't end up being the one merged into the repo.

Generally most of the work occurs after a bug is reported, as it did here.

Reported-by should go to the person who reported the issue 6 years ago. Finding the issue (again), investigating, debugging, fixing and testing that fix sounds more like a hypothetical "Fixed-by", or co-authorship, depending on how similar the final patches really are.

Authoring the patch is often trivial once the debugging is done. Describing the debugging as just reporting is underselling it.

That's fair, but before you know it you're going to have a whole taxonomy of different kinds of contributions and there simply isn't one for 'x did RCA' and the fact that the original patch wasn't properly signed off as mentioned in the exchange with the kernel maintainer may have been all that stood between that and another level of accreditation. Which by the way wasn't responded to by the OP as far as I can see, even though the maintainer clearly mentioned it and the LKML list spells out that that is a requirement for accreditation.

yah, this is a sticky point. This is one of those scenarios where I put the onus on the person more familiar with the process to inform others for these sort of nuances. Its one of those information asymmetry / familiarity problems. Maybe both were not well versed in the concept of coauthorship though to be fair and it didn't occur to either of them not knowing what they didn't know.

I suspect the maintainer never properly realized how much Co-authorship or authorship of the patch meant to the contributor (given that this was their first contribution), and that was probably informed by the size of the patch, the fact that the OP used their corporate email address and the fact that the patch was very small, required work wasn't properly formatted for immediate inclusion.

One thing I've learned from this thread is that as maintainer of a FOSS package, especially a popular one you are always going to get yelled at (to the point that people will make up reasons and put words in your mouth for yelling at you), no matter what you do. People are literally calling for the maintainer to leave.

The maintainer would have been yelled at no matter what he did? That's an odd conclusion to make from that article.

Or you're adding some personal other experiences? (What are those? People yelling at you because you did attribute someone for the work they did?)

The patch I found was signed off. If it wasn't I fail to see how the maintainer could have legitemately signed off his own patch considering it was modified from or inspired by the original patch.

They went back and forth on that in email with the maintainer very clearly stating their intentions.

I did not find that yet. Can I read that anywhere?

My understanding is that if the initial patch was not signed off then the maintainer could not sign off his patch, unless he wanted to take on the liability of certifying that the contributor was indeed allowed to contribute the initial patch under whatever license we are talking about here. That sounds like a legal risk I would not be willing to take.

Yes, and that was one of the reasons the maintainer rewrote it (which wasn't a lot of work since it was a tiny patch anyway).

The OP has submitted a link to an email archive further down in the thread.

I see which email thread you mean now. AFAICS OP submitted the patch with a proper sign-off again approximately 6 hours after they were told the sign off was missing. So I don't see how that could have been an issue. The maintainers patch is from more than a week later.

> Yes, and that was one of the reasons the maintainer rewrote it (which wasn't a lot of work since it was a tiny patch anyway).

I don't think a simple rewrite is enough to convincingly solve the described problem. There is a reason "clean room design" exists and considering the maintainer read the original patch first before creating their own there is a good argument that they were at least subconsciously inspired by the original patch and therefore plagiarized. That is how I understand the legal aspects of this, anyway.

And when your fix was the actual fix, but the maintainer rewrote it stylistically? Why should the maintainer get that credit?

The author's proposed patch had issues raised in review that were never addressed. I disagree with the characterization that the differences between the two authors' patches were purely cosmetic.

Which is all the more reason to give good credit. I have to justify effort I do on company time to my boss. If I had to put in months of work on company time, that needs to be clear to my boss's boss who may not know anything about programming but signs the check. Such people think writing code is the hard part, so it is easier to justify the costs if I'm given credit for writing code for several months (even though the code itself took a couple hours)

I'm pretty sure most software people do understand that the work leading up to the fix was the most valuable part.

I feel like what some people don't understand is that there are contributions like this all the time, and it is often better to take the submitted code as a proof-of-concept than bring a newcomer up to speed on the maintainers' coding standards.

There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag. He didn't write the actual commit that fixed the issue, so he was credited in the commit message instead. That seems fine to me. The fact that they didn't include an entire paragraph detailing the exact nature of his contribution isn't a reason to blow this up into some big community drama with over 500 comments on Hacker News.

> There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag.

"Based-on-patch-by:" and/or "Root-caused-by:" comes pretty close, I think.

It may seem like a small difference, but I understand the author's disappointment.

Those might be better, but neither is a tag that is used in kernel commits. There is a list of specific tags that are used, and specific conditions on their use. "Reported-by:" was not a wholly arbitrary choice of words by the maintainer.

AFAIK, there are no rules limiting what tags you may use -- you can make up your own if you like. And people have. Here's what the kernel git says right now:

    linux$ git log | sed -nE 's/^ *([^ ]+-by:).*$/\1/p' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | egrep -v ' [0-9] '
         20 ack-by:
         74 acked-and-tested-by:
     195801 acked-by:
         24 acked-for-backlight-by:
         49 acked-for-mfd-by:
         19 acked-in-principle-or-something-like-that-by:
         21 acked-off-by:
         10 analysed-by:
         47 analyzed-by:
         26 based-on-a-patch-by:
         97 based-on-patch-by:
         15 based-on-work-by:
        128 bisected-by:
         18 boot-tested-by:
         37 build-tested-by:
        147 co-authored-by:
       4779 co-developed-by:
        175 debugged-by:
         60 diagnosed-by:
         11 disliked-by:
         11 eviewed-by:
         51 fixed-by:
         18 fix-suggested-by:
         32 found-by:
         48 generated-by:
         19 improvements-by:
         79 inspired-by:
         18 located-by:
         10 not-acked-by:
         86 noticed-by:
         30 original-by:
        140 originally-by:
         95 original-patch-by:
         44 pointed-out-by:
         14 proposed-by:
         10 reivewed-by:
         22 reported-and-acked-by:
         12 reported-and-analyzed-by:
         77 reported-and-bisected-by:
         12 reported-and-debugged-by:
         23 reported-and-suggested-by:
       3017 reported-and-tested-by:
         21 reported-bisected-and-tested-by:
      58990 reported-by:
         11 requested-and-tested-by:
        363 requested-by:
         10 review-by:
         55 reviewd-by:
        513 reviewed-and-tested-by:
     304543 reviewed-by:
         16 reviewed-off-by:
         67 reviwed-by:
         11 root-caused-by:
         29 sigend-off-by:
         10 signed-by:
        157 signed-of-by:
    2253448 signed-off-by:
         59 singed-off-by:
         54 spotted-by:
         32 suggested-and-acked-by:
         12 suggested-and-reviewed-by:
         17 suggested-and-tested-by:
      15568 suggested-by:
         48 tested-and-acked-by:
         22 tested-and-reported-by:
         35 tested-and-reviewed-by:
      62630 tested-by:
         12 verified-by:

My suggestions are both there (far less often than "Reported-by:", but that's not surprising). I think "Analyzed-by:", "Debugged-by", "Diagnosed-by", "Originally-by:", or "Original-patch-by:" would also have worked.

If you don't filter out the tags with less than 10 uses, there are some fun ones. For example, "You're-my-ding-a-ling-by:" should be used more often. :)

There is Analyzed-by, it's not super common but in the end you can make up whatever *-by you want. You can also say "Thanks to ... for analyzing the issue and suggesting a possible fix".

I think it depends a lot on how much the final patch was based on the one he wrote. There are a few phases of solving an issue:

Identified: They have found an issue and reported it.

Debugged: They found the cause of the issue.

Fixed: They wrote the fix.

It seems that Ariel should be credited for somewhere between Debugged and Fixed. But is only explicitly given credit for the first "tier" of solving the problem. It would have been nice to explain a bit more the work that Ariel put in.

But I agree that I wouldn't expect an inferior (by the maintainer's perspective) patch to be included just to give that credit. But a sentence explaining how Ariel contributed would likely be much appreciated.

Unfortunately the author wasn't comfortable sharing his patch ("this mailing list is private so I cannot link to the original patch I sent"), but a comment now buried deep in the discussion [1] says:

> The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.

It sounds like the author wrote the fix and the maintainer merely edited it to fit the project style.

If that truly is all that was done, how hard would it have been to ask the author to quickly make that change?

1: https://news.ycombinator.com/item?id=37672558

IF the patch was only edited for style or other minor issues, then the copyright remains with the original contributor. If the patch was completely rewritten from scratch and is very different then not. (linux does not require copyright attribution)

If the poster wants to get a lawyer he can probably force rewriting git history to give him credit. Is it worth it - probably not.

But the OP has copyright. The LKML archive is there for everybody to see, they wrote a bit of code. That code was then modified and that modified version was entered into the repo under the maintainers name, as it usually goes. And that's because when you mail LKML you play by their rules, which have been made very explicit:

https://www.kernel.org/doc/html/v4.17/process/submitting-pat...

Note the bit about the Co-developed-by tag:

"A Co-Developed-by: states that the patch was also created by another developer along with the original author. This is useful at times when multiple people work on a single patch. Note, this person also needs to have a Signed-off-by: line in the patch as well."

and

"Note, you did not properly sign-off on this commit, so it couldn't be applied anyway :("

From the exchange between the OP and the kernel maintainer. Which may have been the whole issue.

> From the exchange between the OP and the kernel maintainer. Which may have been the whole issue.

Well, if it was, the maintainer didn't communicate that well/at all:

"I prefer my version".

That was made up by the OP.

> Well, if it was, the maintainer didn't communicate that well/at all:

You're making the mistake of accepting at face value a one-sided account of an issue, and in the process failing to even check what the answer actually was.

None of that changes the fact that the original patch is copyright by the author, and it is highly likely the courts will consider the changes style issues which do not change copyright ownership. Unless the kernel maintainer can show he didn't look at the patch, only the description of the issue and then recreated the patch from scratch.

Oh, we're going to court now?

Seriously, this is getting way out of hand: when contributing to a project that has been going for more than a few decades you need to first familiarize yourself with how things are done to set your expectations for the interaction appropriately. The Linux kernel group does a pretty good job and they have their own ways of doing things. It's custom - and polite - to get the lay of the land before yelling 'robbery' when what actually happened is exactly what is supposed to happen: the bug got fixed, you got credited for the report and the maintainer spent some of their - precious - time on getting your proposal - because that is what a patch sent to LKML is - fixed and included.

And that's ignoring for the moment the fact that the interaction wasn't at all like the OP suggested it was.

If it were me I wouldn't think it was getting out of hand. Kernel contributions are the kind of thing that goes on your resumé and can land you a dream job. I would look into courts too.

Then please never submit any patches to LKML because the last thing a maintainer needs is a court case from some entitled newbie that can't be bothered to read the documentation and on top of that is so focused on accreditation that they are willing to go nuclear over a teensy contribution.

FWIW a submission to LKML does not come with any kind of guarantees for either accreditation, use, timeliness or consideration. You are making a small gift to the Linux kernel and all of its users and as such you are being thanked. Hopefully you got more value out of the Linux kernel than you contributed on account of the work that others have put in. The LKML record will suffice to prove your claims of copyright but realize that your work does not stand on its own, it is always going to be within a larger context. Try affixing a (C) Worewood to a patch you intend for inclusion and send it to LKML and see how you'll fare.

The fact that this kind of kernel patch is in any way relevant to one's resume is exactly the thing that is getting out of hand. And the author links to his linkedin profile in the footer, and well, the reference to this patch/contribution/whatever is there, unsurprisingly (and it is the only thing there that they cared about enough to expand upon).

Going to court about this is a right. It might not be a good idea, it might not be worth it, but it is a right.

> The Linux kernel group does a pretty good job and they have their own ways of doing things

I'm not saying otherwise. However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change. Yes the maintainer spent time, but it appears like more credit is being claimed by the maintainer than is deserved, credit that should go to the patch submitter. It doesn't matter if this is normal Linux process, it is still wrong and the maintainers should change their process to be morally correct.

Of course I don't know if the interaction was as OP claims or not. I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)

> However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change.

I think they're doing things as 'by the book' as possible.

> Of course I don't know if the interaction was as OP claims or not.

Well, he documented it twice and those two accounts differ considerably.

> I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)

Who will the OP sue?

For what exactly?

In which court?

None of this makes any sense. If you think the possible outcome of submitting an unsolicited small and broken patch to a security mailing list of a major FOSS project is going to result in you taking anybody to court for copyright infringement then it probably is a great idea not to contribute at all, this will save everybody time and grief. Besides that: the OP - as far as I'm concerned - has copyright to their contribution to LKML, note that nobody except for the OP claims that this is not the case.

It's interesting how for instance all of the comments written in this forum are technically copyrighted by their writers. But you don't control them after submitting them because of the way the forum is structured, the jurisdiction that it is run from and the expectations that come with forum comments. LKML patch submissions are like that as well: they come with a whole pile of baked in assumptions that the OP apparently wasn't familiar with. The idea that each and every minor patch author, especially of patches that are broken and that do not contain required elements is going to end up being hand-held through the process of making a proper contribution is ridiculous.

The maintainers work-load is such that the pay-off is that your contribution is looked at at all, better still if it results in a fix (even if it isn't literally yours). And if you want credit then you should at least state that up front so that the maintainer has a chance to work with you out of the spotlight until you're ready to submit your patch publicly.

Threatening to sue on account of something like this is exactly why I would never be the maintainer of a major open source project, life is too short to deal with all the drama and entitlement.

It's now available here: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...

Many are asking and I’d like your thoughts. Why did you misrepresent their words to the extent you did?

I don't have access to the private emails between me and Michael Ellerman anymore because I exchanged emails with him from my work email address. I've switched companies since then so unfortunately I don't have access to that conversation anymore. I do remember he pointed me to another bug that I could fix if I wanted to become a Linux kernel contributor. The first part I was paraphrasing from what I could remember.

"Reported-by" is absolutely not the appropriate level of recognition for Ariel's input. This would be suitable if he just raised the issue with the maintainer along with some context. Instead, he put a lot of work into figuring out the nature of the problem and implementing a fix.

This is very unethical conduct on the maintainer's part.

> This is very unethical conduct on the maintainer's part.

And this is why finding good maintainers for visible FOSS projects is hard.

You know what's unethical conduct? Misrepresenting someone's words in a way that make them look bad.

The maintainer did exactly what they usually do, I see absolutely nothing unexpected here, note that this was an unsolicited patch sent to a security mailing list. And this is typically how those are dealt with. To claim 'unethical conduct' is one small step removed from a formal complaint about the maintainer, and which is exactly the wrong message to send here. Witch hunts like this cause good people to leave FOSS projects. The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches. If you must have credit then you should not contribute in this fashion.

> The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches

Is something like "we may accept your work and choose not to give you credit" actually stated somewhere when you sign up for or submit to that security mailing list?

Because that's certainly not the usual rule for unsolicited work in other contexts.

You can read the LKML mailing list page for submitting patches:

https://www.kernel.org/doc/html/v4.17/process/submitting-pat...

Absolutely nowhere does it say that accepting your patch will lead to you automatically being given kernel contributor status, and to require that status on the basis of committing a single tiny patch that wasn't properly signed off and required work shows a different set of expectations than one that I would see as reasonable.

To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel.

Now to look at this patch it looks Michael took the report, debugged, tested, and resolved the issue, when all he actually did is move a single line to outside of a conditional.

> and required work shows a different set of expectations

You're really stretching here, the only "required work" missing was a sign off, which Michael could have given.

In any other environment, this would be plagiarism. And it looks morally poor.

Well, we're going to have to differ on that then. Michael - in my opinion - properly credited the OP for his contribution, he could have done a longer back and forth to coach the OP to present the 'perfect patch' but this is the wrong venue for that.

Besides that the OP misrepresented the interaction to a degree that he loses my sympathy, he makes the maintainer come off like a dick when in fact that wasn't the case at all, the interchange was polite and to the point and exactly in line with what I'd expect from a kernel maintainer.

> To me there's a difference between having a commit bit ("kernel contributor status") and having a contribution that was accepted into the kernel.

Who do you think has the commit bit on the Linux repo? Hint: kernel contributors don't.

10–20 good patches is probably the minimum baseline for a contributor. Merging a couple if statements into mainline verbatim is pretty iffy. This guy’s expectations are whack.

Yes, it should have been under "Co-developed-by".

No, because as the exchange between the maintainer and the OP explicitly mentions it wasn't properly signed off on. That's the requirement for that particular tag: that a submission is in principle ready to be applied.

Tell us, what "development" did Michael do that warranted him getting credit, and the OP not?

Kazinator did a pretty good job at that, besides: Michael is not taking any credit, LKML is there for all to read.

https://news.ycombinator.com/item?id=37675544

The sticking point here seems to be the DCO, which the “signed off by” thing attests. With that attestation other people who sign-off to the DCO can carry the patch forward (maximum to a pull request against Linus' tree). Without it though you have a broken chain.

But it ain't much of a sticking point. Most of the time it is just an oversight that can be pointed out and corrected. All it takes is for the maintainer to point it out and ask for it and then then the author to do it. (The patch author themselves need to do it or else there wouldn't be a point to the sign-off; forging a sign-off would defeat the purpose.)

The "Reported-By" must be read in the context of the patch carrying that tag, and not in the context of the blog author's initial issue. The accepted patch has the following title:

> powerpc/32: Fix overread/overwrite of thread_struct via ptrace

Miculas is credited with identifying the low-level issue: ptrace is overwriting thread_struct. To me, that does recognize that Miculas did significant analysis work.

Reported-by doesn't specifically express the idea that Miculas investigated the problem through to the root cause.

Reported by would be appropriate credit if (a) the maintainer did not read Ariel's code or (b) Ariel's code was utter crap, so it was effectively discarded.

"I like my code better" indicates that neither of this happened. So, Ariel deserves (at least partial) credit for fixing, since this was not a "clean room" fix.

And if Ellerman did not want to spend time going back and forth, he could have accepted Ariel's patch then immediately modify in a new commit.

For that it would have to be properly signed off. This was explicitly noted in the exchange and not remedied by OP.

Why introduce risk in a bisect? A Co-developed-by or another appropriate attribution tag should solve this nicely?

Lots of options it seems: https://news.ycombinator.com/item?id=37685190

"I like my code better" is not what the maintainer said[1]:

> Hi Ariel,

> I've added Christophe to Cc who works on ppc32.

> 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?

> I've also attached the test case I've been using.

> Christophe are you able to test these on some 32-bit machines? I've

> tested it in qemu and on one 32-bit machine I have here, but some more

> real testing would be good.

> If the patch works then I'll need to do manual back ports for several of

> the stable kernels, and then once those are ready I will publish the

> patch.

> cheers

> [...]

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

Except nobody said “I like my code better”. Or even pointed to another issue for OP to fix. See https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

Agreed. I see the job of an experienced maintainer as a facilitator who should bend over backward to help other people's contributions land cleanly. The help often involves feedback on style and architecture consistency, but a sign of a great maintainer is someone who credits others, and mostly stays behind the curtain making sure everything goes smoothly.

And occasionally coming out from under the bridge to give guidance when a contributor gets too far into the weeds.

Agreed. The maintainer can insist on writing the code that makes it into the kernel for quality purposes - that makes sense. But here the article author is a co-author of that patch.

In academic publishing, this is analogous to sending a pre-print to someone, and that person then publishing on that topic listing you in acknowledgments rather than as a co-author. I get that the point here isn't publishing, it's kernel development, but authorship is still quite important for a professional C.V.

The first few times I submitted suggested patches to the Linux kernel (before semi-automated submissions through the LKML were possible), I had a dialog with the maintainer (Ted Tso in this case). Once he was satisfied with the correctness of my work, he incorporated the patch and all was good. I never asked for, nor received any credit. I was solely interested in improving the kernel and not interested in getting my name in there. (My name ended up in the contributors list anyway for something else a few years later, but I never cared one way or the other.)

I used to think it was fine to take someone else's contribution and then create a total rewrite of it in my own branch and merge that. Or to go into someone's PR and push a rewrite into a new commit on Github. At least in the latter case there'll still be a contributor credit (`Co-Authored-By`), but someone had to do the same with me for me to realise that it kinda sucked and really soured the experience of being a contributor. In my case, it was that someone 'forked' my project by dumping the code into their own repo without any of the commit history.

As you say, even if the code was shite, the refactored fix that got merged in would never have existed without it. "I like my version better," feels pretty dismissive and regardless of any other fact I can see how anyone would feel a bit miffed about that after they put the work in.

Edit: the reply linking to the actual response from the maintainer invalidates my last sentence.

But nobody said "Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix."!

This[1] is what the maintainer (Michael) said.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

This is much more reasonable than the "paraphrased" reply in the blog post.

I think it's somewhat dishonest that the blog author used the quotation feature in his blog post, but instead of including a quote he made up his own response as if the kernel maintainer said it. I barely noticed this parenthetical above the gigantic block quote:

> He said (paraphrasing):

Anyone reading the blog post too fast would assume the kernel maintainer actually said those dismissive words in the gigantic block quote.

Yeah, the paraphrasing here is misleading.

Ironically the topic is intellectual honesty.

What's the big deal about misquoting here?

The blog post author just liked his version better. ;-)

>Anyone reading the blog post too fast would assume the kernel maintainer actually said those dismissive words in the gigantic block quote.

That's my case. I only know it was paraphrased because of this thread. The quote pulled my attention before I could finish the previous line.

Yeah, and I might have felt a bit “blind” if it were not for you guys also having the same experience: I did not see that parenthetical at all, probably both on account of the linebreak right before it and the (as you say) huge blockquote.

I would hope the author of the post corrects this, "I wanted to fix it differently" is not even close to "I like my version better."

It's still a bit crap to not get proper credit, but it's not fair to put words into someone else's mouth either. The author isn't paraphrasing, he's sharing the story he's told himself after being upset.

And the maintainers reply already includes the proposed patch, with:

> Reported-by: Ariel Miculas <...>

Ariel could just have pressed "reply" in his email client and pointed this out if he felt wronged.

But no, instead he is writing a blog post one year later misrepresenting the maintainer and the Linux project.

I believe the implication is that this exchange happened in private.

I have this done to me a lot and honestly don’t feel a thing. People don’t really care about other people’s coding styles anyway (except they all suck); the thing got done, everyone got credit. I guess everyone feels differently.

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.

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.

Not on a security related list though. That's entirely the wrong expectation.

Security through obscurity? Oh...

linuxppc-dev is not a security list.

It was cc-'d to the security list.

On the first patch that Miculas submitted with their gmail address that was not looked at by any of the parties involved in the rest of the story. The subsequent mails to linuxppc-dev where Leroy and Ellerman were involved were not cross-posted AFAICT.

Yes, that's correct. But the OP didn't have to CC the security mailing list in the first place and that changed the dynamic considerably.

Note that the degree to which this has blown up is disproportional and that besides the fact that Michael Ellerman could have handled this more gracefully the OP did not seek to resolve this out of band, misrepresented the interaction and ignored an olive branch that would have given him exactly what he wanted.

The bit where I am in strict disagreement with how Michael Ellerman handled this is actually the reverse of what happened: if the original patch wasn't properly signed off on and the OP was responsive they actually put themselves at risk by re-using the code without proper attribution. This - and that's speculative - probably was because the code identified the essence of the fix but introduced a couple of new problems and because it was so small he may have felt that fixing it and adding a 'Reported-by' tag plus the LKML archive would be sufficient cover for that. But from a strict reading of the LKML guidelines that was the wrong thing to do.

And the LKML guidelines themselves should be made clearer with respect to how the various levels of contribution are dealt with because that seems to matter a lot to some people and they need to spell out more clearly that submitting a patch may result in your code ending up in the kernel with LKML as the only visible proof that this is the case. Because the OP may not realize it but that is the essential part: that their submission to LKML ended with a bug in the Linux kernel fixed and there is ample proof to document that and I'm pretty sure that nobody would claim otherwise.

A lot of these maintainers are already overworked and don't have time to tutor every single person that wants to put kernel contributor on their resume. A lot of people have this extremely idealistic view of open source but the reality is that the vast majority of patches you receive will be atrocious and you shouldn't have to tutor every single "potential" contributor. This case is even worse since this issue was posted to a security mailing list which means time to resolution is important.

Who knows how long this would have been unaddressed without Ariel Miculas initial input.

Part of the job of a maintainer is to curate and foster input so the project has a robust community in the future.

The maintainer in this case did a miserable job of that.

On the other hand, to dig yourself out of the hole of “I’m too busy and there’s nobody around to help”, you have to slow down and do this, sometimes.

> to dig yourself out of the hole of “I’m too busy and there’s nobody around to help”, you have to slow down and do this

Exactly! If you treat new contributors as crap because you are overworked, you will push away potential long-term collaborators who could share the load thus ensuring you will be working alone far into the future. This is a failure state and if I had a manager doing that to those he was managing, he wouldn't be a manager for long.

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

This seems like a very cynical view of what happened here, and completely unfounded.

Obviously these big open-source projects need gatekeepers, but if the gatekeepers often make aspiring contributors feel violated and humiliated rather than offering feedback to get their initial contributions across the finish line, general interest and enthusiasm for contributing are going to dry up. Maybe that's by design, but it doesn't feel sustainable in the long term.

> feel violated and humiliated

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

> multiple major issues

Seems debatable and debated, reading through the rest of this thread.

Regardless, I'll reiterate my point more straightforwardly: it's the maintainers' prerogative to treat aspiring contributors however they like, but actions have consequences, and some of those consequences may be deleterious to a project's health.

> Seems debatable and debated, reading through the rest of this thread.

Most of the people commenting in this thread haven't looked at the code and anyone saying the two patches are equivalent can be safely ignored. Out of the issues kazinator pointed out, 1 and 2 are definitely major issues and 3 is debatable although it is definitely suboptimal.

> some of those consequences may be deleterious to a project's health

Of course, but I think it might not be in the way the "everyone can be a valued contributor" crowd thinks.

> the "everyone can be a valued contributor" crowd

Of course! Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay, if not those whose merit has already been proven?

> Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay

This is unironically a very serious problem and why most of the best open source projects are basically corporate FAANG projects that are really only open source for optics.

On its face, you won't catch me arguing with that. It's a hard problem, for sure.

See https://news.ycombinator.com/item?id=37692883

It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating.

Talking about utilitarian consequences, Linus had been way worse and while I fully agree from a moral perspective that his most extreme behaviors were bad, from a purely utilitarian perspective that didn't prevent Linux from being one of the most successful OSS projects out there.

> It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating.

Isn't this a little bit disingenuous? Do you really think the author of OP's blog post is upset simply because a Linux kernel maintainer has far more domain expertise than him and is in principle capable of writing a "better" patch?

That would be pretty irrational, I agree!

The real disingenuous part is where OP lied about the maintainer saying his patch was better.

It would be pretty bad if he said that, but he never did.

I agree that Miculas (the submitter of the original patch) should not have chosen formatting typically associated with direct quotations, but now you're the one putting words in his mouth: he didn't say Ellerman said his (Ellerman's) version was better, he (Miculas) said Ellerman said he liked his (Ellerman's) version better.

Ellerman's actual words were "I wanted to fix it differently", so while I don't think Miculas' paraphrasing was entirely appropriate (why paraphrase at all?), I also don't think it was a misrepresentation of what Ellerman actually said.

Because it could be seen as communicating: "my ten minutes of coding around the array access problem is more perfect than your hours of investigation to root cause the issue plus your ten minutes of coding".

Besides the fact that he didn't actually say that at all.

> This seems like a very cynical view of what happened here, and completely unfounded.

It is not unfounded at all. The author clearly stated the reason they wanted their commit to be accepted was should they could be contributor.

Do you think there is any reason somebody might want to be credited for work they did other than having the ability to put it on their resume?

He had the credit amongst those who were paying attention. It wasn't like this was done in secret. Others chimed in to agree that the maintainers commit was better. So the only credit he didn't get was a commit credit which is important to be a "Linux Contributor" which clearly explictly wrote was the reason they asked for their commit to be used or to work on another patch.

I think it would be odd to disbelieve the author.

> Maybe that's by design, but it doesn't feel sustainable in the long term.

That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version...

One might also consider the rarity of maintainers who can write high quality code and donate large amounts of time. To find and retain someone like that one might also be required to allow them to be curt with random people on the internet from time to time. I can see how drive by contributions could get old fast from their point of view.

> That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version...

Indeed, and while we're speaking in broad generalities, surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term...

> I can see how drive by contributions could get old fast from their point of view.

Indeed. But (again addressing generalities) my issue here is that the contribution in question doesn't read as "drive by" to me.

> surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term...

If the rate of submissions falls then it certainly makes sense to adjust. Until then, don't fix what isn't broken.

Frankly, if you treat effortful but green contributors the same way you treat grindset morons and LinkedIn jockeys, I would put money on the submission rate from the latter continuing to increase long after most of the former have decided your project isn't worth their time.

This is a bit of a moot point, though, since I don't think it's very common for Linux kernel maintainers to behave this way. Correct me if I'm wrong.

I looked at the two patches, and TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch.

In a company where people are expected to stay around for a while, it may make sense to invest time to bring juniors up to speed. But I wonder whether that's true for OSS projects in general. A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture -- this is not a junior who just joined the team, and they have no commitment to stick around to do more contributions.

In this case, from a utilitarian perspective, it doesn't seem obvious the maintainer should spend the extra time coaching.

This might be a minority view here, but TBH I don't think anyone should be obliged to go out of their way to spend extra time and effort to avoid offending a random person on the Internet.

The time to write the patch is insignificant in this context.

I would say that the author stated he asked for his patch to be accepted so he could be a contributor implies they weren't planning on contributing more. So it doesn't seem like a sceranio where they should spend that extra time.

Not really.

1. Please don't drop cases from your #if CONFIG_PPC32 blocks that are handled on 64 bit. You can use if (IS_ENABLED(CONFIG_PPC32)) instead of #ifdef so the only difference is in the array access.

2. Please remove the FPRINDEX macro; as you note in your commit message, we can assume TS_FPRWIDTH is 1.

The maintainer also wrote a long and detailed commit message in his own version of the patch; he had time to explain things.

In this exact situation, I would possibly have made the code adjustments myself and written "patch provided by Ariel Miculas". Then send an e-mail saying that I made a few minor tweaks to your patch, here is what it looks like.

"patch provided by" tells the truth: that person provided a working patch. It doesn't say that the patch they provided is precisely this one.

A maintainer can't approve a patch that wasn't properly signed off, that's one of the very few rules set for patch submission that has nothing to do with the code but everything to do with the legal implications of including code that isn't properly attributed and an essential part in keeping the Linux kernel unencumbered.

This is not some rubberstamp formality, it is an actual declaration of authorship and shields the kernel maintainers from possible claims of copyright infringement.

> TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch.

This is always the case for a senior developer dealing with a junior developer. Basically your argument is that junior developers shouldn't try to contribute and if they do, they will just be rejected out of hand if they make any mistakes. Okay.

> But I wonder whether that's true for OSS projects in general. A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture -- this is not a junior who just joined the team, and they have no commitment to stick around to do more contributions.

If you treat people like crap, they won't stick around. So it is a bit of a self-fulfilling prophecy.

I think that great OSS leaders are few and far between. One that I can think of that I've worked closely with for a decade is mrdoob of Three.js. Humility, openness, focus and good people skills. I cannot approach his skill set here, and in part that is why I respect it so much. He achieves a lot and there are hundreds of contributors to Three.js of all different skill levels. And he definitely is not going around rewriting simple PRs just because he can and instead he and others are coaching and encouraging the community. This is why Three.js thrives.

I think this particular OSS developer isn't leader and is more of an individual contributor type who doesn't collaborate well. That is okay. It is unfortunate that his behavior is reflecting poorly on the Linux project, but that is who he is.

> Basically your argument is that junior developers shouldn't try to contribute and if they do, they will just be rejected out of hand if they make any mistakes. Okay.

I don't think that's as wrong as it sounds. There are projects and codebases that are more or less "done" (and heading towards obsolescence) and aren't worth it to expend resources for juniors to learn how to work on them.

It's usually much more rewarding to have junior developers try to implement something "new" instead of fixing obscure bugs on a stable codebase. There's much more leeway for mistakes in new features, there is less/no learning curve to grok the intricacies of the existing code, and fewer surprising edge cases that the juniors would inevitably miss because they haven't been stung by it 10 years ago.

As I mentioned, it's up to the projects themselves to decide how much they want to expend extra resources in bringing up potential new contributors. As with most things in software engineering, it's a trade off.

And yes, the OP feeling angry with the way the kernel maintainer handled this issue could be said to be a trade off as well. I think the only thing that's unfair about this discussion is that you and maybe a hundred others are making claims about the kernel maintainer ("isn't leader", "behavior reflecting poorly on the Linux project", "treat people like crap") for allegedly misattributing credit for a less than 20 line patch.

Imagine a minor mistake you made 1.5 years ago making the front page of HN and hundreds of people slinging insults at you. I wonder how that feels. Quoting from you:

> If you treat people like crap, they won't stick around.

> I think that great OSS leaders are few and far between.

We can also revert this and say that great contributors are "few and far between".

Collaboration, patience, and empathy is a two-way street. Could the maintainer have done better? I guess; I would have done things a bit different. Then again, maybe their dog died that morning and they were in a foul mood? I'm not joking: people aren't perfect, they have good and bad days for all sorts of reasons, etc. Everyone makes a mistake now and again.

But whatever this maintainer could have done better, this blog post also isn't a good look: sour grapes a year and a half later and making a big deal out of what is really a singular minor personal conflict (and with some misrepresentations to boot). Now, maybe the author's dog died this morning, so I'm not going to attach any far-fetched conclusions about this person, or about Cisco, because again, everyone has bad days and no one is perfect.

Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event.

> But whatever this maintainer could have done better, this blog post also isn't a good look

You are correct, I definitely would not have written that blog post either.

> Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event.

I believe what you are describing is formally called the Central Attribution Error (CAE.) https://ethicsunwrapped.utexas.edu/glossary/fundamental-attr...

You are right, I should edit my original comment to remove my speculations that are probably based on CAE but it is now locked for editing.

You're missing the point. "I can do it faster" discourages new contributors from wanting to help out ever again.

> a fraction of the time needed to explain how to write a better patch

He apparently had six years (since bug was reported) to do it. I think he surely could spend some time.

>A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture

Everyone involved in this story, both the original author, the second person who authored the patch, and the maintainer who reviewed it, are on the mailing list for that obscure architecture. It's obvious that they all care about it. Its "obscurity" in your eyes is irrelevant.

>In this case, from a utilitarian perspective, it doesn't seem obvious the maintainer should spend the extra time coaching.

https://news.ycombinator.com/item?id=37675328

> https://news.ycombinator.com/item?id=37675328

I was replying to a specific comment suggesting that the maintainer should do a code review, give comments and ask for an update to the patch, instead of rewriting the patch. Quoting my words out of context isn't helpful here.

And my point was that from "a utilitarian perspective" there's a middle ground between "coach the original author to produce a better patch" and "commit your own patch without crediting the original author"; it's "commit your own patch while crediting the original author". There's no "out of context" quoting in my comment.

What usually happens is that someone sends a patch with a text description of the problem, but no test case. So what I do in those cases is just quickly look at the patch and create a test case first, on the current stable version, to reproduce the bug. This is both so that a test case exists, but also so that I have a deeper understanding of the problem.

When that is done, often the fix is simple, and the author's patch sometimes just ... isn't that great, often for entirely understandable reasons, so it's easier to just fix it myself "from scratch".

So whose patch is it then? In some cases the patch was useful and I'm "inspired" by it, in other cases I'm not. I tend to err on the side of caution, but I've definitely merged my share of patches where the Author field was, IMHO, kind of a lie.

As for code review: it's really time-consuming. And while a few "minor bug fixers" of today become "hard-core contributors" or tomorrow, realistically, most people show up to fix one bug and are never seen again. That's perfectly fine! But it does mean that "teaching" everyone who shows up quickly become an enormous time sink. There's a bit of a trade-off to be made here.

"This change is closely based on a well-considered patch from A. U. Thor <author@example.com>, who also originated the bug report."

A. U. Thor can point to that 10 years later and say he or she fixed that; nobody cares if the maintainer changed a few things.

>Sorry, just because you found this trivially fixable array mismatch doesn't mean your buggy patch has to be accepted the way it is.

I know reading is hard, but it's not an excuse to put words in other people's mouths.

>>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. I was also open to working with him, addressing his feedback and sending subsequent versions of patches.

So the maintainer now has to tutor this guy for god knows how long until he gets it right? All three issues brought up by kazinator are reasonable grounds for ignoring the patch. Do you think that the already overworked maintainers should have to spend significant amounts of their time tutoring every potential contributor? Are you going to pay them for that?

It doesn't sound like you've ever maintained an active free software project.

It's not "tutoring" to perform a code review and request additional changes to the patch. That's a standard feedback mechanism in free software development.

kazinator's analysis may be right, but it doesn't sound like it would have taken the maintainer more than a few minutes to explain his objections and given the contributor a chance to shore up his patch.

There's plenty of examples in the history of the kernel project of much larger patches going round and round until they land. From kazinator's description, it's possible the patch could have been made ready in a single review round.

> All three issues brought up by kazinator are reasonable grounds for ignoring the patch.

The patch (and bug report) wasn't ignored. That's kind of the point.

Miculas is not dumb; he's obviously a self-starter who pulled the investigation together through gdb, and the kernel interface, plus surrounding research into the history of the problem. He got excited to close the array access problem and lost sight of the necessity to fix only that and not change anything else, like the bounds check on the index. All it needed was a nudge to put his attention to that detail.

He could just have asked as a review of the the maintainers patch[1], e.g. work with the maintaner to fix it.

[1] https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...

I honestly don't know how two people could "work together to fix it" for an apparently straightforward patch where less than 20 lines are changed...

> I told him that..

Is this true though?

> Sorry, just because you found this trivially fixable array mismatch doesn't mean your buggy patch has to be accepted the way it is.

That's not really what anyone is suggesting should have happened. The maintainer should've just taken the two minutes of extra time required to checkout the OP's code, make whatever changes the maintainer wanted and commit it with co-authorship.

That clearly would've been the best course of action for the maintainer to follow (especially given that the OP expressed his desire to the recognized for his contribution) -- the best fix gets merged in and the work of others is acknowledged/respected. That said, I'm not surprised it didn't happen -- social niceties often seem to escape the maintainers of these sorts of repos...

Debugging is hard, sometimes very hard. Writing a fix on a familiar code base is comparatively trivial, especially having a working version of the prior fix as the guide. Writing the second version is always easier.

Saying that it’s a simple fix shows one doesn’t understanding the amount of work go into bug fixings in software development.

In this case Michael even acknowledged that he could not reproduce it initially but only later had it nailed down. This speaks volume about the amount of work OP put into debugging and fixing the problem. Robbing him of his work is just not right.

If you've been chasing a bug for a while and finally have a fix, you may have code blindness to ever-important issues not related to the fix. The testing you're doing is whether or not that problem went away. This is true even if you're familiar with the code base.

That's why we have pair programming and code reviews.

That same developer who spotted your code blindness today will exhibit that themself tomorrow.

The person not involved in the feature or fix is completely free to think about nothing else but "in what ways is this change wrong"?

I've written countless of patches / PRs for diverse OSS . Most of the times was to scratch an itch.

Most of the time as well the PR doesn't get accepted because of various reasons. I don't care. I do the PRs so that the code is out there. No I wont spent time making it "good enough " to merge into your repo. I provide it as is, and I'd someone likes it enough they can do the red tape.

Some of it has been just accepted and merged. Some was slightly modified by the repo owner before merging. Good for them.

I dont do open source code for the glory or to be popular, I do it because I like it .

Aaah I miss the 80s and 90s.

1. As I said in the original thread:

  There is already a check at the beginning of the function:
  if (index > PT_FPSCR)
     return -EIO;

2. fpscr will actually be written to by this line of code:

  +       ((unsigned int \*)child->thread.fp_state.fpr)
  +               [FPRINDEX(index)] = data;

3. This is a nitpick.

So please tell me how my patch was buggy.

1. The index > PT_FPSCR test isn't good enough:

  int ptrace_get_fpr(struct task_struct *child, int index, unsigned long *data)
  {
          unsigned int fpidx = index - PT_FPR0;

          if (index > PT_FPSCR)
                  return -EIO;

          flush_fp_to_thread(child);
          if (fpidx < (PT_FPSCR - PT_FPR0))
                  memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long));
          else
                  *data = child->thread.fp_state.fpscr;

          return 0;
  }

It is testing the original signed value of type int, which could be negative, and therefore convert to a huge unsigned int value manifested in fpidx.

(Also, the function risks integer subtraction underflow in "index - PT_FPR0". If we pass in the value INT_MIN, subtracting a positive value from it is undefined behavior.)

It looks like the original author knew that the -EIO test is too weak, so the converted unsigned value is tested again.

Regarding 2, accessing fpscr using fpr[32] is undefined behavior (out of bounds array access), which is probably why the original code is refraining from that, but testing for that value and separately accessing the member.

However is also this bit of uncertainty (I have not fully drilled into). On 32 bit PPC, that PT_FPSCR is defined with an extra offset of 1:

   #define PT_FPSCR (PT_FPR0 + 2*32 + 1)

I suspect that this is due to PPC being big endian; the + 1 displaces the index to the lower half of a 64 bit word. This also tells me that this fpscr register must be 32 bits on PPC32?

Thus, even with the range check in place, out-of-bounds access past the array is possible if user space requests the [64] index since the range check is testing for below 65. The [64] index isn't fpscr, but the upper half of u64 fpscr.

There is also the aspect that when we assign to fpscr, the whole 64 bit value is assigned, not just half of it.

Lmao, even GH does something where it's: "by ORIGINAL_AUTHOR, co-authored by MAINTAINER". Ah but the kernel is a special secret club indeed.

The correct thing to do is to leave these comments as a code review and let the contributor fix it. No one argued in favor of accepting a buggy patch.

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.

It seems he did get credit in the ‘Reported-By’ tag.

That doesn't give credit for 5 days of debugging. It gives credit for raising the issue, which was already done, six years prior.

Best way to get help with an issue is to post the wrong solution. I remember hearing that somewhere.

Cunningham's Law.

You could've demonstrated it by calling it the wrong name

The issue reported was arguably the lower-level one uncovered by the debugging. So I’d say they reported the result of their debugging.

... and their fix.

... and their results of forward regression testing.

There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. Ignoring that the maintainer literally moved one line of code (of about forty additions) and "contributed" it with himself as the author.

I'd say the maintainer plagiarized OP's code.

> There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution.

I don't really understand that either. Someone found a problem, researched it, found and tested a solution, voluntarily offered a patch, and everyone wants to pretend that it was nothing? "It was only x lines", "it was a simple/trivial patch to an obscure project", "It wasn't done in the exact way they wanted it". What is wrong with some people! It was a bug that was reported years ago but nobody took the time to fix it. This guy put in the work and delivered, which in the end is what matters.

But that's only credit for finding the bug, not fixing it. He put quite a lot of work into fixing the bug, and that credit got stolen by someone who merely rewrote his fix.

Since text in commit messages is free, a more accurate tag hurts noone but keeps the spirits up and encourages future work: Based-on-work-by, Investigated-by, ...

Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"

That doesn't cover the scope of his contribution

I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!". This is not how a project reliant on community efforts could sustain itself.

I always thought a project as big and respected as that of the linux-kernel would have folks who know better, and look out for the best interests of teh project while respecting new-comers. After all they were new when they started contributing?

I dont think anybody in their right mind would advocate for a "not best" solution to be accepted just because a new-comer brought it. The right thing to do would have been - "Here, I have reviewed your patch. This and This are troubling because of this reason. I'd recommend re-writing this like that. Tell me if you need assistance with this, and I can help write that part" and co-author such a patch. That's how you get a good pipeline of future contributors who also care.

> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!"

Frankly, I think that's a non-trivial problem to solve: how to get the assumedly better fix while not ruffling the feathers of the more junior contributor so not to discourage on-ramping.

I guess the best way to do it would be to have a co-authored-by tag, or something akin.

I see multiple people saying the authors fix was in a way inferior. Where is this mentioned?

It was stated by the maintainer as the reason for discarding the author's contribution.

What the maintainer actually said was [0]:

> 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?

Which to me, at least, reads very differently than claiming the author's patch is worse.

[0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

(Credit to nolist_policy for pointing this out upthread.)

We can't really know as we can't see the author's patch, but given that (i) the guy answering is responsible for the whole CPU architecture in Linux and (ii) the author mourns his putative contributor badge but does not criticize the other patch, that's a bet I'm ready to take.

FYI

https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...

Obviously the author is not going to say their fix was worse, but commenters on here have described why: https://news.ycombinator.com/item?id=37675544

see https://news.ycombinator.com/item?id=37692883

A pull request and some comments to help the author understand what needs to be adjusted is a common way to handle this with the projects that I work with.

On the other hand this can lead to getting stuck in a never ending code-review ping-pong game.

Having seen both sides of that table many times, you can see the value in someone who just gets the shit done. Especially since this was security related and may have had some urgency to get merged before a release. Imagining how much work these guys must have accepting patches you can sympathize with taking some shortcuts.

Nobody's saying the maintainer should have to do a never-ending code review ping pong game.

The maintainer is free to come up with their version and expedite committing it. The point is that if their patch is based on the original author's patch (which in this case it is; they just shuffled a few lines around), then the original author should've been credited as Author or Co-Authored-By.

Why? Theres no expectation for you to put in a lot of effort, and if in the hands of a domain expert, could have taken minimal effort. I'm sure everyone has had PRs that could have been resolved in minutes if the submitter had reached out first.

Complaining about it reeks of a junior developer mentality.

You miss the part where this was a bug that was reported 6 years prior?

> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!".

Then you shouldn't contribute to someone else's project.

It is not “their” project now is it?! This attitude never gets anywhere productive. It only encourages gatekeepers.

I didn’t say I’d be pissed if my contributions are turned away. Every project sure is entitled to say - we don’t need your contributions. But that’s not what happened here. They received this blog author’s contributions, suggested revisions - which they seem to have made and spent time on, and then to only flush them out at the end.

By your logic, if you don’t want someone contributing to your project, just ignore the contribution or say that you don’t want them - do not take it without due credit.

It is their project. They are gatekeepers. They don't have any real obligations regarding your contributions, baring a legal issue.

You can, of course, fork the project, or do whatever you want with the code.

> The linux kernel isn't a reward

It certainly seems that you're correct judging by the article, in the worst possible way.

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/lin...

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.

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.

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.

> it's a four line bug fix for a very old issue on a non-mainstream platform

This thinking is what commercial software market dominance is made of. People unwilling to make the software move from the 99% case to the 100% case because those with the authority to hand out credit can't even be bothered to do that. Meanwhile, corporations just pay their people for scutwork, including the unsexy kind like making the software work correctly on a corner case architecture, and while credit isn't given, money is.

If anything, credit should be given even more freely for fixing old problems. "How the hell is this bug 6 years old and still here" is a common criticism of open source software.

It's hardly putting somebody's name "next to" Torvalds to note that they isolated a buffer overrun and contributed a correction for it.

I'm all for the 'Suggested-by' tag but still note that the maintainer did not act in a way that maintainers for the Linux kernel have been acting for pretty much as long as the kernel has existed. Security holes get plugged, credit is secondary to that, and drama over that credit is showing a large misunderstanding about how the Linux kernel has historically dealt with drive by patches, especially small ones.

Sure, but how do we know that's the case here?

By reading the email exchange between the OP and the kernel maintainers. Which is materially misrepresented in TFA.

The contribution is not miniscule. It can take hours or even months to come up with some 1-line fixes.

As long as you insist in measuring contributions by the way the patch looks, I can't take that seriously.

How come you didn't fix it? I'm sure it would have taken you only 5 minutes to find it and 2 more minutes to write a fix.

Well, they're not going to send in any more work that requires this standard of debugging, so the kernel will remain insecure in those ways. That isn't great, but perhaps we'll each just have our own preferred kernel flavors like how a bunch of us would use Con Kolivas's alternate scheduler back in the day.

And that way, forks being present, attribution is required for copyright and hence, copyleft.

And that's precisely the bit that the OP omitted.

I haven't compared the patches but a comment below [1] says:

It sounds like the author did quite a bit more than "suggest" the patch idea. They debugged the issue and wrote an entire patch which was accepted with one small change.

1: https://news.ycombinator.com/item?id=37672558

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.

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.

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

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.

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.

Could have OP presented their case in a more neutral manner? Sure. But it is nonetheless an extremely frustrating situation that was handled terribly.

Right?! It's so disappointing to see so many toxic comments here. This thread feels a little like one of the worse ones on LKML. The guy literally did 95% of the work and he gets criticised here for wanting to be recognized for that. What is wrong with people.

If you have an overeager junior that went off and spent a week resolving a task that wasn’t prioritized and wasn’t what they were supposed to be working on, I think you could rightly take them aside and tell them “we’ll have to table this for now and come back to it later. Right now we’re prioritizing X and can’t be spending time on…”.

Being a professional is partly about learning how to dissociate yourself from your work, and to realize 99% of the time, your teammates aren’t trying to sabotage you for some nefarious scheme. We’ve all worked on projects for months that eventually got canned. We’ve all gotten rough comments in a code review. It’s up to you as a professional to take those things in stride and learn from it rather than letting that stuff destroy your morale.

And of course, the people who are blunt and rude will also have to learn that being blunt and rude ruins many relationships. But we’re all professionals here, not artists.

If a junior civil engineer was building a bridge and ended up designing it with structural defects, and the senior engineer came up to him and said “I’m sorry we’re just going to have to redo all this because it’s unsalvageable at this point”. The senior is perfectly fine in this case! I don’t want to drive on shoddy bridges built to protect a juniors ego.

Edit: I also think a lot of the comments responding talking about how toxic the maintainer is may not have much experience maintaining a large open source project. I’ve had contributors for some of my OSS projects, and accepting a PR from a random person is a lot of work. Often, it’s more work than doing it yourself. The amount of time needed to carefully review the code, communicate with the contributor to fix issues, make sure the code is upholding the expected quality and expectations is immense. At a job, a junior has already been vetted through an interview process. It’s not some random stranger requesting a change. There’s way more factors here than many of the dissenters here seem to be taking into account.

And getting a PR rejected does suck. But having been on both sides I understand both sides. It’s a difficult situation and it’s hard to resolve these things without upsetting someone unintentionally. (Based on the maintainers communication, it doesn’t seem like they were being particularly nasty or rude).

Yeah, this thread is a lightning rod for people demonstrating bad interpersonal relationships and it’s really cringeworthy considering what the age range of HN readers can be.

There's a difference between managing or coaching juniors in your company/team, and random persons on the Internet offering a tiny patch.

There's an expectation for junior devs on your team to stick around for a while, and presumably there was an interview process that established some baseline ability so you're reasonably confident that they can grow towards your expectations.

The random person on the internet isn't obliged to stick around, and most often for these kind of "drive-by" fixes they won't be. You don't know the actual abilities of this random person and how well they'd respond to your comments on their fixes.

If we're talking about management, IMHO one of the most frustrating things of managing people is when somebody else assigns random people as your reports and you're now responsible for their performance. Now imagine some random self-entitled person on the Internet spent a couple days working on a sub par fix, and now you're responsible for coaching them as if you're their manager?

The analogy is honestly ridiculous.

I often wondered what the big fuss was about when people talked about hosting projects on github and unwanted PRs (eg. https://news.ycombinator.com/item?id=25940799 )

Now I kind of understand. Not wanting to deal with random PRs and you'd be accused of "destroying morale, wasting people's time" and being a bad manager. Such insane ideas of entitlement...

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.

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.

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.)

Should be in your "Sent" folder right?

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?

Ok I've forwarded the email thread: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...

Forwarding a random email conversation from a year+ ago without any context to public mailing list that is read who knows how many people just to get it into an archive so that you can link to it in HN comment does not really help your case.

And if you care so much about getting your code into the kernel you should consider replying to this: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...

On a related note Christophe Leroy should be applauded for his calm and matter of fact response. I don’t know if I would be capable of that.

You can export the eml of the sent mail

Same for the original patch from the mailing conversation above. The original results in (reformatted)

  #ifdef CONFIG_PPC32
       *data = ((unsigned int *)child->thread.fp_state.fpr)[FPRINDEX(index)];
  #else
        flush_fp_to_thread(child);
        if (fpidx < (PT_FPSCR - PT_FPR0))
                memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long));
        else
                *data = child->thread.fp_state.fpscr;
  #endif

while the final patch is

        flush_fp_to_thread(child);
 if (fpidx < (PT_FPSCR - PT_FPR0)) {
  if (IS_ENABLED(CONFIG_PPC32))
   *data = ((u32 *)child->thread.fp_state.fpr)[fpidx];
  else
   memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long));
 } else
   *data = child->thread.fp_state.fpscr;

So there is actually a difference between both solutions. The original has neither the flush_fp_to_thread not the else-condition for the PPC32 architecture. I cannot say which is right/wrong/better but it's definitively a different result.

There's a clear logical difference in those two patches and I can't blame the maintainer for going with his version.

Attribution should be given though, regardless of the bug OPs patch introduced the actual line that fixes the issue is clearly the same thing with the appropriate coding style.

As a maintainer, I can understand his reasoning but TBH it would've been easier and more respectful to just reply with the proper code snippet, having the contributor submit it (if he agreed) and then giving them credit.

Honestly, the comment section of this thread sucks, the level of self righteousness, "aggression" and gatekeeping is ridiculously uncalled for.

Agreed. You basically get paid in reputation, trustworthiness, and maybe even beer/brownie/pizza points.

I also think that public interactions offer a preview of how easy (or difficult) it will be to work with someone on a project... we're not experts on every domain of knowledge, so the best bet is to approach interactions with a bit of humility and respect.

If this were an AITA reddit thread, ESH (a little bit).

As an old C programmer, I'd be wary of code sent to me with a bunch of custom macros. That might indicate a certain immaturity with C. Maintaining a large code base is part fire suppression and part avoiding name collisions.

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/lin... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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.

I really feel bad for the maintainer. Its already hard enough of a job without this sort of stuff.

Yup. Incredibly unprofessional and a pointless emotional outburst. I felt second hand embarrassment from reading the blog post.

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.

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.

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.

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.

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.

Woah, that stinks! Any you care to name and shame?

Won't do, but apparently building up your contribution score helps finding a job at Google.

As a maintainer of small projects, I love when people contribute code or tests. I try to help them get the code in a good place with regards with the rest of the code base (this is the hardest part, as most developers do not follow project conventions as they just want to push the fix without first having to learn about that), but will accept patches as soon as I see that the code is approximately right and just needs another 15 minutes of my time after merging to "polish" it up and perhaps add a few more tests and things like that... I think that was the case here, and the maintainer should've done that. The person would get the credit, the maintainer would just spend a few minutes doing the necessary clean ups to get it accepted upstream, everyone would be happy. Saying "my version is better" is extremely obnoxious behaviour and unprofessional, regardless of whether it's actually better. If you haven't fixed the issue in 6 years since it was first reported, you should admit that without the person's contribution there just wouldn't be a fix by you, so taking the fix once you've been shown "a solution" is really kind of stealing.

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.

> 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

"Perhaps then we should make all contributions anonymized, so that we can ensure people are contributing for what we think are the "right" reasons".

> 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.

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?

> If you walked into a company unannounced and started doing work no one asked you to do (which is a far more accurate analogy)…

This is not analogous at all. The very premise of open source involves contribution from a community of volunteers. Contributing code to a project that accepts contributions from the public is the way things are expected to work, and is about as far removed as it can possibly be from showing up at a company unannounced and expecting to receive pay.

People contribute to these projects for a variety of reasons, but at the base of it all, it’s a very human endeavor, and in lieu of receiving monetary payment for productive work, proper attribution for contributors is about as low of a bar as one can set, and should be the minimum standard.

If the “kernel contributor” badge conveys something more than the maintainers are willing to convey about a contribution, there should be something that does.

That's a good point. Patch contributor would be a nice starterpoint I think, but it smacks of 'GitHub badges'. Note that if you create a metric like that it will for sure be gamed.

I would say even “recognizing original author and presenting yourself as an editor” would be even more fair.

> 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.

Especially after OP notes that the issue had been reported on and subsequently ignored for 6 years. Pretty lame behavior by the maintainer IMO.

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/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/24...

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.

> Misrepresenting the actual statement this way is garbage. There's a world of difference in the two statements.

That's debatable. What's not debatable is that not giving OP credit for the fix is disrespectful and bordering on plagiarism.

Even if OP's patch wasn't as good as the final one (and giving OP feedback + time to improve their patch themselves isn't an option for some reason), not giving him credit is wrong. This bug would have remained were it not for his effort debugging and developing a fix, and his company investing the development time on it.

I expected the maintainer to be bit of an asshole. Apparently they were totally respectful. They probably figured `Reported-by` is good enough credit, not putting themselves in the author's shoes (we all do this all the time). The author could have e-mailed the maintainer back and ask them to review their attribution practices and that would've been it. Instead they wrote a scathing article.

It’s not debatable at all. It’s simply malicious to put something someone never said in a block quote to make them look bad, especially when the block quote font size is like twice that of everything else. They also cowardly added a “(paraphrasing)” outside to cover their ass. (Edit: in case it’s not clear, I’m not saying they added that after the post was published.)

They achieved their goal: look at how many comments assume that malicious “paraphrasing”. They also made sure those of us who aren’t so quick to jump to conclusions after hearing a one-sided story will never interact with them ever.

Malicious or a mis-remembering?

Conveniently misremembering a quote and making that gross misrepresentation a callout is indistinguishable from malice. I cover my ass by avoiding people who commit deniable acts indistinguishable from malice.

The OP did say he was paraphrasing.

Except that's not what the maintainer said! OP's putting words in their mouths, and getting mad about that. That's not a winning strategy in life, especially where text communication is concerned.

Actions speak louder than words. At the end of the day, the author was not credited for doing most of the work of fixing the bug. I'd be pretty mad too.

Actions do speak louder than words. The code that ended up getting committed is the only real action here though. Everything else is words. Who wrote the original code, who wrote the commit message, what words were in the commit message. At the end of the day, if we concentrate on the action, and not the words, then we should ignore who said what and look to see if the bug was fixed and if the code works.

Don't get me wrong, I'd absolutely be annoyed too, not to get more credit than a "reported-by", but: you are not your code, and the bug got fixed.

The actions include finding the bug, debugging it, and proposing a strategy for the fix that ended up being adopted in practice. All stuff the maintainer did not do but took credit for.

Actions do speak loudly - such as misrepresenting other people's statements so they sound worse than they are.

He didn't actually author the patch. He did get a reported by credit. If you look through the thread, he clearly got some mentorship from the maintainers because the first attempts weren't maintainable.

Moreover, what is the guarantee the maintainer won't pull another one, will say that he again likes his version better and point to yet another bug?

The actual thread shows the maintainer implementing the fix in a way he found better and prepping to do the backports for other stable kernels. The actual response was "Thanks for your patch, but I wanted to fix it differently" and gives him credit for reporting.

The suggestion that the maintainer "pulled" something here is quite something. Is there any evidence that the author ever tried to ask for more credit aside from carping about it on their blog in public?

If there was evidence that they'd gone to the maintainer and said "um, hey, I feel like I should get more credit than that" I might feel more sympathetic. As it is, they misrepresented the words of the maintainer and played the victim. If there's evidence they have tried to correct this on list then I might feel differently.

At this point, only Michael Ellerman could have this evidence in his mailbox. I've switched companies since then and unfortunately I don't have the private email exchange which happened between us (I've emailed him from my corporate email address).

Except... that's not how it happened at all. OP makes it seem as though the exchange was disrespectful but it really wasn't.

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.

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.

I made a feature contribution to Xen years ago that ended up with a few lines in the kernel. Got merged pretty promptly but no credit that I can find.

I didn't notice at the time but now I'm job hunting, past credits seem a bit more important.

My interactions have not been so negative. In particular Greg Kroah-Hartman is a saint for helping me get acquainted with kernel development by providing very patient feedback as I contributed a series of patches.

Other maintainers have been similarly responsive, though the tone is typically "very technical feedback from a busy person" rather than new-developer-relations. These people receive patches of random quality, often from one-shot contributions. Triage of the patch stream must be pretty exhausting.

I completely understand why people want their name on a kernel patch - it's pretty cool and a good thing to have on a resume - but at the same time, the bar for contributing is quite high and I think the dev process should not optimize for newbie contributors.

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.

> 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.

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.

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

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.

A bug report for this issue had already been filed, and years had passed without it being fixed.

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.

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.

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.

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.

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.

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.

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.

> 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.

Not exactly. Reported-by is for reporting the symptom; the root cause analysis is separate (and often requires much more work).

Some do, some don't. The chances of getting something fixed increase with the amount of prepwork that you do. I try to include as much detail as I can when reporting a bug, typically those reports get ignored so OP materially improved his chances by doing that, but root cause analysis is still covered by 'Reported-by' as far as I can see.

> 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.

It is generally a very bad strategy to do unasked work and expect appreciation or gratitude in return.

Which is why the OSS model never took off. Or wait...

Most of the work was probably debugging the issue and pinning down the cause. I guess we have all had issues which took a lot of time to debug, but the actual fix was just a few lines (or even just a few characters). And you have to do that work "up front" - I mean, asking the Linux maintainers in advance if they're ok with you trying to pin down an issue you're facing would sound a bit strange?

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-...

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-patche...

> 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

> 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.

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.

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.

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.

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!"

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!

Assuming computers will still be programmed by then. I think your observation is spot on by the way.

It’s probably a good idea these things are pointed out these days.

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.

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.

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?

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.

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

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.

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)

Personal secretary was sarcasm, "personal coding assistant" would be more accurate.

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-Sof...

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.

Generally the value that you would bring with your fix is not worth the burden you put on everyone else. There are many hobby projects with a more open attitude specifically for this reason, because they are willing to take this burden for the sake of having people feel good about contributing. Try Serenity for example. Most open source projects obviously will not have such an attitude.

Which is why my bug will never be fixed by those projects holding on their attitude gatekeeping for the benefit of... not sure, you tell me.

> for the benefit of... not sure, you tell me

I just did. Because the burden of dealing with an annoying contributor outweighs the value of their contribution

I mean, we're not talking about contributors who implement a whole new feature which you hadn't planned and want you to merge it, we're talking about bug fixes, which are generally short, and their value should be easy to gauge?

Would you simply accept a random persons PR fixing a bug without basically re-doing all the work? I know I wouldn't.

Even a simple line change (especially in huge projects like the kernel) can have unexpected consequences. Your fix might fix the bug in question but cause others down the line. It can make the code harder to maintain, not fit style guides, etc. There are numerous issues caused by these "drive by patches".

Unless you actually maintain a project or is heavily involved, it's easy to miss the forest from the trees.

Ironically, the person sending the patch is most times being paid by a company to do so (since they are fixing an issue they found) while the maintainer is most likely unpaid/underpaid.

I've had a very small experience maintaining a library and already had to deal with "bug fixes" that take huge swaths of your time and simply cannot be merged. So I empathize with the maintainer here much more than the Cisco employee that was allowed days of paid work to poke around the issue and tried to fix it. The maintainer very likely had to reproduce the bug and consider any implications of the fix beyond what the author would have by the simple fact he actually maintains that project.

Personally I think a co-authored tag wouldn't hurt, but I cannot blame the maintainer for not having that in his mind when he's focused in doing his job (which is, again, most likely unpaid/underpaid).

But I can't help but feel disgust from a paid Cisco employee bashing an open source maintainer simply because his ego got slightly bruised.

Yeah, those pesky contributors...

Drive-by contributors are not what most projects need

Repelling drive-by contributors usually pertains to people who want to dump massive amounts of feature creep into existing FOSS. There's a legitimate place for not adding Bobs massive feature list all at once because you don't know if Bob will be around after 2 years and you end up cutting most of them because you can't figure them out.

The last place biting drive-by contributors should apply is for bugfixes. Bugfixes are one of the most common ways beginners/newcomers are incentivized to contribute (and keep contributing), especially to FOSS. Even Stallman, who otherwise is someone who I would not consider a good example for any kind of communication, implicitly acknowledges that if you're a maintainer, you should try to work with people submitting patches to get them merged rather than antagonize them because of your possible maintenance burden[0].

[0]: https://stallman.org/stallman-computing.html (see the how to learn to program section, which while largely bad advice on actually learning how to program, does have the nugget that "fixing bugs is a great way to get into FOSS dev" and "most maintainers will be happy to receive your patches and work with you to get them formatted and correct", which is imo implicit advice for maintainers to be kind to new contributors.)

I don’t know that seems like a good way to make sure no one knows how to maintain these things after the core contributors die. I’ve seen PR ping pong mentioned elsewhere and it’s odd because “PR ping pong” is part of how I became an effective member of my team and eventually eased some of the load for everyone else.

My experience with many patches was that they just sit some place ignored for years until they cannot be merged anymore. Not even rejected, just silence. So let's not claim that the project full timers were some kind of all-knowing all-powerful benevolent gods. They are humans too and nothing better than the casual contributors, so only when there's a match it works.

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)

> 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.

"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.

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.

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.

"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...

It is when you'll now get grouped in with those who just say "X doesn't work"

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.

No, it is merely a hyperbole. You are right in the legal sense, the maintainers don't owe him to put his name in the copyright header. There is no legal IP for the root cause analysis part of the work.

However arguably root cause analysis is a significant part of fixing a bug, often much more work than writing the lines that fix the bug. A "reported by" is not an acknowledgement of this kind of work.

IMO the author earned an opportunity to write the patch themselves with the guidance of the maintainers. What the author got robbed of is this opportunity.

> earned an opportunity to write the patch themselves

Doesn't work that way when it's declared a security problem. Fix ASAP is the only way forward for those.

> No copyright was infringed. Where is the theft?

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.

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 :) :)".

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.

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!

Someone trying to claim significant work experience based on a single patch would be a huge red flag. This blog post is a red flag on fire.

Oh, I wasn't suggesting that someone claim significant work experience, far from it. To prove your capabilities from FOSS contributions, you either have to (A) stick with one project for a long time and build up a strong reputation, or (B) make many small-ish contributions to a wide variety of projects. It's in that latter case that, without public credit, it can be difficult to prove to a potential employer that you really did the work.

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.

The maintainer never said "I like my version better". That was completely made up.

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.

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.

> 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.

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?

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".

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.

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.

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.

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

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/m...

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.

I used this word to emphasise my strong feelings about the situation.

    Bug discovered by Bob
    Initial fix by Bob
    Fix refactored by Chris

How difficult would that be?

It might prove difficult if Chris has been at IBM for over 20 years.

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.

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.

Not too long ago, this was actually discussed on HN here: https://news.ycombinator.com/item?id=33742130

Tbf the maintainer said the behaviour showed up in one of the existing tests, so effectively they already had it.

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.

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...

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/ -- typically (non-platform) subsystem maintainers write their own stress tests. But stress tests are merely probabilistic.

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?

The problem was fixed. The goal was reached.

Not everything in life is about getting a golden star in your grade book.

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?

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.

You have control over the inputs but not the outcomes :)

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.

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.

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.

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.

>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.

This sounds like they didn't understand what they were signing up for. If I lead a project, I get to take credit for the project not for specific IC work.

Of course if you happen to do IC work as well it makes sense to take credit for that, but I think that mixing leadership and IC work tends to result in burnout.

How would giving credit to the author of the article (the person that did most of the legwork) cause the project maintainer to feel unhappy ? I simply don’t get that.

The project maintainer surely would have not felt bad giving credit to someone ? Exhibiting this kind of leadership usually makes me feel great !

On the contrary, as we see from the article, the lack of credit really did create unhappiness from thin air…

I agree that in this case the maintainer should have at least put then as a co-author. At the same time the maintainer should get credit for their own on the improved patch. Middle ground versus extremes of leader get's all explicit credit or leader gets no explicit credit.

Low expectations is recipe for a very sad life

If you can be happy with nothing, you win life!

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.

Exactly the opposite, actually.

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).

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.

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.

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. Definitely not to be pessimistic about anything, quite the contrary - be optimistic that you'll be positively surprised!

Regardless of all that I hope you work out your depression, it sucks.

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.

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.

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?

>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.

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.

My thoughts exactly.

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.

> 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

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.

> 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)

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.

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.

Great! So I can hand you all my work and you will do it, I will take credit, and you will be happy?

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.

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.

Everything in life is about golden star stickers

  > 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).

I sure hope nobody's getting a job based on a single patch.

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.

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.

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.

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.

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.

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.

> just sent the maintainer an email that he thought he deserved more credit would have been all it took to get it fixed

Agreed completely.

> workload on the part of the maintainer(s) ... unfamiliarity with the various processes ... absence of even clearer rules

Yes these all contribute to the problem. The 'culture' of an open source project is basically opaque to a new contributor, no matter how "open" project's comms are a new contributor can't read them all. That's why it's unreasonable to expect them to be able to completely understand the rules, processes, and workloads that affect everyone involved in the environment where they are just making a new contribution.

Which is why embracing the messy humanity and going all in on radical candor is the best solution. The other option is giving every new contributor a 10M word reading list just to catch up on the context, which is so impractical it's hardly worth mentioning.

One issue may be the perceived intentions of the OP in the original conversation, they did mention credit but they also switched to their corporate email right in the middle (probably because they used company resources or to give the request more weight) which could have been easily interpreted as 'Cisco wants this stuff fixed pronto' and that may have been a misinterpretation about the goals of the OP, which - given the time span involved between the original fix and the blog post - may well have shifted over time.

But Michael Ellerman's graceful apology puts to rest any kind of perceived bad intentions and the way the pitchforks have been brought out here to skewer a maintainer that simply made a - small - mistake in the heat of the moment is reminiscent of the the treatment of some other maintainers who chose to step down instead of to continue to be dumped on for just getting their job done. The OP made mistakes and did some questionable stuff, Michael Ellerman made a mistake but to me seems to have maintained the high ground from a moral perspective in spite of all of the vitriol here, including that from the OP.

If anything that thread is a model of restraint.

Oh I found the thread with Michael's response, I hadn't seen that. I think your assessment is reasonable.

https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...

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.Followthroug...

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.

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.

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.

I make most of my open-source contributions quasi anonymously, and don't want attribution. Does that make me the odd one?

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.

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.

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.

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.

The correct title would be „Why I am offended instead of happy that a problem got solved“ ;)

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.

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.

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.

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.

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.

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.

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.

"don't give up, there's so many jerks you still have to meet!"

not exactly encouraging

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.

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.

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

Because you actually just want to improve it?

If that were the only consideration, the kernel could be placed into the public domain.

Is attribution the only reason for the GPL??

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.

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! :)

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.

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.

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.

One thing I like very much about using git and github is the provenance trail of every contribution.

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.

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.

> 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

Relevant Jonathan Blow: “The idea of a pull request is offensive”.

https://youtu.be/XLVjSeusPYg?si=NbTzVx6QlB337zSs&t=25s

Reading now with the updates, I think the issue was overcome, glad to see such cases :)

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.

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.

Does that mean if I've been contributing anonymously I've been robbed of every contribution?

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.

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.

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.

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.

can't wait to see how these things go once Linus steps down and Linux continues without him.

You think egos are big now...

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.

> 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.

If someone is more interested in receiving credit than fixing bugs, OSS might not be the best place to hang out.

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.

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.

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

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.

> 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.

Reported-by is the normal response for this kind of patch, 1000's of examples in the kernel mailing lists.

This whole thing tastes to me like a pay-off for an unwanted gift, you don't go into this sort of an exchange on a security mailing list expecting kernel contributor credit for fixing a bug. That's just not how it works. Maybe it should work like that but it simply doesn't. OP had pre-set expectations and those were found to be in the wrong, nobody got 'robbed' and misrepresenting the exchange to one that makes the kernel maintainer seem like an asshole when that wasn't at all how it went down makes me feel even less good about the whole thing.

Reported-by ranges the gamut of 'I ran into this bug' to 'I found this issue and here is my patch, which I hope is useful to you'.

If you want to negotiate credit rules for 4 line patches up front you are of course welcome to do so but keep in mind that maintainers can and do accept patches, rewrite them and contribute them under their own name (and their responsibility), especially security patches.

I don't think the number of lines is relevant. A patch is a patch and the author should be credited as such.

> Maybe it should work like that

Definitely

> A patch is a patch and the author should be credited as such.

But the patch was not taken. The maintainer fixed it a different way. So credit is given for reporting the issue and suggesting a fix, and that is what is represented by the Reported-By. Is that so hard to understand?

its the suggesting a fix (ie doing the research) thats missed, anybody can point out a bug

No, that's not what "Reported-By" means. The kernel community has different conventions.

This entire HN comment section is ridiculous with everyone acting as if the author wrote an entire subsystem and someone else took attribution.

The author here figured out a bug and suggested a fix. It happens that they conmunicated their fix in the form of a patch, but that happens very regularly in kernel land.

In the end the author got a Reported-By, which is entirely appropriate for what happened. If the maintainer accepted the author's patch as-is or with minimal modification then yes, they should get Author attribution. But the patch that was taken was substantially different.

What is interesting about this whole thread is that apparently a whole raft of people are ready to string up the kernel maintainers for doing what they've been doing for years rather than to stop to question whether the first time contributor may have a communications issue or a different set of expectations than that which is the norm for a project that has been going for a couple of decades.

Weirder still because all of this has been done in the open for all of that time, it's not as if how the Linux kernel is maintained is a secret.

Questioning the consensus is how things evolve and hopefully progress.

I can't believe people are trying to extrapolate this situation into how someone would act as a manager in a company.

Can't you see that the kernel has its own conventions and practices that are entirely different from typical corporate practices?

This isn’t even remotely close to what I said, and I can’t even see how it could be misinterpreted so badly. Did you reply to the correct comment?

If receiving credit is your primary motivation, over actually solving problems that affect people other than yourself, I don’t think that’s a great attitude towards OSS. I’m genuinely surprised this is even considered a hot take.

Why not? OP identified a problem that affects everyone and inplemented a fix. Maybe the original fix wasn't as optimized as it should be, but they deserve proper recognition nonetheless. In the OSS world, recognition and reputation are important.

And who are you to decided that? How about people who demonstrate incredibly judgemental behaviour such as yourself, do you have a place in OSS... and is somehow qualified to judge who else does? Don't think so.

I’m not deciding anything. I’m saying that if credit is all you care about, OSS isn’t the best place to hang out, because credit is not guaranteed.

Yeah, I’ve contributed to OSS. And more often than not, I haven’t received credit. I couldn’t care less.

> 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."

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.

> 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.

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.

> 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.

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.

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).

> 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. :)

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.

> I get that true altruism probably doesn’t exist

It does exist, but unfortunately people who practice it are not believed by those who do not, because they cannot fathom it.

> 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.

> Not crediting them is plagiarism.

not if it is a substantially different fix.

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.

> 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.

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.

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?

Fair enough. I've attempted to reword this to be more considerate of the possibilities.

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.

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.

I’m not sure I understand what that has to do with my comment.

IF the code someone writes deserves to be included in a project, they deserve to have their name attributed to that code. You acting like there is some threshold of code to submit before someone's authorship is recognized is weird.

When you submit a patch to LKML you propose a fix, and if your patch is properly formatted and cleanly merges without further changes then it may be included as is. Or it might be parked until that section gets worked on in a larger context. In no way should your expectation be that your submission will be included verbatim and that you will be registered in the gitlog unless the maintainer decides that it be so.

Note that you are talking about a project that is older than quite a few of the people on HN and that it pays off to know how such a project operates before attempting to contribute, more so if you plan to go nuclear about your expectations not being met.

Finally, and if you do go nuclear it helps if you don't materially misrepresent the interaction with the maintainer, who did not exactly ask for your contribution.

We don't have to discuss what might happen. We have a specific instance of something happening. In this case someone submitted a patch, the patch with a 1 line change ended up in the kernel. There is no need to talk about maybes, contexts, or what ifs. The kernel maintainer took someone else's code and put it in the kernel under their own name.

https://elinux.org/images/0/06/Lca13-gregkh-I-dont-want-your...

https://www.cutenessoverflow.com/cute-and-adorable-puppy-pic...

So?

> 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.

> 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.

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.

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.

> Linux seems to be doing just fine.

"just fine" is not what we aim for. "just fine" is probably what they thought of the OpenSSL library before heartbleed.

> Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.

Sure but it sounds like you're making a generalization about a specific instance you know nothing about. There doesn't seem to be an enormous cost detailed by the maintainer in the email thread. Just that he'd rather gatekeep the project and rob someone of the opportunity for contribution.

Linux is doing more than “just fine” and is in no way similar to OpenSSL.

This individual wasn’t robbed of the opportunity for a contribution. He received credit for his contribution via a reported-by flag. It’s a tiny patch — all the work was in identifying the bug, which is what he received credit for.

He did something valuable, and has every right to write it up, but clearly has limited understanding of the development process he’s participating in. It was wildly inappropriate of him to of put anyone on blast in response to this.

Once, I learned that someone wrote a "security patch" for another project that embeds mine. They focused solely on the part where their fuzzer caused a crash, they wrote a patch that, in their mind, fixes exactly the problem they found. But the patch made no sense - it added a check mid-loop for something which was an invariant. The actual wrongness was in an entirely different file, it was passing invalid initial values, and checks needed to go there instead. I fixed the issue in my project correctly, and in the changelog I gave credit to the original person for both discovering the security flaw and providing a patch... that I didn't use.

In another situation, I was using an emulator and it didn't read a file correctly. I read its source code for the first time, I fixed it, in what I thought was the right way. I supplied the bug report and the patch. The maintainer thanked me and fixed it a different way - a way that wasn't obvious from their code, but was a better fit.

In another situation, I found a library that sticks out like a sore thumb and doesn't accept values that other libraries do (the standard they're all aiming for says the value is "implementation defined" so this is technically allowed but it annoys me). I raised a bug. I offered a patch. The maintainer had a bug up his ass about this particular value and told me he was changing nothing. Not much I can do about that.

In conclusion:

FOSS maintainers aren't endless fonts of personal validation for you. Some of them don't even want contributors. They already gave you the software for free, _and_ the legal means to fix it yourself. You can patch it, you can fork it. Your fork might be better than theirs!

They might accept your bug report. They might review your patch. They might accept your patch. They might mentor in you how their project works. They might devote all their time to contribution management and never have time to write their own project. Each of these takes their time and energy. They don't owe you any of that. Not every project is a popularity contest, not every project wants your help. This is all OK.

It isn't sustainable, and it's a sign of bad leadership waiting for the proverbial (or literal) "hit by a truck" principle to show up.

You are correct in that it is the maintainers's choice. No doubt about it. But now, a potential contributor who invested a significant amount of time in a problem clearly nobody else had solved up to that point, was snubbed. The work was capitalized on, used as a foundation for a solution, and not even a comment giving credit was given.

This sends a terrible message not only to them, but to future contributors as well on a project that needs a new generation of talent to perpetuate it. This isn't just any OSS project; this is the Linux kernel, something millions if not billions rely on. Scale up this behavior, and it won't end well.

> It isn't sustainable, and it's a sign of bad leadership

It can be sustainable; not all FOSS projects need every possible contributor. Being a good leader is not a prerequisite, either. Direct cooperation isn’t even necessary!

The fact that source code is available allows anyone to fork and compete with the original authors. On average, only mismanaged projects will get out-competed by their forks.

You're making some poor comparisons to justify how things were done in this instance. What actually happened here is someone encountered a bug, they diagnosed the bug, they fixed the bug, they brought the bug up on a mailing list, they updated their fix, they submitted their fix. The maintainer changed 1 line of their fix from an #ifdef to a macro that has the same ultimate effect and then stuck their name on the fix.

Beyond the morality of doing this, there is a practical consideration of copyright issues. OP did that as part of his job. OP and his employer have some sort of agreement of ownership of these 30 lines of code and the maintainer putting his name on it and putting it into the kernel could someday be a problem.

> Why is the fix by the author inferior?

The maintainer deemed it inferior and they are the one to decide. By posting on a security list, the maintainer went out of their way to give the issue critical priority, speedy processing and extra critical correctness review. We all like the feeling of credit, but this context is very important.

It's too bad the proposed fix wasn't good enough, but getting the issue resolved is always first priority, above getting claim to the fix.

> We all like the feeling of credit, but this context is very important.

Exactly, this is why a field "co-authored-by:" is a nice middle ground that allows for providing partial credit to the original author while maintaining maintainer's freedom to rewrite the whole damn thing.

Linux does not use Co-authored-by.

There was no Signed-off-by in the original patch, and the rules say Co-developed-by also requires a Signed-off-by.

It was a security issue and was fixed ASAP, not waiting to hear back from the submitter.

https://kernel.org/doc/html/latest/process/submitting-patche...

> the proposed fix wasn't good enough

That hasn't been proven, we need to see the patches.

> That hasn't been proven

It was decided by the maintainer, the only person who can make the decision.

> we need to see the patches.

... they are linked in the post.

I think the maintainer's post mentions that he solved the problem by making a special case for 32bit instead of introducing conditionals and macros, which I assume was what the reporter had.

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.

> 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?

> 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.

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.

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.

Just because the patch was urgent is not an excuse for not giving proper credit. Co-author appears to be the minimum credit.

There are typically multiple ways to write code to address a given issue. They might differ in aesthetics (including clarity of intend), but also performance, maintainability, extensibility and robustness. It's not uncommon that those who wrote the code to be fixed rewrite the patch in order to improve on aforementioned properties while avoiding lengthy back-and-forth when asking for improvement of the patch. They are often in a better position to do so due to familiarity with the code, it's history and (unwritten) development path.

That is by no means plagiarism. If not communicated clearly, can however lead to disappointment of those who submitted the patch. An 'inspired-by' comment would have been nice.

Yeah it just seems like a bad strategy on the maintainers part. Seems like one of those perfect places to teach a new contributor style guides and make them more useful in the future. To me approaching it this way comes off as disinterest in welcoming new contributors, which maybe now they’re not needed, but being so unwelcoming could one day leave us with no one capable of maintaining these projects.

It is plagiarism by definition if you don’t give credit to the person who wrote the original patch. Paraphrasing a source without citing it is certainly considered plagiarism in non-programming contexts (even if you think that you improved the prose style).

A patch, by definition is a modification of an existing piece of code, in this case a very small one. Now, it is possible that copyright protection would apply to such a small piece of code in that context but plagiarism usually does not involve a perfect record (the mailing list where the patch was submitted) that states exactly where the original work was submitted, what was done to it to make it ready for inclusion as well as an admonishment that the patch was not usable because it wasn't properly signed off.

Plagiarism means that the kernel maintainer included the code and pretended that it was their original creation and nothing of the sort happened so I don't think that word should be used in this context. Nobody doubts the OP wrote the code, nobody is saying that they did not and nobody passes it off as their own.

Misrepresenting your level of reliance on a particular source is plagiarism, and is uncontroversially recognized as such in any other context. If I say that I was inspired to study a particular problem by Paper X, but don't mention that my own paper includes several copied paragraphs of Paper X that I've lightly edited, then that is plagiarism.

If there is a public record that makes it obvious that you've plagiarised, then that doesn't mean you're not guilty of plagiarism. It just means you failed to cover your tracks.

None of this has anything to do with copyright. Not all plagiarism involves copyright violations and not all copyright violations are instances of plagiarism.

Well, for me the bar for plagiarism is apparently higher than for you, for me it is 'passing something off as your own' and that never happened here. I'm open to other definitions that I'm not currently aware of.

The commit log and associated metadata misrepresent the authorship of the code.

I am using the bar that you can find by googling 'plagiarism policy' and reading any number of documents explaining what constitutes plagiarism in an academic context.

Plagiarism is not a crime, so the kernel maintainers can choose to decide that it's socially acceptable in the context of kernel development if they want to.

I think you just relegated a very large chunk of the Linux kernel to plagiarism.

I'm not sure if I'd agree with a 'very large chunk', but certainly I don't think this is an isolated incident. It's just that people don't usually make a fuss.

I think the basic issue stems from the fact that LKML sees patches as 'proposals' unless they can be included as is without further work. And any would-be contributor would be (heh) able to see that for themselves by looking at the many years of documented interaction between maintainers and the general public.

These long running projects all have their own styles and conventions for interaction (LKML itself being one of those) and the onus is on newcomers to familiarize themselves with that. Authorship, especially in the context of a project of this magnitude and with so many different people maintaining different parts of it is always going to be somewhat nebulous, because after all, you're changing a tiny little bit in a huge machine and anything worthy of copyright is usually expected to stand alone as a 'work'. That's definitely not the case here. And so the sign-off becomes a critical bit, if you omit that then you've just created a problem for the maintainer. Personally, I would never expect to be named author of a patch sent to the kernel mailing list, but if I wrote a sizeable subsystem then I would definitely expect that kind of recognition.

For patches like this your pay-off is the fact that they are taken into consideration at all.

Rationalize it all you want, but not even the maintainer agrees with you at this point:

https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...

> I'm sorry about the way I handled your patch. I should have spent more time working with you to develop your patch.

> I agree that the Reported-by tag doesn't properly reflect the contribution you made, I should have realised that at the time

The maintainer is responsible for quality and correctness. I don't know the specifics of this patch, but it's absolutely not strange for a maintainer to make changes with these goals in mind.

Hell, maintainers are usually more aware of broader concerns than the contributor.

I don't know the specifics of the patch either since OP has not linked their patch nor the final kernel commit. I don't understand why being a private list would be a problem since they can just post their patch on their website. Maybe they're waiting for the fix to hit mainline first.

But when someone submits a patch to any of my OSS projects and I want to make modifications to it before I merge it, I either keep the original author as the Author and make myself as Co-Authored-By, or make myself the Author and keep the original author as Co-Authored-By, depending on how much change I had to make to the original patch. In either case I also have the original author review my version to get their approval of my version.

The only case where I would not credit the original author at all (or only as Reported-By) is if my version had absolutely nothing to do with their patch, say they fixed the symptom in file X and I fixed the cause in file Y.

Edit: https://news.ycombinator.com/item?id=37674872 found the patches. If it was my project I'd consider these in the Author/Co-Authored-By category because they're basically the same patch.

The patch absolutely passed the bar.

The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.

I'd argue the differences are not just style changes and even "just style" changes are not trivial. The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.

After he did none of the hard part.

I'm sure other people did the "hard part" too for the Row hammer and Heartbleed bugs; which were even harder. All they got was credit in identifying the bugs; kernel-contributor-status is not a prize for doing hard work finding bugs.

* OP didn't identify the bug, it had been reported years prior. OP identified the root cause and suggested a working fix.

* What then is the hard part, if this is the "hard part"

* What is kernel contributor status a "prize" for then, if not for contributing to the kernel?

* Why all the focus on OP wanting recognition for the work, and 0 on the dev who merged the patch. Why not have all patches be merged by a committe/ someone who isn't the author.

The maintainer (not random dev) didn't "merge" the patch - they rewrote an entirely new patch. Ate you arguing OP should be credited for that work? Sure, the maintainer could have guided OP towards the same patch over multiple exchanges/days, but it is their prerogative - they have to maintain the code going forward and are not obliged to accept patches that are in rough shape (in their judgement). OP did contribute to the kernel - but not by having their code included as they had hoped.

Michael Ellerman is between a rock and a hard place here: he could have done better and that's something that may have to be added to the guidelines for the patch contributors, at the same time maintainers have a massive workload and this was a tiny, broken patch submitted in a non-standard way by a new contributor. He could have made the origins of the few lines of code clearer but maintainers do this all the time, they usually are more focused on the quality of the code, and getting a fix in (even if it isn't yours) and may not realize that the contribution is insignificant compared to the fact that someone is very much focused on the credit.

Incentives clearly aren't aligned and I think if the OP would have taken this up privately they could have worked it out. Instead you get this public attack on people that we already have far too few of and one that misrepresents the interaction. That's where I draw the line: you keep your dirty laundry inside until you've exhausted every avenue for redress if you really care that much. Note that Ellerman explicitly offered to work with the OP if he wanted to be credited for a patch to the kernel on another bug, which is one way to differentiate between drive-by contributors and long term relationships.

All in all I think everybody could have done better here but Michael Ellerman's wrongs are far less clear to me than what the OP did and I'm fairly sure if there had been a ready for inclusion patch or better guidelines about how to deal with various degrees of crediting contributors (and probably for a more substantial fix) that there would have been no problem either.

Personally I don't see the problem at all: the LKML thread is archived for eternity, the contribution of the OP is clear, if he wants to say he's contributed code to the kernel I don't think anybody would object to that and Ellerman did his job as a maintainer, even if he could have handled it with some more grace I'm more than willing to forgive him. If I had been in the OPs place I would have probably jumped at the opportunity suggested by the invitation, and I definitely would not have 'paraphrased' the interaction or use the word 'robbed' without first reaching out to Michael Ellerman because those two things alone undo any goodwill created by the submission of the patch.

> I'd argue the differences are not just style changes and even "just style" changes are not trivial.

Op did all the research and multiple implementations of a fix. Ellerman refactored the fix to be simpler, but the effect is the same.

> The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.

It more seems like he knew about IS_ENABLED and Miculas didn't, because he uses `IS_ENABLED(CONFIG_PPC32)` instead of Miculas' `#ifdef CONFIG_PPC32`. Besides, Ellerman's changes are all inside `#ifdef CONFIG_PPC_FPU_REGS` blocks anyway so I'm not sure this was a major consideration. Using `IS_ENABLED` gets you 90% of the way to the "cleaner" patch, and in a ~30 line patch I don't know if it's worth golfing further.

Miculas' patch: https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

Ellerman's patch: https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...

EDIT:

Oh he also got a code review giving him exactly these tips [0]. IDK, getting real "I don't want to coach this rookie, I'll just do this myself, thanks for the tip" vibes from Ellerman here. Maybe that's valid, but it seems like not a wonderful way to keep people interested in kernel dev.

[0]: https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...

Ellerman's patch also has a significantly different and more detailed commit message, which should not be ignored.

I'm just disagreeing that the patches are the same. I agree that Miculas did do the hard work by finding the cause of the issue in the first place - but he's correctly credited as the reporter.

As for the clean patch - part of the issue is that Miculas was slightly overengineering some of it with the additional macros and added noise with extra conditions on the fpidx declaration.

Ellerman's "I don't want to coach this rookie" vibe is somewhat understandable given this is the security mailing list - it's just not the time and the place to be going back-and-forth.

I generally agree and gave you an upvote. The macros up top were hard for me to grok too, mostly I was reading it thinking, "why isn't this just a cast" and it turns out is could be! And I get this is the security mailing list, but it's 32-bit PPC, and they took days to really get to it. FWIW I think Ariel was being overly cautious; it's hard to see how this could be a significant security issue, and it feels counterproductive to punish him for being cautious. I can kind of see both sides, but I just can't get over doing all the work Ariel did and only getting a "Reported by" credit. His feelings are justified IMO.

BRB, gonna rewrite every repo I’m on to credit the linter as the author of every commit.

> There is nothing wrong with being motivated by getting credit.

They did get the credit, just not for the code, and rightly so.

If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel, more so if it is posted as a security issue which get special treatment and a whole pile of extra review to make sure that the fix doesn't introduce yet another problem.

This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues, clearly some work went into this. But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up, especially if you want to do security work where the details really matter, so props for identifying the issue, but no medal for delivering something that didn't meet the bar for inclusion. And that last bit is where 'kernel contributor' comes in. The whole 'robbed' angle is an interesting one, it appears that there is a much higher perceived value than the one that is normally associated with getting an issue fixed (which is what most people would like to see). Perverse incentives are a thing and it is good to be aware of them.

> The value of FOSS is fixing a problem once for everyone.

No, the value of FOSS is the ability to read and modify the source code.

> Linus Torvalds himself had questionable attitude at times.

Whether Linus has had questionable attitude at times is immaterial: clearly he was a contributor and so is credited. This person did not contribute as of now. You see the same with YC and pretty much anything that people would like to have on their resume: the thing itself is less important than the CV mention.

> have hurt for doing all the analysis, even if the patch itself got completely rewritten?

That there are many more implications for being allowed to call yourself an author. The kernel contributors are doing very important work and their standards for inclusion are high. You don't make it into that circle without adopting their standards.

> They did get the credit, just not for the code, and rightly so.

They received credit for reporting the issue, which is a fraction of what they did. They provided the entire solution, full stop. The maintainer only restated it.

That's because it is a tiny fix. To ask for credit as a contributor makes it seem as though that was the whole goal and that's why the OP feels 'robbed' as though this is a thing of great value that has been taken away from them.

That's not how I interpret the contents of the exchange:

https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/m...

Could the kernel maintainer have handled this better? Probably yes. Was the OP robbed? In my opinion, no, their work was credited and the fix is so small it doesn't warrant elevating the OP to 'Kernel contributor' which is typically reserved for more substantial contributions, not bug fixes of a few lines.

Another comment has a nice middle ground in the form of the 'Suggested-by' tag which I think would have been an improvement. I've got a little project on the go and I'm meticulous about crediting people but the context is entirely different there, nobody is going to hold up my project to claim they are a contributor on their CV so I'm fine with the kernel maintainers keeping the list of 'kernel contributors' manageable.

After how many lines of someone contributing code to the kernel are they considered to be a >kernel contributor<?

How is fixing bugs not a contribution?

This entire attitude around denying attribution is unreal. I see it in industry all of the time, especially now that I'm in gamesdev. People pull out all of the stops to prevent certain people or even certain disciplines from receiving credit for their efforts. It's abysmal.

What’s the incentive here? It seems more likely it just wasn’t a concern to the maintainers. The guy can still call himself a Linux contributor if he wants. He submitted a couple if statements and didn’t get it signed off. Why split hairs over what the commit message says?

That is an excellent question. It may well be that even single line drive by patches raise to the bar of being a kernel contributor, it may be that most of the authors of such small patches have historically had a better idea of their place in the greater scheme of things and that what matters is that the bug gets fixed (it's a security issue, after all) rather than that it gets fixed in their way or with their name affixed to the patch.

Fixing bugs is a contribution, and detecting bugs and doing RCA is also a contribution. In this case the OP got credited for the second and the third using the appropriate mechanism. The maintainer could have used another tag to add additional credit, but chose not to as is their right - and custom with such small patches, especially if they need work.

High profile projects such as the Linux kernel suffer from attracting people that just want to be associated with the project, I think OP went considerably beyond that and deserves some credit but does not have an automatic right to a particular kind of credit and if that was his expectation he should have ensured up front that that was the outcome. By posting an incomplete patch for a security issue to the kernel mailing list this was the expected outcome, in fact the maintainer spent considerable time on back-and-forth with the OP.

> it may be that most of the authors of such small patches have historically had a better idea of their place in the greater scheme of things

Historically, denying those, who went to great lengths for their contributions, even the minor bit of attention they deserved, has led at times to the castle getting torched down.

It pays off to have your expectations calibrated before you engage in an activity. To be named a kernel contributor on the basis of this particular patch seems to be a bit excessive (even if it had been properly signed off, which it wasn't), of course you are entirely welcome to disagree with that.

To give some perspective: there are ~30 million lines of code in the kernel and about 5K named contributors, and a much smaller set of maintainers who will accept patches, modify them, discard them, rewrite them and or merge them based on their judgment, which they generally exercise very well.

Agreed the expectations are so far out of line I doubt the maintainers see a problem. If this guy wants to be a kernel contributor he can keep contributing to the kernel.

Flagging someone as a kernel contributor should not be conflated with the magnitude of contributions.

The LKML is all the proof the OP needs to show he contributed and precisely in what way. This post is way over the top and even if Michael Ellerman could have handled this better so could the OP.

IDK this stuff all sounds specious to me. If I envision a world where anyone who contributes Miculas' level of effort into the kernel gets into "kernel contributors", that world seems great to me. Linus wrote a whole new version control system, surely someone over there can figure out how to maintain a list of contributors.

> To ask for credit as a contributor makes it seem as though that was the whole goal

There's nothing, at all, wrong with this.

> There's nothing, at all, wrong with this.

I don't know about that. I maintain a small project and I've received exactly one outside contribution, and I made sure to properly credit that. Nobody is going to send me patches in order to gain social standing. But popular open source projects are a different matter and the maintainers there are hip to the fact that people use often minor contributions to increase their standing. Now: the OP clearly went beyond that, and I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one. But that's hairsplitting to me and if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost.

> the maintainers there are hip to the fact that people use often minor contributions to increase their standing

That's a fair concern but I don't think that's what we're talking about here. This isn't someone running around correcting whitespace or documentation to pad their resume. They did a bunch of technical and mailing list research. That kind of effort is promising.

> I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one

Yeah or maybe "co-author" or whatever (IDK anything about kernel tags). It seems pretty evident to me that Ellerman cleaned up Micunas' original patch using his kernel expertise. I'm not at all calling "plagiarism" or anything like that, but I am calling "collaboration".

> if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost

I'm not sure what the original private email was so who knows if it's a faithful paraphrase, but I can forgive OP for being miffed and I could also forgive Ellerman for being irritated about being misrepresented. Someone should be the mature person here though, and--call me naive if you want haha--I'd look to the kernel dev for that.

For Co-developed-by status though it would require a properly signed off patch which this wasn't. And that's where you run into the issue of this being posted to a security mailing list for all to see: you've essentially started the clock on something that you no longer control and fixing the but takes priority over other niceties.

Yeah I mean, I want to be respectful of Linux workflows and conventions. I just think it's hard to understand a situation where someone could put this much effort into improving the kernel and not get a contributor credit. Like, by the normal definition of the word it's definitely a contribution: it required a lot of technical skill to do, and he did try to follow kernel conventions when he was made aware of them. It's not really his fault that trying to contribute to Linux is a byzantine process where maybe no one will be at all nice to you.

> And that's where you run into the issue of this being posted to a security mailing list for all to see: you've essentially started the clock on something that you no longer control and fixing the but takes priority over other niceties.

Yeah, but on the other hand it's an obscure architecture and they took a few days to really process it. It also doesn't preclude them crediting him as a co-author.

---

I guess my overarching point is that, while this may be completely reasonable from a kernel dev's point of view--a person super steeped in kernel culture and processes--it's mostly nonsensical to everyone else. This issue is pretty simple. This guy did a bunch of work in good faith, tried to do things right, and some insider basically stole his thunder. That sucks! No amount of like, careful or sympathetic explanations of kernel workflows and semantics is really meaningful in the face of that.

I think the nail in the coffin is that everyone believes this happened right? No one needs to be convinced kernel devs are completely uncaring and insensitive. Maybe that attracts a certain crowd and maybe that's on purpose, or maybe it's just self-fulfilling, but at the very least it doesn't seem very welcoming. Either way, it doesn't bode well for the future.

EDIT: I said they took over a week to really process it but I misremembered, it was just a few days

I think that the main sticking point is that the credit for a contribution to the kernel, no matter how small is of sufficient value now that this needs more consideration from the maintainers. And Michael Ellerman actually agrees with that based on his response in the thread. I think a Suggested-by or even a Co-authored-by would be an improvement on the current situation. But the frame of mind of a typical kernel maintainer to me appears to be that they believe you want them to fix the issue, not that the credit matters more to you than the fix.

If I were in the position of the OP the LKML record alone suffices as proof that I contributed a major chunk of work to fixing a bug in the Linux kernel, and if I did feel that the credit was handled wrongly I would have taken that up with the maintainer. And finally, I would have done so right away, not a long time after and in such a disingenuous way.

Well said, 100% agree

I don't know if you've been in the open-source space for very long, because this is not how it works. It's pretty standard to work very hard to give credit (and not some silly "reporter" credit) to the first person to show up with a working patch for an issue (as long as they are willing to work with the maintainers and make requested changes), because it builds goodwill in the community and encourages contributions. Of course, the kernel maintainers are free to break that social compact, but it's still "robbing" someone of what social norms lead one to expect. And this "robbery" isn't a victimless act, either. Finding a high-complexity (and it was, don't confuse yourself) issue and solving it is a good undertaking that shows that you're a good developer, and also brings some spotlight to the company you represent, which can be good for recruiting and developer relations.

Source: I have asked this question on HN before: https://news.ycombinator.com/item?id=31225599

But: it wasn't a working patch, it was mailed to a security mailing list alerting, and it wasn't properly signed off as required for inclusion. Those things alone make the expectations for credit strange. LKML has its own set of very specific rules around this stuff.

Of course, this all makes perfect sense if you live inside the LKML bureaucracy. From the outside it just seems bonkers. This is why it's important to reconsider policies that don't make sense.

Agreed, but OP made himself part of that bureaucracy entirely voluntarily. It's as if I show up to a casino and start playing without familiarizing myself with the rules and the environment first. Note that the kernel maintainers are in general getting a lot of crap for doing a very large amount of work and that this sort of post that attacks a particular maintainer by name is really damaging, far more so than if the OP had never submitted their patch in the first place.

Absolutely agree. But remember that this affects all of us, because "with many eyes all bugs are shallow" only works if lots of people show up and contribute.

> That's because it is a tiny fix

And this is how I know you're not a professional programmer, because you naively assume that finding the root cause is zero work. Most of the time it's debugging and testing that takes almost all the time involved in a fix.

> But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up

I'd suggest not opining on the inner motivations of strangers on the internet. It doesn't add value to this conversation, and your guesses are likely wrong due to missing important context and details.

It's there for everybody to read, as well as in comments here, I'm not guessing at anything. You can't be 'robbed' of something you do not already have.

And that's before we get into misrepresenting the kernel maintainers words in a way that considerably changes their meaning.

Maybe you’re not a native English speaker? “Getting robbed” can also mean not getting something you are justly deserved.

> can also mean not getting something you are justly deserved.

It can, but whether that's the case here or not is debatable and I think what we mostly see here is the OPs unfamiliarity with how LKML deals with tiny patches mailed to the security lists.

> It's there for everybody to read

Yes, it is. His motivation is very clear:

> Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore.

This is an incredibly uncharitable description of his motivation:

> If the goal is to fix something to be able to put kernel contributor on your resume

So, then the OP should be happy. But that's not what I'm reading, I read accusations about robbery, see words put in people's mouths that are not backed up by the evidence and a patch that misses required bits and pieces to be accredited in the first place.

What they wrote in their blog is without value after changing the nature of the exchange with the kernel maintainer to make them look like a dick when nothing of the sort actually happened. It only proves that you can't believe what is in that article.

He did almost all the work in fixing a problem that had existed unfixed for six years. He figured out what the problem was and fixed it. He did this because it was causing problems at work. When he contributed the fix upstream the maintainer tweaked it a bit and merged it, with a bug report credit. The author did far more than simply report a bug. As he says – the bug was already reported six years ago (and apparently the actual reporter didn’t get credit for that). He figured out what the problem was and fixed it, but he didn’t get credit for that.

His motivation is clear – he fixed the bug because it affected him. The fact that he’s pissed off for not getting credit for that bug fix doesn’t change that.

> If the goal is to fix something to be able to put kernel contributor on your resume

This quite clearly was not his goal. His goal was to fix the bug he was experiencing at work. So why are you saying otherwise?

> So why are you saying otherwise?

Because I read the article and the exchange between the maintainer and the OP.

It smacks of entitlement and shows a complete unfamiliarity with the kernel development process. Maybe that's all there is to this but to claim a kernel developer 'robbed' a first time contributor when in fact what happened is exactly what you'd expect to happen makes me wonder about the OPs motives, especially because he materially misrepresented the interaction between himself and the maintainer to make the maintainer look bad. It looks like the credits were the goal, and if they weren't then what's the fuss about?

> It looks like the credits were the goal, and if they weren't then what's the fuss about?

Because that is how fairness works in the minds of most humans. People can have multiple motivations. I go to work to earn cash, but I'd be unhappy if someone else got credit for the work I did.

However, at least I'd have got paid; if I was doing something out of altruism I'd be a lot more unhappy if I didn't get credit for the work I'd done.

> It smacks of entitlement and shows a complete unfamiliarity with the kernel development process

Even if this were true, it does absolutely nothing to change the fact that his motivation was to fix the bug he was experiencing at work.

> It looks like the credits were the goal, and if they weren't then what's the fuss about?

You are failing to distinguish between the purpose for doing something and something of value. These are two distinct things. The goal was to fix the bug. The credit is of value. The fact that he is upset about not receiving the value he feels he deserves does not alter what the goal was.

It’s straightforward and obvious that he fixed a bug because it was affecting him. Why are you so eager to deny that?

> Even if this were true, it does absolutely nothing to change the fact that his motivation was to fix the bug he was experiencing at work.

Sure, but this blog post was written well after that time, and I do not see the OP aiming to be properly credited in the intermediary. That doesn't mean that a more appropriate tag could have been used, I just wonder about the motivations for the post because it clearly isn't either timely or the best venue to address this, especially not in the way in which it was done.

> You are failing to distinguish between the purpose for doing something and something of value. These are two distinct things. The goal was to fix the bug. The credit is of value. The fact that he is upset about not receiving the value he feels he deserves does not alter what the goal was.

Yes, and that's why I'm totally supportive of having a 'Suggested-by' or even a 'Co-authored-by' tag on this. But I'm also aware of the fact that the LKML record alone serves to document the OPs contribution and that nobody has made any claim to the contrary, he is - to all intents and purposes except for the git-log the contributor of some lines of code. That these were modified by the maintainer is something people normally would not have cared that much about. And maybe that should change, but that's so far been roughly the norm for these kind of fixes.

> It’s straightforward and obvious that he fixed a bug because it was affecting him. Why are you so eager to deny that?

Because of (1) the timing, (2) the misrepresentations in the post, (3) the fact that alternative venues were not sought before making some fairly heavy accusations. It looks to me as though the bug fix may originally have been the reason the work was done and maybe the OP or their employer were happy with it but now, so many months later it seems the OP is more focused on the credit.

"That circle"? You make it sound like an exclusive club for the elite. This isn't supposed to be a popularity contest.

Linus' attitude is very material. Kernel leadership sets the stage for other contributors to do the same, good or bad.

Linus' attitude has nothing to do with it, he wasn't part of this exchange at all. And yes, it's an exclusive club, hence people trying to become a part of it.

Open source software development is not an exclusive club. If you contribute to open source software you are an open source contributor.

Stop gatekeeping.

Security patches are the last place (especially tiny ones) where you want to make a stand for proper attribution of four line patches, the rest got properly credited. Note that the OP misrepresented the nature of the exchange with the kernel maintainer and that puts their motivation about the whole thing in doubt. Nobody got robbed. OP still has contributed code, the LKML lists are proof of that and if you think that in the future every such patch should carry an automatic 'Suggested-by' or 'Coauthored-by' tag then you could propose that. But for now this is the maintainers call and by sending mail to the LKML you play by their rules.

That's not gatekeeping, that's just reality, and yes, kernel maintainers are an in-group whether we like it or not. My take on that is that if I had stuff that gets included that I couldn't care less about the attribution because what they give me is so much more than I'll ever be able to give back. Of course everybody is welcome to their own motivations, but you send unsolicited patches with the hope that they'll be used, if you get credit that's great but then the patch had better be ready to run as is and preferably for something a bit more substantial.

Um, Kernel maintainers are an exclusive club for the elite. Seriously, I'm not even trying to be funny or edgy or anything.

The hierarchy roughly goes: users -> script kiddies -> programmers -> compiler writers -> kernel devs.

I will point out that finding and root causing a bug (and perhaps writing a test) is THE contribution. Very often fixing the bug, once all unknowns have been resolved, is trivial.

Many times a one line fix takes days off debugging and analysis. Seems like this was the case here, since the original bug was open for 6 years.

And indeed, they received the proper accreditation for that. As well as the mailing list entries which are there for all to see.

"Reported-by" reads like: "this person mentioned the problem to us". In this case he did all the heavy lifting which is like 95% of the work. How is reported-by a proper accreditation? I feel like many commenters here never had to debug any complex or subtle, hard-to reproduce bugs. Either that or there are many assholes on this site.

Well, maybe there should be a 'contributed an improperly signed patch with issues' tag that would cover the situation. But in the case of mailing to a security list your general expectations should be to hope that it will be included, and hopefully speedily.

This comment is so far off the charts, even I, a pathological lurker, made an account...

Let me see if I get the ranking right:

> But the motivation isn't clean

> The kernel contributors are doing very important work and their standards for inclusion are high.

> security work where the details really matter, so props for identifying the issue

> Perverse incentives are a thing and it is good to be aware of them.

> with a mediocre contribution

>This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues

I wonder where normal people fit into this mental framework.

Contributors with pure thoughts <?> Kernel contributor > Security Contributors > Perverse contributors <?> Mediocre contributors > > People who sneak into OSS projects by fixing minor issues

> If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel

Someone's desire to put "kernel contributor" on their resume is immaterial to the appropriateness of receiving that badge. "Mediocre" is a judgement you're projecting here, but we don't have evidence that the code was mediocre. And even if it was mediocre, most software goes through iterations, the first of which is almost always a mess. If the code he wrote was directly responsible for the code the maintainer wrote, there's a case to be made that credit is still due even if not a single line of the original code made it into the codebase.

"You didn't type the exact line of characters that made it into GitHub so therefore you did not contribute" is a very limited view of the whole series of interactions and investment of human capital that ultimately led to the fix.

> But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up

This is projection again. When you don't receive credit for your work and get upset about it, it does not imply that the only reason you did something was for the recognition. If you get passed up for a promotion at work because a coworker lied and took credit for your work, you're allowed to be pissed about that, and it doesn't mean that you don't deserve a promotion because you worked hard to get a promotion. I don't get the logic here at all.

I agree that if the only reason someone contributes is to play a status game, that can lead to some questionable behaviors. But there's no evidence that this is the case here.

> No, the value of FOSS is the ability to read and modify the source code.

There is no singular attribute that makes up the "value of FOSS". Reading and modifying source code are valuable, but not exclusive to FOSS. The shared value of contributed fixes is also a major benefit of FOSS. FOSS is many things.

> This person did not contribute as of now.

I cannot imagine how you could conclude that the author did not contribute. If your definition of contribution is limited to "lines of text checked into a repo", perhaps you're correct, but this is an extremely limited view and incomplete picture of the nature of open source contribution.

The bug was around for many years. Would the code that did make it into the kernel have been written in the same timeframe if the author had not submitted their own solution?

There could have been many very good reasons not to include the author's code, and I'm not arguing against that. But it seems extremely disingenuous to claim that the author did not contribute quite a bit to this fix.

- the patch was missing a required element if the author wanted to be credited in the first place

- the patch was incomplete

- the patch was mailed to a mailing list that has a different set of priorities than the patch submitter assumed

The author did get credit though and that was for the 98% or so of the work they did. And finally, the LKML will - presumably forever - document his contribution in all its glory.

Anyway, I don't think we're going to see eye to eye on this one, in my experience nothing out of the ordinary happened here. Maybe that's wrong and it needs to be addressed but I would have picked a different hill for that battle.

I was primarily reacting to your assertions that the author doesn’t deserve recognition due to intrinsic motivations and the direct claim that they have as of yet not contributed.

What you’ve listed here are procedural issues that are easily corrected and have no bearing on whether or not contribution actually occurred, and no relation to those broader claims.

Zooming out a bit, maybe what you’re describing is indeed the status quo, and what the author described is a perfectly normal experience. If so, then the author’s piece should be seen as shining a light on kafkaesque bureaucratic bullshit that threatens the spirit of FOSS and thus FOSS itself.

Maybe “kernel contributor” needs to be better defined, and maybe it requires more than one contribution. Maybe there needs to be something more than “reported by” but less than “kernel contributor”.

But again, at no point is it fair to claim that the author did not contribute.

> I don't think we're going to see eye to eye on this one, in my experience nothing out of the ordinary happened here

Frankly, you’re shifting the goalposts so this isn't about seeing eye to eye. “Ordinary” is quite often very problematic, and each person is free to choose their own battles. You don’t have to agree that this was the right hill, but that is unrelated to a reasonable definition of “contribution”, and irrelevant to author’s choice to make some noise about their own personal experience.

Noise is a first step towards improving a situation. Change has to start somewhere. And FOSS maintainers need to be aware of the harm they bring to the projects they’ve been entrusted to steward when they forget about the human factors involved.

> And FOSS maintainers need to be aware of the harm they bring to the projects they’ve been entrusted to steward when they forget about the human factors involved.

All I see is that no good deed goes unpunished.

Or maybe good deeds are good deeds, and bad behavior is bad behavior.

Maintainers deserve gratitude, empathy, and respect. Most of them are holding the line against shitty contributions and shoddy code, and that’s a good thing. The good they do doesn’t absolve them of problematic behavior.

I'll settle for 'perceived problematic behavior' and suggest you read the actual interchange between the OP and the kernel maintainer. Because it paints a completely different picture.

I did read the exchange, and there is problematic behavior all around.

The author did themselves a disservice with their disingenuous paraphrasing. The lack of attribution remains a problem however, and is not justified by the author’s misrepresentation; just as the author’s behavior is not justified by the lack of attribution.

OP could have maintained the moral high ground but didn’t, and that’s a bummer, because now this is an “everyone sucks here” situation.

Attribution remains important.

That's fair. And Michael Ellerman actually agrees that he could have handled this better, I think OP should have just worked on this in private exchange rather than to make a public attack.

I think that given the status of the project there should be a change to the guidelines to ensure that even the smallest contributions get properly credited, but to make sure that then isn't gamed you'd need to somehow get out of the binary 'I'm a contributor' vs 'I've been contributing for years' situation by adding yet another metric or the inflation of the term 'kernel contributor' will be such that some people who do contribute on a regular basis will feel that their status is diminished.

Project governance is complex. I'm very mindful of the reason (see the drama around PEP 572) why GvR quit the status of head of the Python project, being a project maintainer is a very tough spot to be in because every action you perform is potentially going to be under the magnifying glass and all the good you do is forgotten five minutes later.

If ever I was considering contributing to a FOSS project, this comment and many others like it within this thread has firmly convinced me that it’s not worth the trouble.

That's almost spot on.

I've just barely arrived at the conclusion that I could make a change, offering minor suggestions and changes on projects I care about and then have the read someone degrading a contribution that is still "several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues"

And when you point this extreme ranking out as inappropriate, your comment gets vaporized.

This REALLY bloody hurts

YMMV, but here's what happened with my pull requests.

12 - accepted, sometimes additional changes were required

1 - ignored; this was a trivial change and I wouldn't have submitted it now.

1 - rejected; the maintainer didn't understand my proposed fix and closed the pull request.

1 - rejected; the maintainer disagreed with the proposed change.

My comment didn't survive long at all, yet I still recommend giving it some serious thought.

> This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues

As someone just getting started with but a tiny OSS footprint and grade care to not step on anyone's toes, this is a deeply unfair statement.

> There is nothing wrong with being motivated by getting credit.

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

Perhaps being a recognized kernel contributor would have given them more leverage in their salary negotiations with their employer?

Or future employers. All the wrangling about "this guy should be selfless and just be happy he made the world a better place" is bonkers. He lobbied his job to give him time to put in a bunch of highly technical work to improve the kernel. Would it really be so bad to acknowledge him as a contributor? How in the world is his work not a contribution?

""" Solution taken from arch/powerpc/kernel/ptrace32.c --- arch/powerpc/kernel/ptrace/ptrace-fpu.c | 31 +++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) """

You really consider this a contribution? You genuinely want to call someone submitting this a kernel contributor and imply they know anything about the code? I mean, I get the social angle of trying to build each other up and do each other favors but in the long run we're doing more harm than we are good by warping the meaning of the title

I consider it a great first contribution. Dude took initiative at his job to try to make his and his teammates' lives easier, investigated a super technical issue, found prior art and built on it, sought help on the list, and tried to shepherd it to get it merged. It was significant effort, and he in no way had to do it. He definitely didn't need to upstream it.

The amount of energy wasted in this thread on the meaning of "contributor" could boil me water for tea. Bewildering, honestly.

Reporting a security issue is not the place for seeking help on the list and shepherding. The idea behind the patch was written simpler by others because the original patch was both technically unacceptable to the maintainer and not cleared for inclusion in the kernel (no Signed-off-by).

He posted to security out of an abundance of caution, but it's hard to see how this could be a significant security issue. Feels unfair to punish him for being considerate here.

Also kernel workflows are not intuitive. I don't have any idea what signed-off-by is or how to get it. Don't you post to the list? What else would you do? Would it have been better for Miculas to spend time researching kernel workflows while this "security issue" remained unpatched? Feels like there's not really a way for him to win here.

> original patch was both technically unacceptable to the maintainer and not cleared for inclusion in the kernel (no Signed-off-by)

Crediting as a co-author is a good compromise here, I would say.

This is a weird argument. Why should the contributor’s salary negotiations be a major consideration for the maintainer?

> There is nothing wrong with being motivated by getting credit.

It's wrong if it's your top priority instead of improving the codebase. And even then not being wrong doesn't mean you are entitled to get it, your motivations are your own.

I'm not sure why intentions would matter here, or how one would compare the value of different intentions. If someone adds value to the codebase and fixes, or helps to fix, a valid bug why should we care why they did it?

Sure intentions may indicate the liklihood of the person contributing more in the future, but that's a health metric for the project and unrelated from the contribution itself.

>why should we care why they did it?

Because it's important to cultivate the right motivation among contributors. Allowing people with selfish motivations to thrive eventually destroys the project.

Assuming that you can control who thrives in a project seems like a death nail in and of itself. Contributions should stand on their own, why the person contributed them or who the person is should have no bearing on the FOSS project.

Recognition of individual contributions is a core component to why Open Source even works in the first place. It would not work if an abstract, utopian ideal of "improving the codebase" was the primary driver. A bug fix contribution may be borne out of necessity, but ultimately codebase improvements are a side effect of the social phenomenon of people being highly motivated to be recognized by their peers.

Notoriety is the currency of open source software. And that's a feature, not a bug.

The blog post author sure has earned notoriety, by now.

Hundreds of charity and service organizations have found to their detriment that you're wrong, and that there needs to be this.

I volunteered at an animal shelter that was unable to be a no-kill shelter. One of the first things they'd learned to ask at intake was "What's in it for you?"

People would invariably misunderstand. "I get to help these animals" or similar. "No, that's what you're doing here. What do you get out of it?"

And they'd still answer altruistically.

But what the charity wanted to hear was the "selfish" answer. Because it's perfectly okay to have a selfish answer as well as be doing a good thing. In fact, it's preferable, because it's often the selfish answer that will keep you coming back when things are tougher or uglier, versus walking away because "I can't do this, it's costing me too much".

Perhaps instead codebase contributions should be anonymized? Maybe then we can ensure people are contributing "for the right reasons"...

> There is nothing wrong with being motivated by getting credit.

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

Are you familiar with Hacktoberfest? Every October you get an absolute torrent of crappy PRs from people who saw a youtube video on "How to get a free T-shirt". See https://blog.domenic.me/hacktoberfest/

Yes, Hacktoberfest is the most extreme example of this situation.

> There is nothing wrong with being motivated by getting credit.

Nothing wrong is too strong of a statement. Obvious to me, but wonder why not to others that it would be better if someone was motivated by something else other than credit, something like doing good, the challenge of the problem etc. Motivation solely for credit is egotistic and will lead to other problems with team and self-worth etc.

We have a name for such people and generally despised, "clout chasers"

> > It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.

> You don't know that.

From TFA:

> He said (paraphrasing): "Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix." I found this really perplexing and insulting. Instead of getting recognized for fixing the issue, he wanted to give me more work to do.

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?

> 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.

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.

> 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.

Just because something is free, it doesn’t make it common property. Being able to use the kernel and modify _your own copy_ is not the same as the kernel itself being common property. The four freedoms don’t grant us permission or rights to alter other people’s copies of the software, so those copies are not common property.

> 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!".

That’s basically what happened, yeah? The author got credit for reporting it.

> The four freedoms don’t grant us permission or rights to alter other people’s copies of the software, so those copies are not common property.

Of course, but accepting a bug, giving feedback on a submitted patch to be included in the kernel is openly saying "We're willing to accept this, but you need to polish this and that", which the author did.

In practice he got the permission to modify their copy.

> That’s basically what happened, yeah? The author got credit for reporting it.

No, definitely not. They got a "reported-by" tag, which means "the author told me that something is not working, so I did all the work to find why, did all the work to solve, did all the work to implement, did all the work to commit."

In reality, the author found, debugged, solved and patched the problem. The maintainer didn't like the style, pushed his version, and claimed that all work is done by him, except hitting his proverbial foot to a proverbial stone while walking (i.e. discovering the bug).

> In practice he got the permission to modify their copy.

I wouldn’t consider it common property if permission is required. It seems like our definitions of common property differ, but I’m not sure there’s any value in trying to align ourselves on this.

> No, definitely not. They got a "reported-by" tag, which means "somebody told me that something is not working, so I did all the work to find why, did all the work to solve, did all the work to implement, did all the work to commit."

Got it. Yeah I agree this is not the same. However, I still stand by my original stance which is that no one is owed anything, especially when they do something no one asked them to do.

> I’m not sure there’s any value in trying to align ourselves on this.

Same here.

> I still stand by my original stance which is that no one is owed anything, especially when they do something no one asked them to do.

I understand your point, but nothing is mandatory in Free Software. However, this is not about internet points, but it's human decency with consequences.

Strip the event from The Kernel and computer domain, this is plain rude, unjust and unethical. The author says this, and I concur.

First, we need to do better as humans. This is the lesson.

> I understand your point, but nothing is mandatory in Free Software. However, this is not about internet points, but it's human decency with consequences.

The way OP framed it in the blog post, it sure does seem like it's mostly about Internet Points:

    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.

As far as I know, there is no official title of "Kernel Contributor" that comes with a certificate written on parchment. I have code I wrote in the Linux kernel. Am I an official Kernel Contributor? If so, I didn't receive my merit badge, and that doesn't mean any human decency rules were broken. Having code in the kernel is not that big a deal. I highly doubt I got any job offers because of it. This seems as Internet-pointy as HN karma.

> 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.

Woah this claim a bit too strong. There's a "reported-by" line in the final patch that ended in the kernel:

https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...

Whether that's sufficient is another matter.

Well, no, it's not.

Giving a mere "reported-by" tag to a person who comes with a patch is just too unjust. Isn't it? The patch may not deserve to be included in the tree as-is, which can be understandable, yet dismissing all the research is essentially saying "you're too young to be here. Leave this to grown men, ride your tricycle over there. Here's a candy. Good boy."

I don't understand why the act of not taking a small patch should be interpreted in such a personally insulting way.

It sounds like you are just trying pour oil on a fire.

Would you prefer to live in a world where people are obliged to spend extra time dealing with easily-broken egos because all non-overtly-friendly acts can and will be interpreted as contempt? I personally rather assume people are well intentioned, and let them focus on fixing problems instead of catering to egos.

Or maybe you like playing the ego game. That's fine, but I'm really honestly questioning my assumptions towards humanity in the discussion here. Do people really think I view them in contempt if I don't write a couple paragraphs of words to sooth their egos after I disagree with them?

Because it's not about not accepting the patch. I'm not there. It's about the style.

About the oil: I'm not that kind of person. I'm just defending what I'm thinking right. Also, I know about oil burns. That's something I'd never wish on my enemy.

One doesn't need to be overly, or overtly friendly, or to write long fluffy sentences to come across as kind. It's about the word choice yes, but not in the straightforward way we are wired to think. It's something more subtle.

I write many e-mails every day, talking with people from many nations, at every level in many projects. Some of these mails are novellas, some of them are four word bursts. Yet regardless of the length of the mail, I can convey the tone I want, and people understand that.

Sometimes I need to say no to people, and I say it directly. Sometimes I thank them sincerely. Rarely I write hard/heavy mails, which is something I hate to do (and I don't use the word lightly), but without any strong words, and they go through too.

Being kind is not playing the ego game, and doesn't need extra time. What is wrong is thinking that you can throw words and/or people around just because you don't see their faces, don't like how they name the variables, or you think you can say anything because you're a nerd/geek/hacker/whatever and these features or adjectives give you license to push people around.

Lastly, I think soft-skills are way more important in development communities, because your projects' life-span is measured with the health of the community supporting it. Gate-keeping, elitism, and similar acts slowly but surely damages a community. We should strive to be better humans first.

Coding is easy. Communication is hard.

> What is wrong is thinking that you can throw words and/or people around just because you don't see their faces, don't like how they name the variables, or you think you can say anything because you're a nerd/geek/hacker/whatever and these features or adjectives give you license to push people around.

I don't know what you're talking about. Are you talking about the jerks you encountered in life, or the exchange between the OP and the kernel maintainer? Because I don't see any of that behavior, nor anything that warrants the hostile interpretation I objected to earlier.

Have you actually read the email exchanges in question, or are you taking the OP's claims at face value?

PS: nvm, given your hyperbole at the very beginning ( https://news.ycombinator.com/item?id=37677962 ) I probably gave you too much credit for attempting a grounded discussion.

I was going to write a detailed answer to your comment, but after your P.S. and assumptions about my intentions, I think I have the same feeling about my hopes for a grounded and fruitful discussion with you.

All the best,

Have a nice day.

> The developer could have accepted that allegedly inferior fix, give the credit, and patch it with their own version in a single commit.

My best oss contribution was done exactly like this. Someone else reviewed my code, made some changes, but my name was on the commits. I was happy that someone else took the time to make my code better and at the same time, keep my name on it.

As has been mentioned elsewhere if this had been submitted via the standard process, something more like that might have happened.

However, this was submitted to the security mailing list which is optimized for quick, precise fixes, not for teaching new contributors how to adhere to coding standards.

This methodology also has the side effect of "new contributor has security fix but can't contribute it because they need to be "taught" on non-security issues first."

No it doesn't.

The new contributor didn't have the knowledge and skills to make a patch that followed project standards. They were still able to submit a report and a first attempt at fixing the issue and get people who do know how to do that to craft a fix quickly. This is the system working correctly.

Rather than being thankful that other people contributed their time and effort to help OP solve the issue their company was facing, OP decided to misquote the person who helped them and start drama where none was needed.

> Rather than being thankful that other people contributed their time and effort to help OP solve the issue their company was facing, OP decided to misquote the person who helped them and start drama where none was needed.

Wow, way to turn this around. The user had fixed their issue. Don't make it like "other people" "helped them solve it".

The user and his company were quite capable of compiling their own kernel and using that. They solved their own problem, with no help from others.

They then chose to disseminate it for the greater good.

And yet people like you are demanding that they show gratitude to the community for somehow deigning to help them.

You seem to take this very personally for some reason. I have "demanded" nothing...

Anyone is welcome to fork the kernel and commit code of whatever quality they want.

However, if they want their code included in the official kernel, then they need to follow that projects coding standards. They are not entitled to get their poorly written code merged to satisfy their ego.

Sure, a "suggested-by" tag would have been appropriate, but I would posit that after this public tantrum, getting assistance becoming official kernel contributor will be a bit harder. Who wants to donate their time and energy to someone who may twist their words to start unnecessary public drama as soon as they feel a little slighted?

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.

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-patche...

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.

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.

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.

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.

> 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?

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.

Based on what? Discounting credit as motivation is a bit naive and motivation is the only way shit gets done.

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!

> 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.

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.

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

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.

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.

Please don't cross into personal attack.

https://news.ycombinator.com/newsguidelines.html

Sorry about that, dang.

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 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.

> 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?

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.

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.

> 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.

>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.

> 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.

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.

Sounds like you are the problem, I don't see what is Microsoft's hand in this.

> 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.

The fact that it's hosted there doesn't mean that your unhelpful attitude is their fault.

I take your abrupt change of subject to mean that that you now observe Microsoft's hand in this.

You can use git without GitHub . An example of this is the Linux kernel

Correct. I wrote about Github, not git.

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.

> 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.

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.

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.

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.

Reply on news.ycombinator.com