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.
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.
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, 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.
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.
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.
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.
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 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.)
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.
My 'fixation' is that if you write a 1000 word angry blogpost attacking a kernel maintainer that you weren't properly credited that you could have at least submitted your patch properly formed. You seem to think that a sign-off is a formality, but it really isn't: it's to shield the kernel maintainers from copyright lawsuits by parties that surreptitiously include copyrighted code. It is a very important item on the checklist for a maintainer. You need to personally certify that you are able to make this particular contribution. See the LKML guideline for submitting patches that I've already linked to twice now.
Having that present would have likely increased the chances of this thing never happening in the first place by a significant factor. Almost every large open source project has their own quirky bits like that and as a newcomer you should at least read the documentation on how to contribute if you want to contribute, especially if that documentation is readily available and meticulously kept up to date.
Note that LKMS treats patches typically as proposals and not as must include verbatim or ignore and that by engaging the Linux kernel security mailing list a whole pile of mechanisms kicks in that remove options to play nice with newbie submitters and to help coach them through how to reach the state of the patch that would have been expected the first time around.
OP is aiming a pretty heavy handed attack on a kernel maintainer (a thankless job on the best of days), does so by misrepresenting their interaction in ways that matter and on top of that couldn't be bothered to read the docs.
I follow your point about the OP maybe not understanding some context and well it's just a hard lesson learned.
I don't follow your fixation on sign-off. I am familiar with the guidelines. Like I said, sign-off is clerical. Yes it's obviously important, but it's still clerical. Nothing you've said changes that.
I agree there's obviously a middle ground here where both the maintainer was acting in the best interest of the community to get a security fix integrated and where the first-time contributor was perhaps miss-attributed in the commotion and feels slighted but also can learn a lesson. I'm not one of those out there calling for a witch hunt to cancel the maintainer (honestly I don't know where to those people are, but I'll take your word that you've encountered a few of them).
Still, your fixation on "well Ariel didn't sign off on the commit so all's fair" is pretty dismissive of the work Ariel did to get to the patch. The bug was acknowledged and outstanding. This obviously wasn't something massively problematic or the original bug would have been fixed when it was reported (I guess maybe it was misunderstood and it really was serious, but I don't get that vibe), so I don't think we're dealing with a case of urgency trumping all human decency.
At the end of the day, Ariel is a contributor. No not someone who has privileged commit access to the software, but a contributor to the project nonetheless, whether a maintainer copy-pasted the work or not. And hopefully someone who will continue to contribute in the future. I hope Ariel can come to see it that way whether the maintainer tries to make things right, or even just apologize for the confusion, or not.
I don't read Ariel sharing his experience as an attack. I read it in his words as:
> Well, I certainly didn’t feel inspired to get involved with the kernel community again. On the contrary, I felt belittled and angry that my work wasn’t properly recognized.
> My first contribution to the kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work.
I, at least, hold the "lkml bureaucracy" to higher standards.
He choose explicitly to bring the Linux security mailing list into this and that changed the playbook considerably. That changes the situation from one where you can take your time to coach the new person to one where speed is of the essence.
Whatever work Ariel has done has been grossly negated by this attack piece, besides the fact that it omits and/or materially alters the nature of the interaction. At no point did the maintainer leave any doubt as to their intentions, nor was anything that happened unexpected. If you start off your career as a contributor to the Linux kernel by mailing the security mailing list then that requires you to do your homework because otherwise things will be out of your hands. If that was the OPs intention he would have done better to leave the security mailing list out of it and first strike up a conversation with the maintainer about what the best way to start contributing is (there are guides as well, but since he clearly wanted to target this particular subsystem that would have been a valid approach in my opinion).
It's an attack to me because (1) it mentions an exchange that names individuals and (2) it does so using some very expensive words ('robbery'). That's not the kind of accusation that you make lightly and in this case I think it is vastly misrepresenting what actually happened. You only have to read the responses in this thread to OPs misrepresented account to realize how much effect such a thing can have.
What happened is that someone new chose a wrong and ultimately broken way to submit a patch to LKML and that the maintainers did their best to get maximum mileage out of it without wasting time on formalities. Note that these are pretty busy people, to put it mildly and by mailing the security list you've just made them that much more busy still (even though, technically the patch was an improvement it still required work that then ended up becoming high priority).
As for Ariel being a contributor: according to LKML he submitted a proposed patch that needed work, wasn't properly signed off and according to the git commit log he created a report. That's the extent of it, and that's fairly accurate given the standards for these things.
If you want to argue that those standards need work then you may well have a point. But within the current framework this all was 'business as usual' and totally expected.
I'm not arguing with any established contribution process. I'm arguing with your interpretation of this entire issue because it's plain and simply uncharitable and wrong and furthermore doesn't come from any position of authority. You've littered the entire comments section with your snooty attitude and it really doesn't progress the dialog one bit. More importantly, it's not how a community should treat contributors which is why I'm even commenting in the first place. I can handle internet divas being pathetic asshats on HN when it's only hurts themselves. I can't handle the same at the expense of a well-meaning contributor who put in hard work to fix an issue that makes the kernel better for everyone and especially where it involves spreading blatant misinformation about how the kernel community supposedly is allowed to treat people, and takes liberties with IP law.
I even tried to reach a middle ground understanding and you've doubled down asserting that there's no world in which the author's lived experience can be valid because he didn't initially add a signed-off-by line. If you actually read the post, the author spends most of the time describing the issue and the fix. He takes maybe 5 sentences to explain how he didn't feel like his contribution was accepted in a considerate manner and it's discouraged him from making further contributions. It's not some grand 1000 work attack and if anybody has the thick skin to withstand one of those it's the goliath of the LKML.
Anyway, the author pretty explicitly states that he did go back and forth with the maintainer privately and provided a fixed up patch which addressed feedback he'd received on the first patch (presumably with a signed-off-by line, now) and the maintainer still didn't want to give credit. You've conveniently ignored this part of the narrative entirely. This really discredits your whole "it was a quick security list issue and wasn't even formatted properly lol this guy obviously deserves no respect for engaging the security list and generally being a noob" angle.
Everything that we know points to the contributor trying to act responsibly by engaging the security list first since they didn't know the security impact of a possibly major security issue (overwriting the stack of a traced process). I completely fail to understand your logic whereby doing so means the OP obviously fucked up and deserves to have his contribution belittled and stolen and that's just life on the LKML... seriously I think it's time you just admit you're in the wrong here and stop shit posting.
We've already been through the whole "you shouldn't need to have thick skin and tolerate insults and disrespect to contribute to the linux kernel" as a community. Linus even took a leave of absence over this shit. Your stance that this stuff is acceptable and par for the course is no longer the status quo. Grow up.
Not adding much to the conversation with my comment here, but I'd like to thank you for calling jaques out on their attitude.
I've been trying to browse this thread and before I started checking usernames I got the the impression that there's a whole world of maintainers who think it's acceptable to be disrespectful to people spending a lot of time and effort on trying to contribute.
It turns out it's just a few (very prolific) people creating a lot of negative noise across the thread. Thank you for stepping up.
FWIW, that "Signed-off" gate isn't as solid a shield as one might want.
If someone put the work in to identify a bug, contributed a fix, and that fix wasn't accepted but another fix inspired by the previous fix was accepted... That could be plagarism.
Burden of proof is on the plaintiff to prove the fix was inspired by the RCA and proposed fix, of course, but this isn't exactly a clean-room work and kernel maintainers should probably be careful about taking ideas without signoff on the lead-in side too. There's a reason Marvel et. al. in the publishing world can't accept new character concepts.
The purpose of DCO is to move the guilt of plagiarism etc from the Linux kernel project to the individual contributor who added the Signed-off-by line.
Indeed. What I'm saying is it might not work to remove that guilt if a bug is reported and a solution presented, and then instead of incorporating the solution presented the kernel team (without DCO in hand) fixes the bug using code that looks suspiciously inspired by the provided solution.
This is murky enough that it would have to be decided in the court of law, but it's not cut and dry enough that it would be immediately thrown out of that court of law.
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.
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.
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.
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.
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.
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.
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.
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:
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?
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:
"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.
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.
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.
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.
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).
> 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.
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 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.
"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.
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.
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.
I don't think extrapolating "one person who acts badly not being much of a loss" to "all maintainers should leave" is a good interpretation of what was said.
If this person is a wanker they all are, if this person should leave they all should leave. Absolutely nothing happened here that warrants such a response.
You really should familiarize yourself a bit more with how contributions to the kernel work, especially because there is an excellent document that lays out exactly how contributions to the kernel are handled.
No part of that document details out that if you fail to follow their exact ritual then they get to steal your code and include it as their own. In comments all over this thread you go on about OP not following the proper ritual to appease the Greg Kroah-Hartman, for the code not being significant enough, for being unsolicited, for not being exactly as some random maintainer would like it. None of that matters. What matters is that this guy's code is in the kernel, unattributed, with minimal changes. If the kernel maintainers feel the ritual wasn't followed, then they can reject the patch, not steal it.
Seeiously, what are you expecting from Michael? Go back and forth with the newbie until he makes a perfect patch? Sorry, but that's bullshit and clearly a horrible use of a maintainer's time.
Michael did his best by fixing the patch and incorporating into the kernel and properly giving credit to the newbie by using the "Reported-By". The fact that there isn't a proper tag to describe the newbie's case is not Michael's fault. Maybe the kernel should add a "Debugged-and-fix-suggested-by", but I also think this is bullshit.
As noted elsewhere in the thread, there is no fixed set of tags that Michael was limited to choosing from. And he has now acknowledged that the use of Reported-By was incorrect:
Again as I said, maybe "Reported-By" was not the most correct tag, but it still attributes some form of credit to the newbie. I just think that's too much woke culture and self entitlement from the newbie. You just have to work harder and up your skills to match the maintainer's standards before you can be called a kernel hacker. One or two patches, imho, is not enough to be called a kernel hacker, especially when it's only about fixig a bug. I fixed many similar obscure bugs. Writing a precise algorithm for Automatic NUMA balancing is a true kernel challenge for which one deserves to be called a kernel hacker.
When I started contributing to the kernel, it was super painful and I failed multiple times. I got super harsh comments (someone called me "retard. It was fun, I laughed, eventually part of my work gor merged) but I always respected the maintainers and I was eager to better myself and improve my analytical and development skills with an open mind to be as sharp as the senior hackers. I always looked up to them and never thought in the same way the newbie did when my patches got re-written or dismissed. I just considered myself "not good enough" and I felt "I had to work harder and smarter".
It is irrelevant whether or not anyone considers this guy a 'kernel hacker', because all he wanted was proper credit for the work he did, not a shiny gold badge with 'kernel hacker' written on it. There is never any excuse for failing to credit people's work. It seems you agree that he was not properly credited in this instance (and indeed Michael acknowledges this in his apology).
Your second paragraph is the same logic that frats use to defend hazing rituals. (I went through it, so why shouldn't the new guy?)
Introducing the word 'woke' into this discussion can't possibly be a good idea.
In my opinion, it's all market economics that decide how things work. The moment you introduce a complex courting procedure, where maintainers are required to be nice and acknowledge every little detail and guide the newbies through every half-baked contribution, you'll kill the project. That's because what keeps the maintainers and the senior contributing and maintaining is the technical work and not the human work. Most maintainers would rather spend their time exploring, contributing and doing technically useful stuff than making every newbies happy and welcome and teach ing them to be smarter and better developer. Such a project will automatically loose the ultra smart, self-driven people that keeps projects like the Linux kernel relevant for more than 30 years. It's all market economics.
No, it’s simple ethics and nothing more: credit where credit is due.
The maintainer said this guy ‘reported’ the bug when he’d actually diagnosed and fixed it. That was a mistake which the maintainer since apologized for, and the mistake could have been avoided without any additional time and effort on the maintainer’s part simply by using a more appropriate tag.
You are really going off into outer space with this stuff about ‘market economics’ and ‘complex courting rituals’. In my experience, whenever I need to make very complex and wide-ranging arguments to justify my behavior, it usually means that I’m the asshole.
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.
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.
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.)
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:
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.
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.
> 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.
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.
>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.
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.
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.
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.
> 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.
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?
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".
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.
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.
> 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.
> 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.
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.
Ok. Here is a lesson on forums. The comment thread you replied to is full of a guy trying to use a strawman argument. Except he stuck with the same one. You came along with a new strawman argument. So because you replied to a series of strawman arguments with a new attempt at a strawman arguments I wrote my comment in context of where it is in the thread of replies. So I congratulated you on being different. However, I then went on to shame you for using a strawman argument in the first place.
The lesson here, is always remember context. The point at which you start your input is surrounded with the context of before it. So if you were closer to the start the context of the previous strawman attempts wouldn't have been in play.
This was not a personal attack, it was a statement of fact. The user in question was obviously either engaging in bad faith or could not be bothered to read back for ~15 seconds to understand the context of my post. When I pointed this out to them, they doubled down. They were not just wrong, in my personal opinion or objectively in whatever sense---they wasted my time and insulted me.
You can see from my other comments in this thread that I prefer to engage respectfully with other commenters, even ones I disagree with, and I believe my total commenting history going back to 2016 will reflect that I do in fact take the intended spirit of the site to heart. But if speaking forthrightly to a bad faith and/or willfully ignorant interlocutor like this user drags me down to their level in your view, you ought to ban me right now. Thanks.
If you find yourself inspecting someone else's comments or behavior for how much bad faith you perceive, or what they couldn't be bothered to do, or anything of the "who said what" variety, you've already fallen off the path of curiosity* and this is a clear sign that you should refrain from posting. That's not a criticism—it happens to all of us and it takes work and practice to avoid it. But it's work we all have to do as a community, if HN is to last for its intended purpose. (Btw that's also the answer to why 37677835 was flagged - it wasn't a personal attack but it was a step off the garden path and into the weeds.)
When a commenter uses phrases like "bad faith" or "willfully ignorant" or "down to their level' about another commenter, it's usually a sign that they're too activated by a conversation to really practice the principle "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." (https://news.ycombinator.com/newsguidelines.html) In such a case it is better to refrain from posting until you no longer feel that way. Why? because you (I don't mean you personally, but all of us) are not functioning in the range of curiosity when you feel that way—it's impossible; and second, if you reply with what feels to you like "speaking forthrightly" in that moment, you're likely to post things that land with the other commenter, and also the general reader, as attacks, not to mention get replied to by moderators asking you not to post that way.
A statement becomes a personal attack when it's intended as an attack, not simply because it's hurtful to the recipient. For instance, (addressing the pg example you mentioned elsewhere) it's not generally a personal attack when an old and/or sick person's doctor says they have a few months left at best, though hearing it will probably upset them. It's likely (though absolutely not certain!) that one middle schooler pointing out another's acne intends for it to be hurtful, but I don't think you could reasonably blame a very small child for pointing out the same—though it would certainly be a teachable moment.
Semantics aside, I understand from experience how difficult it is to moderate situations like this, but as a user-privileged participant in any discussion I reserve the right to defend myself (e.g.) when somebody rolls out some half-baked strawman and then accuses me of going off topic. In this case I find it particularly ironic that in a thread full of completely baseless character attacks against Miculas, the author of the linked article (e.g. he just wants credit so he can put it on his resume), I'm the one who gets threatened with a ban for questioning that narrative and not then meekly rolling over for the ensuing tide of bullshit. If you want to see a real, unequivocal, totally one-sided personal attack, you need look no further than the original comment I replied to^[1], and you can't throw a stone from there without hitting another one. I note that those comments remain largely unflagged, which is not a surprise given how acutely vulnerable users of platforms like HN are to the bandwagon effect and similar biases.
My behavior in this regard is not going to change, but my experience in this thread is certainly raising some questions.
If you don't like the phrase "personal attack", I can put it this way instead: please don't post pejoratives using personal language.
In the context of moderating an internet forum, we have to go by effects, not intent: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que..., for a number of reasons: (1) intent isn't observable or generally predictable; (2) effects are both observable and generally predictable; and (3) it's effects which ruin threads.
Everyone always feels like they're the one being singled out and treated unfairly—this isn't a reliable feeling, just a universal bias. If other comments broke the site guidelines as badly as you did, and the mods didn't say anything, that's only because we didn't see them.
> 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.
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.
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.
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"?
>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?
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.
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.
> 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...
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 .
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.
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.
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.
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.
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.
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.
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.
> 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.
... 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.
> 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.
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"
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.
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.
I haven't compared the patches but a comment below [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 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.
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.
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.
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.
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?
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...
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).
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. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
> 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.
> 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.
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.
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.
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 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
> 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.
> 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!
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.
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.
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.
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.
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.)
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.
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.
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.
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)
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.
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.
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.
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...
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.
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!
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.
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 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?
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.
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 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.
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.
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...
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?
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.
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.
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.
>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.
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.
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.
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)
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?
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.
> 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).
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.
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.
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.
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.
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.
* 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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'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.
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 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.
> 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.
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.
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.
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.
> 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.
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.
"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.
> 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:
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.
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.
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.
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
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.
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.
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.
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.
> 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.
> 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?
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 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.
> 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.
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.
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.
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.
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 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.
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.
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.
> 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.
> 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/
> 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.
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.
> 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.
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.
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"...
> 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.
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.
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?
> 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."
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?
> 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.
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.