I got robbed of my first kernel contribution
ariel-miculas.github.io
ariel-miculas.github.io
Clearly no one was fixing this security issue unless he found it and submitted a fix.
It’s unethical to not give credit, in particular if Michael read his patch, changed some stylistic things, and submitted it himself. I’m surprised everyone thinks the maintainer is in the right here.
If someone scooped up your work and took full credit for it, despite it being a collaboration (and even if miculas code was absolute garbage it was still a collaboration), that wouldn’t feel right, and you wouldn’t want to work with them again.
As you say, even if the code was shite, the refactored fix that got merged in would never have existed without it. "I like my version better," feels pretty dismissive and regardless of any other fact I can see how anyone would feel a bit miffed about that after they put the work in.
Edit: the reply linking to the actual response from the maintainer invalidates my last sentence.
This[1] is what the maintainer (Michael) said.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
In academic publishing, this is analogous to sending a pre-print to someone, and that person then publishing on that topic listing you in acknowledgments rather than as a co-author. I get that the point here isn't publishing, it's kernel development, but authorship is still quite important for a professional C.V.
Nothing about that says "I have debugged an issue and contributed actual code to fix it" in there.
[1]: https://docs.kernel.org/process/submitting-patches.html#usin...
Identified: They have found an issue and reported it.
Debugged: They found the cause of the issue.
Fixed: They wrote the fix.
It seems that Ariel should be credited for somewhere between Debugged and Fixed. But is only explicitly given credit for the first "tier" of solving the problem. It would have been nice to explain a bit more the work that Ariel put in.
But I agree that I wouldn't expect an inferior (by the maintainer's perspective) patch to be included just to give that credit. But a sentence explaining how Ariel contributed would likely be much appreciated.
"I like my code better" indicates that neither of this happened. So, Ariel deserves (at least partial) credit for fixing, since this was not a "clean room" fix.
This is very unethical conduct on the maintainer's part.
1. It doesn't lose the fpidx < (PT_FPSCR - PT_FPR0) test from the 32 bit case.
2. In the put function, it doesn't lose the *data = child->thread.fp_state.fpscr; fallback assignment, which is taken when fpidx is out of bounds.
3. It avoids the pointless FPRINDEX macro which reduces to identity if TS_FPRWIDTH is 1. The original patch's commit message says "On PPC32 it's ok to assume that TS_FPRWIDTH is 1", but then includes this anyway:
#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
#define FPRHALF(i) (((i) - PT_FPR0) & 1)
#define FPRINDEX(i) TS_FPRWIDTH * FPRNUMBER(i) * 2 + FPRHALF(i)
The maintainer should, however, acknowledge that Miculas didn't simply report the problem, but that Miculas investigated identified the root cause, and had his own version of almost the same simple fix.
"Reported-By" lacks the precision to express that it was thoroughly investigated by that party, and root-caused.
That happens constantly for new contributors to a project and it is the proper way to do things - it teaches people and brings them up to speed. If you just redo their work, you are discouraging them from contributing while also not allowing for a teachable moment.
In a company where people are expected to stay around for a while, it may make sense to invest time to bring juniors up to speed. But I wonder whether that's true for OSS projects in general. A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture -- this is not a junior who just joined the team, and they have no commitment to stick around to do more contributions.
In this case, from a utilitarian perspective, it doesn't seem obvious the maintainer should spend the extra time coaching.
This might be a minority view here, but TBH I don't think anyone should be obliged to go out of their way to spend extra time and effort to avoid offending a random person on the Internet.
When that is done, often the fix is simple, and the author's patch sometimes just ... isn't that great, often for entirely understandable reasons, so it's easier to just fix it myself "from scratch".
So whose patch is it then? In some cases the patch was useful and I'm "inspired" by it, in other cases I'm not. I tend to err on the side of caution, but I've definitely merged my share of patches where the Author field was, IMHO, kind of a lie.
As for code review: it's really time-consuming. And while a few "minor bug fixers" of today become "hard-core contributors" or tomorrow, realistically, most people show up to fix one bug and are never seen again. That's perfectly fine! But it does mean that "teaching" everyone who shows up quickly become an enormous time sink. There's a bit of a trade-off to be made here.
Saying that it’s a simple fix shows one doesn’t understanding the amount of work go into bug fixings in software development.
In this case Michael even acknowledged that he could not reproduce it initially but only later had it nailed down. This speaks volume about the amount of work OP put into debugging and fixing the problem. Robbing him of his work is just not right.
That's why we have pair programming and code reviews.
That same developer who spotted your code blindness today will exhibit that themself tomorrow.
The person not involved in the feature or fix is completely free to think about nothing else but "in what ways is this change wrong"?
I know reading is hard, but it's not an excuse to put words in other people's mouths.
>>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. I was also open to working with him, addressing his feedback and sending subsequent versions of patches.
[1] https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...
Is this true though?
That's not really what anyone is suggesting should have happened. The maintainer should've just taken the two minutes of extra time required to checkout the OP's code, make whatever changes the maintainer wanted and commit it with co-authorship.
That clearly would've been the best course of action for the maintainer to follow (especially given that the OP expressed his desire to the recognized for his contribution) -- the best fix gets merged in and the work of others is acknowledged/respected. That said, I'm not surprised it didn't happen -- social niceties often seem to escape the maintainers of these sorts of repos...
Most of the time as well the PR doesn't get accepted because of various reasons. I don't care. I do the PRs so that the code is out there. No I wont spent time making it "good enough " to merge into your repo. I provide it as is, and I'd someone likes it enough they can do the red tape.
Some of it has been just accepted and merged. Some was slightly modified by the repo owner before merging. Good for them.
I dont do open source code for the glory or to be popular, I do it because I like it .
Aaah I miss the 80s and 90s.
There is already a check at the beginning of the function:
if (index > PT_FPSCR)
return -EIO;
+ ((unsigned int \*)child->thread.fp_state.fpr)
+ [FPRINDEX(index)] = data;
So please tell me how my patch was buggy.
int ptrace_get_fpr(struct task_struct *child, int index, unsigned long *data)
{
unsigned int fpidx = index - PT_FPR0;
if (index > PT_FPSCR)
return -EIO;
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0))
memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long));
else
*data = child->thread.fp_state.fpscr;
return 0;
}
(Also, the function risks integer subtraction underflow in "index - PT_FPR0". If we pass in the value INT_MIN, subtracting a positive value from it is undefined behavior.)
It looks like the original author knew that the -EIO test is too weak, so the converted unsigned value is tested again.
Regarding 2, accessing fpscr using fpr[32] is undefined behavior (out of bounds array access), which is probably why the original code is refraining from that, but testing for that value and separately accessing the member.
However is also this bit of uncertainty (I have not fully drilled into). On 32 bit PPC, that PT_FPSCR is defined with an extra offset of 1:
#define PT_FPSCR (PT_FPR0 + 2*32 + 1)
Thus, even with the range check in place, out-of-bounds access past the array is possible if user space requests the [64] index since the range check is testing for below 65. The [64] index isn't fpscr, but the upper half of u64 fpscr.
There is also the aspect that when we assign to fpscr, the whole 64 bit value is assigned, not just half of it.
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.
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.
Complaining about it reeks of a junior developer mentality.
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.
Then you shouldn't contribute to someone else's project.
It certainly seems that you're correct judging by the article, in the worst possible way.
Reported-by is more of a participation medal because it can mean anything including "yo dawg, kernel crashes when I look at it wrong"
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.
Ref: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> 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.
It sounds like the author did quite a bit more than "suggest" the patch idea. They debugged the issue and wrote an entire patch which was accepted with one small change.
Lines of code modified is a notoriously bad signal for estimating the significance of software engineering contributions. And at the end of the day, credit is damn near free to give out and volunteer projects ought to let it run like water.
And that way, forks being present, attribution is required for copyright and hence, copyleft.
If you have a (eager) junior on your team and they contribute a helpful, but sub-par quality PR for some issue, the worst possible way to handle the interaction is admonish them for not being good enough, throw their code in the bin and then rewrite it yourself.
You’ve destroyed morale, wasted their time and yours, ensured that they haven’t learnt anything - and thus won’t be able to improve or meaningful contribute next time and you’ve likely dissuaded them from asking for help or volunteering for anything next time. Even if they waded into a hectic past of the codebase, there’s better ways to handle this interaction.
There's an expectation for junior devs on your team to stick around for a while, and presumably there was an interview process that established some baseline ability so you're reasonably confident that they can grow towards your expectations.
The random person on the internet isn't obliged to stick around, and most often for these kind of "drive-by" fixes they won't be. You don't know the actual abilities of this random person and how well they'd respond to your comments on their fixes.
If we're talking about management, IMHO one of the most frustrating things of managing people is when somebody else assigns random people as your reports and you're now responsible for their performance. Now imagine some random self-entitled person on the Internet spent a couple days working on a sub par fix, and now you're responsible for coaching them as if you're their manager?
The analogy is honestly ridiculous.
I often wondered what the big fuss was about when people talked about hosting projects on github and unwanted PRs (eg. https://news.ycombinator.com/item?id=25940799 )
Now I kind of understand. Not wanting to deal with random PRs and you'd be accused of "destroying morale, wasting people's time" and being a bad manager. Such insane ideas of entitlement...
Being a professional is partly about learning how to dissociate yourself from your work, and to realize 99% of the time, your teammates aren’t trying to sabotage you for some nefarious scheme. We’ve all worked on projects for months that eventually got canned. We’ve all gotten rough comments in a code review. It’s up to you as a professional to take those things in stride and learn from it rather than letting that stuff destroy your morale.
And of course, the people who are blunt and rude will also have to learn that being blunt and rude ruins many relationships. But we’re all professionals here, not artists.
If a junior civil engineer was building a bridge and ended up designing it with structural defects, and the senior engineer came up to him and said “I’m sorry we’re just going to have to redo all this because it’s unsalvageable at this point”. The senior is perfectly fine in this case! I don’t want to drive on shoddy bridges built to protect a juniors ego.
Edit: I also think a lot of the comments responding talking about how toxic the maintainer is may not have much experience maintaining a large open source project. I’ve had contributors for some of my OSS projects, and accepting a PR from a random person is a lot of work. Often, it’s more work than doing it yourself. The amount of time needed to carefully review the code, communicate with the contributor to fix issues, make sure the code is upholding the expected quality and expectations is immense. At a job, a junior has already been vetted through an interview process. It’s not some random stranger requesting a change. There’s way more factors here than many of the dissenters here seem to be taking into account.
And getting a PR rejected does suck. But having been on both sides I understand both sides. It’s a difficult situation and it’s hard to resolve these things without upsetting someone unintentionally. (Based on the maintainers communication, it doesn’t seem like they were being particularly nasty or rude).
:
the worst possible way to handle the interaction is admonish them for not being good enough, throw their code in the bin and then rewrite it yourself.
You should perhaps read through again, that's not what appears to have happened, or at least it's possibly an emotional retelling of one side of the story.
How should have this been handled? Easy: something called “code review”. The maintainer could have simply reviewed the patch and suggested what changes need to be made for it to be accepted. And if the maintainer really wants some credit for some odd reason, they can get the Reported-By tag. Win-win!
But what ended up happening is a loss of (at least) one potential long-term contributor. I for one definitely thought more highly of kernel maintainers.
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.
#ifdef CONFIG_PPC32
*data = ((unsigned int *)child->thread.fp_state.fpr)[FPRINDEX(index)];
#else
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0))
memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long));
else
*data = child->thread.fp_state.fpscr;
#endif
flush_fp_to_thread(child);
if (fpidx < (PT_FPSCR - PT_FPR0)) {
if (IS_ENABLED(CONFIG_PPC32))
*data = ((u32 *)child->thread.fp_state.fpr)[fpidx];
else
memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long));
} else
*data = child->thread.fp_state.fpscr;
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.
(Totally with you though: maintainer was a douche. People are the worst.)
I can think of at least three times off the top of my head [1][2][3] this "happened" to me. It honestly never even occurred to me to be upset about it... because my primary goal was to fix the bug, and I was happy to have done so.
My sincere advice to OP is to delete this blog post... they will regret it in the future.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Last year I took on an issue that has been opened for years, did all the work creating a pull-request, updating test code, yada yada, even another one that fixes their build problem. The maintainer took the PR to fix their build problem and simply ignores the original issue. Any chance I will spend my time contributing to that project again? No way.
1. Open PR
2. Get comments asking for changes, you only have time to fix it a few days later.
3. PR gets closed as fixed by another PR submitted by a frequent contributor.
4. Find said PR is your exact code with a variable name change (approved instantly through lower 'friend' review standards)
5. Look at that user's profile and notice almost every contributions were copy-pasted from other people.
Not that it matters now, since the AI revolution the open source licenses are widely breached and I haven't submitted any open source code since and wont do so again.
Do they have jobs? If so, to make these kinds of comments imo they should be working completely for free. Salary is a form of recognition for contribution.
Personally, adding a co-author (even if the final solution ends up different to the one proposed, but the solution is based around the findings of the original solution) is such a tiny thing to do. I think the author has a valid point to moan about this.. it isn't the first and won't be the last instance of somebody feeling their contribution to something is going unrecognised.
people are acting like we are code robots who never want recognition for a job well done. even if the patch itself was inferior, the debugging effort certainly was not
No, that’s a different scenario. Where employment is concerned, the employer and employee have an agreement where work is performed in exchange for compensation.
If you walked into a company unannounced and started doing work no one asked you to do (which is a far more accurate analogy to what happened to the OP), very few people would argue you’re entitled to compensation.
This is not analogous at all. The very premise of open source involves contribution from a community of volunteers. Contributing code to a project that accepts contributions from the public is the way things are expected to work, and is about as far removed as it can possibly be from showing up at a company unannounced and expecting to receive pay.
People contribute to these projects for a variety of reasons, but at the base of it all, it’s a very human endeavor, and in lieu of receiving monetary payment for productive work, proper attribution for contributors is about as low of a bar as one can set, and should be the minimum standard.
If the “kernel contributor” badge conveys something more than the maintainers are willing to convey about a contribution, there should be something that does.
I find the blog post a little in bad taste, but sometimes you need to stir things to get meaningful change.
How many other first time contributors has this exact thing happened to who now will never contribute again but didn't speak up?
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.
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.
Basically from what I can tell, the kernel is so large that you have individual maintainers responsible for a specific tree. Those maintainers in turn basically run their own little fiefdom in terms of what contributions they accept and even how they accept them. Some demand the use of git send-mail like in the olden days, others use a more dedicated website for contributors to upload their patches to (forgot the domain).
The problem is that a good chunk of those maintainers are apparently running roughshod in terms of basic decency or willingness to communicate with people submitting patches. Prospective contributors have been yelled at or had their patches rejected for bugs that weren't in code they introduced (but were in the git diff they exported into send-mail) or for fixing a bug that their code relied on while adding a new feature (because it "should've been a separate patch"). It's not all of them, but enough to be frustrating.
As for reimplementing submitted patches rather than offering feedback on existing ones and refusing the proper credit - this doesn't surprise me in the slightest, nor does the offense being taken suprise me. This is pretty much the exact same situation that led to the disastrous ffmpeg and avconv forking situation (where the lead maintainer would often not bother giving feedback and reimplement entire PRs on his own, without care for the other person involved). Seeing that replicated is unlikely given its Linux, but bad maintenance does usually follow a few trends.
There's a reason that when you get to more "niche" hardware combos like say, homebrewed videogame consoles, most projects don't bother upstreaming to begin with, even if their patches are otherwise quality work. Not everyone wants to deal with these sorts of LKML politics.
Other maintainers have been similarly responsive, though the tone is typically "very technical feedback from a busy person" rather than new-developer-relations. These people receive patches of random quality, often from one-shot contributions. Triage of the patch stream must be pretty exhausting.
I completely understand why people want their name on a kernel patch - it's pretty cool and a good thing to have on a resume - but at the same time, the bar for contributing is quite high and I think the dev process should not optimize for newbie contributors.
As for maintainers "taking and rewriting", that has happened since the beginning of free software, the tales of "XXX took my patch and rewrote it, without crediting me in any way" are legion. It's why "Reported-By" was belatedly added, because the phenomenon is so endemic that doing nothing looks bad. But it still happens every day in all sorts of projects, not just Linux.
I didn't notice at the time but now I'm job hunting, past credits seem a bit more important.
This is called diplomacy.
Anyway. This story is about the opposite of that.
Diplomacy is a choice, usually a trade-off, in favoring a longer-term relationship. Failure to even want to be diplomatic shows the Linux maintainer thinks this person is worthless as a human being on a long-term basis wrt kernel maintenance. And that's fine, but don't be surprised when that contributor is offended and proves you right.
I feel sad for the maintainer in question who suddenly is on the receiving end of a borderline defamatory blog post featured in the front page of HN for some minor "mistake" he made 1.5 years ago. Apparently according to some comments in this discussion what he did was pretty much standard procedure even.
Where is "being kind" for him? Where is the "encourage them to keep doing what they are doing" for him? Not the misattribution of course, but like, to not feel discouraged after 20 thankless years of contributing to the kernel and 10 years of maintaining a kernel subsystem?
Speculative statements like this are anything but kind: "Linux maintainer thinks this person is worthless as a human". Take your own medicine. Actually be empathic, not only to those wearing the protagonist hat, but to every single person, and perhaps especially those unfairly villainized.
> shows the Linux maintainer thinks this person is worthless as a human being
bit of a contradiction. This highly speculative take on the maintainer isn't exactly kind.
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.
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.
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.
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
Instead of taking my fix, the maintainer spent a month making drastic changes to the architecture to address my problem and fix. There was a major version increase and people left using the old version of the code either had to deal with breaking changes to adopt the newest version with the fix, or use my fork. The whole thing was non-sensical and I came away thinking the maintainer was an absolute idiot.
No one likes their hard work going to waste so I don't know how a rewrite under someone else's name could ever be justified. Wanting to get credit for your work is only natural and sometimes career changes are hinging on being able to build your resume in this way. Even from just a reputation aspect to get more sway when attempting to tackle more ambitious changes.
When credit is robbed from someone for no good reason, it's just wrong imo. It's crazy this even has to be explained.
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.
I have seen (and sadly self experienced!) this kind of story way too often. And let me tell you this: This guy is now burned by this bad interaction and is successfully shooed away.
And some folks wonder why "nerds" and "geeks" are seen as socially inapt...
I don't even think that Mr. Ellerman had any malicious intents. But it just shows again, that the so called people skills are nothing to be neglected when choosing leading figures.
To paraphrase George Carlin: "It's a big club. And you're not in it!"
There seems to be a large "old school open source" and "new school Github open source" culture clash here.
This sort of thing wouldn't even make for a 5 minute controversy on IRC back in the day. But I also can see valid points and the expectations developers who grew up in a different era now have. The olden days were certainly not perfect, but neither is the new age.
Certainly going to be interesting times as torches get passed for these huge fundamental open source projects over the next decade or two!
IMO, what the maintainer did (taking authorship and crediting the original author/reporter via Reported-by, after rewriting the entire patch including the commit message) was in line with kernel conventions. The lines are a bit blurry, and I think keeping the original author/reporter as at least a Co-developer would also have been acceptable. Still, people sometimes complain if they are kept as the author or co-developer if their patch is rewritten, as they don't want to "own" that rewritten patch and take blame for any issues in it. So pick your poison.
Ideally, more time would have been taken to work with the original author/reporter to get their patch in shape. Unfortunately, there isn't always time for that. In this case, the bug was reported to security@kernel.org as a security vulnerability, so that throws much of the usual process out the window; it needed to be fixed quickly. The maintainer went out of their way to get it fixed quickly, in a better way, and even added unit tests for it later. The original author/reporter was credited in both the fix commit and the pull request merge commit. Also note that the maintainer's commit is dated June 7 and was merged into mainline on June 9. So AFAICS, it predated the original author/reporter sending a revised patch; it postdated only the first patch.
> as a security vulnerability, so that throws much of the usual process out the window; it needed to be fixed quickly
Was not the bug reported originally six years ago?
The Linux Kernel is the deep end, and the Linux Kernel Security team is the Marianas Trench.
It took gumption to make a first attempt to that level. It sounds like it was damn well done, but I have found that people in that level of things are generally not particularly welcoming of folks just coming in and assuming equal status. It's an unhealthy ego thing, but it's also quite human.
I encounter it all the time. I don't come across as an alpha nerd, and am often treated quite dismissively. It used to infuriate me, but nowadays, I just shrug, and say "your loss." I don't think I'm missed; even if my contribution would have made a great difference. Sometimes, I have had stuff I pioneered used without credit, but I put it out there for a reason. Most of the software I write is designed to help people in need, and if it gets to them; no matter the route, then it's good. I am not particularly interested in getting credit.
There was a post, a day or so ago, about "I Will Not Read Your F%%king Script"[0], and it sort of spoke to the same kind of mindset.
Basically, if we jump into the deep end, the rewards can be great, but we won't receive any help, or any pity. We will be treated as interlopers, and can look forward to being treated fairly barbarously.
All that said, I encourage the author to keep it up, but I'd gently suggest not making it a front page HN issue. That probably won't help.
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...
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.)
It works! I'd rarely file a bugfix to a high-profile project now I know how contemptuous some of the maintainers are.
(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)
Saying he was "robbed" is wrong; nobody said he was going to get his patch accepted, much less be given a specific amount of credit. If he had been promised something, and his work was taken without giving him what was promised, I could see that as being "robbed". But giving someone something in the hopes of something in return, that was never promised, and being mad when you don't get what you hoped for? That's sour grapes. It's like taking a girl out for dinner and saying you were "robbed" when you don't get any after.
The bug got fixed, which is a much bigger deal. Often maintainers don't accept your fixes at all, so you're still subject to the bug. Lesson learned: maintainers can be dicks, don't expect anything from them. (I report bugs and user experience issues all the time, and I mostly get either ignored or told that it was expected in some way, so they don't have to accept any responsibility or fix the problem)
Nah, that's too cynical for me. I prefer to believe that most people are good. Just stop giving power to dicks, and route around them. Find projects that aren't run by dicks, and contribute there.
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.
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.
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.
Copyright infringement is not theft
If you did the work, and your employer paid for it, surely they know you contributed the fix and appreciate the leveling up you had to do to accomplish it.
So you know what you did, the person paying you knows, so where's the problem?
The way it is being presented makes it seem like nefarious work stealing went on. The thread posted doesn't indicate that though, and again, the people who matter know.
Your gold star is the growth you got along the way, not the 'authored by' note.
The reality is that if you or he had been on the other side, you'd know that as a maintainer, you have enough to balance without worrying about everyone else's resume.
This is the equivalent of a reviewer rejecting the paper, and then publishing the same paper in their own words, saying "I like my phrasing better".
The author is right to be upset.
It seems to me that 90% of the effort for this fix was contributed by the author of this post and the 10% effort of writing, testing and verifying the few-line fix was contributed by the maintainer. At the very least it seems the original author should have got a Co-Authored-By attribution, even if no lines of his original patch made it into the final commit.
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.
Now, the maintainer could have made this guy more welcome... but I imagine it's quite a bit of work to get a new contributor up to speed to the point where they are consistently a net positive for the project. In any particular case you have to decide whether you want to take on that work or not, and I can hardly blame someone who isn't getting paid for opting out of that, even if the reason is just that they don't want to do it that day.
> I was also open to working with him, addressing his feedback and sending subsequent versions of patches.
That's good, but it's important to note that that's asking the other person to do a bunch of work that helps you, not them. You're asking for a favor here, probably the dearest and often scarcest resource of an open source maintainer -- their time.
I suspect the author failed a little test when rejecting the other piece of kernel work... who needs someone who wants you to help them work on their problems but isn't willing to help you work on yours?
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.
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.
I am surprised and a bit sad at so many comments questioning the author
My first contribution to Emacs is a very similar experience as the author's. I took time to debug a long-standing issue in Emacs, I wrote a patch, I asked other users to test my patch, and I addressed comments on emacs-devel, but eventually it got completely rewritten by a maintainer without any credit for my efforts.
Bug discovered by Bob
Initial fix by Bob
Fix refactored by Chris
It was a bit discouraging, but I didn't feel robbed (since circumstances were different!) - and I realize it's difficult for maintainers to also find the time to onboard new contributors.
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'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...
On most of project deliveries we have gone back to only integration testing.
I think your main recourse is writing articles like this as there is nothing else.
Maybe next time try not to involve this particular OSS contributor?
Not everything in life is about getting a golden star in your grade book.
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
Not being able to accept that shows immaturity.
> Not everything in life is about getting a golden star in your grade book.
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).
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.
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.
* It wouldn't have hurt to give Ariel more credit with a `Co-Authored-By` instead of `Reported-By`, especially considering that the 'report' came with a working code fix. If this form of credit is outside the typical Linux commit authoring norms, then maybe this is a good motivation to adjust them.
* Ariel should have brought up the complaint about the Reported-By tag at the time instead of letting his frustration and disappointment fester for a year then writing a blog post about it.
* The "(paraphrased)" maintainer response to asking for more credit feels off, and the formatting of the blog post is badly misleading. I'd much prefer a direct quote than a paraphrasing for something like this, where it's important to have raw data for third parties (like everyone in this thread) to come to a valid judgement on this aspect.
* I can't tell if this was communicated in private or if the response is contained in one of the links mentioned in this thread. In general the whole timeline is rather difficult to follow which doesn't help.
Between this and the recent rust drama, I think we're running face first into the biggest issue of text-only communication mediums: it's really hard to communicate intent and feelings through text. You can dismiss that as silly human foibles, but the human shit actually matters. In person communication has such a higher bandwidth it's insane, and if we're going to continue pretending that we can replace it entirely with text, we will have to commit to a much higher level of transparency and candor than we'd feel comfortable with in person, else it will be harder than necessary to maintain community over the long run.
Both sides could have done better, but this level of attack is unwarranted for what happened and if Michael Ellerman is capable of seeing that they could have handled the situation better then I'd hope the OP has the insight that they too could have handled this better, for instance by communicating with the maintainer directly.
Your point about communications is well noted, I think a part of it stems from a combination of workload on the part of the maintainer(s) and unfamiliarity with the various processes and attitudes as well as the absence of even clearer rules on how kernel maintainers should deal with various levels of contributions.
Agreed completely.
> workload on the part of the maintainer(s) ... unfamiliarity with the various processes ... absence of even clearer rules
Yes these all contribute to the problem. The 'culture' of an open source project is basically opaque to a new contributor, no matter how "open" project's comms are a new contributor can't read them all. That's why it's unreasonable to expect them to be able to completely understand the rules, processes, and workloads that affect everyone involved in the environment where they are just making a new contribution.
Which is why embracing the messy humanity and going all in on radical candor is the best solution. The other option is giving every new contributor a 10M word reading list just to catch up on the context, which is so impractical it's hardly worth mentioning.
> On very rare occasion, you may see something completely different: another developer posts a different solution to your problem. At that point, chances are that one of the two patches will not be merged, and “mine was here first” is not considered to be a compelling technical argument. If somebody else’s patch displaces yours and gets into the mainline, there is really only one way to respond: be pleased that your problem got solved and get on with your work. Having one’s work shoved aside in this manner can be hurtful and discouraging, but the community will remember your reaction long after they have forgotten whose patch actually got merged.
I think that summarises it perfectly.
[1] https://www.kernel.org/doc/html/v4.17/process/6.Followthroug...
Is his version better? Presumably, it is in the kernel source now? It would be interesting to see them side by side.
If he just took your implementation, stuck his name on it and pushed it, that would clearly be an asshole move.
If he read your description, looked at your implementation and wrote a much better one, then that is beneficial for the codebase and Linux.
In which case proper credit was given.
Writing kernel code is hard. Very few people get their first contribution into the kernel. which sucks for the ego of someone making a contribution, but it makes the codebase better.
In a generous light, the maintainer recognized that you were interested in helping the kernel and he saw you had some talent, so he offered you a new task as a step to learn more and building your skills as a kernel developer.
He could have communicated it in a more verbose and polite manner for sure.
<message>
Reported-by: ...
Signed-off-by: ...
[<initials>: fixed a typo in the commit message]
Signed-off-by: <initials>
[<initials2>: fixed a leak, oh my!]
Signed-off-by: <initials2>
Assuming proper signoff attribution (DCO), it's absolutely possible to clean up a patch, note that in the commit message, and then either give the original author full authorship or give one of you a co-author status.
That seems like a more reasonable way to go if you don't have time to go multiple review rounds, trying to poke them towards the preferred solution.
For example, the only video of mine ever put on YouTube isn’t on my account, someone asked if they could post it. It got 10k views, I feel like that’s pretty good just for a little messing around, but I’m still glad it’s not tied to me.
The Linux kernel gets away with this because it's the biggest/most important software project in the world.
When I had a similar experience with another open source project, I lost the desire to ever contribute to that project again.
Not granting that, especially when it wasn’t a horribly buggy patch with a one line description, is really scummy of the maintainer and he should’ve known better.
Not that this comment addresses the author's unhappiness.
> I spent a lot of time and effort doing root cause analysis, fixing the bug, testing and validating the fix, getting feedback from other engineers at my company, adapting the fix to the latest kernel version, and sending two different patches to Michael Ellerman, the PowerPC maintainer.
Thank you for doing all the work for free. Meanwhile Michael Ellerman gets paid by IBM to use your work.
I hope now you understand an important thing about open source: if you're doing the work for free, you're an idiot.
Person did the hard work and figured out a kernel bug. Was related to memory handling, so sent it to security list. Big ego on security list truncated the reporter's troubleshooting, proof, and patch, and basically ignored the contributions to a 'they reported it' badge.
What's a little bit of empathy cost? The person wrote code that fixed the issue. Even if it wasn't accepted, it's still a reference patch.
And people wonder why FLOSS ecosystems, well, suck. 'reported and initially patched by __' costs nothing, and is a hell of a lot of good will. But nope.
If I do kernel sec patches like this, I'll just get a cool URL, a funny image, and publish it as an 0day. That way, I'll get credit AND a cve.
It's 100% unethical to take credit for someone else's work.
You encountered one jerk - there is undoubtedly many, many jerks working in that field.
not exactly encouraging
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.
Their assertion was that my 0day code was so poor they had to rewrite but it wasn't that significantly different. Yes, admittedly my ruby skill is poor, but the fundamental gist of the code was still there.
I expect they are to this day still distributing my 0day without any credit.
The maintainer probably should've been a little more generous with his attribution than just posting "reported by:" in the bug fix, but ultimately OP is just the guy who reported the bug not who fixed it. They aren't obligated to fix the bug the way some rando on the email thread wants it to be fixed because it's still their code. This isn't just the way open-source works, it's also the way most corporations work.
It's also perfectly normal for a bug report to contain an example fix because the reporter knows how to make it go away but not necessarily how to make it go away the "right" way so I can easily understand how the maintainer saw this as a "reported-by".
Calling them out on a blog post that you then submit to hackernews doesn't make you seem like a pleasant person to work with either.
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
If the OP, Ariel, did not do what they did, the kernel would not be fixed. Therefore, they contributed the fix.
FreeBSD, being a kernel commit, and having your name in it, you will be snatched up by various companies that use it, and not only puts a footnote that they do.
Example, Apple, Playstation, Juniper, Oracle, etc.
BSD pays off more.
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.
You think egos are big now...
> 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.
You don't know that.
There is nothing wrong with being motivated by getting credit.
And there is nothing wrong with fixing FOSS problems you're affected by.
The value of FOSS is fixing a problem once for everyone.
> this attitude doesn’t qualify for contributor status.
Since when was attitude a qualifier for contributor status?
Linus Torvalds himself had questionable attitude at times.
The simple fact is: He did contribute, he just didn't get credited.
How much would a
Co-authored-by: ...
The credit they deserves is identifying the issue - not for writing a patch that didn't pass the bar (especially on security-report where maintainer gives critical priority, speedy review, extra focus on correctness, etc.).
Had this been done on a non-security mailing list, their patch would probably have gotten in after a few iterations.
EDIT: The original reporter was credited as "reported-by" in the patch, so removed the section saying there should be a standard for that.
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.
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.
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.
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.
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.
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.
The developer could have accepted that allegedly inferior fix, give the credit, and patch it with their own version in a single commit. I'd have done that, for example, all the while trying to communicate with the submitter of the patch about my intentions.
Maybe he wanted the badge for his own honor, not to put it anywhere else. Some people are into that kind of thing, and he fixed a legitimate problem of his to earn this. I can understand them and respect them for that.
> No one asked you to do this.
Their work needed this. The company needed this to work better, and they deserve the credit for doing the work. This is not open for discussion in my opinion.
> You seem to have no interest in fixing other problems (which you were given an opportunity to do)
As I aforementioned, you need time to do this. It's not given that the author has free time to work on any problems they deem worthy. I'd love to fix tons of bugs, mine or not, but I can't do that because lack of time. Heck, I can't find an hour to finish implementing my own projects. How do we know that he has the whole day to do the research and fix other bugs?
My best oss contribution was done exactly like this. Someone else reviewed my code, made some changes, but my name was on the commits. I was happy that someone else took the time to make my code better and at the same time, keep my name on it.
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.
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.
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.
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.
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.
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.
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!
Based on what happened the first time, fixing other problems may have led to the same outcome again.
(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?
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.
So what ? These are two perfectly valid motivations. The only thing that matters really is that in the end it benefits everyone.
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.
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.
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.
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?
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.
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.
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.
Now I just fix my own copy and wish others luck doing likewise.
Makes me wonder if maybe funding github is part of Microsoft's long vision for the death of open source.
Perhaps in your haste to conclude that I am the problem you overlooked my mentioning github, which Microsoft owns. It is a website where, among other things, many open source projects are hosted.
If you replied to a comment by mistake then disregard.
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.
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.
"Sorry, I like my version better" is almost verbatim the same ripoff-kissoff I've gotten before in one specific circumstance in the past.
Get over it. Open source is like that. Count your blessings - most people would be happy if their worst experience would be only twice as bad as this.