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.
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.
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.
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.
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?
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.
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.
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!
It would be pretty bad if he said that, but he never did.
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.
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.
I think it would be odd to disbelieve the author.
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.
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.
If the rate of submissions falls then it certainly makes sense to adjust. Until then, don't fix what isn't broken.
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.
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.
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.