[pc86]

> I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies.

The whole point of this article is that these are your three options.

What are you saying the fourth option is? It sounds like you're just saying "yeah but this isn't good because (for example) nobody will merge my random bug fix into React core." That's sort of the point - your options then are #2 or #3.

[peteradio]

#4:

Integrate your patch+tests into your build process and don't bump on every external lib revision. Maybe that's basically forking, but what would be the issue with doing this for an OSS project dependency?

[jacobr1]

Yes - this is the answer (if you can't work with upstream). There are many variants to this: monkey-patching, vendoring (local fork), micro-libs that replace a subset of functionality, wrapper libs, etc ...

[civil_engineer]

Yes. This is the happy path. But also submit the patch, of course!

[lanstin]

This is what I do. Sometimes maintainers eventually fix it and sometimes they don't. i am happy when they do of course, but work is fine either way.

Of course i make it a point myself to view each dependency as a significant cost and to work seriously to minimize them. I used to version pin or vendor in the deps, and then subscribe to the security announce DL for all deps, and avoid insane things like npm or mvn, but that has become more difficult and having a conmercial dep scanning service in your CI makes mvn or npm safe enough, but it remains true that code dependencies are a long term cost. for personal stuff, i would rather take OSS code I find and take the few hours it takes to modify it into my standards, leaving attribition, assuming the license allows of course. copy, modify and recombine.

[chris_wot]

The LibreOffice project in effect does this in a number of libraries.

[chris_wot]

If a bug fix with test coverage sits in a queue for years, just because the maintainer is an arsehole, then a bit of mild criticism should probably be expected.

Consider it a fixed fork fuck you.

[pc86]

The "just because the maintainer is an arsehole" thing is the question here. How many times is it really just because the maintainer doesn't like the person who submitted it, or they just laugh to themselves and want to see how angry people get? I'd venture a guess to say almost never.

The issue becomes when folks assume it's just the maintainer being a jerk rather than any number of completely valid reasons, which could be anything from "PRs from employees and core contributors are prioritized and we can barely handle those as it is" to whole way to "I don't think this feature fits in with my larger vision for the project."

It is almost never "just because the maintainer is an arsehole."

[chris_wot]

There could never, ever be an Ulrich Drepper who maintained a project the size and importance of glibc in any project, ever.

[chrisseaton]

> then a bit of mild criticism should probably be expected

No they’ve every right to ignore your PRs for any reason or no reason at all. You aren’t paying them.

You can ask them to merge but you’ve got no basis to criticise them because they never promised you anything.

[chris_wot]

In that case, I guess forking the project to fix it whilst criticising them is disallowed?

[chrisseaton]

Can I ask you to send me $100 and then criticise you when you don’t? Or is that an unreasonable criticism since why on earth should you send me any money?

[imtringued]

It is the opposite, the submitter sends a patch aka $100 and then the maintainer rejects the money/patch.

[chris_wot]

That’s not unreasonable, if I used your work or wanted a change.

[chrisseaton]

But it's the other way around - why would you pay someone who was also using your work for free?

[chernevik]

The point of the comment is that "fix it" isn't an option when the maintainers won't even look at your bug fix.

I'm VERY appreciative of FOSS but it does seem that if you are going to maintain a project then it isn't unreasonable to expect that you'll at least consider a PR, and give some reason if you choose to reject it.

[peteradio]

Not to saturate this thread with my varying opinions, but default rejection with reasoning of stability could be assumed. Anyone who has worked in code long enough knows seemingly obvious changes can have unintended consequences. If a company is making money off my FOSS code then maybe they can test their fixes for an eternity before I incorporate it and it potentially breaks some other companies code.

[tpoacher]

Just because it's the whole point of the article doesn't make it true.

In the corporate context of the particular person you're replying to (rather than the general case of an isolated disgruntled user), there are infinitely many options. The above are just the ones 'desired' by the author in their ideal world. Perhaps this could be the unwritten 4th F: "Fight dirty".

You could, for instance, go down the litigation route until shit falls your way. Or pay random shills to post articles twice a week on how React isn't what it used to be because of this bug. You could convince the twittersphere that this particular bugfix is offensive and should be hashtagged. You could pay people to spam their github with issues that are effectively that bug and waste enough developer time until they decide that not fixing that bug is costing them more time than it does to fix it.

If your company C-team feels this is simply a matter of economics and happy to pay the 'cost', these are totally valid options.

And while the author of this blog does have a point and I sympathize, they'd better be prepared to face the consequences of resorting to the 3rd F too quickly when they do. The world is not all peaches and roses out there.

[zaphar]

Anyone who chooses option 4 has a high chance of becoming a pariah. It is also equivalent to option #3 for the author. He's just going to ignore you and his projects are probably going to ignore you. The only person option #4 hurts is you.

The correct thing for any reasonable engineer to do is transparently communicate the impact of those previous decisions to their management. The framework/library/system we chose no longer supports our needs in this instance. We can either workaround it, maintain a fork of it, or replace it. The costs of doing each of these is X. What do you want to do.

Fighting dirty is unlikely to accomplish getting your feature out the door.

[shadowgovt]

Any company that embraces option four should consider that the door swings both ways. Convince the developer providing the free service that it's not worth their time and you have bought yourself a free ticket to becoming the new maintainer or becoming content with your product being based on a rotting dependency.

Option 5, "find cash to pay for maintenance," is a much better option than option four for a corporation to consider.