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.
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.
* 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.
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 were 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.
Op did all the research and multiple implementations of a fix. Ellerman refactored the fix to be simpler, but the effect is the same.
> The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
It more seems like he knew about IS_ENABLED and Miculas didn't, because he uses `IS_ENABLED(CONFIG_PPC32)` instead of Miculas' `#ifdef CONFIG_PPC32`. Besides, Ellerman's changes are all inside `#ifdef CONFIG_PPC_FPU_REGS` blocks anyway so I'm not sure this was a major consideration. Using `IS_ENABLED` gets you 90% of the way to the "cleaner" patch, and in a ~30 line patch I don't know if it's worth golfing further.
Miculas' patch: https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
Ellerman's patch: https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...
EDIT:
Oh he also got a code review giving him exactly these tips [0]. IDK, getting real "I don't want to coach this rookie, I'll just do this myself, thanks for the tip" vibes from Ellerman here. Maybe that's valid, but it seems like not a wonderful way to keep people interested in kernel dev.
[0]: https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
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.
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.
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.
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.
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.
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. 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.
https://www.mail-archive.com/[email protected]/m...
> I'm sorry about the way I handled your patch. I should have spent more time working with you to develop your patch.
> I agree that the Reported-by tag doesn't properly reflect the contribution you made, I should have realised that at the time
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.
Hell, maintainers are usually more aware of broader concerns than the contributor.
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.
They did get the credit, just not for the code, and rightly so.
If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel, more so if it is posted as a security issue which get special treatment and a whole pile of extra review to make sure that the fix doesn't introduce yet another problem.
This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues, clearly some work went into this. But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up, especially if you want to do security work where the details really matter, so props for identifying the issue, but no medal for delivering something that didn't meet the bar for inclusion. And that last bit is where 'kernel contributor' comes in. The whole 'robbed' angle is an interesting one, it appears that there is a much higher perceived value than the one that is normally associated with getting an issue fixed (which is what most people would like to see). Perverse incentives are a thing and it is good to be aware of them.
> The value of FOSS is fixing a problem once for everyone.
No, the value of FOSS is the ability to read and modify the source code.
> Linus Torvalds himself had questionable attitude at times.
Whether Linus has had questionable attitude at times is immaterial: clearly he was a contributor and so is credited. This person did not contribute as of now. You see the same with YC and pretty much anything that people would like to have on their resume: the thing itself is less important than the CV mention.
> have hurt for doing all the analysis, even if the patch itself got completely rewritten?
That there are many more implications for being allowed to call yourself an author. The kernel contributors are doing very important work and their standards for inclusion are high. You don't make it into that circle without adopting their standards.
They 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.
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.
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
The amount of energy wasted in this thread on the meaning of "contributor" could boil me water for tea. Bewildering, honestly.
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.
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.
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.
Notoriety is the currency of open source software. And that's a feature, not a bug.
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"...
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.
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"
> 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.
You don't know that.
There is nothing wrong with being motivated by getting credit.
And there is nothing wrong with fixing FOSS problems you're affected by.
The value of FOSS is fixing a problem once for everyone.
> this attitude doesn’t qualify for contributor status.
Since when was attitude a qualifier for contributor status?
Linus Torvalds himself had questionable attitude at times.
The simple fact is: He did contribute, he just didn't get credited.
How much would a
have hurt for doing all the analysis, even if the patch itself got completely rewritten?