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.
Once, I learned that someone wrote a "security patch" for another project that embeds mine. They focused solely on the part where their fuzzer caused a crash, they wrote a patch that, in their mind, fixes exactly the problem they found. But the patch made no sense - it added a check mid-loop for something which was an invariant. The actual wrongness was in an entirely different file, it was passing invalid initial values, and checks needed to go there instead. I fixed the issue in my project correctly, and in the changelog I gave credit to the original person for both discovering the security flaw and providing a patch... that I didn't use.
In another situation, I was using an emulator and it didn't read a file correctly. I read its source code for the first time, I fixed it, in what I thought was the right way. I supplied the bug report and the patch. The maintainer thanked me and fixed it a different way - a way that wasn't obvious from their code, but was a better fit.
In another situation, I found a library that sticks out like a sore thumb and doesn't accept values that other libraries do (the standard they're all aiming for says the value is "implementation defined" so this is technically allowed but it annoys me). I raised a bug. I offered a patch. The maintainer had a bug up his ass about this particular value and told me he was changing nothing. Not much I can do about that.
In conclusion:
FOSS maintainers aren't endless fonts of personal validation for you. Some of them don't even want contributors. They already gave you the software for free, _and_ the legal means to fix it yourself. You can patch it, you can fork it. Your fork might be better than theirs!
They might accept your bug report. They might review your patch. They might accept your patch. They might mentor in you how their project works. They might devote all their time to contribution management and never have time to write their own project. Each of these takes their time and energy. They don't owe you any of that. Not every project is a popularity contest, not every project wants your help. This is all OK.
It isn't sustainable, and it's a sign of bad leadership waiting for the proverbial (or literal) "hit by a truck" principle to show up.
You are correct in that it is the maintainers's choice. No doubt about it. But now, a potential contributor who invested a significant amount of time in a problem clearly nobody else had solved up to that point, was snubbed. The work was capitalized on, used as a foundation for a solution, and not even a comment giving credit was given.
This sends a terrible message not only to them, but to future contributors as well on a project that needs a new generation of talent to perpetuate it. This isn't just any OSS project; this is the Linux kernel, something millions if not billions rely on. Scale up this behavior, and it won't end well.
> It isn't sustainable, and it's a sign of bad leadership
It can be sustainable; not all FOSS projects need every possible contributor. Being a good leader is not a prerequisite, either. Direct cooperation isn’t even necessary!
The fact that source code is available allows anyone to fork and compete with the original authors. On average, only mismanaged projects will get out-competed by their forks.
You're making some poor comparisons to justify how things were done in this instance. What actually happened here is someone encountered a bug, they diagnosed the bug, they fixed the bug, they brought the bug up on a mailing list, they updated their fix, they submitted their fix. The maintainer changed 1 line of their fix from an #ifdef to a macro that has the same ultimate effect and then stuck their name on the fix.
Beyond the morality of doing this, there is a practical consideration of copyright issues. OP did that as part of his job. OP and his employer have some sort of agreement of ownership of these 30 lines of code and the maintainer putting his name on it and putting it into the kernel could someday be a problem.
That's a stupid approach to maintaining a project. A maintainer should want to make their project the best it can be, and the best way to do that is encouraging contributors to keep contributing. If they can't do that, their work deserves to die and yield way for better managed repos/forks.
I have a similar experience with a bug fix I submitted and the decision to delay my fix to literally change the whole architecture of the project left a bad taste in my mouth. After that I stopped contributing to the project and just kept my fixes to myself.
It's especially annoying when the maintainer asks for help and pulls this. Architecture changes after proposing small fixes to projects has been a somewhat common occurrence for me.
"just fine" is not what we aim for. "just fine" is probably what they thought of the OpenSSL library before heartbleed.
> Accepting drive-by patches carries an enormous cost. It’s very common to need to rewrite them substantially.
Sure but it sounds like you're making a generalization about a specific instance you know nothing about. There doesn't seem to be an enormous cost detailed by the maintainer in the email thread. Just that he'd rather gatekeep the project and rob someone of the opportunity for contribution.
Linux is doing more than “just fine” and is in no way similar to OpenSSL.
This individual wasn’t robbed of the opportunity for a contribution. He received credit for his contribution via a reported-by flag. It’s a tiny patch — all the work was in identifying the bug, which is what he received credit for.
He did something valuable, and has every right to write it up, but clearly has limited understanding of the development process he’s participating in. It was wildly inappropriate of him to of put anyone on blast in response to this.
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.