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