There’s a recurring problem here where a mechanism primarily developed as a means for collaboration within a field - research papers, CVEs, kernel patches - also becomes a source of prestige, causing the original collaboration tool to become decreasingly useful as people (justifiably) go out of their way to get their name on one.
(I’m not saying Ariel didn’t deserve more credit here - I’m saying we need better mechanisms to acknowledge, and give equivalent credit to, contributions to the kernel that don’t involve literally authoring the patch.)
I can’t help but think that the code committed to the kernel was not written by the author. As a matter of fact, no line of code in the kernel is from him. There might be a good reason for a maintainer to rewrite a patch (which is often a lot less effort than trying to explain to the contributor what should be modified).
But you think about it:
Is the original problem solved in a good way? YES
Is the time spent by the contributor well invested? YES
Does it benefit the larger community? YES
Is the work by the original contributor recognized? YES (although less than he hoped)
Can the original contributor brag about it? YES (the blog post is about exactly that).
I can’t help but feel that this is more an ego issue than anything. Oh, you want a badge of honor for that contribution? Seriously? Isn’t that childish?
(I’m not saying Ariel didn’t deserve more credit here - I’m saying we need better mechanisms to acknowledge, and give equivalent credit to, contributions to the kernel that don’t involve literally authoring the patch.)
as far as I understand it, those mechanisms exist but the maintainer didn’t avail themself of them. the kernel allows @Suggested-By and @Co-Authored-By, either of which seem to me to be appropriate for the level of effort shown in the blog post. the root causing of the problem is the contribution, not to mention the patch that fixed the problem (even in a less than ideal way)
Co-Authored-Byis meant for patches which were written by multiple people. Generally, this is used for greenfield patches, where substantial chunks were written by someone else. It’s not appropriate for a 2-line patch where the person didn’t write any of the lines.
Suggested-by would be more appropriate, but it’s generally used for suggestions and not bug reports. It could be used for a bug report if e.g. the bugfix was non-obvious. But in this case, it seems like the trouble was identifying the cause of the bug, and not fixing it.
However, I suspect OP would only be satisfied with Author: in the commit message…
I wish the author had framed this slightly differently, as in “I did the legwork on a kernel bug but all I got was this Reported-By mention”. Loaded terms like “robbed” imply exclusive ownership to an object in the commons (kernel code). It’s also not the smartest to publicly accuse a maintainer of being unethical if you want to either contribute to kernel work in the future.
But that’s just my opinion. I don’t believe everything starring on the HN frontpage deserves to be posted here, but it’s not flag-worthy just for that.
It’s reasonably common to not get your patch accepted in favor of another one. I wrote a book on open source contribution called How to Open Source and I call out that possibility.
I also see other related behavior where contributors will “claim” an issue but never work on it, or on the other side of the spectrum ask if they can work on an issue and never hear back (so they never start on it). In general I recommend going into a contribution with a growth and learning mindset. If two people submit a patch, great! You’ve got someone to learn from and compare notes. If yours doesn’t get merged, you’ve still got experience in that area of code that will make the next contribution easier.
I’m also a Ruby core contributor and have spent a lot of time working with maintainers. It’s less common that a maintainer will do what’s described, but sometimes I see a case where someone fixed a bug, but maybe not at the ideal spot (like slapping on a bandaid when the patient needed stitches). Ideally a maintainer will guide them, but that’s a huge amount of work to do async pairing with someone who might disappear at the drop of a hat. Depending on the situation it can be easier to just do it yourself.
Ideally if I did that I(as a maintainer) would like to at least pull in their commit and modify it so we are coauthors, but that’s also extra work for the maintainer and might not be appropriate in all situations.
It sucks that this happens, but the trick to succeeding in open source is not getting stuck. Even if OP was bothered by this interaction I would suggest they turn to other projects instead of away from open source. Or in time, if the sting wears off…the second patch is usually easier than the first.
I think proper credit matters a great deal for all projects, especially open source ones.
I took a brief look at the submitted patch and the rejected one
and can’t judge if there is a superior difference between them.
What I can see is that a kernel maintainer was sent a fix for a seven year old bug, read it, then came up with a similar fix for it and then submitted it as theirs.
In the short term the seven year old bug gets fixed. Presumably a small number of users get a benefit.
In the long term this story remains which creates a bad impression of the management of this project and reduces the number of people putting in effort to help out.
Perhaps a better way of handling this would have been:
Thank you so much for analyzing this old bug and taking the time to fix it. I propose a different solution that is better because of X. I propose you implement this solution and send that in instead.
“I propose you implement this solution and send that in instead.”
That works if you’re ready to mentor somebody into your community. No, maintainers sometimes don’t have the time or energy for that, and it shouldn’t be a requirement because that tightens up the maintainer pool even more.
However, in such a case it’s still possible to answer
Thank you so much for analyzing this old bug and taking the time to fix it. Your patch doesn’t fit a bunch of requirements for the project, so I built upon it and made it suitable for integration. It’s merged now, with proper attribution in the Co-Authored-By: line. Again, thank you for digging into this long-standing bug.
The other part I found grating was “I took your patch, made it my own, but you can look at other issues whose solution, should you provide any, I can make my own.” (the latter part heavily implied, but given the precedence, who knows?)
With a response like the above, that can become
By the way: if you want to get more familiar with this code area, I have a few open issues that you could look at.
and it would be an earnest proposal for “not too much time training you, but here’s how to get into this community.”
Almost certainly this would have been the right way to handle this situation.
Some people are suggesting that the author shouldn’t have been invested in receiving public recognition for their work here, or that seeing the kernel be improved should have been reward enough. They forget that part of what made Linux so successful originally was the fact that Linus encouraged collaborative effort, and was not stingy with giving credit where credit was due. These things make a real difference.
I think you’re right. Even though what the maintainer actually did is “legal” and maybe even “ethical,” it fails the “moral” test. If I reject a junior engineer’s changes and rewrite them as my own, that junior will absolutely never trust me with their work ever again, and with good reason! Code is only one of the desired outputs in any software engineering project. Another desired output is the trust and relationships that make keeping that project sustainable. While we only have one side of this story here, it’s empirically failed to build trust.
First, note that the alternative is by Michael Ellerman, not Christophe Leroy (the maintainer). The actual quote from Christophe is
Michael’s patch seems easier to understand.
And it is! It’s shorter, has fewer macros, has less ifdefs, and is more idiomatic. The feedback provided says just as much. Normally, what happens next is that Christophe would ask Ariel for a v2, but since he already has another (better) patch, it’s perfectly reasonable to just apply that one. Ariel even gets a Reported-by.
Yeah this is understandable and perhaps not talked about enough: there is a lot of angst in FOSS that comes from peoples’ work being rejected. Usually the work isn’t paid, so people are left with nothing but the belief that all their time and effort was wasted and not valued by others. I think wanting to do work that is valued by your peers is a fundamental human trait, so I don’t buy the “it’s just ego” dismissal.
This issue fundamentally stems from the sole remaining “property” still present in the ordinarily propertyless domain of FOSS: ownership over a release channel. Strictly speaking there isn’t “the” Linux kernel because anybody can build and publish their own fork. But one of these forks has way, way higher usage than any other so control over who gets their changes into that specific fork is a source of power in an ideally less-hierarchical system. Interestingly this closely mirrors a conflict in a totally egalitarian society explored in the novel The Dispossessed by UKLG way back in 1974, where characters wrestle for control over what material is distributed through a scientific publishing channel.
I don’t have any ideas to resolve this (possibly irreconcilable) conflict other than to say to the author: it sucks, a lot of us have been there, it’s normal and fine to feel angry, just try to recount the positives (like technical things you learned) and move on. Not saying it’s the case here but there certainly are maintainers who enjoy wielding their power to exclude more than others. Maybe try contributing somewhere else in the kernel next time once you’ve recovered your mojo.
I already commented earlier with a semi dismissive comment on the orange website. But I’ll try to be more thoughtful here, since the title was changed to a less aggressive headline.
I think the issue is the entitlement of a subset people who interact with open source projects. Maybe I’m what’s wrong with open source: IMHO, open source maintainers are already giving their work for free, I don’t think they owe anybody mentorship or unconditional patch merging. Instead of merging bad code or mentoring the blog’s author, the maintainer decided to write the fix themselves from scratch.
There was a little frustrating moment late in the implementation when Victor Stinner reimplemented much of scandir using a different approach (as little C code as possible), without prior discussion. And I’m sure he wouldn’t mind me relating this, as it’s all on the bug tracker and was resolved well. Victor had been helpful and involved throughout, but I was a bit frustrated at this (and said as much), and he admitted being a bit overzealous and could see how much faster the pure C implementation was.
Unlike the OP’s issue, it ended up being resolved, and my code – with modifications – was included in Python 3.5. It’s one of the open source contributions I’m most proud of.
So I agree with the OP that, as a contributor, having the rug swept out from under you like this is very frustrating. However, I’m not sure that a whole blog post calling a maintainer out is a good idea. At least do it without the loaded and heavy words like “robbing”. Maintainers do have a lot on their plate and little time, so it’s good to keep things in perspective and try to put yourself in their shoes, rather than antagonising them.
I had a similar experience with Rust, on a feature that’s now in the standard library. I brought this up off-handedly once and got dogpiled, so I’ll keep this vague to avoid a repeat of that.
Author let his ego cloud his judgment. He found the issue, submitted his patch. The patch was sub-optimal and the maintainer wrote an optimal version. I understand his point that he wished the maintainer would have coached him to the right solution but that would have needlessly used up the maintainers time. The only difference at the end is that it would have been his name on the commit instead of the maintainers, which doesn’t make sense either. He did get a “Reported-By” credit which is a legitimate credit.
Someone else pointed to an “entitlement” among open source users. I really think that is the case. People who use open source have inaccurate expectations about how it works.
Without seeing the full conversation and the relevant code of the mentioned patches, it is hard to draw a conclusion; we only read one side of the story. It’s unfortunate that the drama overshadows this interesting recount of a very challenging bug hunt.
There’s a recurring problem here where a mechanism primarily developed as a means for collaboration within a field - research papers, CVEs, kernel patches - also becomes a source of prestige, causing the original collaboration tool to become decreasingly useful as people (justifiably) go out of their way to get their name on one.
(I’m not saying Ariel didn’t deserve more credit here - I’m saying we need better mechanisms to acknowledge, and give equivalent credit to, contributions to the kernel that don’t involve literally authoring the patch.)
Thanks for pointing the real problem here.
I can’t help but think that the code committed to the kernel was not written by the author. As a matter of fact, no line of code in the kernel is from him. There might be a good reason for a maintainer to rewrite a patch (which is often a lot less effort than trying to explain to the contributor what should be modified).
But you think about it:
I can’t help but feel that this is more an ego issue than anything. Oh, you want a badge of honor for that contribution? Seriously? Isn’t that childish?
as far as I understand it, those mechanisms exist but the maintainer didn’t avail themself of them. the kernel allows @Suggested-By and @Co-Authored-By, either of which seem to me to be appropriate for the level of effort shown in the blog post. the root causing of the problem is the contribution, not to mention the patch that fixed the problem (even in a less than ideal way)
Co-Authored-Byis meant for patches which were written by multiple people. Generally, this is used for greenfield patches, where substantial chunks were written by someone else. It’s not appropriate for a 2-line patch where the person didn’t write any of the lines.Suggested-bywould be more appropriate, but it’s generally used for suggestions and not bug reports. It could be used for a bug report if e.g. the bugfix was non-obvious. But in this case, it seems like the trouble was identifying the cause of the bug, and not fixing it.However, I suspect OP would only be satisfied with
Author:in the commit message…I wish the author had framed this slightly differently, as in “I did the legwork on a kernel bug but all I got was this Reported-By mention”. Loaded terms like “robbed” imply exclusive ownership to an object in the commons (kernel code). It’s also not the smartest to publicly accuse a maintainer of being unethical if you want to either contribute to kernel work in the future.
But that’s just my opinion. I don’t believe everything starring on the HN frontpage deserves to be posted here, but it’s not flag-worthy just for that.
It’s reasonably common to not get your patch accepted in favor of another one. I wrote a book on open source contribution called How to Open Source and I call out that possibility.
I also see other related behavior where contributors will “claim” an issue but never work on it, or on the other side of the spectrum ask if they can work on an issue and never hear back (so they never start on it). In general I recommend going into a contribution with a growth and learning mindset. If two people submit a patch, great! You’ve got someone to learn from and compare notes. If yours doesn’t get merged, you’ve still got experience in that area of code that will make the next contribution easier.
I also have a conference talk where I mention this barrier (and others) https://m.youtube.com/watch?v=-8UQMH6p-Mw&list=PL9oQ7yETvN13V5Xp7016XupVLg3WqiMtx&index=8&pp=iAQB you can skip through the intro video.
I’m also a Ruby core contributor and have spent a lot of time working with maintainers. It’s less common that a maintainer will do what’s described, but sometimes I see a case where someone fixed a bug, but maybe not at the ideal spot (like slapping on a bandaid when the patient needed stitches). Ideally a maintainer will guide them, but that’s a huge amount of work to do async pairing with someone who might disappear at the drop of a hat. Depending on the situation it can be easier to just do it yourself.
Ideally if I did that I(as a maintainer) would like to at least pull in their commit and modify it so we are coauthors, but that’s also extra work for the maintainer and might not be appropriate in all situations.
It sucks that this happens, but the trick to succeeding in open source is not getting stuck. Even if OP was bothered by this interaction I would suggest they turn to other projects instead of away from open source. Or in time, if the sting wears off…the second patch is usually easier than the first.
I think proper credit matters a great deal for all projects, especially open source ones.
I took a brief look at the submitted patch and the rejected one and can’t judge if there is a superior difference between them.
What I can see is that a kernel maintainer was sent a fix for a seven year old bug, read it, then came up with a similar fix for it and then submitted it as theirs.
In the short term the seven year old bug gets fixed. Presumably a small number of users get a benefit.
In the long term this story remains which creates a bad impression of the management of this project and reduces the number of people putting in effort to help out.
Perhaps a better way of handling this would have been:
And that is a conversation.
That works if you’re ready to mentor somebody into your community. No, maintainers sometimes don’t have the time or energy for that, and it shouldn’t be a requirement because that tightens up the maintainer pool even more.
However, in such a case it’s still possible to answer
The other part I found grating was “I took your patch, made it my own, but you can look at other issues whose solution, should you provide any, I can make my own.” (the latter part heavily implied, but given the precedence, who knows?)
With a response like the above, that can become
and it would be an earnest proposal for “not too much time training you, but here’s how to get into this community.”
Almost certainly this would have been the right way to handle this situation.
Some people are suggesting that the author shouldn’t have been invested in receiving public recognition for their work here, or that seeing the kernel be improved should have been reward enough. They forget that part of what made Linux so successful originally was the fact that Linus encouraged collaborative effort, and was not stingy with giving credit where credit was due. These things make a real difference.
I think you’re right. Even though what the maintainer actually did is “legal” and maybe even “ethical,” it fails the “moral” test. If I reject a junior engineer’s changes and rewrite them as my own, that junior will absolutely never trust me with their work ever again, and with good reason! Code is only one of the desired outputs in any software engineering project. Another desired output is the trust and relationships that make keeping that project sustainable. While we only have one side of this story here, it’s empirically failed to build trust.
OK, lets look at the patches themselves
OP’s patch
the alternative
First, note that the alternative is by Michael Ellerman, not Christophe Leroy (the maintainer). The actual quote from Christophe is
And it is! It’s shorter, has fewer macros, has less ifdefs, and is more idiomatic. The feedback provided says just as much. Normally, what happens next is that Christophe would ask Ariel for a v2, but since he already has another (better) patch, it’s perfectly reasonable to just apply that one. Ariel even gets a
Reported-by.Yeah this is understandable and perhaps not talked about enough: there is a lot of angst in FOSS that comes from peoples’ work being rejected. Usually the work isn’t paid, so people are left with nothing but the belief that all their time and effort was wasted and not valued by others. I think wanting to do work that is valued by your peers is a fundamental human trait, so I don’t buy the “it’s just ego” dismissal.
This issue fundamentally stems from the sole remaining “property” still present in the ordinarily propertyless domain of FOSS: ownership over a release channel. Strictly speaking there isn’t “the” Linux kernel because anybody can build and publish their own fork. But one of these forks has way, way higher usage than any other so control over who gets their changes into that specific fork is a source of power in an ideally less-hierarchical system. Interestingly this closely mirrors a conflict in a totally egalitarian society explored in the novel The Dispossessed by UKLG way back in 1974, where characters wrestle for control over what material is distributed through a scientific publishing channel.
I don’t have any ideas to resolve this (possibly irreconcilable) conflict other than to say to the author: it sucks, a lot of us have been there, it’s normal and fine to feel angry, just try to recount the positives (like technical things you learned) and move on. Not saying it’s the case here but there certainly are maintainers who enjoy wielding their power to exclude more than others. Maybe try contributing somewhere else in the kernel next time once you’ve recovered your mojo.
I already commented earlier with a semi dismissive comment on the orange website. But I’ll try to be more thoughtful here, since the title was changed to a less aggressive headline.
I think the issue is the entitlement of a subset people who interact with open source projects. Maybe I’m what’s wrong with open source: IMHO, open source maintainers are already giving their work for free, I don’t think they owe anybody mentorship or unconditional patch merging. Instead of merging bad code or mentoring the blog’s author, the maintainer decided to write the fix themselves from scratch.
I had a somewhat similar experience when I contributed
os.scandirto Python. To quote my original write-up:Unlike the OP’s issue, it ended up being resolved, and my code – with modifications – was included in Python 3.5. It’s one of the open source contributions I’m most proud of.
So I agree with the OP that, as a contributor, having the rug swept out from under you like this is very frustrating. However, I’m not sure that a whole blog post calling a maintainer out is a good idea. At least do it without the loaded and heavy words like “robbing”. Maintainers do have a lot on their plate and little time, so it’s good to keep things in perspective and try to put yourself in their shoes, rather than antagonising them.
I had a similar experience with Rust, on a feature that’s now in the standard library. I brought this up off-handedly once and got dogpiled, so I’ll keep this vague to avoid a repeat of that.
Author let his ego cloud his judgment. He found the issue, submitted his patch. The patch was sub-optimal and the maintainer wrote an optimal version. I understand his point that he wished the maintainer would have coached him to the right solution but that would have needlessly used up the maintainers time. The only difference at the end is that it would have been his name on the commit instead of the maintainers, which doesn’t make sense either. He did get a “Reported-By” credit which is a legitimate credit.
Someone else pointed to an “entitlement” among open source users. I really think that is the case. People who use open source have inaccurate expectations about how it works.
Most of my kernel contributions will never be accepted, either. I feel that this is typical and working as intended.
Without seeing the full conversation and the relevant code of the mentioned patches, it is hard to draw a conclusion; we only read one side of the story. It’s unfortunate that the drama overshadows this interesting recount of a very challenging bug hunt.