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.
From what I've read, the majority of kernel contributors get paid by their employers, that is, they fix things that affect them.
And, I'm guessing that getting credited for their work is important to them too, for career reasons if nothing else.
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 does exist, but unfortunately people who practice it are not believed by those who do not, because they cannot fathom it.
Why is the fix by the author inferior? By all we know it could even be better. Not taking sides, just pointing out that your response seems kinda biased against the author.
> Also, the only reason you put so much effort into this was to fix your own problem
Isn't this the case with most problems? Fix the problems that impact you first, then other ones. That's completely normal.
It very often happens in FOSS that a contribution is well-intentioned, but doesn't match all qualities of the project, and asking them to fix it vs. rewriting wastes a lot of time. I've seen this pattern several times before: First-time contributor delivers patch, reviewer thinks "The idea is great, but it's faster if I just rewrite it rather than give feedback."
Consequence is, first-time contributor will not contribute to this project again.
FOSS maintainers can learn some pedagogy here.
I tried having a patch rejected only to see the maintainer rewrite my patch that introduced bugs.
I have a similar experience with a bug fix I submitted and the decision to delay my fix to literally change the whole architecture of the project left a bad taste in my mouth. After that I stopped contributing to the project and just kept my fixes to myself.
It's especially annoying when the maintainer asks for help and pulls this. Architecture changes after proposing small fixes to projects has been a somewhat common occurrence for me.
Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.
Regardless, this individual received a reported-by credit. That’s more than adequate.
"just fine" is not what we aim for. "just fine" is probably what they thought of the OpenSSL library before heartbleed.
> Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.
Sure but it sounds like you're making a generalization about a specific instance you know nothing about. There doesn't seem to be an enormous cost detailed by the maintainer in the email thread. Just that he'd rather gatekeep the project and rob someone of the opportunity for contribution.
This individual wasn’t robbed of the opportunity for a contribution. He received credit for his contribution via a reported-by flag. It’s a tiny patch — all the work was in identifying the bug, which is what he received credit for.
He did something valuable, and has every right to write it up, but clearly has limited understanding of the development process he’s participating in. It was wildly inappropriate of him to of put anyone on blast in response to this.
In another situation, I was using an emulator and it didn't read a file correctly. I read its source code for the first time, I fixed it, in what I thought was the right way. I supplied the bug report and the patch. The maintainer thanked me and fixed it a different way - a way that wasn't obvious from their code, but was a better fit.
In another situation, I found a library that sticks out like a sore thumb and doesn't accept values that other libraries do (the standard they're all aiming for says the value is "implementation defined" so this is technically allowed but it annoys me). I raised a bug. I offered a patch. The maintainer had a bug up his ass about this particular value and told me he was changing nothing. Not much I can do about that.
In conclusion:
FOSS maintainers aren't endless fonts of personal validation for you. Some of them don't even want contributors. They already gave you the software for free, _and_ the legal means to fix it yourself. You can patch it, you can fork it. Your fork might be better than theirs!
They might accept your bug report. They might review your patch. They might accept your patch. They might mentor in you how their project works. They might devote all their time to contribution management and never have time to write their own project. Each of these takes their time and energy. They don't owe you any of that. Not every project is a popularity contest, not every project wants your help. This is all OK.
You are correct in that it is the maintainers's choice. No doubt about it. But now, a potential contributor who invested a significant amount of time in a problem clearly nobody else had solved up to that point, was snubbed. The work was capitalized on, used as a foundation for a solution, and not even a comment giving credit was given.
This sends a terrible message not only to them, but to future contributors as well on a project that needs a new generation of talent to perpetuate it. This isn't just any OSS project; this is the Linux kernel, something millions if not billions rely on. Scale up this behavior, and it won't end well.
It can be sustainable; not all FOSS projects need every possible contributor. Being a good leader is not a prerequisite, either. Direct cooperation isn’t even necessary!
The fact that source code is available allows anyone to fork and compete with the original authors. On average, only mismanaged projects will get out-competed by their forks.
Beyond the morality of doing this, there is a practical consideration of copyright issues. OP did that as part of his job. OP and his employer have some sort of agreement of ownership of these 30 lines of code and the maintainer putting his name on it and putting it into the kernel could someday be a problem.
The maintainer deemed it inferior and they are the one to decide. By posting on a security list, the maintainer went out of their way to give the issue critical priority, speedy processing and extra critical correctness review. We all like the feeling of credit, but this context is very important.
It's too bad the proposed fix wasn't good enough, but getting the issue resolved is always first priority, above getting claim to the fix.
Exactly, this is why a field "co-authored-by:" is a nice middle ground that allows for providing partial credit to the original author while maintaining maintainer's freedom to rewrite the whole damn thing.
There was no Signed-off-by in the original patch, and the rules say Co-developed-by also requires a Signed-off-by.
It was a security issue and was fixed ASAP, not waiting to hear back from the submitter.
https://kernel.org/doc/html/latest/process/submitting-patche...
It was decided by the maintainer, the only person who can make the decision.
> we need to see the patches.
... they are linked in the post.
You don't know that.
There is nothing wrong with being motivated by getting credit.
And there is nothing wrong with fixing FOSS problems you're affected by.
The value of FOSS is fixing a problem once for everyone.
> this attitude doesn’t qualify for contributor status.
Since when was attitude a qualifier for contributor status?
Linus Torvalds himself had questionable attitude at times.
The simple fact is: He did contribute, he just didn't get credited.
How much would a
Co-authored-by: ...
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.
That's incredibly reasonable. Not crediting them is plagiarism.
Moreover, even most permissive open source licenses require attribution.
not if it is a substantially different fix.
Besides, even if your method is genuinely original, it's only fair to credit the work you're building on. If you're writing an academic paper and come up with a whole new mathematical approach algorithm, you still reference the previous best algorithm.
Yeah it really is. If they rejected the approach and rewrote it from scratch that is sufficient. Doing a cleanroom reimplmentation with someone who had never seen the original patch is a good affirmative defense to protect against all possible lawsuits, but it isn't required.
> If you're writing an academic paper and come up with a whole new mathematical approach algorithm, you still reference the previous best algorithm.
This isn't an academic paper, and the proposed fix wasn't published, and it sounds like the maintainer thought the proposed algorithm was "poor" not "previous best".
You can consider it "rude" but under no circumstances is this illegal in any way.
He asked to accept "a patch" not "the patch". You left out the next sentence: "I was also open to working with him, addressing his feedback and sending subsequent versions of patches."
It should also be noted that by sending to security@, you trigger a machine optimized for getting fix merged fast to protect the user base - not one optimized for teaching new contributors.
This is the crux of the issue, and that generated a mismatch of expectations vs reality. If it went through LKML I'm pretty sure someone would have guided him to have a patch accepted and fully authored by OP.
As an external observer, however, I empathize and sympathize with OP.
Based on what happened the first time, fixing other problems may have led to the same outcome again.
the debugging *is* the work! the work for which he went uncredited, that's the crux of the whole thing. he got a Reported-By which just means he ran into a bug and told someone about it, not that he root caused it, wrote a patch and bothered to submit it.
This whole thing tastes to me like a pay-off for an unwanted gift, you don't go into this sort of an exchange on a security mailing list expecting kernel contributor credit for fixing a bug. That's just not how it works. Maybe it should work like that but it simply doesn't. OP had pre-set expectations and those were found to be in the wrong, nobody got 'robbed' and misrepresenting the exchange to one that makes the kernel maintainer seem like an asshole when that wasn't at all how it went down makes me feel even less good about the whole thing.
Reported-by ranges the gamut of 'I ran into this bug' to 'I found this issue and here is my patch, which I hope is useful to you'.
If you want to negotiate credit rules for 4 line patches up front you are of course welcome to do so but keep in mind that maintainers can and do accept patches, rewrite them and contribute them under their own name (and their responsibility), especially security patches.
> Maybe it should work like that
Definitely
But the patch was not taken. The maintainer fixed it a different way. So credit is given for reporting the issue and suggesting a fix, and that is what is represented by the Reported-By. Is that so hard to understand?
This entire HN comment section is ridiculous with everyone acting as if the author wrote an entire subsystem and someone else took attribution.
The author here figured out a bug and suggested a fix. It happens that they conmunicated their fix in the form of a patch, but that happens very regularly in kernel land.
In the end the author got a Reported-By, which is entirely appropriate for what happened. If the maintainer accepted the author's patch as-is or with minimal modification then yes, they should get Author attribution. But the patch that was taken was substantially different.
Weirder still because all of this has been done in the open for all of that time, it's not as if how the Linux kernel is maintained is a secret.
Can't you see that the kernel has its own conventions and practices that are entirely different from typical corporate practices?
If receiving credit is your primary motivation, over actually solving problems that affect people other than yourself, I don’t think that’s a great attitude towards OSS. I’m genuinely surprised this is even considered a hot take.
Yeah, I’ve contributed to OSS. And more often than not, I haven’t received credit. I couldn’t care less.
It seems like a rather significant thing to state based on a single blog post. Do you know this person from before?
They received a reported-by credit, which was more than sufficient — especially on a tiny patch that got rewritten.
The important work was identifying and reporting the issue, and they got credit for that.
By turning around and writing an angry blog post, they turned a non-issue into some seriously unpleasant drama. Nobody is going to particularly want to deal with them again.
Note that you are talking about a project that is older than quite a few of the people on HN and that it pays off to know how such a project operates before attempting to contribute, more so if you plan to go nuclear about your expectations not being met.
Finally, and if you do go nuclear it helps if you don't materially misrepresent the interaction with the maintainer, who did not exactly ask for your contribution.
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?
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.
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.
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.
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.
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?
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.
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.
Just because something is free, it doesn’t make it common property. Being able to use the kernel and modify _your own copy_ is not the same as the kernel itself being common property. The four freedoms don’t grant us permission or rights to alter other people’s copies of the software, so those copies are not common property.
> The maintainer didn't have to accept the patch per se. He could have just written "This bug is discovered, dissected and fixed by $THE_PERSON. Patch is implemented and committed by me. Thanks a lot, $THE_PERSON!".
That’s basically what happened, yeah? The author got credit for reporting it.
Of course, but accepting a bug, giving feedback on a submitted patch to be included in the kernel is openly saying "We're willing to accept this, but you need to polish this and that", which the author did.
In practice he got the permission to modify their copy.
> That’s basically what happened, yeah? The author got credit for reporting it.
No, definitely not. They got a "reported-by" tag, which means "the author told me that something is not working, so I did all the work to find why, did all the work to solve, did all the work to implement, did all the work to commit."
In reality, the author found, debugged, solved and patched the problem. The maintainer didn't like the style, pushed his version, and claimed that all work is done by him, except hitting his proverbial foot to a proverbial stone while walking (i.e. discovering the bug).
I wouldn’t consider it common property if permission is required. It seems like our definitions of common property differ, but I’m not sure there’s any value in trying to align ourselves on this.
> No, definitely not. They got a "reported-by" tag, which means "somebody told me that something is not working, so I did all the work to find why, did all the work to solve, did all the work to implement, did all the work to commit."
Got it. Yeah I agree this is not the same. However, I still stand by my original stance which is that no one is owed anything, especially when they do something no one asked them to do.
Same here.
> I still stand by my original stance which is that no one is owed anything, especially when they do something no one asked them to do.
I understand your point, but nothing is mandatory in Free Software. However, this is not about internet points, but it's human decency with consequences.
Strip the event from The Kernel and computer domain, this is plain rude, unjust and unethical. The author says this, and I concur.
First, we need to do better as humans. This is the lesson.
The way OP framed it in the blog post, it sure does seem like it's mostly about Internet Points:
I told him that I would really appreciate if he could accept a patch from me, so that I could receive credit for fixing this issue and become a kernel contributor.
Woah this claim a bit too strong. There's a "reported-by" line in the final patch that ended in the kernel:
https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...
Whether that's sufficient is another matter.
Giving a mere "reported-by" tag to a person who comes with a patch is just too unjust. Isn't it? The patch may not deserve to be included in the tree as-is, which can be understandable, yet dismissing all the research is essentially saying "you're too young to be here. Leave this to grown men, ride your tricycle over there. Here's a candy. Good boy."
It sounds like you are just trying pour oil on a fire.
Would you prefer to live in a world where people are obliged to spend extra time dealing with easily-broken egos because all non-overtly-friendly acts can and will be interpreted as contempt? I personally rather assume people are well intentioned, and let them focus on fixing problems instead of catering to egos.
Or maybe you like playing the ego game. That's fine, but I'm really honestly questioning my assumptions towards humanity in the discussion here. Do people really think I view them in contempt if I don't write a couple paragraphs of words to sooth their egos after I disagree with them?
About the oil: I'm not that kind of person. I'm just defending what I'm thinking right. Also, I know about oil burns. That's something I'd never wish on my enemy.
One doesn't need to be overly, or overtly friendly, or to write long fluffy sentences to come across as kind. It's about the word choice yes, but not in the straightforward way we are wired to think. It's something more subtle.
I write many e-mails every day, talking with people from many nations, at every level in many projects. Some of these mails are novellas, some of them are four word bursts. Yet regardless of the length of the mail, I can convey the tone I want, and people understand that.
Sometimes I need to say no to people, and I say it directly. Sometimes I thank them sincerely. Rarely I write hard/heavy mails, which is something I hate to do (and I don't use the word lightly), but without any strong words, and they go through too.
Being kind is not playing the ego game, and doesn't need extra time. What is wrong is thinking that you can throw words and/or people around just because you don't see their faces, don't like how they name the variables, or you think you can say anything because you're a nerd/geek/hacker/whatever and these features or adjectives give you license to push people around.
Lastly, I think soft-skills are way more important in development communities, because your projects' life-span is measured with the health of the community supporting it. Gate-keeping, elitism, and similar acts slowly but surely damages a community. We should strive to be better humans first.
Coding is easy. Communication is hard.
I don't know what you're talking about. Are you talking about the jerks you encountered in life, or the exchange between the OP and the kernel maintainer? Because I don't see any of that behavior, nor anything that warrants the hostile interpretation I objected to earlier.
Have you actually read the email exchanges in question, or are you taking the OP's claims at face value?
PS: nvm, given your hyperbole at the very beginning ( https://news.ycombinator.com/item?id=37677962 ) I probably gave you too much credit for attempting a grounded discussion.
All the best,
Have a nice day.
At the very least the maintainer could have modified the submitted patch and thus granted co-authorship to the submitter.
Who knows — maybe the maintainer is a narcissist who couldn’t accept patches for his own broken code.
https://kernel.org/doc/html/latest/process/submitting-patche...
If an OSS project ever needs to change the license they will need to seek permission from each contributor. You can't relicense a project if you have some code that's submitted without proper attribution to the actual copyright holder.
(a) so why it is okay for companies to sponsor events and use it as a marketing, but not okay for people doing same?
(b) what's wrong if people want to help fixing problems when they get impacted? isn't it good that they are not demanding someone else to fix, but giving a help?
Having done all the debugging work and figuring out a way to fix it, it's a bit nasty of the maintainer to make a "better version" of it and rudely tell them to be "more useful. Basically it's the same as accepting the contribution and refactoring it afterwards.
If the author "only wanted Linux street creds", without the context of a problem, they could have searched for an easy issue to fix and contribute on that. No, wait, now you'd consider that an act of selfless OSS contribution, fixing random problems not related to you!
So what ? These are two perfectly valid motivations. The only thing that matters really is that in the end it benefits everyone.
Also, more to the case in point, how do you know the contributor's solution is "inferior"? Isn't it equally possible that the current maintainer refused to give space to the new entrant lest they lose the grip on their position? I have seen this behaviour a lot in the corporate world.
And, if getting your code into the Kernel is the only way you get that label then that's a shit system, all the testing and writing solutions "contributes" to the final code, its like the 90% you don't ever see.
Sorry shortcake27, this is just a bad take lol
Everybody does this:
1. Yes, I'd like some credit and status. -- Every human ever.
2. I have a problem, I would like to fix it -- Every programmer with a problem.
Could you tell us which open source projects are yours so that we, as a community, can avoid contributing to them? We don't want to support this type of behaviour.
Who’s “we”? You say I’m off-base, yet this is one of the most upvoted comments I’ve ever written. Clearly a lot of people agree with me. At the end of the day, these are all just opinions and you seem to think yours is correct while others are wrong. A dangerous position to hold.
The main thing is to re-read one's comments after posting them and then edit out anything you notice that breaks the site guidelines. It's much easier to notice these things after posting them. That's my experience anyhow, and it's why https://news.ycombinator.com/newsguidelines.html includes the phrase "edit out".
One tip, in case helpful: you can set 'delay' in your profile to give you time (up to 10 minutes) to look over and edit your posts before others see them.
I have code in your OS, node and maybe your web framework.
I am *absolutely* only interested in OSS when I get credit. Why would I remain interested in contributing if someone else takes credit?
Your comment made me think. I’ll preface this with an I also have code in your favourite web framework.
There are many people like myself who don’t care about attribution, and don’t understand people who care more about attribution than the project itself.
Then there are just as many people like you, who are only interested in contributing as long as credit is given. And you seem just as equally unable to empathise with my position.
And I feel like this is causing such a heated environment, because neither of these groups are seeing eye to eye.
Just a thought.
> Then there are just as many people like you, who are only interested in contributing as long as credit is given.
The "as long as credit is given" reads oddly to me. Attribution, for me is basically table stakes. Score of zero. I contribute, my contributions are attributed to me. I think you think of credit as a reward, but it's not. It's just decency to me.
Someone taking credit, enjoying the fruits of my work, but not enough to attribute them to me, is minus one. It's not that I'm not being rewarded, but rather that I'm being stolen from.
Most people want credit for their work. People enjoy recognition for the things they do, though not all people crave it.
As for part b), isn't that exactly the attitude encouraged in snide style by OSS advocates whenever someone complains about the function or quality of an open source project?
"If you don't like behavior x, you can fork it and fix it yourself <smiley face>"
So someone does some work that many don't do, did it for free, and wants to see their name somewhere on the patch note. Sounds reasonable to me. If that gets more people (self) interested in maintaining one of the world's most important software projects, okay.
I think this is the least we can do for people who contribute to OSS. Add to that that "contributing" could be as much as commenting on an issue. It's basically zero-cost and encourages help.
> 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.