[fsdjkflsjfsoij]

A lot of these maintainers are already overworked and don't have time to tutor every single person that wants to put kernel contributor on their resume. A lot of people have this extremely idealistic view of open source but the reality is that the vast majority of patches you receive will be atrocious and you shouldn't have to tutor every single "potential" contributor. This case is even worse since this issue was posted to a security mailing list which means time to resolution is important.

[caconym_]

> A lot of these maintainers are already overworked and don't have time to tutor every single person that wants to put kernel contributor on their resume.

This seems like a very cynical view of what happened here, and completely unfounded.

Obviously these big open-source projects need gatekeepers, but if the gatekeepers often make aspiring contributors feel violated and humiliated rather than offering feedback to get their initial contributions across the finish line, general interest and enthusiasm for contributing are going to dry up. Maybe that's by design, but it doesn't feel sustainable in the long term.

[hnfong]

It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating.

Talking about utilitarian consequences, Linus had been way worse and while I fully agree from a moral perspective that his most extreme behaviors were bad, from a purely utilitarian perspective that didn't prevent Linux from being one of the most successful OSS projects out there.

[caconym_]

> It would be quite sad if we've gotten to a point where saying "I think my patch is better than yours" from a domain expert to a newbie is considered humiliating and violating.

Isn't this a little bit disingenuous? Do you really think the author of OP's blog post is upset simply because a Linux kernel maintainer has far more domain expertise than him and is in principle capable of writing a "better" patch?

That would be pretty irrational, I agree!

[zassy]

The real disingenuous part is where OP lied about the maintainer saying his patch was better.

It would be pretty bad if he said that, but he never did.

[caconym_]

I agree that Miculas (the submitter of the original patch) should not have chosen formatting typically associated with direct quotations, but now you're the one putting words in his mouth: he didn't say Ellerman said his (Ellerman's) version was better, he (Miculas) said Ellerman said he liked his (Ellerman's) version better.

Ellerman's actual words were "I wanted to fix it differently", so while I don't think Miculas' paraphrasing was entirely appropriate (why paraphrase at all?), I also don't think it was a misrepresentation of what Ellerman actually said.

[jacquesm]

Besides the fact that he didn't actually say that at all.

[kazinator]

Because it could be seen as communicating: "my ten minutes of coding around the array access problem is more perfect than your hours of investigation to root cause the issue plus your ten minutes of coding".

[fsdjkflsjfsoij]

> feel violated and humiliated

A lot of contributors are going to feel like this if their patch doesn't get accepted immediately and the maintainer in this case was extremely respectful even though the offered patch had multiple major issues. Contributors shouldn't feel entitled to free tutoring.

[caconym_]

> multiple major issues

Seems debatable and debated, reading through the rest of this thread.

Regardless, I'll reiterate my point more straightforwardly: it's the maintainers' prerogative to treat aspiring contributors however they like, but actions have consequences, and some of those consequences may be deleterious to a project's health.

[fsdjkflsjfsoij]

> Seems debatable and debated, reading through the rest of this thread.

Most of the people commenting in this thread haven't looked at the code and anyone saying the two patches are equivalent can be safely ignored. Out of the issues kazinator pointed out, 1 and 2 are definitely major issues and 3 is debatable although it is definitely suboptimal.

> some of those consequences may be deleterious to a project's health

Of course, but I think it might not be in the way the "everyone can be a valued contributor" crowd thinks.

[ariel-miculas]

See https://news.ycombinator.com/item?id=37692883

[caconym_]

> the "everyone can be a valued contributor" crowd

Of course! Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay, if not those whose merit has already been proven?

[fsdjkflsjfsoij]

> Who will keep the hordes of dimwits and dilettantes and LinkedIn jockeys at bay

This is unironically a very serious problem and why most of the best open source projects are basically corporate FAANG projects that are really only open source for optics.

[xw3099]

> Maybe that's by design, but it doesn't feel sustainable in the long term.

That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version...

One might also consider the rarity of maintainers who can write high quality code and donate large amounts of time. To find and retain someone like that one might also be required to allow them to be curt with random people on the internet from time to time. I can see how drive by contributions could get old fast from their point of view.

[caconym_]

> That could be, but on the other hand, the Linux kernel is more than 30 years old and is on its 6th version...

Indeed, and while we're speaking in broad generalities, surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term...

> I can see how drive by contributions could get old fast from their point of view.

Indeed. But (again addressing generalities) my issue here is that the contribution in question doesn't read as "drive by" to me.

[xw3099]

> surely no strategy that worked to launch a project from tiny seed to maturity and market saturation has ever then failed to keep it relevant in the long term...

If the rate of submissions falls then it certainly makes sense to adjust. Until then, don't fix what isn't broken.

[caconym_]

Frankly, if you treat effortful but green contributors the same way you treat grindset morons and LinkedIn jockeys, I would put money on the submission rate from the latter continuing to increase long after most of the former have decided your project isn't worth their time.

This is a bit of a moot point, though, since I don't think it's very common for Linux kernel maintainers to behave this way. Correct me if I'm wrong.

[that_guy_iain]

> This seems like a very cynical view of what happened here, and completely unfounded.

It is not unfounded at all. The author clearly stated the reason they wanted their commit to be accepted was should they could be contributor.

[caconym_]

Do you think there is any reason somebody might want to be credited for work they did other than having the ability to put it on their resume?

[that_guy_iain]

He had the credit amongst those who were paying attention. It wasn't like this was done in secret. Others chimed in to agree that the maintainers commit was better. So the only credit he didn't get was a commit credit which is important to be a "Linux Contributor" which clearly explictly wrote was the reason they asked for their commit to be used or to work on another patch.

I think it would be odd to disbelieve the author.

[a_t48]

On the other hand, to dig yourself out of the hole of “I’m too busy and there’s nobody around to help”, you have to slow down and do this, sometimes.

[bhouston]

> to dig yourself out of the hole of “I’m too busy and there’s nobody around to help”, you have to slow down and do this

Exactly! If you treat new contributors as crap because you are overworked, you will push away potential long-term collaborators who could share the load thus ensuring you will be working alone far into the future. This is a failure state and if I had a manager doing that to those he was managing, he wouldn't be a manager for long.

[ChildOfEru]

Who knows how long this would have been unaddressed without Ariel Miculas initial input.

Part of the job of a maintainer is to curate and foster input so the project has a robust community in the future.

The maintainer in this case did a miserable job of that.