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 not how I interpret the contents of the exchange:
https://www.mail-archive.com/[email protected]/m...
Could the kernel maintainer have handled this better? Probably yes. Was the OP robbed? In my opinion, no, their work was credited and the fix is so small it doesn't warrant elevating the OP to 'Kernel contributor' which is typically reserved for more substantial contributions, not bug fixes of a few lines.
Another comment has a nice middle ground in the form of the 'Suggested-by' tag which I think would have been an improvement. I've got a little project on the go and I'm meticulous about crediting people but the context is entirely different there, nobody is going to hold up my project to claim they are a contributor on their CV so I'm fine with the kernel maintainers keeping the list of 'kernel contributors' manageable.
How is fixing bugs not a contribution?
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.
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.
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.
> What’s the incentive here?
To not turn away people who want to contribute, and have proven they can help, who are doing the job they're asked to do by their employers in the case of industry, by being an asshole to them.
> To ask for credit as a contributor makes it seem as though that was the whole goal
There's nothing, at all, wrong with this.
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.
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.
> 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
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.
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.
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 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.
Yes, it is. His motivation is very clear:
> Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore.
This is an incredibly uncharitable description of his motivation:
> If the goal is to fix something to be able to put kernel contributor on your resume
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.
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?
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.
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?
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.
Linus' attitude is very material. Kernel leadership sets the stage for other contributors to do the same, good or bad.
Stop gatekeeping.
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.
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.
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 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.
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.
All I see is that no good deed goes unpunished.
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.
The author did themselves a disservice with their disingenuous paraphrasing. The lack of attribution remains a problem however, and is not justified by the author’s misrepresentation; just as the author’s behavior is not justified by the lack of attribution.
OP could have maintained the moral high ground but didn’t, and that’s a bummer, because now this is an “everyone sucks here” situation.
Attribution remains important.
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.
I've just barely arrived at the conclusion that I could make a change, offering minor suggestions and changes on projects I care about and then have the read someone degrading a contribution that is still "several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues"
And when you point this extreme ranking out as inappropriate, your comment gets vaporized.
This REALLY bloody hurts
12 - accepted, sometimes additional changes were required
1 - ignored; this was a trivial change and I wouldn't have submitted it now.
1 - rejected; the maintainer didn't understand my proposed fix and closed the pull request.
1 - rejected; the maintainer disagreed with the proposed change.
> This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues
As someone just getting started with but a tiny OSS footprint and grade care to not step on anyone's toes, this is a deeply unfair statement.
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.