by kkapelon on 9/27/23, 8:58 AM with 692 comments
by ohyes on 9/27/23, 1:59 PM
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.
by kazinator on 9/27/23, 2:55 PM
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.
by inglor on 9/27/23, 9:09 AM
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.
by superboum on 9/27/23, 1:09 PM
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...
by FridgeSeal on 9/27/23, 10:41 AM
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.
by micw on 9/27/23, 9:13 AM
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.
by jcalvinowens on 9/27/23, 6:21 PM
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...
by mhkhung on 9/27/23, 3:04 PM
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.
by JokerDan on 9/27/23, 1:07 PM
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.
by V__ on 9/27/23, 9:09 AM
What a great way to make sure someone will never help you again and disincentivize others from doing the same.
by noirscape on 9/27/23, 1:21 PM
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.
by hermannj314 on 9/27/23, 2:11 PM
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.
by ptico on 9/27/23, 9:53 AM
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
by jabradoodle on 9/27/23, 9:27 AM
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.
by underdeserver on 9/27/23, 9:10 AM
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.
by finnjohnsen2 on 9/27/23, 9:14 AM
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-...
by derangedHorse on 9/27/23, 12:09 PM
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.
by pm90 on 9/27/23, 9:14 AM
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.
by runxel on 9/27/23, 12:01 PM
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!"
by phil21 on 9/27/23, 4:20 PM
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!
by ebiggers on 9/27/23, 6:25 PM
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.
by ChrisMarshallNY on 9/27/23, 3:59 PM
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.
by jjgreen on 9/27/23, 9:07 AM
by 0xbadcafebee on 9/27/23, 1:17 PM
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)
by acatton on 9/27/23, 9:26 AM
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.
by gorjusborg on 9/27/23, 5:28 PM
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.
by tpoacher on 9/27/23, 3:05 PM
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.
by zoogeny on 9/27/23, 5:56 PM
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.
by firtoz on 9/27/23, 9:10 AM
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.
by jmull on 9/27/23, 3:54 PM
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?
by i_am_a_peasant on 9/27/23, 9:09 AM
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".
by blinkingled on 9/27/23, 9:41 AM
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.
by jdance on 9/27/23, 1:19 PM
I am surprised and a bit sad at so many comments questioning the author
by ariel-miculas on 9/27/23, 10:17 AM
by juxtapose on 9/27/23, 9:55 AM
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.
by bloopernova on 9/27/23, 2:31 PM
Bug discovered by Bob
Initial fix by Bob
Fix refactored by Chris
by andrelaszlo on 9/27/23, 3:28 PM
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.
by micw on 9/27/23, 9:15 AM
by bhouston on 9/27/23, 10:41 AM
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?
by tasubotadas on 9/27/23, 9:05 AM
Not everything in life is about getting a golden star in your grade book.
by infogulch on 9/27/23, 10:33 PM
* 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.
by oytis on 9/28/23, 10:16 AM
> 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...
by ThinkBeat on 9/27/23, 9:58 AM
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.
by avgcorrection on 9/27/23, 8:55 PM
<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.
by jamesu on 9/27/23, 9:30 AM
by ok123456 on 9/27/23, 2:43 PM
by the_biot on 9/27/23, 5:39 PM
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.
by jwildeboer on 9/27/23, 2:50 PM
by gumby on 9/27/23, 3:48 PM
Not that this comment addresses the author's unhappiness.
by alexeiz on 10/1/23, 2:57 AM
> 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.
by pierat on 9/27/23, 1:21 PM
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.
by smoothgrammer on 9/27/23, 2:09 PM
It's 100% unethical to take credit for someone else's work.
by andrewstuart on 9/27/23, 9:41 AM
You encountered one jerk - there is undoubtedly many, many jerks working in that field.
by zamadatix on 9/27/23, 9:52 PM
by bowsamic on 9/27/23, 9:34 AM
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.
by sacnoradhq on 9/28/23, 2:13 AM
by r053bud on 9/27/23, 4:58 PM
by lobocinza on 9/29/23, 3:27 AM
by incomingpain on 9/27/23, 11:33 AM
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.
by snickerbockers on 9/27/23, 3:10 PM
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.
by WalterBright on 9/27/23, 2:54 PM
by cranx on 9/27/23, 3:51 PM
by staticelf on 9/27/23, 9:22 AM
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.
by foooorsyth on 9/27/23, 3:21 PM
by tumetab1 on 10/3/23, 4:44 PM
by sevagh on 9/27/23, 5:16 PM
If the OP, Ariel, did not do what they did, the kernel would not be fixed. Therefore, they contributed the fix.
by JediPig on 9/27/23, 3:49 PM
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.
by ftxbro on 9/27/23, 4:25 PM
by lyind on 9/27/23, 9:23 AM
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.
by naikrovek on 9/27/23, 5:17 PM
You think egos are big now...
by shortcake27 on 9/27/23, 9:18 AM
> 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.
by RunSet on 9/27/23, 4:20 PM
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.
by oytis on 9/27/23, 9:32 AM
by barrkel on 9/27/23, 9:47 AM
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.
by arbitrage on 9/27/23, 1:43 PM
"Sorry, I like my version better" is almost verbatim the same ripoff-kissoff I've gotten before in one specific circumstance in the past.
by not_your_vase on 9/27/23, 9:58 AM
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.