[stupidcar]

As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Nor can you force your employer to negotiate a contract with the maintainer.

Don't get me wrong: I'm not arguing the maintainer has any responsibility to fix your issue. I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. Their choices are constrained by factors outside their control, and they are under pressure to deliver. It's this pressure that explains some of the frustration and anger that can bubble up in open source discussions.

I don't think there's an easy solution, but more empathy on all sides might be a start.

[hypfer]

> As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in.

Well y'know... you're kinda being paid for that. That literally is your job. You're given money to deal with that.

It is not a matter of "empathy" for a FOSS maintainer to do your job for you.

[ricardobeat]

I would like to know which universe everyone here lives in, where such scenario is a possibility. Let’s say you use Kubernetes. A transitive dependency that does DNS resolution in a built in module is doing something wrong, like not resolving hosts ending with the letter X. You can’t “refactor to remove the dependency”, you can’t realistically maintain a fork of the whole thing. This is what the majority of these situations look like. OSS is supposed to be a collaborative environment where everyone can contribute a little, not a “fuck you, pay me” environment.

[hampereddustbin]

If commanded, sure, but in many cases your job would actually be to communicate the changing environment to management so they may allocate more resources or pay the maintainer or whatever middleman company to upkeep the required software.

Silently trying to plow through problems of these magnitudes will cause the project to be late and still cost the same. It's bad for everyone

[keybored]

The hypothetical FOSS maintainer is giving a new meaning to “kill them with kindness” in this thread.

[swatcoder]

> frustration and anger

The root problem in your story is that your developer doesn’t feel like they can safely convey to their manager that the project has unexpected constraints. That form of intimidation happens, sure, but it’s not very nice to bring random strangers into the drama of your poor work environment.

If you have a shitty manager that you can’t communicate with, the maintainer doesn’t deserve to become the outlet for your frustration and anger, do they?

There’s a classic story of the workee coming home and taking out his work problems on his wife, who takes it out her marital problems on their kids, who take out their problems on the pets.

It’s meant to help you see that shuffling your problems on other people doesn’t solve problems and instead just makes other’s lives worse.

[BowBun]

Another take: Maybe many of us in software have enjoyed a long run of productivity driven by open source availability. That productivity is now baked into many software cultures (who doesn't assume they can use industry standard libraries, outside of very sensitive environments?) and an expected part of what programmers can do.

Imagine turning around 40 years in and telling business folks "Oh crap, actually we're only 20% as effective because we've been ignoring glaring security, maintainability, and social issues around FOSS that we've simultaneously benefited from for decades".

Feels like some golden handcuffs to me!

[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?

[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.

[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.

[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.

[sbuttgereit]

For the maintainer in the scenario it is precisely that simple. For the client developer sure, they might be in a tough spot not directly of their own making but their difficult position does not somehow convey any responsibility at all to the maintainer... not even a responsibility to be sympathetic, empathetic, or kind. Any action by a frustrated developer against the maintainers at this point, any harassment whatsoever, might be explainable by the developer's situation but would not be in any way justified by it.

The developer's problems are just not the maintainer's in any way and any attempt to harass the maintainers into being responsive would be unethical. Full stop.

[mpol]

In that case you could maintain a set of patches for upstream, instead of going for a full fork. You could document how much time you spend maintaining those patches and communicate that to your manager. If it is still cheaper to maintain that set of patches and not pay upstream, I guess that is a business decision that might financially work out.

[swiftcoder]

"paying upstream" is fine for little independent open-source projects, but for the big popular dependencies it doesn't actually work. You can't just pay Google to work on Android/Chrome, or pay Facebook to make changes to React...

[samsquire]

> and they are under pressure to deliver.

You're being paid to deliver and the maintainer is not. This is a critical fact. The maintainer did their bit, it's time to do yours.

> but more empathy on all sides might be a start.

More empathy for the _maintainers_ I think.

[ricardobeat]

> it’s time to do yours

And how is fixing a bug and submitting the patch not doing your part? This is what OSS is all about.

[blowski]

This all comes down to "no silver bullets" and "there are no solutions, only trade-offs".

You can have codebase x for free, but depending on future changes is risky, especially if it's close to your core. A larger team are likely to be more stable, but be less amenable to any specific changes you want. You can fork the code, or provide patches, but this adds extra complexity you'll need to manage.

[lallysingh]

Sounds like that developer inherited a problem at work and wants to make it someone else's problem. Solving those problems is part of their job.

[hampereddustbin]

This issue would be above the developer's paygrade.

It's not the developer's job to make requirements fit in the timeframe, that would be the manglement's job. If execs have made bad decisions with regards to the developer's input on what it's going to take, the problem is solely on them.

[gpvos]

That's a rather idealized view. In practice, management has more than enough ways to make it the developer's problem. Of course, that may mean it's time to leave.