Low expectations is a helpful part of living a peaceful life. Everything nice that happens is a bonus, but I’d recommend not staking your happiness on what others do and don’t do.
Yes, but you can also do things for other people to make their day better. Saying that happiness comes from within doesn’t mean you shouldn’t try help others feel happy.
The best leaders never take credit themselves. It doesn’t matter if it’s a paid job or as a volunteer on an OSS project, if you lead, you give all the credit to those who work under your direction.
Then you're just shifting the same unhappiness the person who wrote this blog feels to the leaders. That sort of flies when the leaders get a ton of money or other benefits but this is an OSS maintainer. Going for extremes tends to lead to worse outcomes than aiming for a good middle ground.
>It doesn't create unhappiness when you're a leader because that's part of the deal.
Having spoken to a lot of low level leaders I'd disagree. It does create unhappiness because in the end they are no less human. That unhappiness may be worth it for the other benefits and the happiness they gain from them but saying they don't experience unhappiness is dismissing their very human emotions. But often the unhappiness dominates, they burn out and then get replaced by some narcissist/sociopath. That person is fully happy and rises up the ranks.
This sounds like they didn't understand what they were signing up for. If I lead a project, I get to take credit for the project not for specific IC work.
Of course if you happen to do IC work as well it makes sense to take credit for that, but I think that mixing leadership and IC work tends to result in burnout.
How would giving credit to the author of the article (the person that did most of the legwork) cause the project maintainer to feel unhappy ? I simply don’t get that.
The project maintainer surely would have not felt bad giving credit to someone ? Exhibiting this kind of leadership usually makes me feel great !
On the contrary, as we see from the article, the lack of credit really did create unhappiness from thin air…
I agree that in this case the maintainer should have at least put then as a co-author. At the same time the maintainer should get credit for their own on the improved patch. Middle ground versus extremes of leader get's all explicit credit or leader gets no explicit credit.
the secret of a happy life is trying to be happy, whatever that means to you, and making it, the secret of a sad life is trying to be happy and failing at it.
Humans aren't machines. In my experience it's very hard to actually have universally low expectations and be content with them in the long run. Usually people who say that either have low expectations in only certain areas (ie: material wealth, etc.) or are bottling up resentment (ie: the classic midlife crisis).
That's the point! It's very hard to have small expectations especially if you see your friends, colleagues or generally other people to 'be better' or 'have more', but if you can not care about this, you'll be happy. It is against human nature, though.
I'm literally in extensive therapy because of the huge emotional and psychic damage that having low expectations for everything has caused. Literally immense self-sabotage. Huge feelings of hopelessness and inability to do basic work without feeling suicidal because I expect the worse.
So no, it isn't always the opposite. For many of us, our pessimistic attitude has been extremely damaging.
Someone else here said
> You have control over the inputs but not the outcomes :)
I can't speak for others, but for me personally, having low expectations has caused me to become lackadaisical or even destructive with my inputs. What is the point if it will just go wrong?
EDIT: I can't reply because /u/dang has blocked my account again
> That... isn't what I mean by low expectations? For me, it means to be grateful for what you've got, to question feelings of envy and to not feel that you deserve something.
That's called "gratitude", not "low expectations"
"Low expectations" means you expect low, i.e. bad. It's pessimism.
That... isn't what I mean by low expectations? For me, it means to be grateful for what you've got, to question feelings of envy and to not feel that you deserve something. Definitely not to be pessimistic about anything, quite the contrary - be optimistic that you'll be positively surprised!
Regardless of all that I hope you work out your depression, it sucks.
Why can’t we try and change things we feel are unfair? Sure, we can’t change everything and we don’t always get what we want, but surely we can try, like asking someone to improve their behavior?
Either you're high status enough to not care about these things, or you get walked all over. For most people fighting for recognition on important or valuable things is worthwhile.
I mean the maintainers fix really does look better... op can and is credited with finding the bug because and that literally is all he did in concern of the code that ended up in the kernel. If you look at the initial commit and the linked stackoverflow answer I understand that the maintainer was hesitant to merge and wrote a clean implementation of it. Not even going into the "laying words into someones mouth" shit he did.
He found a bug (even that is questionable because it got reported prior), copy&paste-developed a fix and is angry that it doesn't get merged and now throws a hissy fit that he got attributed with the exact thing he did. Looking at his employer makes this even funnier.
> Is it so wrong for people to want to feel appreciated for their work?
Is it so wrong to not be awarded a medal everytime someone does something?
The title says "I got robbed", the reality is the solution has been discarded for something the maintainer, who's going to maintain that code, liked better.
The handling wasn't great, sure, but the real appreciation comes from within, from knowing you found a solution to the problem, not from others.
It is like going to the doctor with the solution and being upset if the doctor replaces it with something he can trust
It’s hard for me not to empathize with the author when they:
- diagnosed a longstanding bug
- contributed an initial patch
- actively reached out to the maintainer, who said they would reach out in private
- contributed additional versions that were reviewed
just to have the maintainer take over the contribution wholesale. How would you feel when you put in all that work and receive basically no recognition for it? Maybe you are truly ascetic and have no need for it, but most people appreciate being credited and being encouraged to contribute again.
> How would you feel when you put in all that work and receive basically no recognition for it?
I would feel that nothing bad happened and that my code was actually reviewed by a kernel maintainer, that acknowledged the problem, and found a solution based on mine, which is in itself a big ego boost.
But probably it's just because I have been programming for over 25 years, because I like solving problems, and I don't do it for the recognition, which is basically a false coin. The recognition at work is the salary, the recognition when I volunteer is that I contribute to help people when I can, not that the people I help are grateful to me. Sometimes they are ungrateful too, but that's not why I do it, so I don't care.
In my opinion it is childish otherwise, you do things you think they are right because you think they are right, not for some prize.
Never let your sense of morals prevent you from doing what is right.
> ----------------
- diagnosed a longstanding bug
- contributed an initial patch
- actively reached out to the maintainer, who said they would reach out in private
- contributed additional versions that were reviewed
That's basically what I used to do when my car had a problem and I brought it to the mechanic, because I grew up in my uncle's body shop.
but the mechanic does it professionally and of course he wants to do all the process again, so he can be sure what the real problem is. At that point he probably found a solution which is slightly better than mine or that solves the root of the problem, not just the symptom.
So now I just go there and tell him what is that I feel it's wrong (e.g. the motor keeps stalling) and I let him fix it.
If I wanted to become a real contributor, I would start from the bottom, as everyone does: changing oil (here's a bug you can fix)
My thoughts too. A bug existed, the maintainer looked at a contribution and as the maintainer picked the best solution which happened to be his own solution. That’s how the kernel community works. The community picks what’s best for the kernel. Not what looks good on your resume.
Someone spent 5 days debugging and giving the explicit details of the problem and a proposed solution. They should be given some credit, even if the exact lines of code that fix the problem weren't the ones proposed. The maintainer could've just given the feedback required for the contributor to submit the desired patch. Or some metadata on the commit could've offered attribution to the contributor. From the article, this was 90% the work of the contributor and 10% (maybe?) the work of the maintainer. Considering that being mentioned as a contributor to the kernel is a Big Thing, completely neglecting to give any mention is poor taste.
That’s quite harsh. And also a very simplistic tautology.
This post is literally about not getting credit for one’s work. If you don’t believe that the author deserved recognition for their work then you should say that outright.
There is a data field to store that information: who contributed a change. Writing your name instead of the actual author seems wrong and I wouldn't blame him to feel unrecognised. I agree it's probably not a big thing but remains a valid feeling in that situation.
> Not everything in life is about getting a golden star in your grade book.
No, but being a kernel contributor could affect his job prospects in the future.
One of the prides that I can discuss in job interviews are my contributions to upstream software stacks (mostly PHP frameworks such as Laravel and Magento). I have had a patch rewritten by a maintainer that arguably made the patch worse - that left a very sore feeling for me and I think that it was the very last patch that I sent to that particular project (Wordpress, which I am glad to be rid of).
A Wordpress patch, no. But an accepted Linux Kernel patch is a prestigious hurdle, albeit minor, and could easily put the OP over other applicants without.
I agree, although I do understand that some people might have a problem with it.
Last year I spent the whole friday night debugging an issue in a lib I've been using at work. I found an issue, wrote tests to demonstrate it, fixed the issue, write more tests and opened a PR. Maintainer months later closed an issue and I saw it has been fixed within one of his owns PRs. It did sting a bit, but I remembered I learned A LOT while debugging it and I fixed an issue that was bugging us on work.
Maybe the connection to this topic won't be obvious, but I used to read Animal Farm and think that the Donkey was supeior to the Horse. Nowadays I don't think that anymore. The Horse was never alone for a day in his life. The Donkey survived the Horse but was left alone. So I now think "I will work harder" is the right approach most of the time.
I've experienced similar (not in the kernel, but a high profile OS project), making an initial contribution is interpreted as an offer to become the personal secretary for one of the project full timers. I politely backed away.
New contributors often have the opposite problem where after an initial contribution they're looking for areas to get involved with and time with a maintainer is valued. Usually the missing part is maintainers willing to do this.
(Unless you mean literally personal secretary and dealing with their personal life or setting meetings up and stuff, I assumed you meant tell you what bugs are worth looking at etc)
If only these drive-by contributors would be around to maintain the stuff like secretaries that would be a dream. As it is, I think you may have the roles reversed: the maintainers are not there to merge your patch and look after it in perpetuity.
The entire purpose of these responses is to repel the drive-by contributor who invariably generates clerical work for the full-time maintainer. It's just a sad fact about the nature of this work that it's often done by volunteers who are massively overloaded, and "contributions" are often so minuscule or low quality that they are actually just additional time-demands on already-overworked maintainers.
Generally the value that you would bring with your fix is not worth the burden you put on everyone else. There are many hobby projects with a more open attitude specifically for this reason, because they are willing to take this burden for the sake of having people feel good about contributing. Try Serenity for example. Most open source projects obviously will not have such an attitude.
I mean, we're not talking about contributors who implement a whole new feature which you hadn't planned and want you to merge it, we're talking about bug fixes, which are generally short, and their value should be easy to gauge?
Would you simply accept a random persons PR fixing a bug without basically re-doing all the work?
I know I wouldn't.
Even a simple line change (especially in huge projects like the kernel) can have unexpected consequences. Your fix might fix the bug in question but cause others down the line. It can make the code harder to maintain, not fit style guides, etc. There are numerous issues caused by these "drive by patches".
Unless you actually maintain a project or is heavily involved, it's easy to miss the forest from the trees.
Ironically, the person sending the patch is most times being paid by a company to do so (since they are fixing an issue they found) while the maintainer is most likely unpaid/underpaid.
I've had a very small experience maintaining a library and already had to deal with "bug fixes" that take huge swaths of your time and simply cannot be merged. So I empathize with the maintainer here much more than the Cisco employee that was allowed days of paid work to poke around the issue and tried to fix it. The maintainer very likely had to reproduce the bug and consider any implications of the fix beyond what the author would have by the simple fact he actually maintains that project.
Personally I think a co-authored tag wouldn't hurt, but I cannot blame the maintainer for not having that in his mind when he's focused in doing his job (which is, again, most likely unpaid/underpaid).
But I can't help but feel disgust from a paid Cisco employee bashing an open source maintainer simply because his ego got slightly bruised.
Repelling drive-by contributors usually pertains to people who want to dump massive amounts of feature creep into existing FOSS. There's a legitimate place for not adding Bobs massive feature list all at once because you don't know if Bob will be around after 2 years and you end up cutting most of them because you can't figure them out.
The last place biting drive-by contributors should apply is for bugfixes. Bugfixes are one of the most common ways beginners/newcomers are incentivized to contribute (and keep contributing), especially to FOSS. Even Stallman, who otherwise is someone who I would not consider a good example for any kind of communication, implicitly acknowledges that if you're a maintainer, you should try to work with people submitting patches to get them merged rather than antagonize them because of your possible maintenance burden[0].
[0]: https://stallman.org/stallman-computing.html (see the how to learn to program section, which while largely bad advice on actually learning how to program, does have the nugget that "fixing bugs is a great way to get into FOSS dev" and "most maintainers will be happy to receive your patches and work with you to get them formatted and correct", which is imo implicit advice for maintainers to be kind to new contributors.)
I don’t know that seems like a good way to make sure no one knows how to maintain these things after the core contributors die. I’ve seen PR ping pong mentioned elsewhere and it’s odd because “PR ping pong” is part of how I became an effective member of my team and eventually eased some of the load for everyone else.
My experience with many patches was that they just sit some place ignored for years until they cannot be merged anymore. Not even rejected, just silence. So let's not claim that the project full timers were some kind of all-knowing all-powerful benevolent gods. They are humans too and nothing better than the casual contributors, so only when there's a match it works.
The linux kernel isn't a reward and while I empathize with the OP I would absolutely prefer a better solution to maintain than one from the community. So the maintainer was well within their rights.
That said, it's so easy to just give people who contributed to the fix attribution, in Node.js we make a point of trying to give credit in release notes and add `Co-Authored-By:` to PRs where we took _some_ work people did in PRs and adapted it.
When you maintain something for a while, credit often stops being important to you (you _are_ the maintainer of the area after all) so it's hard to remember that for new contributors it's often very important.
Totally a loss for OP and that part of linux that the maintainer wasn't more attentive to the fact sharing credit (especially when deserved like in this case) was important to OP.
... and their results of forward regression testing.
There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. Ignoring that the maintainer literally moved one line of code (of about forty additions) and "contributed" it with himself as the author.
> There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution.
I don't really understand that either. Someone found a problem, researched it, found and tested a solution, voluntarily offered a patch, and everyone wants to pretend that it was nothing? "It was only x lines", "it was a simple/trivial patch to an obscure project", "It wasn't done in the exact way they wanted it". What is wrong with some people! It was a bug that was reported years ago but nobody took the time to fix it. This guy put in the work and delivered, which in the end is what matters.
But that's only credit for finding the bug, not fixing it. He put quite a lot of work into fixing the bug, and that credit got stolen by someone who merely rewrote his fix.
Since text in commit messages is free, a more accurate tag hurts noone but keeps the spirits up and encourages future work: Based-on-work-by, Investigated-by, ...
Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"
I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!". This is not how a project reliant on community efforts could sustain itself.
I always thought a project as big and respected as that of the linux-kernel would have folks who know better, and look out for the best interests of teh project while respecting new-comers. After all they were new when they started contributing?
I dont think anybody in their right mind would advocate for a "not best" solution to be accepted just because a new-comer brought it. The right thing to do would have been - "Here, I have reviewed your patch. This and This are troubling because of this reason. I'd recommend re-writing this like that. Tell me if you need assistance with this, and I can help write that part" and co-author such a patch. That's how you get a good pipeline of future contributors who also care.
> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!"
Frankly, I think that's a non-trivial problem to solve: how to get the assumedly better fix while not ruffling the feathers of the more junior contributor so not to discourage on-ramping.
I guess the best way to do it would be to have a co-authored-by tag, or something akin.
We can't really know as we can't see the author's patch, but given that (i) the guy answering is responsible for the whole CPU architecture in Linux and (ii) the author mourns his putative contributor badge but does not criticize the other patch, that's a bet I'm ready to take.
A pull request and some comments to help the author understand what needs to be adjusted is a common way to handle this with the projects that I work with.
On the other hand this can lead to getting stuck in a never ending code-review ping-pong game.
Having seen both sides of that table many times, you can see the value in someone who just gets the shit done. Especially since this was security related and may have had some urgency to get merged before a release. Imagining how much work these guys must have accepting patches you can sympathize with taking some shortcuts.
Nobody's saying the maintainer should have to do a never-ending code review ping pong game.
The maintainer is free to come up with their version and expedite committing it. The point is that if their patch is based on the original author's patch (which in this case it is; they just shuffled a few lines around), then the original author should've been credited as Author or Co-Authored-By.
Why? Theres no expectation for you to put in a lot of effort, and if in the hands of a domain expert, could have taken minimal effort. I'm sure everyone has had PRs that could have been resolved in minutes if the submitter had reached out first.
Complaining about it reeks of a junior developer mentality.
> I'd be pissed if I put in a lot of effort revising my contributions to a project, only to be told at the end that "I like my version better, so go away!".
Then you shouldn't contribute to someone else's project.
It is not “their” project now is it?!
This attitude never gets anywhere productive. It only encourages gatekeepers.
I didn’t say I’d be pissed if my contributions are turned away. Every project sure is entitled to say - we don’t need your contributions. But that’s not what happened here. They received this blog author’s contributions, suggested revisions - which they seem to have made and spent time on, and then to only flush them out at the end.
By your logic, if you don’t want someone contributing to your project, just ignore the contribution or say that you don’t want them - do not take it without due credit.
That sort of thing still happens with FreeBSD, even recently. Find a kernel bug, spend days tracking it down and fixing it, contact a maintainer for feedback before submitting it, and then they slightly reformat it and commit as their own work.
Yeap, happened to me on FreeBSD, happened to me on NetBSD. With Linux it was better, I once had a Tested-by: given as well as a Reported-by: when I encountered some cgroup crashes.
The maintainer wrote a much more pertinent patch that I did, as I was not all that familiar with the subtle ways cgroups couple with a lot of other subsystems. I didn't care really about getting credit, whatever info he required of me I straight away gave, reproducer, .config, he was very polite, and I found the amount of credit I got for that fair.
On the other hand once I asked for a certain block layer patch to be included in Linux stable and Jens Axboe yelled at me asking me to stop spamming him. Boy that guy's a d*k.. I get it, you're briliant, io_uring is a great thing and we all love it, except for your weird naming conventions with the tail and head pointers for the circular buffers. But by the gods will I strive my best to be as not-like-you as possible if I become a big name on an open source project.
This is when I lose all sympathy for the OP. All of it. Misrepresenting the actual statement this way is garbage. There's a world of difference in the two statements.
I do understand why people clamor to get a patch into the kernel. It's a big deal. Feeling like you've come close and fallen short has to sting.
But, part of having a patch accepted is being able to work with maintainers. Clear fail here. There's a definite air of entitlement in claiming that you're "robbed" of a patch and misrepresenting other people's words and actions.
> Misrepresenting the actual statement this way is garbage. There's a world of difference in the two statements.
That's debatable. What's not debatable is that not giving OP credit for the fix is disrespectful and bordering on plagiarism.
Even if OP's patch wasn't as good as the final one (and giving OP feedback + time to improve their patch themselves isn't an option for some reason), not giving him credit is wrong. This bug would have remained were it not for his effort debugging and developing a fix, and his company investing the development time on it.
I expected the maintainer to be bit of an asshole. Apparently they were totally respectful. They probably figured `Reported-by` is good enough credit, not putting themselves in the author's shoes (we all do this all the time). The author could have e-mailed the maintainer back and ask them to review their attribution practices and that would've been it. Instead they wrote a scathing article.
It’s not debatable at all. It’s simply malicious to put something someone never said in a block quote to make them look bad, especially when the block quote font size is like twice that of everything else. They also cowardly added a “(paraphrasing)” outside to cover their ass. (Edit: in case it’s not clear, I’m not saying they added that after the post was published.)
They achieved their goal: look at how many comments assume that malicious “paraphrasing”. They also made sure those of us who aren’t so quick to jump to conclusions after hearing a one-sided story will never interact with them ever.
Conveniently misremembering a quote and making that gross misrepresentation a callout is indistinguishable from malice. I cover my ass by avoiding people who commit deniable acts indistinguishable from malice.
Except that's not what the maintainer said! OP's putting words in their mouths, and getting mad about that. That's not a winning strategy in life, especially where text communication is concerned.
Actions speak louder than words. At the end of the day, the author was not credited for doing most of the work of fixing the bug. I'd be pretty mad too.
Actions do speak louder than words. The code that ended up getting committed is the only real action here though. Everything else is words. Who wrote the original code, who wrote the commit message, what words were in the commit message. At the end of the day, if we concentrate on the action, and not the words, then we should ignore who said what and look to see if the bug was fixed and if the code works.
Don't get me wrong, I'd absolutely be annoyed too, not to get more credit than a "reported-by", but: you are not your code, and the bug got fixed.
The actions include finding the bug, debugging it, and proposing a strategy for the fix that ended up being adopted in practice. All stuff the maintainer did not do but took credit for.
Actions do speak loudly - such as misrepresenting other people's statements so they sound worse than they are.
He didn't actually author the patch. He did get a reported by credit. If you look through the thread, he clearly got some mentorship from the maintainers because the first attempts weren't maintainable.
The actual thread shows the maintainer implementing the fix in a way he found better and prepping to do the backports for other stable kernels. The actual response was "Thanks for your patch, but I wanted to fix it differently" and gives him credit for reporting.
The suggestion that the maintainer "pulled" something here is quite something. Is there any evidence that the author ever tried to ask for more credit aside from carping about it on their blog in public?
If there was evidence that they'd gone to the maintainer and said "um, hey, I feel like I should get more credit than that" I might feel more sympathetic. As it is, they misrepresented the words of the maintainer and played the victim. If there's evidence they have tried to correct this on list then I might feel differently.
At this point, only Michael Ellerman could have this evidence in his mailbox. I've switched companies since then and unfortunately I don't have the private email exchange which happened between us (I've emailed him from my corporate email address).
> Open or closed source, sometimes the maintainers or engineers will go with different approaches or fixes.
I think you're highlighting a really important point. A maintainer who has a wider view of a system will more often than not know what a good, consistent fix should look like for that system. It may not be the approach that someone with a laser-like focus on a single, specific problem may have. In some cases it might even be that a fix for a particular issue is not desirable due to other effects it has, and that's OK.
That said, a little understanding from both sides would go a long way: the person who did the initial work, in knowing that the maintainers have been at it for longer, and the maintainer for thanking the person for bringing it to their attention and pushing towards a resolution.
Hard to judge this situation without hearing the other side. I don't know if the PowerPC maintainer saw significant issues with this guy's code.
One thing I do know is that putting in a lot of work up front, without any communication, sending a patch and then getting all worked up if it's not accepted is not generally a good strategy.
That and being a kernel developer is for the most part not all that glamorous. For me whenever I ended up sending a kernel patch it was because I uncovered some bug while working on a larger userspace project.
I think that OP had not so much a problem with the PowerPC maintainer coming up with his own solution (which is basically the same, except maybe fitting the coding style better), but the fact that all his efforts for finding the root cause of the bug were not recognized.
The PowerPC maintainer could have send him a message like: "Thank you for the patch. Thank you for diving into this bug and finding the root cause. I will attribute your effort. I have taken the liberty to come up with a solution that better matches the coding standards. I hope you do not mind. I will submit the following patch." and I think the OP would be perfectly happy.
Some do, some don't. The chances of getting something fixed increase with the amount of prepwork that you do. I try to include as much detail as I can when reporting a bug, typically those reports get ignored so OP materially improved his chances by doing that, but root cause analysis is still covered by 'Reported-by' as far as I can see.
> One thing I do know is that putting in a lot of work up front, without any communication, sending a patch and then getting all worked up if it's not accepted is not generally a good strategy.
It is generally a very bad strategy to do unasked work and expect appreciation or gratitude in return.
Most of the work was probably debugging the issue and pinning down the cause. I guess we have all had issues which took a lot of time to debug, but the actual fix was just a few lines (or even just a few characters). And you have to do that work "up front" - I mean, asking the Linux maintainers in advance if they're ok with you trying to pin down an issue you're facing would sound a bit strange?
Comparing both patches, I see a clear difference. While the contribution from the linked article changes the behaviour of both branches of the if...else, the final contribution changes only the parth in the "if" branch.
I guess, the maintainer had some reason to change the code. Nevertheless, giving credits to the original patch author would be appropriate since the actual fix was almost 100% copied.
I'm the author of the post. Unfortunately, I cannot link to the original patch I sent (it was very different) because I only sent it to the Linux kernel security mailing list. I wish I had saved it somewhere so I could show it.
Forwarding a random email conversation from a year+ ago without any context to public mailing list that is read who knows how many people just to get it into an archive so that you can link to it in HN comment does not really help your case.
So there is actually a difference between both solutions. The original has neither the flush_fp_to_thread not the else-condition for the PPC32 architecture. I cannot say which is right/wrong/better but it's definitively a different result.
There's a clear logical difference in those two patches and I can't blame the maintainer for going with his version.
Attribution should be given though, regardless of the bug OPs patch introduced the actual line that fixes the issue is clearly the same thing with the appropriate coding style.
As a maintainer, I can understand his reasoning but TBH it would've been easier and more respectful to just reply with the proper code snippet, having the contributor submit it (if he agreed) and then giving them credit.
Honestly, the comment section of this thread sucks, the level of self righteousness, "aggression" and gatekeeping is ridiculously uncalled for.
Agreed. You basically get paid in reputation, trustworthiness, and maybe even beer/brownie/pizza points.
I also think that public interactions offer a preview of how easy (or difficult) it will be to work with someone on a project... we're not experts on every domain of knowledge, so the best bet is to approach interactions with a bit of humility and respect.
If this were an AITA reddit thread, ESH (a little bit).
As an old C programmer, I'd be wary of code sent to me with a bunch of custom macros. That might indicate a certain immaturity with C. Maintaining a large code base is part fire suppression and part avoiding name collisions.
I can see both sides of the issue. The kernel maintainer is within their rights to implement their fix and accept it; they probably work with this codebase a lot and have to deal with issues that crop up. If the added code doesn’t match up in some way, they should be free to fix that.
But this issue could have been handled better. The kernel maintainers should have better attribution mechanisms. At least share authorship in the commit so the patch sender gets credit and is incentivized to contribute more. Its so easy to do that and it can create so much goodwill for little cost.
A solution mentioned a few times here is to take the patch as suggested by the maintainer, but to give a 'co-author' credit to the person who did all the debugging.
This gives the best code quality (or at least style match) and still credits the hard work done by the author.
> A Suggested-by: tag indicates that the patch idea is suggested by the person named and ensures credit to the person for the idea. Please note that this tag should not be added without the reporter's permission, especially if the idea was not posted in a public forum. That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future.
> Please note that this tag should not be added without the reporter's permission
Given that the OP was upset for not being recognized as a kernel contributor, I wonder whether they'd settle for this. If not, then that would explain why Suggested-by was not used here.
One thing that wonders me. The patch contains a fix but obviously no unit test that verifies it. Is that the standard of linux kernel development? In the company I work for, the patch would certainly be rejected because of that.
I'm unfamiliar with how the Linux kernel does their tests, but presumably it would require a diverse set of hardware, and a lot of code would have to be in the form of integration tests...
A very large portion of the Linux kernel code can't even run in userspace. It's not your average software project.
Here's one integration test project: https://linux-test-project.github.io/ -- typically (non-platform) subsystem maintainers write their own stress tests. But stress tests are merely probabilistic.
I can’t empathise with the author. It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.
> instead he implemented his own version of the fix. I told him that I would really appreciate if he could accept a patch from me, so that I could receive credit for fixing this issue and become a kernel contributor.
In other words, you asked a maintainer to accept an inferior fix just so you can put “kernel contributor” on your resume.
> My company and I should have received proper credit for solving this issue, especially considering how much effort we put into it.
No one asked you to do this. You aren’t owed anything when you do an unasked favour for someone else. Also, the only reason you put so much effort into this was to fix your own problem. Which, from my understanding, is now fixed. You seem to have no interest in fixing other problems (which you were given an opportunity to do). IMHO this attitude doesn’t qualify for contributor status.
I'm sure the OSS ecosystem would be better for everyone if every project started removing the names of contributors from the commit log and replacing them all with the name of the primary maintainer. Everyone loves it when they dedicate time out of their life to improving something and it ends up under someone else's name, after all.
Yeah, it's baffling to me how many people here have little consideration for the recognition of work. I sincerely hope these people never ever attempt a management career.
this thread is *wild*, everyone is jumping down the OPs throat for the crime of doing a ton of work while receiving zero credit for it and having the gall to be upset about it
He did a ton of work and got credited for it. The four line patch isn't a ton of work once you've done the RCA and besides it required work by the maintainer to get it to pass. And he changed the essence of the interaction with the maintainer, who isn't going to hang around to teach a newcomer how to properly submit a patch in a cycle of back-and-forths (of which there were already plenty) in a security issue.
> The four line patch isn't a ton of work once you've done the RCA and besides it required work by the maintainer to get it to pass
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.
Reported-by is the normal response for this kind of patch, 1000's of examples in the kernel mailing lists.
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.
> A patch is a patch and the author should be credited as such.
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?
No, that's not what "Reported-By" means. The kernel community has different conventions.
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.
What is interesting about this whole thread is that apparently a whole raft of people are ready to string up the kernel maintainers for doing what they've been doing for years rather than to stop to question whether the first time contributor may have a communications issue or a different set of expectations than that which is the norm for a project that has been going for a couple of decades.
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.
This isn’t even remotely close to what I said, and I can’t even see how it could be misinterpreted so badly. Did you reply to the correct comment?
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.
Why not? OP identified a problem that affects everyone and inplemented a fix. Maybe the original fix wasn't as optimized as it should be, but they deserve proper recognition nonetheless. In the OSS world, recognition and reputation are important.
And who are you to decided that? How about people who demonstrate incredibly judgemental behaviour such as yourself, do you have a place in OSS... and is somehow qualified to judge who else does? Don't think so.
> In other words, you asked a maintainer to accept an inferior fix just so you can put “kernel contributor” on your resume.
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."
The thing is, working with the contributor to guide them to write a specific patch entirely different from what they did is a lot of work, and quite frankly really awkward for both parties. And at that point, it is no longer the contributors patch. The maintainer authored it in its entirety, and the contributor slapped their name on it.
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.
> 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.
This is exactly the problem. By doing this with a security issue you are essentially going to have to be happy to see the problem fixed, regardless of whether or not it has your name on it because the maintainer has more to do than to tutor you until you 'get it right'. There are other more suitable venues for this.
> It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.
Even if that's the case, aren't those supposed to be "ok" motivations?
A lot of the point of giving people credit is to encourage further contributions. And people only fixing problems that affect them is a very common starting point for people becoming contributors.
My point (which I didn’t convey properly) is that the combination of the two isn’t all that productive, ie “I’ll only work on problems that affect me and only if you give me credit”. I get that true altruism probably doesn’t exist, but I’ve contributed to dozens of projects where I haven’t received credit, and I didn’t care because I helped fix problems that affected thousands of people, which I felt was more important than whatever label was placed on me (or not).
> I’ve contributed to dozens of projects where I haven’t received credit, and I didn’t care because ...
This seems a bit weird to me. Not the contribution-without-credit thing on your part, but the trying to denigrate the article authors contribution because their motivations were different from yours. Even though their motivations were just as valid as yours. :)
It seems it was quite productive, no? An important bug was fixed. Next time, it probably won't. Which may very well be a fine trade-off if giving credit is a lot of work that nobody wants to do - just expect less contributions with that approach.
Making changes for the sake of it doesn't stop plagiarism being plagiarism. More charitably, “substantially different” is not a high enough bar when you literally just read the other author's patch.
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.
> More charitably, “substantially different” is not a high enough bar when you literally just read the other author's patch.
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.
I want to add that the author's attitude can be considered prohibitive to their professional and personal growth. They are taking quite a strong position (blogging about it emphasizes how much this matters to them) which could have the unintended side effect of discouraging peers and managers from honestly giving them feedback on the situation.
Edit: I've reworded this to be less black and white. The down-voting here does exemplify the argument that negative feedback is not appreciated.
As a long-time OSS contributor and an active maintainer on a different OSS operating system, I can definitively state that the answer is: yes, it’s absolutely limiting.
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.
This patch is miniscule, and does not deserve 'Kernel contributor' status, which seems to be what the OP is after, and which I don't think is warranted for this sort of thing.
IF the code someone writes deserves to be included in a project, they deserve to have their name attributed to that code. You acting like there is some threshold of code to submit before someone's authorship is recognized is weird.
When you submit a patch to LKML you propose a fix, and if your patch is properly formatted and cleanly merges without further changes then it may be included as is. Or it might be parked until that section gets worked on in a larger context. In no way should your expectation be that your submission will be included verbatim and that you will be registered in the gitlog unless the maintainer decides that it be so.
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.
We don't have to discuss what might happen. We have a specific instance of something happening. In this case someone submitted a patch, the patch with a 1 line change ended up in the kernel. There is no need to talk about maybes, contexts, or what ifs. The kernel maintainer took someone else's code and put it in the kernel under their own name.
> you asked a maintainer to accept an inferior fix
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.
That's a stupid approach to maintaining a project. A maintainer should want to make their project the best it can be, and the best way to do that is encouraging contributors to keep contributing. If they can't do that, their work deserves to die and yield way for better managed repos/forks.
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.
"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.
Linux is doing more than “just fine” and is in no way similar to OpenSSL.
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.
Once, I learned that someone wrote a "security patch" for another project that embeds mine. They focused solely on the part where their fuzzer caused a crash, they wrote a patch that, in their mind, fixes exactly the problem they found. But the patch made no sense - it added a check mid-loop for something which was an invariant. The actual wrongness was in an entirely different file, it was passing invalid initial values, and checks needed to go there instead. I fixed the issue in my project correctly, and in the changelog I gave credit to the original person for both discovering the security flaw and providing a patch... that I didn't use.
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.
It isn't sustainable, and it's a sign of bad leadership waiting for the proverbial (or literal) "hit by a truck" principle to show up.
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 isn't sustainable, and it's a sign of bad leadership
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.
You're making some poor comparisons to justify how things were done in this instance. What actually happened here is someone encountered a bug, they diagnosed the bug, they fixed the bug, they brought the bug up on a mailing list, they updated their fix, they submitted their fix. The maintainer changed 1 line of their fix from an #ifdef to a macro that has the same ultimate effect and then stuck their name on the fix.
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.
> We all like the feeling of credit, but this context is very important.
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.
I think the maintainer's post mentions that he solved the problem by making a special case for 32bit instead of introducing conditionals and macros, which I assume was what the reporter had.
It doesn't matter what the intent behind the fix is, even if it is 100% for personal gain. In my opinion, it should be treated fairly, like any other commit and given credit where credit is due.
> The simple fact is: He did contribute, he just didn't get credited.
The credit they deserves is identifying the issue - not for writing a patch that didn't pass the bar (especially on security-report where maintainer gives critical priority, speedy review, extra focus on correctness, etc.).
Had this been done on a non-security mailing list, their patch would probably have gotten in after a few iterations.
EDIT: The original reporter was credited as "reported-by" in the patch, so removed the section saying there should be a standard for that.
If I submit a patch and a maintainer (or anyone else) reads it and writes their own based on it, then they have edited my work. If they don’t attribute me at all, then they are plagiarizing. Maybe there is no law to protect me, but it’s social contract.
If it was taken verbatim, sure - while perfectly fine under the license, that would be a dick move. But you should also note that the commit contains an additional essay or two's worth of analysis and justification, and includes test sign-off from other people. Even if you disregard the difference in code, the difference in commits is huge.
And as mentioned elsewhere, this issue was submitted to security@, triggering a machine optimized solely for resolving issues quickly and correctly for the safety of the user-base, and not one suited for training new contributors. If this was submitted normally, it's quite likely that this would have gotten merged after an iteration or two - which could easily have taken a week or more.
There are typically multiple ways to write code to address a given issue. They might differ in aesthetics (including clarity of intend), but also performance, maintainability, extensibility and robustness. It's not uncommon that those who wrote the code to be fixed rewrite the patch in order to improve on aforementioned properties while avoiding lengthy back-and-forth when asking for improvement of the patch. They are often in a better position to do so due to familiarity with the code, it's history and (unwritten) development path.
That is by no means plagiarism. If not communicated clearly, can however lead to disappointment of those who submitted the patch. An 'inspired-by' comment would have been nice.
Yeah it just seems like a bad strategy on the maintainers part. Seems like one of those perfect places to teach a new contributor style guides and make them more useful in the future. To me approaching it this way comes off as disinterest in welcoming new contributors, which maybe now they’re not needed, but being so unwelcoming could one day leave us with no one capable of maintaining these projects.
It is plagiarism by definition if you don’t give credit to the person who wrote the original patch. Paraphrasing a source without citing it is certainly considered plagiarism in non-programming contexts (even if you think that you improved the prose style).
A patch, by definition is a modification of an existing piece of code, in this case a very small one. Now, it is possible that copyright protection would apply to such a small piece of code in that context but plagiarism usually does not involve a perfect record (the mailing list where the patch was submitted) that states exactly where the original work was submitted, what was done to it to make it ready for inclusion as well as an admonishment that the patch was not usable because it wasn't properly signed off.
Plagiarism means that the kernel maintainer included the code and pretended that it was their original creation and nothing of the sort happened so I don't think that word should be used in this context. Nobody doubts the OP wrote the code, nobody is saying that they did not and nobody passes it off as their own.
Misrepresenting your level of reliance on a particular source is plagiarism, and is uncontroversially recognized as such in any other context. If I say that I was inspired to study a particular problem by Paper X, but don't mention that my own paper includes several copied paragraphs of Paper X that I've lightly edited, then that is plagiarism.
If there is a public record that makes it obvious that you've plagiarised, then that doesn't mean you're not guilty of plagiarism. It just means you failed to cover your tracks.
None of this has anything to do with copyright. Not all plagiarism involves copyright violations and not all copyright violations are instances of plagiarism.
Well, for me the bar for plagiarism is apparently higher than for you, for me it is 'passing something off as your own' and that never happened here. I'm open to other definitions that I'm not currently aware of.
The commit log and associated metadata misrepresent the authorship of the code.
I am using the bar that you can find by googling 'plagiarism policy' and reading any number of documents explaining what constitutes plagiarism in an academic context.
Plagiarism is not a crime, so the kernel maintainers can choose to decide that it's socially acceptable in the context of kernel development if they want to.
I'm not sure if I'd agree with a 'very large chunk', but certainly I don't think this is an isolated incident. It's just that people don't usually make a fuss.
I think the basic issue stems from the fact that LKML sees patches as 'proposals' unless they can be included as is without further work. And any would-be contributor would be (heh) able to see that for themselves by looking at the many years of documented interaction between maintainers and the general public.
These long running projects all have their own styles and conventions for interaction (LKML itself being one of those) and the onus is on newcomers to familiarize themselves with that. Authorship, especially in the context of a project of this magnitude and with so many different people maintaining different parts of it is always going to be somewhat nebulous, because after all, you're changing a tiny little bit in a huge machine and anything worthy of copyright is usually expected to stand alone as a 'work'. That's definitely not the case here. And so the sign-off becomes a critical bit, if you omit that then you've just created a problem for the maintainer. Personally, I would never expect to be named author of a patch sent to the kernel mailing list, but if I wrote a sizeable subsystem then I would definitely expect that kind of recognition.
For patches like this your pay-off is the fact that they are taken into consideration at all.
The maintainer is responsible for quality and correctness. I don't know the specifics of this patch, but it's absolutely not strange for a maintainer to make changes with these goals in mind.
Hell, maintainers are usually more aware of broader concerns than the contributor.
I don't know the specifics of the patch either since OP has not linked their patch nor the final kernel commit. I don't understand why being a private list would be a problem since they can just post their patch on their website. Maybe they're waiting for the fix to hit mainline first.
But when someone submits a patch to any of my OSS projects and I want to make modifications to it before I merge it, I either keep the original author as the Author and make myself as Co-Authored-By, or make myself the Author and keep the original author as Co-Authored-By, depending on how much change I had to make to the original patch. In either case I also have the original author review my version to get their approval of my version.
The only case where I would not credit the original author at all (or only as Reported-By) is if my version had absolutely nothing to do with their patch, say they fixed the symptom in file X and I fixed the cause in file Y.
Edit: https://news.ycombinator.com/item?id=37674872 found the patches. If it was my project I'd consider these in the Author/Co-Authored-By category because they're basically the same patch.
The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.
I'd argue the differences are not just style changes and even "just style" changes are not trivial. The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
I'm sure other people did the "hard part" too for the Row hammer and Heartbleed bugs; which were even harder. All they got was credit in identifying the bugs; kernel-contributor-status is not a prize for doing hard work finding bugs.
* OP didn't identify the bug, it had been reported years prior. OP identified the root cause and suggested a working fix.
* What then is the hard part, if this is the "hard part"
* What is kernel contributor status a "prize" for then, if not for contributing to the kernel?
* Why all the focus on OP wanting recognition for the work, and 0 on the dev who merged the patch. Why not have all patches be merged by a committe/ someone who isn't the author.
The maintainer (not random dev) didn't "merge" the patch - they rewrote an entirely new patch. Ate you arguing OP should be credited for that work? Sure, the maintainer could have guided OP towards the same patch over multiple exchanges/days, but it is their prerogative - they have to maintain the code going forward and are not obliged to accept patches that are in rough shape (in their judgement). OP did contribute to the kernel - but not by having their code included as they had hoped.
Michael Ellerman is between a rock and a hard place here: he could have done better and that's something that may have to be added to the guidelines for the patch contributors, at the same time maintainers have a massive workload and this was a tiny, broken patch submitted in a non-standard way by a new contributor. He could have made the origins of the few lines of code clearer but maintainers do this all the time, they usually are more focused on the quality of the code, and getting a fix in (even if it isn't yours) and may not realize that the contribution is insignificant compared to the fact that someone is very much focused on the credit.
Incentives clearly aren't aligned and I think if the OP would have taken this up privately they could have worked it out. Instead you get this public attack on people that we already have far too few of and one that misrepresents the interaction. That's where I draw the line: you keep your dirty laundry inside until you've exhausted every avenue for redress if you really care that much. Note that Ellerman explicitly offered to work with the OP if he wanted to be credited for a patch to the kernel on another bug, which is one way to differentiate between drive-by contributors and long term relationships.
All in all I think everybody could have done better here but Michael Ellerman's wrongs are far less clear to me than what the OP did and I'm fairly sure if there had been a ready for inclusion patch or better guidelines about how to deal with various degrees of crediting contributors (and probably for a more substantial fix) that there would have been no problem either.
Personally I don't see the problem at all: the LKML thread is archived for eternity, the contribution of the OP is clear, if he wants to say he's contributed code to the kernel I don't think anybody would object to that and Ellerman did his job as a maintainer, even if he could have handled it with some more grace I'm more than willing to forgive him. If I had been in the OPs place I would have probably jumped at the opportunity suggested by the invitation, and I definitely would not have 'paraphrased' the interaction or use the word 'robbed' without first reaching out to Michael Ellerman because those two things alone undo any goodwill created by the submission of the patch.
> I'd argue the differences are not just style changes and even "just style" changes are not trivial.
Op did all the research and multiple implementations of a fix. Ellerman refactored the fix to be simpler, but the effect is the same.
> The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
It more seems like he knew about IS_ENABLED and Miculas didn't, because he uses `IS_ENABLED(CONFIG_PPC32)` instead of Miculas' `#ifdef CONFIG_PPC32`. Besides, Ellerman's changes are all inside `#ifdef CONFIG_PPC_FPU_REGS` blocks anyway so I'm not sure this was a major consideration. Using `IS_ENABLED` gets you 90% of the way to the "cleaner" patch, and in a ~30 line patch I don't know if it's worth golfing further.
Oh he also got a code review giving him exactly these tips [0]. IDK, getting real "I don't want to coach this rookie, I'll just do this myself, thanks for the tip" vibes from Ellerman here. Maybe that's valid, but it seems like not a wonderful way to keep people interested in kernel dev.
I'm just disagreeing that the patches are the same. I agree that Miculas did do the hard work by finding the cause of the issue in the first place - but he's correctly credited as the reporter.
As for the clean patch - part of the issue is that Miculas was slightly overengineering some of it with the additional macros and added noise with extra conditions on the fpidx declaration.
Ellerman's "I don't want to coach this rookie" vibe is somewhat understandable given this is the security mailing list - it's just not the time and the place to be going back-and-forth.
I generally agree and gave you an upvote. The macros up top were hard for me to grok too, mostly I was reading it thinking, "why isn't this just a cast" and it turns out is could be! And I get this is the security mailing list, but it's 32-bit PPC, and they took days to really get to it. FWIW I think Ariel was being overly cautious; it's hard to see how this could be a significant security issue, and it feels counterproductive to punish him for being cautious. I can kind of see both sides, but I just can't get over doing all the work Ariel did and only getting a "Reported by" credit. His feelings are justified IMO.
> There is nothing wrong with being motivated by getting credit.
They did get the credit, just not for the code, and rightly so.
If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel, more so if it is posted as a security issue which get special treatment and a whole pile of extra review to make sure that the fix doesn't introduce yet another problem.
This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues, clearly some work went into this. But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up, especially if you want to do security work where the details really matter, so props for identifying the issue, but no medal for delivering something that didn't meet the bar for inclusion. And that last bit is where 'kernel contributor' comes in. The whole 'robbed' angle is an interesting one, it appears that there is a much higher perceived value than the one that is normally associated with getting an issue fixed (which is what most people would like to see). Perverse incentives are a thing and it is good to be aware of them.
> The value of FOSS is fixing a problem once for everyone.
No, the value of FOSS is the ability to read and modify the source code.
> Linus Torvalds himself had questionable attitude at times.
Whether Linus has had questionable attitude at times is immaterial: clearly he was a contributor and so is credited. This person did not contribute as of now. You see the same with YC and pretty much anything that people would like to have on their resume: the thing itself is less important than the CV mention.
> have hurt for doing all the analysis, even if the patch itself got completely rewritten?
That there are many more implications for being allowed to call yourself an author. The kernel contributors are doing very important work and their standards for inclusion are high. You don't make it into that circle without adopting their standards.
> They did get the credit, just not for the code, and rightly so.
They received credit for reporting the issue, which is a fraction of what they did. They provided the entire solution, full stop. The maintainer only restated it.
That's because it is a tiny fix. To ask for credit as a contributor makes it seem as though that was the whole goal and that's why the OP feels 'robbed' as though this is a thing of great value that has been taken away from them.
That's not how I interpret the contents of the exchange:
Could the kernel maintainer have handled this better? Probably yes. Was the OP robbed? In my opinion, no, their work was credited and the fix is so small it doesn't warrant elevating the OP to 'Kernel contributor' which is typically reserved for more substantial contributions, not bug fixes of a few lines.
Another comment has a nice middle ground in the form of the 'Suggested-by' tag which I think would have been an improvement. I've got a little project on the go and I'm meticulous about crediting people but the context is entirely different there, nobody is going to hold up my project to claim they are a contributor on their CV so I'm fine with the kernel maintainers keeping the list of 'kernel contributors' manageable.
This entire attitude around denying attribution is unreal. I see it in industry all of the time, especially now that I'm in gamesdev. People pull out all of the stops to prevent certain people or even certain disciplines from receiving credit for their efforts. It's abysmal.
What’s the incentive here? It seems more likely it just wasn’t a concern to the maintainers. The guy can still call himself a Linux contributor if he wants. He submitted a couple if statements and didn’t get it signed off. Why split hairs over what the commit message says?
That is an excellent question. It may well be that even single line drive by patches raise to the bar of being a kernel contributor, it may be that most of the authors of such small patches have historically had a better idea of their place in the greater scheme of things and that what matters is that the bug gets fixed (it's a security issue, after all) rather than that it gets fixed in their way or with their name affixed to the patch.
Fixing bugs is a contribution, and detecting bugs and doing RCA is also a contribution. In this case the OP got credited for the second and the third using the appropriate mechanism. The maintainer could have used another tag to add additional credit, but chose not to as is their right - and custom with such small patches, especially if they need work.
High profile projects such as the Linux kernel suffer from attracting people that just want to be associated with the project, I think OP went considerably beyond that and deserves some credit but does not have an automatic right to a particular kind of credit and if that was his expectation he should have ensured up front that that was the outcome. By posting an incomplete patch for a security issue to the kernel mailing list this was the expected outcome, in fact the maintainer spent considerable time on back-and-forth with the OP.
> it may be that most of the authors of such small patches have historically had a better idea of their place in the greater scheme of things
Historically, denying those, who went to great lengths for their contributions, even the minor bit of attention they deserved, has led at times to the castle getting torched down.
It pays off to have your expectations calibrated before you engage in an activity. To be named a kernel contributor on the basis of this particular patch seems to be a bit excessive (even if it had been properly signed off, which it wasn't), of course you are entirely welcome to disagree with that.
To give some perspective: there are ~30 million lines of code in the kernel and about 5K named contributors, and a much smaller set of maintainers who will accept patches, modify them, discard them, rewrite them and or merge them based on their judgment, which they generally exercise very well.
Agreed the expectations are so far out of line I doubt the maintainers see a problem. If this guy wants to be a kernel contributor he can keep contributing to the kernel.
The LKML is all the proof the OP needs to show he contributed and precisely in what way. This post is way over the top and even if Michael Ellerman could have handled this better so could the OP.
IDK this stuff all sounds specious to me. If I envision a world where anyone who contributes Miculas' level of effort into the kernel gets into "kernel contributors", that world seems great to me. Linus wrote a whole new version control system, surely someone over there can figure out how to maintain a list of contributors.
> To ask for credit as a contributor makes it seem as though that was the whole goal
I don't know about that. I maintain a small project and I've received exactly one outside contribution, and I made sure to properly credit that. Nobody is going to send me patches in order to gain social standing. But popular open source projects are a different matter and the maintainers there are hip to the fact that people use often minor contributions to increase their standing. Now: the OP clearly went beyond that, and I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one. But that's hairsplitting to me and if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost.
> the maintainers there are hip to the fact that people use often minor contributions to increase their standing
That's a fair concern but I don't think that's what we're talking about here. This isn't someone running around correcting whitespace or documentation to pad their resume. They did a bunch of technical and mailing list research. That kind of effort is promising.
> I'm on the same side as another commenter here in that the 'Suggested-by' tag would have been the more appropriate one
Yeah or maybe "co-author" or whatever (IDK anything about kernel tags). It seems pretty evident to me that Ellerman cleaned up Micunas' original patch using his kernel expertise. I'm not at all calling "plagiarism" or anything like that, but I am calling "collaboration".
> if that's worth penning a post like this for, especially one that misrepresents the kernel maintainers words in a meaningful way then all perspective is lost
I'm not sure what the original private email was so who knows if it's a faithful paraphrase, but I can forgive OP for being miffed and I could also forgive Ellerman for being irritated about being misrepresented. Someone should be the mature person here though, and--call me naive if you want haha--I'd look to the kernel dev for that.
For Co-developed-by status though it would require a properly signed off patch which this wasn't. And that's where you run into the issue of this being posted to a security mailing list for all to see: you've essentially started the clock on something that you no longer control and fixing the but takes priority over other niceties.
Yeah I mean, I want to be respectful of Linux workflows and conventions. I just think it's hard to understand a situation where someone could put this much effort into improving the kernel and not get a contributor credit. Like, by the normal definition of the word it's definitely a contribution: it required a lot of technical skill to do, and he did try to follow kernel conventions when he was made aware of them. It's not really his fault that trying to contribute to Linux is a byzantine process where maybe no one will be at all nice to you.
> And that's where you run into the issue of this being posted to a security mailing list for all to see: you've essentially started the clock on something that you no longer control and fixing the but takes priority over other niceties.
Yeah, but on the other hand it's an obscure architecture and they took a few days to really process it. It also doesn't preclude them crediting him as a co-author.
---
I guess my overarching point is that, while this may be completely reasonable from a kernel dev's point of view--a person super steeped in kernel culture and processes--it's mostly nonsensical to everyone else. This issue is pretty simple. This guy did a bunch of work in good faith, tried to do things right, and some insider basically stole his thunder. That sucks! No amount of like, careful or sympathetic explanations of kernel workflows and semantics is really meaningful in the face of that.
I think the nail in the coffin is that everyone believes this happened right? No one needs to be convinced kernel devs are completely uncaring and insensitive. Maybe that attracts a certain crowd and maybe that's on purpose, or maybe it's just self-fulfilling, but at the very least it doesn't seem very welcoming. Either way, it doesn't bode well for the future.
EDIT: I said they took over a week to really process it but I misremembered, it was just a few days
I think that the main sticking point is that the credit for a contribution to the kernel, no matter how small is of sufficient value now that this needs more consideration from the maintainers. And Michael Ellerman actually agrees with that based on his response in the thread. I think a Suggested-by or even a Co-authored-by would be an improvement on the current situation. But the frame of mind of a typical kernel maintainer to me appears to be that they believe you want them to fix the issue, not that the credit matters more to you than the fix.
If I were in the position of the OP the LKML record alone suffices as proof that I contributed a major chunk of work to fixing a bug in the Linux kernel, and if I did feel that the credit was handled wrongly I would have taken that up with the maintainer. And finally, I would have done so right away, not a long time after and in such a disingenuous way.
I don't know if you've been in the open-source space for very long, because this is not how it works. It's pretty standard to work very hard to give credit (and not some silly "reporter" credit) to the first person to show up with a working patch for an issue (as long as they are willing to work with the maintainers and make requested changes), because it builds goodwill in the community and encourages contributions. Of course, the kernel maintainers are free to break that social compact, but it's still "robbing" someone of what social norms lead one to expect. And this "robbery" isn't a victimless act, either. Finding a high-complexity (and it was, don't confuse yourself) issue and solving it is a good undertaking that shows that you're a good developer, and also brings some spotlight to the company you represent, which can be good for recruiting and developer relations.
But: it wasn't a working patch, it was mailed to a security mailing list alerting, and it wasn't properly signed off as required for inclusion. Those things alone make the expectations for credit strange. LKML has its own set of very specific rules around this stuff.
Of course, this all makes perfect sense if you live inside the LKML bureaucracy. From the outside it just seems bonkers. This is why it's important to reconsider policies that don't make sense.
Agreed, but OP made himself part of that bureaucracy entirely voluntarily. It's as if I show up to a casino and start playing without familiarizing myself with the rules and the environment first. Note that the kernel maintainers are in general getting a lot of crap for doing a very large amount of work and that this sort of post that attacks a particular maintainer by name is really damaging, far more so than if the OP had never submitted their patch in the first place.
Absolutely agree. But remember that this affects all of us, because "with many eyes all bugs are shallow" only works if lots of people show up and contribute.
And this is how I know you're not a professional programmer, because you naively assume that finding the root cause is zero work. Most of the time it's debugging and testing that takes almost all the time involved in a fix.
> But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up
I'd suggest not opining on the inner motivations of strangers on the internet. It doesn't add value to this conversation, and your guesses are likely wrong due to missing important context and details.
It's there for everybody to read, as well as in comments here, I'm not guessing at anything. You can't be 'robbed' of something you do not already have.
And that's before we get into misrepresenting the kernel maintainers words in a way that considerably changes their meaning.
> can also mean not getting something you are justly deserved.
It can, but whether that's the case here or not is debatable and I think what we mostly see here is the OPs unfamiliarity with how LKML deals with tiny patches mailed to the security lists.
> Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore.
This is an incredibly uncharitable description of his motivation:
> If the goal is to fix something to be able to put kernel contributor on your resume
So, then the OP should be happy. But that's not what I'm reading, I read accusations about robbery, see words put in people's mouths that are not backed up by the evidence and a patch that misses required bits and pieces to be accredited in the first place.
What they wrote in their blog is without value after changing the nature of the exchange with the kernel maintainer to make them look like a dick when nothing of the sort actually happened. It only proves that you can't believe what is in that article.
He did almost all the work in fixing a problem that had existed unfixed for six years. He figured out what the problem was and fixed it. He did this because it was causing problems at work. When he contributed the fix upstream the maintainer tweaked it a bit and merged it, with a bug report credit. The author did far more than simply report a bug. As he says – the bug was already reported six years ago (and apparently the actual reporter didn’t get credit for that). He figured out what the problem was and fixed it, but he didn’t get credit for that.
His motivation is clear – he fixed the bug because it affected him. The fact that he’s pissed off for not getting credit for that bug fix doesn’t change that.
> If the goal is to fix something to be able to put kernel contributor on your resume
This quite clearly was not his goal. His goal was to fix the bug he was experiencing at work. So why are you saying otherwise?
Because I read the article and the exchange between the maintainer and the OP.
It smacks of entitlement and shows a complete unfamiliarity with the kernel development process. Maybe that's all there is to this but to claim a kernel developer 'robbed' a first time contributor when in fact what happened is exactly what you'd expect to happen makes me wonder about the OPs motives, especially because he materially misrepresented the interaction between himself and the maintainer to make the maintainer look bad. It looks like the credits were the goal, and if they weren't then what's the fuss about?
> It 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.
> It smacks of entitlement and shows a complete unfamiliarity with the kernel development process
Even if this were true, it does absolutely nothing to change the fact that his motivation was to fix the bug he was experiencing at work.
> It looks like the credits were the goal, and if they weren't then what's the fuss about?
You are failing to distinguish between the purpose for doing something and something of value. These are two distinct things. The goal was to fix the bug. The credit is of value. The fact that he is upset about not receiving the value he feels he deserves does not alter what the goal was.
It’s straightforward and obvious that he fixed a bug because it was affecting him. Why are you so eager to deny that?
> Even if this were true, it does absolutely nothing to change the fact that his motivation was to fix the bug he was experiencing at work.
Sure, but this blog post was written well after that time, and I do not see the OP aiming to be properly credited in the intermediary. That doesn't mean that a more appropriate tag could have been used, I just wonder about the motivations for the post because it clearly isn't either timely or the best venue to address this, especially not in the way in which it was done.
> You are failing to distinguish between the purpose for doing something and something of value. These are two distinct things. The goal was to fix the bug. The credit is of value. The fact that he is upset about not receiving the value he feels he deserves does not alter what the goal was.
Yes, and that's why I'm totally supportive of having a 'Suggested-by' or even a 'Co-authored-by' tag on this. But I'm also aware of the fact that the LKML record alone serves to document the OPs contribution and that nobody has made any claim to the contrary, he is - to all intents and purposes except for the git-log the contributor of some lines of code. That these were modified by the maintainer is something people normally would not have cared that much about. And maybe that should change, but that's so far been roughly the norm for these kind of fixes.
> It’s straightforward and obvious that he fixed a bug because it was affecting him. Why are you so eager to deny that?
Because of (1) the timing, (2) the misrepresentations in the post, (3) the fact that alternative venues were not sought before making some fairly heavy accusations. It looks to me as though the bug fix may originally have been the reason the work was done and maybe the OP or their employer were happy with it but now, so many months later it seems the OP is more focused on the credit.
Linus' attitude has nothing to do with it, he wasn't part of this exchange at all. And yes, it's an exclusive club, hence people trying to become a part of it.
Security patches are the last place (especially tiny ones) where you want to make a stand for proper attribution of four line patches, the rest got properly credited. Note that the OP misrepresented the nature of the exchange with the kernel maintainer and that puts their motivation about the whole thing in doubt. Nobody got robbed. OP still has contributed code, the LKML lists are proof of that and if you think that in the future every such patch should carry an automatic 'Suggested-by' or 'Coauthored-by' tag then you could propose that. But for now this is the maintainers call and by sending mail to the LKML you play by their rules.
That's not gatekeeping, that's just reality, and yes, kernel maintainers are an in-group whether we like it or not. My take on that is that if I had stuff that gets included that I couldn't care less about the attribution because what they give me is so much more than I'll ever be able to give back. Of course everybody is welcome to their own motivations, but you send unsolicited patches with the hope that they'll be used, if you get credit that's great but then the patch had better be ready to run as is and preferably for something a bit more substantial.
I will point out that finding and root causing a bug (and perhaps writing a test) is THE contribution. Very often fixing the bug, once all unknowns have been resolved, is trivial.
Many times a one line fix takes days off debugging and analysis. Seems like this was the case here, since the original bug was open for 6 years.
"Reported-by" reads like: "this person mentioned the problem to us". In this case he did all the heavy lifting which is like 95% of the work. How is reported-by a proper accreditation? I feel like many commenters here never had to debug any complex or subtle, hard-to reproduce bugs. Either that or there are many assholes on this site.
Well, maybe there should be a 'contributed an improperly signed patch with issues' tag that would cover the situation. But in the case of mailing to a security list your general expectations should be to hope that it will be included, and hopefully speedily.
This comment is so far off the charts, even I, a pathological lurker, made an account...
Let me see if I get the ranking right:
> But the motivation isn't clean
> The kernel contributors are doing very important work and their standards for inclusion are high.
> security work where the details really matter, so props for identifying the issue
> Perverse incentives are a thing and it is good to be aware of them.
> with a mediocre contribution
>This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues
I wonder where normal people fit into this mental framework.
Contributors with pure thoughts <?> Kernel contributor > Security Contributors > Perverse contributors <?> Mediocre contributors > > People who sneak into OSS projects by fixing minor issues
> If the goal is to fix something to be able to put kernel contributor on your resume with a mediocre contribution in order to achieve yet another goal then that's not a good reason to be credited for the code, especially if it isn't your work that makes it into the kernel
Someone's desire to put "kernel contributor" on their resume is immaterial to the appropriateness of receiving that badge. "Mediocre" is a judgement you're projecting here, but we don't have evidence that the code was mediocre. And even if it was mediocre, most software goes through iterations, the first of which is almost always a mess. If the code he wrote was directly responsible for the code the maintainer wrote, there's a case to be made that credit is still due even if not a single line of the original code made it into the codebase.
"You didn't type the exact line of characters that made it into GitHub so therefore you did not contribute" is a very limited view of the whole series of interactions and investment of human capital that ultimately led to the fix.
> But the motivation isn't clean and if you care more about the credit than you do about the fix then clearly you have your priorities mixed up
This is projection again. When you don't receive credit for your work and get upset about it, it does not imply that the only reason you did something was for the recognition. If you get passed up for a promotion at work because a coworker lied and took credit for your work, you're allowed to be pissed about that, and it doesn't mean that you don't deserve a promotion because you worked hard to get a promotion. I don't get the logic here at all.
I agree that if the only reason someone contributes is to play a status game, that can lead to some questionable behaviors. But there's no evidence that this is the case here.
> No, the value of FOSS is the ability to read and modify the source code.
There is no singular attribute that makes up the "value of FOSS". Reading and modifying source code are valuable, but not exclusive to FOSS. The shared value of contributed fixes is also a major benefit of FOSS. FOSS is many things.
> This person did not contribute as of now.
I cannot imagine how you could conclude that the author did not contribute. If your definition of contribution is limited to "lines of text checked into a repo", perhaps you're correct, but this is an extremely limited view and incomplete picture of the nature of open source contribution.
The bug was around for many years. Would the code that did make it into the kernel have been written in the same timeframe if the author had not submitted their own solution?
There could have been many very good reasons not to include the author's code, and I'm not arguing against that. But it seems extremely disingenuous to claim that the author did not contribute quite a bit to this fix.
- the patch was missing a required element if the author wanted to be credited in the first place
- the patch was incomplete
- the patch was mailed to a mailing list that has a different set of priorities than the patch submitter assumed
The author did get credit though and that was for the 98% or so of the work they did. And finally, the LKML will - presumably forever - document his contribution in all its glory.
Anyway, I don't think we're going to see eye to eye on this one, in my experience nothing out of the ordinary happened here. Maybe that's wrong and it needs to be addressed but I would have picked a different hill for that battle.
I was primarily reacting to your assertions that the author doesn’t deserve recognition due to intrinsic motivations and the direct claim that they have as of yet not contributed.
What you’ve listed here are procedural issues that are easily corrected and have no bearing on whether or not contribution actually occurred, and no relation to those broader claims.
Zooming out a bit, maybe what you’re describing is indeed the status quo, and what the author described is a perfectly normal experience. If so, then the author’s piece should be seen as shining a light on kafkaesque bureaucratic bullshit that threatens the spirit of FOSS and thus FOSS itself.
Maybe “kernel contributor” needs to be better defined, and maybe it requires more than one contribution. Maybe there needs to be something more than “reported by” but less than “kernel contributor”.
But again, at no point is it fair to claim that the author did not contribute.
> I don't think we're going to see eye to eye on this one, in my experience nothing out of the ordinary happened here
Frankly, you’re shifting the goalposts so this isn't about seeing eye to eye. “Ordinary” is quite often very problematic, and each person is free to choose their own battles. You don’t have to agree that this was the right hill, but that is unrelated to a reasonable definition of “contribution”, and irrelevant to author’s choice to make some noise about their own personal experience.
Noise is a first step towards improving a situation. Change has to start somewhere. And FOSS maintainers need to be aware of the harm they bring to the projects they’ve been entrusted to steward when they forget about the human factors involved.
> And FOSS maintainers need to be aware of the harm they bring to the projects they’ve been entrusted to steward when they forget about the human factors involved.
Or maybe good deeds are good deeds, and bad behavior is bad behavior.
Maintainers deserve gratitude, empathy, and respect. Most of them are holding the line against shitty contributions and shoddy code, and that’s a good thing. The good they do doesn’t absolve them of problematic behavior.
I'll settle for 'perceived problematic behavior' and suggest you read the actual interchange between the OP and the kernel maintainer. Because it paints a completely different picture.
I did read the exchange, and there is problematic behavior all around.
The author did themselves a disservice with their disingenuous paraphrasing. The lack of attribution remains a problem however, and is not justified by the author’s misrepresentation; just as the author’s behavior is not justified by the lack of attribution.
OP could have maintained the moral high ground but didn’t, and that’s a bummer, because now this is an “everyone sucks here” situation.
That's fair. And Michael Ellerman actually agrees that he could have handled this better, I think OP should have just worked on this in private exchange rather than to make a public attack.
I think that given the status of the project there should be a change to the guidelines to ensure that even the smallest contributions get properly credited, but to make sure that then isn't gamed you'd need to somehow get out of the binary 'I'm a contributor' vs 'I've been contributing for years' situation by adding yet another metric or the inflation of the term 'kernel contributor' will be such that some people who do contribute on a regular basis will feel that their status is diminished.
Project governance is complex. I'm very mindful of the reason (see the drama around PEP 572) why GvR quit the status of head of the Python project, being a project maintainer is a very tough spot to be in because every action you perform is potentially going to be under the magnifying glass and all the good you do is forgotten five minutes later.
If ever I was considering contributing to a FOSS project, this comment and many others like it within this thread has firmly convinced me that it’s not worth the trouble.
I've just barely arrived at the conclusion that I could make a change, offering minor suggestions and changes on projects I care about and then have the read someone degrading a contribution that is still "several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues"
And when you point this extreme ranking out as inappropriate, your comment gets vaporized.
> There is nothing wrong with being motivated by getting credit.
There is nothing wrong with it, but apparently they were also payed by their employer to do the work in the first place, so I don’t know why their personal motivation should be a major consideration here anyway.
Or future employers. All the wrangling about "this guy should be selfless and just be happy he made the world a better place" is bonkers. He lobbied his job to give him time to put in a bunch of highly technical work to improve the kernel. Would it really be so bad to acknowledge him as a contributor? How in the world is his work not a contribution?
"""
Solution taken from arch/powerpc/kernel/ptrace32.c
---
arch/powerpc/kernel/ptrace/ptrace-fpu.c | 31 +++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
"""
You really consider this a contribution? You genuinely want to call someone submitting this a kernel contributor and imply they know anything about the code? I mean, I get the social angle of trying to build each other up and do each other favors but in the long run we're doing more harm than we are good by warping the meaning of the title
I consider it a great first contribution. Dude took initiative at his job to try to make his and his teammates' lives easier, investigated a super technical issue, found prior art and built on it, sought help on the list, and tried to shepherd it to get it merged. It was significant effort, and he in no way had to do it. He definitely didn't need to upstream it.
The amount of energy wasted in this thread on the meaning of "contributor" could boil me water for tea. Bewildering, honestly.
Reporting a security issue is not the place for seeking help on the list and shepherding. The idea behind the patch was written simpler by others because the original patch was both technically unacceptable to the maintainer and not cleared for inclusion in the kernel (no Signed-off-by).
He posted to security out of an abundance of caution, but it's hard to see how this could be a significant security issue. Feels unfair to punish him for being considerate here.
Also kernel workflows are not intuitive. I don't have any idea what signed-off-by is or how to get it. Don't you post to the list? What else would you do? Would it have been better for Miculas to spend time researching kernel workflows while this "security issue" remained unpatched? Feels like there's not really a way for him to win here.
> original patch was both technically unacceptable to the maintainer and not cleared for inclusion in the kernel (no Signed-off-by)
Crediting as a co-author is a good compromise here, I would say.
> There is nothing wrong with being motivated by getting credit.
It's wrong if it's your top priority instead of improving the codebase. And even then not being wrong doesn't mean you are entitled to get it, your motivations are your own.
I'm not sure why intentions would matter here, or how one would compare the value of different intentions. If someone adds value to the codebase and fixes, or helps to fix, a valid bug why should we care why they did it?
Sure intentions may indicate the liklihood of the person contributing more in the future, but that's a health metric for the project and unrelated from the contribution itself.
Because it's important to cultivate the right motivation among contributors. Allowing people with selfish motivations to thrive eventually destroys the project.
Assuming that you can control who thrives in a project seems like a death nail in and of itself. Contributions should stand on their own, why the person contributed them or who the person is should have no bearing on the FOSS project.
Recognition of individual contributions is a core component to why Open Source even works in the first place. It would not work if an abstract, utopian ideal of "improving the codebase" was the primary driver. A bug fix contribution may be borne out of necessity, but ultimately codebase improvements are a side effect of the social phenomenon of people being highly motivated to be recognized by their peers.
Notoriety is the currency of open source software. And that's a feature, not a bug.
Hundreds of charity and service organizations have found to their detriment that you're wrong, and that there needs to be this.
I volunteered at an animal shelter that was unable to be a no-kill shelter. One of the first things they'd learned to ask at intake was "What's in it for you?"
People would invariably misunderstand. "I get to help these animals" or similar. "No, that's what you're doing here. What do you get out of it?"
And they'd still answer altruistically.
But what the charity wanted to hear was the "selfish" answer. Because it's perfectly okay to have a selfish answer as well as be doing a good thing. In fact, it's preferable, because it's often the selfish answer that will keep you coming back when things are tougher or uglier, versus walking away because "I can't do this, it's costing me too much".
Perhaps instead codebase contributions should be anonymized? Maybe then we can ensure people are contributing "for the right reasons"...
> There is nothing wrong with being motivated by getting credit.
While in this case there isn't a big problem, "motivated to commit to OSS projects for credit" causes loads of aggravation in general. Consider the gazillions of "fixed a typo in a comment" PRs that people get from folks trying to pad resumes.
Are you familiar with Hacktoberfest? Every October you get an absolute torrent of crappy PRs from people who saw a youtube video on "How to get a free T-shirt". See https://blog.domenic.me/hacktoberfest/
> There is nothing wrong with being motivated by getting credit.
Nothing wrong is too strong of a statement. Obvious to me, but wonder why not to others that it would be better if someone was motivated by something else other than credit, something like doing good, the challenge of the problem etc. Motivation solely for credit is egotistic and will lead to other problems with team and self-worth etc.
We have a name for such people and generally despised, "clout chasers"
> > It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.
> You don't know that.
From TFA:
> He said (paraphrasing): "Sorry, I like my version better. If you want to be a Linux kernel contributor, here’s an issue you could fix." I found this really perplexing and insulting. Instead of getting recognized for fixing the issue, he wanted to give me more work to do.
Unless you have copious amounts of free time, you can only fix the problems affecting you in your day job, and contribute them back.
The developer could have accepted that allegedly inferior fix, give the credit, and patch it with their own version in a single commit. I'd have done that, for example, all the while trying to communicate with the submitter of the patch about my intentions.
Maybe he wanted the badge for his own honor, not to put it anywhere else. Some people are into that kind of thing, and he fixed a legitimate problem of his to earn this. I can understand them and respect them for that.
> No one asked you to do this.
Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion.
> You seem to have no interest in fixing other problems (which you were given an opportunity to do)
As I aforementioned, you need time to do this. It's not given that the author has free time to work on any problems they deem worthy. I'd love to fix tons of bugs, mine or not, but I can't do that because lack of time. Heck, I can't find an hour to finish implementing my own projects. How do we know that he has the whole day to do the research and fix other bugs?
> Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion.
Why is it not open for discussion? I can’t just fill in a pothole or cut my neighbours grass and expect credit and/or compensation. OSS isn’t common property. You can’t just do whatever you want and expect to receive credit.
Yeah, their work needed a fix and they got a fix. That’s already a better than average outcome.
Free software is common property. This the rule 0. It's everyone's. This is why four freedoms exist, and The Kernel is GPLv2. i.e. Free Software.
Compensation and credit are completely different things. Credit is not compensation. It's an answer to question "Who did this?".
He didn't do whatever he want. He was experiencing a problem, he traced, researched it, debugged it, fixed it, and submitted a patch to The Kernel.
If that was only something "whatever he wanted", the patch would be shot down. The bug is accepted/confirmed on The Kernel side, his patch is being reviewed and deemed "stylistically unacceptable", the reviewer/maintainer wrote his own version, and by pushing the fix w/o attributing him, he effectively claimed that he did all the work from discovery to patching, incl. everything in between.
The maintainer didn't have to accept the patch per se. He could have just written "This bug is discovered, dissected and fixed by $THE_PERSON. Patch is implemented and committed by me. Thanks a lot, $THE_PERSON!".
This is basic human decency. I have my name on many bug reports, either reporting them, or providing more information leading to solution of the bug. I have a couple of patches here and there, and I experienced something similar from another prominent project people interact with every day, but I said that "mneh, whatever".
The author certainly didn't because the treatment he got is really bad, and good for him publicizing this, because these kind of people needs to be known. Well, there might be miscommunication and the story can be completely different, but starting the discussion from somewhere is healthy.
> Free software is common property. This the rule 0. It's everyone's. This is why four freedoms exist, and The Kernel is GPLv2. i.e. Free Software.
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.
> 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.
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).
> In practice he got the permission to modify their copy.
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.
> I’m not sure there’s any value in trying to align ourselves on this.
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.
> 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.
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.
As far as I know, there is no official title of "Kernel Contributor" that comes with a certificate written on parchment. I have code I wrote in the Linux kernel. Am I an official Kernel Contributor? If so, I didn't receive my merit badge, and that doesn't mean any human decency rules were broken. Having code in the kernel is not that big a deal. I highly doubt I got any job offers because of it. This seems as Internet-pointy as HN karma.
> 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.
Woah this claim a bit too strong. There's a "reported-by" line in the final patch that ended in the kernel:
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."
I don't understand why the act of not taking a small patch should be interpreted in such a personally insulting way.
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?
Because it's not about not accepting the patch. I'm not there. It's about the style.
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.
> 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.
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?
I was going to write a detailed answer to your comment, but after your P.S. and assumptions about my intentions, I think I have the same feeling about my hopes for a grounded and fruitful discussion with you.
> The developer could have accepted that allegedly inferior fix, give the credit, and patch it with their own version in a single commit.
My best oss contribution was done exactly like this. Someone else reviewed my code, made some changes, but my name was on the commits. I was happy that someone else took the time to make my code better and at the same time, keep my name on it.
As has been mentioned elsewhere if this had been submitted via the standard process, something more like that might have happened.
However, this was submitted to the security mailing list which is optimized for quick, precise fixes, not for teaching new contributors how to adhere to coding standards.
This methodology also has the side effect of "new contributor has security fix but can't contribute it because they need to be "taught" on non-security issues first."
The new contributor didn't have the knowledge and skills to make a patch that followed project standards. They were still able to submit a report and a first attempt at fixing the issue and get people who do know how to do that to craft a fix quickly. This is the system working correctly.
Rather than being thankful that other people contributed their time and effort to help OP solve the issue their company was facing, OP decided to misquote the person who helped them and start drama where none was needed.
> Rather than being thankful that other people contributed their time and effort to help OP solve the issue their company was facing, OP decided to misquote the person who helped them and start drama where none was needed.
Wow, way to turn this around. The user had fixed their issue. Don't make it like "other people" "helped them solve it".
The user and his company were quite capable of compiling their own kernel and using that. They solved their own problem, with no help from others.
They then chose to disseminate it for the greater good.
And yet people like you are demanding that they show gratitude to the community for somehow deigning to help them.
You seem to take this very personally for some reason. I have "demanded" nothing...
Anyone is welcome to fork the kernel and commit code of whatever quality they want.
However, if they want their code included in the official kernel, then they need to follow that projects coding standards. They are not entitled to get their poorly written code merged to satisfy their ego.
Sure, a "suggested-by" tag would have been appropriate, but I would posit that after this public tantrum, getting assistance becoming official kernel contributor will be a bit harder. Who wants to donate their time and energy to someone who may twist their words to start unnecessary public drama as soon as they feel a little slighted?
Proper attribution is actually important though from a licensing standpoint. Contributors publish their patches under the GPL, but they retain the copyright.
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.
The original patch, as submitted to the security email address, was not acceptable for use in the Linux kernel, as it was missing a Signed-off-by: line. The maintainer had written their own patch by the time the blog post author got around to sending their next email.
This is not true. I've sent subsequent patches to the PowerPC maintainer in private, there was no practical reason why he couldn't work with me instead of implementing his own version.
> It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.
(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?
The problem is the combination of the two. Ie, “I’ll only contribute on problems that affect me personally and then only if I get credit”. I’m not convinced this mentality is productive in the OSS community.
It's as if people have work to do and can only spend their paid time in OSS fixing problems blocking their work.
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!
Nothing wrong with those motivations at all. The maintainer should be fostering new contributors who are doing all this work, who cares if they just want the label. Is the work good or not is all that matters.
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.
Contributing for credit and fixing problems that affect them is what most of open source is about. Why would you ever want your hard work credited to someone else when it could benefit you?
Sorry, you're way off base, in particular with the especially snarky last paragraph. If the effort up to the point of the patch was used, then the effort has value and an acknowledgement is necessary. Taking the work without attribution is tantamount to plaigiarism.
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.
Thanks. It happens and we're all subject to these forces - that's why they're hard to manage. It's too much to expect that they won't sneak in unintentionally.
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.
This has been one of the most polarising conversations I’ve been a part of on HN.
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.
Tone is hard to read on the internet, but I'm not heated and I don't mind that you feel differently.
> 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.
> only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.
This is why kernel maintenance should be left to companies like Google, Microsoft, and IBM. They don't care if they get credit and they put serious efforts toward problems that don't affect them.
>I can’t empathise with the author. It seems like they’re only interested in OSS when a) they get credit, and b) for only fixing problems that affect them.
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.
Seems like a great way of making people feel unwelcomed by the community.
If I were to lay down work on an open source project and not get contribution I would never do any work for that project again. It is important for many to feel appreciated for their work.
The goal shouldn't be recognition but getting the bug fixed. A working system for all is reward in itself.
That said, attribution of work is a major theme in academia and business, where professors or department leads traditionally get credited for their student's or subordinates hard work.
Receiving credit is important to the vast majority of people, and giving credit where it’s due is a leadership quality and ethical standard today. The rules of the game are established and not following them should
be frowned upon.
I hope you never receive credit for anything you do then. If "a working system for all is reward in itself" you shouldn't mind allowing someone else who doesn't think this way to take credit for your work.
A simple example: if I found a bug in the Linux kernel, fixed it and get the code merged, I would 100% put it on my resume and LinkedIn which could be a big plus when looking for my next job.
"robbed" is not a hyperbole here, it's a blatant lie.
The blog author found a bug and submitted a patch, the kernel maintainer fixed the bug differently with his own patch. No copyright was infringed. Where is the theft?
Open Source maintainers don't owe you to accept your patches.
Well, arguably "Reported-By" is indeed an understatement if the author also pinpointed the exact mechanism of the problem and proposed a solution - even if it was rejected. But it's also not maintainer's job to ensure everyone feels properly appreciated, Linux kernel community is very different from corporate environment in good and bad ways.
I often spend hours investigating bugs I am just reporting. This is because I want to make it reproducible for the maintainer. Sometimes making it reproducible narrow down the issue so much that it can be found in the code in a few minutes. "Reported-By" is often not a small feat.
"pinpointing" can mean different things. Indeed a good bug report includes a good description of minimal reproducer, hopefully deterministic. I would also call this "pinpointing".
But the author went further and identified the incorrect parts of the code as well and produced a patch that resolved the issue.
I would sure love if most the bug reports I receive would be of this quality, it would save me a lot of work...
He was robbed of the label/title/achievement 'kernel contributor'. In the same way that the loser of a sports match due to a bad ref call is 'robbed' of something. Which I think is a fair description, given the facts as presented here.
No, it is merely a hyperbole. You are right in the legal sense, the maintainers don't owe him to put his name in the copyright header. There is no legal IP for the root cause analysis part of the work.
However arguably root cause analysis is a significant part of fixing a bug, often much more work than writing the lines that fix the bug. A "reported by" is not an acknowledgement of this kind of work.
IMO the author earned an opportunity to write the patch themselves with the guidance of the maintainers. What the author got robbed of is this opportunity.
In the worse case management thinks the dev didn't do anything at all and are less likely to assign similar work in the future.
In my experience, yes, companies love any way of gaining prestige and contributing to OS is one of them. For some devs it's a strong positive signal when a company they interview for contributes to OS.
There are also performance reviews to be done, where it's a positive to be able to say you/ a dev you manage achieved x.
One time I submitted a patch to implement a feature in an Open Source project, it got completely ignored for 6 months until someone else implemented the same feature which the project went with. Felt a little frustrating, but I've learned sometimes these kind of things happen in large projects.
Linux kernel maintainers might be not good as people managers, but it's also not their job - their focus is the code itself. The sure way to get your name in linux git history if that's you goal is contributing regularly.
> Linux kernel maintainers might be not good as people managers, but it's also not their job
It's absolutely part of their job. Maintaining a healthy pool of contributors is in the job spec, and to do that you need a degree of people-managing skills - expressed either by tools or by the maintainer.
Torvalds makes headlines when he flames, but he definitely always had a penchant for collaboration and delegation, or Linux would not have become what it did. He effectively encoded his philosophy in git, so now most of the people-management is done by tools, but it wasn't like this for a very long time.
Oof, what a bizarre, self-centred post. It makes it seem like they are more interested in having "kernel contributor" on their CV than actually improving the kernel.
This is the worst kind of OSS contributor, the one that jumps in, makes a small change, then leaves, and expects recognition for it. If you really care, stick around and keep helping. Almost no one does.
We can all make our existence so much better by being more empathetic to other people's positions. In this case the maintainer could've just communicated how he would like to see the bug fixed and let the original reporter fix it that way and retain credit.
But he just went and did it himself and then made things further worse by using insensitive language. He could've easily added a line to the patch acknowledging the original fix and the effort that went into it.
Getting the better technical solution in is in most cases not orthogonal to being better humans.
But as it stands, beyond people who get paid for it kernel development is best suited for hobbyists who just have fun figuring things out without any expectation of Internet points.
Having someone else implement the fix and take ownership of the code is a positive in the long term, unless you're committed to the project - in which case you ought to be fine with looking at and fixing other bugs.
In a company context, you'd expect the reviewer to coach someone being onboarded towards a solution the reviewer prefers, but that's because you know the person is going to be around for a while, and they're going to need to take ownership.
If you aren't in it for the long haul, you shouldn't expect your code contributions to stick.
If you’re in front of keyboard, and someone is saying what to type. Does this makes you an author of this code? Definitely no.
If you’re in front of keyboard, someone is saying what to type and you creatively rework what you hear. Does this makes you an author of this code? Like, you know, ChatGPT can make an existing code better, but this doesn’t mean ChatGPT wrote it. So mostly no
See, the programming job is not about typing characters to the code editor. It’s even not about choosing between different idioms or applying common algorithms or patterns. It’s about solving problems. That’s where like 90% of efforts going
You might say OP is not a true OSS developer because of solving own problems. But most OSS contributors are solving their problems, what a surprise. This is why OSS still exists.
You might say OP is a glory hunter. But in fact, he spent few days solving the problem and then the authorship was just stolen by rewriting the solution. It’s normal to demand a proper authorship of the work you’ve done
It doesn't matter how much time was spent. Maybe maintainer could have solved it in hours/minutes if a bug report was filed. What ultimately remains is that the maintainer is responsible for the code, which often times is a much larger burden than submitting a fix.
Take what credit you received, appreciate the learning experience and move on.
741 comments
[ 2.8 ms ] story [ 468 ms ] threadNot everything in life is about getting a golden star in your grade book.
There is no need to try and take explicit credit when you get implicit credit simply from the visibility of leading the project.
Having spoken to a lot of low level leaders I'd disagree. It does create unhappiness because in the end they are no less human. That unhappiness may be worth it for the other benefits and the happiness they gain from them but saying they don't experience unhappiness is dismissing their very human emotions. But often the unhappiness dominates, they burn out and then get replaced by some narcissist/sociopath. That person is fully happy and rises up the ranks.
Of course if you happen to do IC work as well it makes sense to take credit for that, but I think that mixing leadership and IC work tends to result in burnout.
The project maintainer surely would have not felt bad giving credit to someone ? Exhibiting this kind of leadership usually makes me feel great !
On the contrary, as we see from the article, the lack of credit really did create unhappiness from thin air…
the secret of a happy life is trying to be happy, whatever that means to you, and making it, the secret of a sad life is trying to be happy and failing at it.
regardless of the expectations.
So no, it isn't always the opposite. For many of us, our pessimistic attitude has been extremely damaging.
Someone else here said
> You have control over the inputs but not the outcomes :)
I can't speak for others, but for me personally, having low expectations has caused me to become lackadaisical or even destructive with my inputs. What is the point if it will just go wrong?
EDIT: I can't reply because /u/dang has blocked my account again
> That... isn't what I mean by low expectations? For me, it means to be grateful for what you've got, to question feelings of envy and to not feel that you deserve something.
That's called "gratitude", not "low expectations"
"Low expectations" means you expect low, i.e. bad. It's pessimism.
Regardless of all that I hope you work out your depression, it sucks.
No thanks.
Not being able to accept that shows immaturity.
The world would be a much much much much much much shittier place if everyone accepted things and never pushed back.
>Not being able to accept that shows immaturity.
I find not being able to accept that other's have a different but equally valid approach to life shows immaturity.
He found a bug (even that is questionable because it got reported prior), copy&paste-developed a fix and is angry that it doesn't get merged and now throws a hissy fit that he got attributed with the exact thing he did. Looking at his employer makes this even funnier.
Is it so wrong to not be awarded a medal everytime someone does something?
The title says "I got robbed", the reality is the solution has been discarded for something the maintainer, who's going to maintain that code, liked better.
The handling wasn't great, sure, but the real appreciation comes from within, from knowing you found a solution to the problem, not from others.
It is like going to the doctor with the solution and being upset if the doctor replaces it with something he can trust
- diagnosed a longstanding bug
- contributed an initial patch
- actively reached out to the maintainer, who said they would reach out in private
- contributed additional versions that were reviewed
just to have the maintainer take over the contribution wholesale. How would you feel when you put in all that work and receive basically no recognition for it? Maybe you are truly ascetic and have no need for it, but most people appreciate being credited and being encouraged to contribute again.
I would feel that nothing bad happened and that my code was actually reviewed by a kernel maintainer, that acknowledged the problem, and found a solution based on mine, which is in itself a big ego boost.
But probably it's just because I have been programming for over 25 years, because I like solving problems, and I don't do it for the recognition, which is basically a false coin. The recognition at work is the salary, the recognition when I volunteer is that I contribute to help people when I can, not that the people I help are grateful to me. Sometimes they are ungrateful too, but that's not why I do it, so I don't care.
In my opinion it is childish otherwise, you do things you think they are right because you think they are right, not for some prize.
Never let your sense of morals prevent you from doing what is right.
> ----------------
- diagnosed a longstanding bug
- contributed an initial patch
- actively reached out to the maintainer, who said they would reach out in private
- contributed additional versions that were reviewed
That's basically what I used to do when my car had a problem and I brought it to the mechanic, because I grew up in my uncle's body shop.
but the mechanic does it professionally and of course he wants to do all the process again, so he can be sure what the real problem is. At that point he probably found a solution which is slightly better than mine or that solves the root of the problem, not just the symptom.
So now I just go there and tell him what is that I feel it's wrong (e.g. the motor keeps stalling) and I let him fix it. If I wanted to become a real contributor, I would start from the bottom, as everyone does: changing oil (here's a bug you can fix)
This post is literally about not getting credit for one’s work. If you don’t believe that the author deserved recognition for their work then you should say that outright.
One of the prides that I can discuss in job interviews are my contributions to upstream software stacks (mostly PHP frameworks such as Laravel and Magento). I have had a patch rewritten by a maintainer that arguably made the patch worse - that left a very sore feeling for me and I think that it was the very last patch that I sent to that particular project (Wordpress, which I am glad to be rid of).
Last year I spent the whole friday night debugging an issue in a lib I've been using at work. I found an issue, wrote tests to demonstrate it, fixed the issue, write more tests and opened a PR. Maintainer months later closed an issue and I saw it has been fixed within one of his owns PRs. It did sting a bit, but I remembered I learned A LOT while debugging it and I fixed an issue that was bugging us on work.
(Unless you mean literally personal secretary and dealing with their personal life or setting meetings up and stuff, I assumed you meant tell you what bugs are worth looking at etc)
The entire purpose of these responses is to repel the drive-by contributor who invariably generates clerical work for the full-time maintainer. It's just a sad fact about the nature of this work that it's often done by volunteers who are massively overloaded, and "contributions" are often so minuscule or low quality that they are actually just additional time-demands on already-overworked maintainers.
There is a good book about this: https://www.amazon.com/Working-Public-Making-Maintenance-Sof...
It works! I'd rarely file a bugfix to a high-profile project now I know how contemptuous some of the maintainers are.
I just did. Because the burden of dealing with an annoying contributor outweighs the value of their contribution
Even a simple line change (especially in huge projects like the kernel) can have unexpected consequences. Your fix might fix the bug in question but cause others down the line. It can make the code harder to maintain, not fit style guides, etc. There are numerous issues caused by these "drive by patches".
Unless you actually maintain a project or is heavily involved, it's easy to miss the forest from the trees.
Ironically, the person sending the patch is most times being paid by a company to do so (since they are fixing an issue they found) while the maintainer is most likely unpaid/underpaid.
I've had a very small experience maintaining a library and already had to deal with "bug fixes" that take huge swaths of your time and simply cannot be merged. So I empathize with the maintainer here much more than the Cisco employee that was allowed days of paid work to poke around the issue and tried to fix it. The maintainer very likely had to reproduce the bug and consider any implications of the fix beyond what the author would have by the simple fact he actually maintains that project.
Personally I think a co-authored tag wouldn't hurt, but I cannot blame the maintainer for not having that in his mind when he's focused in doing his job (which is, again, most likely unpaid/underpaid).
But I can't help but feel disgust from a paid Cisco employee bashing an open source maintainer simply because his ego got slightly bruised.
The last place biting drive-by contributors should apply is for bugfixes. Bugfixes are one of the most common ways beginners/newcomers are incentivized to contribute (and keep contributing), especially to FOSS. Even Stallman, who otherwise is someone who I would not consider a good example for any kind of communication, implicitly acknowledges that if you're a maintainer, you should try to work with people submitting patches to get them merged rather than antagonize them because of your possible maintenance burden[0].
[0]: https://stallman.org/stallman-computing.html (see the how to learn to program section, which while largely bad advice on actually learning how to program, does have the nugget that "fixing bugs is a great way to get into FOSS dev" and "most maintainers will be happy to receive your patches and work with you to get them formatted and correct", which is imo implicit advice for maintainers to be kind to new contributors.)
That said, it's so easy to just give people who contributed to the fix attribution, in Node.js we make a point of trying to give credit in release notes and add `Co-Authored-By:` to PRs where we took _some_ work people did in PRs and adapted it.
When you maintain something for a while, credit often stops being important to you (you _are_ the maintainer of the area after all) so it's hard to remember that for new contributors it's often very important.
Totally a loss for OP and that part of linux that the maintainer wasn't more attentive to the fact sharing credit (especially when deserved like in this case) was important to OP.
... and their results of forward regression testing.
There's a lot of people expending time here trying to absolutely minimize the OP's effort and contribution. Ignoring that the maintainer literally moved one line of code (of about forty additions) and "contributed" it with himself as the author.
I'd say the maintainer plagiarized OP's code.
I don't really understand that either. Someone found a problem, researched it, found and tested a solution, voluntarily offered a patch, and everyone wants to pretend that it was nothing? "It was only x lines", "it was a simple/trivial patch to an obscure project", "It wasn't done in the exact way they wanted it". What is wrong with some people! It was a bug that was reported years ago but nobody took the time to fix it. This guy put in the work and delivered, which in the end is what matters.
Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"
I always thought a project as big and respected as that of the linux-kernel would have folks who know better, and look out for the best interests of teh project while respecting new-comers. After all they were new when they started contributing?
I dont think anybody in their right mind would advocate for a "not best" solution to be accepted just because a new-comer brought it. The right thing to do would have been - "Here, I have reviewed your patch. This and This are troubling because of this reason. I'd recommend re-writing this like that. Tell me if you need assistance with this, and I can help write that part" and co-author such a patch. That's how you get a good pipeline of future contributors who also care.
Frankly, I think that's a non-trivial problem to solve: how to get the assumedly better fix while not ruffling the feathers of the more junior contributor so not to discourage on-ramping.
I guess the best way to do it would be to have a co-authored-by tag, or something akin.
> Thanks for your patch, but I wanted to fix it differently. Can you try the patch below and make sure it fixes the bug for you?
Which to me, at least, reads very differently than claiming the author's patch is worse.
[0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
(Credit to nolist_policy for pointing this out upthread.)
https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...
Having seen both sides of that table many times, you can see the value in someone who just gets the shit done. Especially since this was security related and may have had some urgency to get merged before a release. Imagining how much work these guys must have accepting patches you can sympathize with taking some shortcuts.
The maintainer is free to come up with their version and expedite committing it. The point is that if their patch is based on the original author's patch (which in this case it is; they just shuffled a few lines around), then the original author should've been credited as Author or Co-Authored-By.
Complaining about it reeks of a junior developer mentality.
Then you shouldn't contribute to someone else's project.
I didn’t say I’d be pissed if my contributions are turned away. Every project sure is entitled to say - we don’t need your contributions. But that’s not what happened here. They received this blog author’s contributions, suggested revisions - which they seem to have made and spent time on, and then to only flush them out at the end.
By your logic, if you don’t want someone contributing to your project, just ignore the contribution or say that you don’t want them - do not take it without due credit.
You can, of course, fork the project, or do whatever you want with the code.
It certainly seems that you're correct judging by the article, in the worst possible way.
When I found a kernel panic on FreeBSD my report was taken by a guy on IRC and was told "just don't worry about it i'll send it to the maintainers".
The maintainer wrote a much more pertinent patch that I did, as I was not all that familiar with the subtle ways cgroups couple with a lot of other subsystems. I didn't care really about getting credit, whatever info he required of me I straight away gave, reproducer, .config, he was very polite, and I found the amount of credit I got for that fair.
On the other hand once I asked for a certain block layer patch to be included in Linux stable and Jens Axboe yelled at me asking me to stop spamming him. Boy that guy's a d*k.. I get it, you're briliant, io_uring is a great thing and we all love it, except for your weird naming conventions with the tail and head pointers for the circular buffers. But by the gods will I strive my best to be as not-like-you as possible if I become a big name on an open source project.
What a great way to make sure someone will never help you again and disincentivize others from doing the same.
> I haven't actually reproduced the crash with gdbserver, but I have a
> test case which shows the bug, so I've been able to confirm it and
> test a fix.
>
> Thanks for your patch, but I wanted to fix it differently. Can you try
> the patch below and make sure it fixes the bug for you?
https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
--
Also, not mentioned was another reviewers comment:
I can't see the benefit of such macros if they are only for PPC32.
:
#ifdefs should be avoided as much as possible.
:
etc
:
Michael's patch seems easier to understand.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
I do understand why people clamor to get a patch into the kernel. It's a big deal. Feeling like you've come close and fallen short has to sting.
But, part of having a patch accepted is being able to work with maintainers. Clear fail here. There's a definite air of entitlement in claiming that you're "robbed" of a patch and misrepresenting other people's words and actions.
That's debatable. What's not debatable is that not giving OP credit for the fix is disrespectful and bordering on plagiarism.
Even if OP's patch wasn't as good as the final one (and giving OP feedback + time to improve their patch themselves isn't an option for some reason), not giving him credit is wrong. This bug would have remained were it not for his effort debugging and developing a fix, and his company investing the development time on it.
They achieved their goal: look at how many comments assume that malicious “paraphrasing”. They also made sure those of us who aren’t so quick to jump to conclusions after hearing a one-sided story will never interact with them ever.
Don't get me wrong, I'd absolutely be annoyed too, not to get more credit than a "reported-by", but: you are not your code, and the bug got fixed.
He didn't actually author the patch. He did get a reported by credit. If you look through the thread, he clearly got some mentorship from the maintainers because the first attempts weren't maintainable.
The suggestion that the maintainer "pulled" something here is quite something. Is there any evidence that the author ever tried to ask for more credit aside from carping about it on their blog in public?
If there was evidence that they'd gone to the maintainer and said "um, hey, I feel like I should get more credit than that" I might feel more sympathetic. As it is, they misrepresented the words of the maintainer and played the victim. If there's evidence they have tried to correct this on list then I might feel differently.
I don't think we have an agreed upon standard of thanking or crediting contributors, everyone does it in their own way.
A lot of work is thankless, though. And sometimes people get angry for something you change, even if it's an improvement for most others.
Sometimes people are thankful, but mostly silently.
Stoicism may be useful.
I think you're highlighting a really important point. A maintainer who has a wider view of a system will more often than not know what a good, consistent fix should look like for that system. It may not be the approach that someone with a laser-like focus on a single, specific problem may have. In some cases it might even be that a fix for a particular issue is not desirable due to other effects it has, and that's OK.
That said, a little understanding from both sides would go a long way: the person who did the initial work, in knowing that the maintainers have been at it for longer, and the maintainer for thanking the person for bringing it to their attention and pushing towards a resolution.
One thing I do know is that putting in a lot of work up front, without any communication, sending a patch and then getting all worked up if it's not accepted is not generally a good strategy.
The PowerPC maintainer could have send him a message like: "Thank you for the patch. Thank you for diving into this bug and finding the root cause. I will attribute your effort. I have taken the liberty to come up with a solution that better matches the coding standards. I hope you do not mind. I will submit the following patch." and I think the OP would be perfectly happy.
But they were! That's exactly what 'Reported-by' is for.
It is generally a very bad strategy to do unasked work and expect appreciation or gratitude in return.
I guess, the maintainer had some reason to change the code. Nevertheless, giving credits to the original patch author would be appropriate since the actual fix was almost 100% copied.
(Totally with you though: maintainer was a douche. People are the worst.)
On a related note Christophe Leroy should be applauded for his calm and matter of fact response. I don’t know if I would be capable of that.
Attribution should be given though, regardless of the bug OPs patch introduced the actual line that fixes the issue is clearly the same thing with the appropriate coding style.
As a maintainer, I can understand his reasoning but TBH it would've been easier and more respectful to just reply with the proper code snippet, having the contributor submit it (if he agreed) and then giving them credit.
Honestly, the comment section of this thread sucks, the level of self righteousness, "aggression" and gatekeeping is ridiculously uncalled for.
I also think that public interactions offer a preview of how easy (or difficult) it will be to work with someone on a project... we're not experts on every domain of knowledge, so the best bet is to approach interactions with a bit of humility and respect.
If this were an AITA reddit thread, ESH (a little bit).
But this issue could have been handled better. The kernel maintainers should have better attribution mechanisms. At least share authorship in the commit so the patch sender gets credit and is incentivized to contribute more. Its so easy to do that and it can create so much goodwill for little cost.
It is probably something the kernel guys (and similar projects) should use generously in examples such as your own to encourage involvement
[1] https://docs.github.com/en/pull-requests/committing-changes-...
Here's the relevant documentation of commit tags: https://kernel.org/doc/html/latest/process/submitting-patche...
Seems like this would have been a good idea
Given that the OP was upset for not being recognized as a kernel contributor, I wonder whether they'd settle for this. If not, then that would explain why Suggested-by was not used here.
On most of project deliveries we have gone back to only integration testing.
I'm unfamiliar with how the Linux kernel does their tests, but presumably it would require a diverse set of hardware, and a lot of code would have to be in the form of integration tests...
Here's one integration test project: https://linux-test-project.github.io/ -- typically (non-platform) subsystem maintainers write their own stress tests. But stress tests are merely probabilistic.
> 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.
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.
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.
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.
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.
Edit: I've reworded this to be less black and white. The down-voting here does exemplify the argument that negative feedback is not appreciated.
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.
So?
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...
That hasn't been proven, we need to see the patches.
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
have hurt for doing all the analysis, even if the patch itself got completely rewritten?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.
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.
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. And so the sign-off becomes a critical bit, if you omit that then you've just created a problem for the maintainer. Personally, I would never expect to be named author of a patch sent to the kernel mailing list, but if I wrote a sizeable subsystem then I would definitely expect that kind of recognition.
For patches like this your pay-off is the fact that they are taken into consideration at all.
https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/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
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.
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 had been a ready for inclusion patch or better guidelines about how to deal with various degrees of crediting contributors (and probably for a more substantial fix) that there would have been no problem either.
Personally I don't see the problem at all: the LKML thread is archived for eternity, the contribution of the OP is clear, if he wants to say he's contributed code to the kernel I don't think anybody would object to that and Ellerman did his job as a maintainer, even if he could have handled it with some more grace I'm more than willing to forgive him. If I had been in the OPs place I would have probably jumped at the opportunity suggested by the invitation, and I definitely would not have 'paraphrased' the interaction or use the word 'robbed' without first reaching out to Michael Ellerman because those two things alone undo any goodwill created by the submission of the patch.
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.
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/linuxppc-dev@lists.ozlabs.org/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.
> 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.
Source: I have asked this question on HN before: https://news.ycombinator.com/item?id=31225599
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.
And that's before we get into misrepresenting the kernel maintainers words in a way that considerably changes their meaning.
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.
The hierarchy roughly goes: users -> script kiddies -> programmers -> compiler writers -> kernel devs.
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.
Let me see if I get the ranking right:
> But the motivation isn't clean
> The kernel contributors are doing very important work and their standards for inclusion are high.
> security work where the details really matter, so props for identifying the issue
> Perverse incentives are a thing and it is good to be aware of them.
> with a mediocre contribution
>This is several levels above people that work their way into OSS projects in order to gain visibility by fixing a lot of trivial issues
I wonder where normal people fit into this mental framework.
Contributors with pure thoughts <?> Kernel contributor > Security Contributors > Perverse contributors <?> Mediocre contributors > > People who sneak into OSS projects by fixing minor issues
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.
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?
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:
As far as I know, there is no official title of "Kernel Contributor" that comes with a certificate written on parchment. I have code I wrote in the Linux kernel. Am I an official Kernel Contributor? If so, I didn't receive my merit badge, and that doesn't mean any human decency rules were broken. Having code in the kernel is not that big a deal. I highly doubt I got any job offers because of it. This seems as Internet-pointy as HN karma.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.
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?
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.
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.
https://news.ycombinator.com/newsguidelines.html
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.
This is why kernel maintenance should be left to companies like Google, Microsoft, and IBM. They don't care if they get credit and they put serious efforts toward problems that don't affect them.
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.
If I were to lay down work on an open source project and not get contribution I would never do any work for that project again. It is important for many to feel appreciated for their work.
seems like a great way to select those people who understand that a fix most of the times requires not simply solving the bug
> If I were to lay down work on an open source project and not get contribution I would never do any work for that project again
and that's okay
there are people that would do it for the project, not for themselves
That said, attribution of work is a major theme in academia and business, where professors or department leads traditionally get credited for their student's or subordinates hard work.
The blog author found a bug and submitted a patch, the kernel maintainer fixed the bug differently with his own patch. No copyright was infringed. Where is the theft?
Open Source maintainers don't owe you to accept your patches.
I often spend hours investigating bugs I am just reporting. This is because I want to make it reproducible for the maintainer. Sometimes making it reproducible narrow down the issue so much that it can be found in the code in a few minutes. "Reported-By" is often not a small feat.
But the author went further and identified the incorrect parts of the code as well and produced a patch that resolved the issue.
I would sure love if most the bug reports I receive would be of this quality, it would save me a lot of work...
However arguably root cause analysis is a significant part of fixing a bug, often much more work than writing the lines that fix the bug. A "reported by" is not an acknowledgement of this kind of work.
IMO the author earned an opportunity to write the patch themselves with the guidance of the maintainers. What the author got robbed of is this opportunity.
Doesn't work that way when it's declared a security problem. Fix ASAP is the only way forward for those.
Copyright infringement is not theft
If OPs story holds up, their employerer paid them to work on OS software and they spent time and expertise debugging and fixing an issue.
Not receiving credit here diminished the likelihood their employer will contribute employee time (money) in the future.
Also, I don't see the criticism of the OP wanting credit for their work. This is totally normal and expected.
They way I understand it, the main thing your employer cares about is getting the bug fixed / feature implemented.
In my experience, yes, companies love any way of gaining prestige and contributing to OS is one of them. For some devs it's a strong positive signal when a company they interview for contributes to OS.
There are also performance reviews to be done, where it's a positive to be able to say you/ a dev you manage achieved x.
It's absolutely part of their job. Maintaining a healthy pool of contributors is in the job spec, and to do that you need a degree of people-managing skills - expressed either by tools or by the maintainer.
Torvalds makes headlines when he flames, but he definitely always had a penchant for collaboration and delegation, or Linux would not have become what it did. He effectively encoded his philosophy in git, so now most of the people-management is done by tools, but it wasn't like this for a very long time.
This is the worst kind of OSS contributor, the one that jumps in, makes a small change, then leaves, and expects recognition for it. If you really care, stick around and keep helping. Almost no one does.
You encountered one jerk - there is undoubtedly many, many jerks working in that field.
not exactly encouraging
But he just went and did it himself and then made things further worse by using insensitive language. He could've easily added a line to the patch acknowledging the original fix and the effort that went into it.
Getting the better technical solution in is in most cases not orthogonal to being better humans.
But as it stands, beyond people who get paid for it kernel development is best suited for hobbyists who just have fun figuring things out without any expectation of Internet points.
In a company context, you'd expect the reviewer to coach someone being onboarded towards a solution the reviewer prefers, but that's because you know the person is going to be around for a while, and they're going to need to take ownership.
If you aren't in it for the long haul, you shouldn't expect your code contributions to stick.
If you’re in front of keyboard, and someone is saying what to type. Does this makes you an author of this code? Definitely no.
If you’re in front of keyboard, someone is saying what to type and you creatively rework what you hear. Does this makes you an author of this code? Like, you know, ChatGPT can make an existing code better, but this doesn’t mean ChatGPT wrote it. So mostly no
See, the programming job is not about typing characters to the code editor. It’s even not about choosing between different idioms or applying common algorithms or patterns. It’s about solving problems. That’s where like 90% of efforts going
You might say OP is not a true OSS developer because of solving own problems. But most OSS contributors are solving their problems, what a surprise. This is why OSS still exists.
You might say OP is a glory hunter. But in fact, he spent few days solving the problem and then the authorship was just stolen by rewriting the solution. It’s normal to demand a proper authorship of the work you’ve done
Take what credit you received, appreciate the learning experience and move on.